We stopped sharing agent logins, and the fix was a smaller credential, not a bigger one

The stale snapshot point is the one I'd underline. Handing an agent a pasted brief feels fine until someone trims the scope in a comment and the agent finishes the old version, cheerfully, with nothing flagging that it read a copy that no longer matches. Read-scoped context the agent can refresh fixes that far better than a one-time paste.

The bit we got wrong early was treating expiry as optional. Long-lived tokens sitting around "just in case" are the ones that leak. Days, not months, and revoke at the team level rather than chasing individual connections.

And the who-prepared vs who-ran split isn't just an audit nicety. When a change turns out wrong, that's the difference between asking "was my brief off" and "did the agent go off track". Collapse them into one shared login and you can't answer either.

The 'who prepared vs who ran it' collapse is the real cost. We run our whole marketing/ops stack (Stripe, hosting, domain providers) on a rule now: never reuse another project's account or a shared login for a new one, even when it would save 10 minutes, because the moment two things share a credential you lose the ability to answer 'which project is actually responsible for this action' later. Also learned the hard way to treat any pasted API key as already compromised the second it lands in a chat log, not just a leaked-to-the-internet one - roll it immediately rather than trusting the channel it arrived through. Your fourth axis (revocable at the team level without deleting individual connections) is the one most tools skip; most let you revoke a person but not a task-scoped grant independent of the person.

The stale snapshot failure mode is the one that bit us too. An agent confidently finishing yesterday's version of the task, with nothing in the system flagging that the scope moved. We ended up with scoped read tokens per task as well, but expiry is still a manual cleanup job for us. Team-level revoke is the part I haven't built. Did you wire expiry into the claim itself, or is there a separate scheduler reaping them?

The distinction between “who prepared this” and “who ran this” is really interesting.

One thing I kept thinking about while reading this: revoking access solves what the agent can fetch next, but not what it has already fetched.

Do you also log which resource version the agent actually read, or only the actions it later performed? It seems useful to be able to reconstruct not just who ran something, but what context they were operating on.

Scoping per task, yes, and I'd add a fifth axis: proving the scope is what you think it is. There is no observer on "read-only". Any read-shaped probe passes whether or not the write bit is there, so an over-granted token fails when it's used, not when it's minted, and it looks like a broken agent.

What works is invoking a write endpoint in a form whose payload must fail validation, since authorization runs first. On GitHub, asking to create a ref that already exists returns 403 for read scope and 422 for write, and nothing is written either way. Most trackers have an equivalent.

Does your mint step assert the scope it asked for, or trust the response?

We solved this less with credential scoping and more with a hard rule: one teammate never runs two jobs at once. Each of my AI teammates has one identity, and if a second job comes in for someone already working, it queues behind their current one instead of running in parallel — we learned that the hard way after two parallel copies of the same "teammate" once overwrote each other's edits on the same page. So the accountability question for us isn't just which credential ran it, it's making sure only one instance of a given identity is ever acting at a time.

We solved this less with credential scoping and more with a hard rule: one teammate never runs two jobs at once. Each of my AI teammates has one identity, and if a second job comes in for someone already working, it queues behind their current one instead of running in parallel — we learned that the hard way after two parallel copies of the same "teammate" once overwrote each other's edits on the same page. So the accountability question for us isn't just which credential ran it, it's making sure only one instance of a given identity is ever acting at a time.

This is the invisible measurement boundary in multi-agent systems: "who prepared this" vs "who ran this" - and why collapsing them into a shared credential breaks debugging.

The security win is obvious. But the better win you named is the measurement one: shared logins make causality invisible. If something goes wrong, you can't distinguish preparation failures from execution failures. The logs don't record two facts; they record one collapsed fact. You lose the ability to measure where the error actually originated.

Scope-per-task credentials keep measurement boundaries intact. "Who prepared the task" and "who executed it" stay separable. "Is the problem my context, or is it the agent's execution?" becomes answerable because the measurements stayed distinct.

Most teams don't notice this until they have an incident and realize they can't answer "who should I ask about this?" The credential design decided that for you already - it forced the answer to be "whoever the shared login belongs to." Narrower credentials give the measurement system (and the team) more room to learn.

The line that matters most here isn't the security fix, it's that shared logins collapse who prepared the work and who ran it into one identity, and once that happens you can't audit your own process. I watched this exact failure mode with MSP clients handing service accounts to automation tools for two decades, the tool works fine until something breaks and nobody can say who authorized what. Scoping the credential to the task instead of the person is the right instinct, most teams only get there after the incident that forces it.

The biggest win you named — who prepared vs who ran stays two facts — is the only reason I can debug my own process. I keep write access scoped to one claimed task at a time so a second session cannot silently finish the previous version of the work. Moving the task forward is a separate, separately authorized step from reading it. I do not give either session a live payments credential.

A shared login would collapse those two names into one, and I would not be able to answer who to ask when a change is wrong. The four-axis split (read-only, one claim, short-lived, revocable) is the pattern. I am not using your tool for it.

The separation between “who prepared this” and “who actually ran it” is the part that really stands out.

Once you preserve that identity chain, there’s another interesting question: can you prove the resulting agent behaviour was actually correct — not just attributable?

For example, after a handoff, do you ever independently replay or sample completed runs to test whether the agent stayed inside the task boundary, used the current context, respected the scoped capability, and returned enough evidence to justify marking the work complete?

That’s the layer I’ve been exploring with OpsWatch — independent verification of what agents actually did against what they were supposed to do.

Wagglet’s scoped credential + attribution model feels like a very natural evidence layer underneath that.

This is a really good point, especially the distinction between the person who prepared the work and the person who actually ran the agent. Shared credentials make that almost impossible to track properly.

I also like the idea of making the credential task-scoped and read-only by default. It solves two problems at once: the agent can always pull the latest context, while its permissions remain limited to the specific task. Separating context access from actions like transitioning or delivering work seems like a much safer model for multi-person agent workflows.

The accountability point is interesting. Shared access can make an automated action traceable technically while still making it unclear who actually owned the decision.

Curious whether that distinction became more important as the number of people using agents increased.