We stopped sharing agent logins, and the fix was a smaller credential, not a bigger one
Short version of something that cost us a few weeks.
When we started handing prepared tasks to teammates who run their own coding agent, the agent needed the task context. The two obvious ways to give it were both bad:
-
Paste the brief into the chat. That is a snapshot. Somebody narrows the scope in a comment ten minutes later and the agent confidently finishes the previous version of the task. Nothing in the system can tell you it was reading a stale copy.
-
Give the agent live access with a normal workspace token. Now a process that generates text can transition, comment on, or delete anything, forever, and every action lands in the audit log under whoever minted the token.
What actually worked was a credential that is narrower on four axes at once:
- read-only, with no ability to deliver or transition anything
- rooted at one claim on one task, enforced server-side rather than requested in the prompt
- expiring in days, not months
- revocable at the team level immediately, without deleting individual connections
The agent can refresh the permitted current context, so the staleness problem goes away, but the starting capability cannot change the task. Moving the task forward is a separate, separately authorized step.
The part I did not expect: the biggest win was not security. It was that "who prepared this" and "who ran this" stayed two different facts. A shared login collapses them into one name, and after that you cannot answer basic questions about your own process - like who to ask when a change turns out to be wrong.
Full disclosure, we build this into a product, so weigh the plug accordingly: https://wagglet.com/how-it-works, and the MCP side is documented at https://wagglet.com/docs/mcp. But none of the pattern needs our tool. With any tracker you can mint a token per task instead of per person, keep it read-scoped, enforce the resource id server-side, and log the human runner as the actor for anything the agent causes.
Curious what other people are doing here. If you hand work to agents across more than one person, are you scoping credentials per task, or is everyone still passing one key around?
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.