One of the quiet assumptions that breaks first when agents move from demos to production is that the agent should run as the human user.

It feels natural: the human opened the laptop, the human owns the repo, the human has the API key. Why give the agent its own credentials? Why route its traffic through its own session? Why log its actions separately?

The answer is the same in every incident we have seen locally: the agent and the human have different risk profiles, different lifetimes, and different blast radii. Reusing the human's session collapses those differences and makes the audit trail unusable.

Three failure modes that show up fast.

1. Scope creep is invisible when the agent inherits the user's OAuth token. A local coding agent asked to open a small PR inherits every scope the human's GitHub or Google session has. A pull request turns into a repo write, a repo write turns into an org-level action, and none of it shows up as the agent. It shows up as the user, at 3am, from an unfamiliar IP. If the agent had its own session with a scoped token, the scope ceiling would have been visible at the point of request, not after the fact.

2. Revocation is impossible. If you discover the agent did something wrong, you have two choices: rotate every credential the human uses (which logs them out of their browser, their email, their cloud console), or leave the credential in place because the human needs to keep working. Neither is good. A separate agent identity can be revoked without touching the human, and the rotation event itself becomes a receipt.

3. Receipts collapse into noise. When the agent's MCP calls, browser navigations, and shell commands are mixed into the human's session log, the log stops being a usable operator artifact. A reviewer cannot answer what did the agent do in run 42, because the run is interleaved with the human's own actions, and vice versa. A separate session gives every run its own contiguous trail, and that trail is the unit of accountability.

The pattern we keep landing on is the same one we wrote up in the local-control-plane posts: give the agent its own credential, its own scope object, its own session identity, and its own receipt stream. The human's session stays clean and revocable; the agent's session is the unit of audit and the unit of revocation. They meet at a small, explicit boundary, usually the tool call, where policy, scope, and approval decisions are made.

A practical starting point if you are not ready to fork credentials yet: at least give the agent a separate user profile in your browser, a separate service-account key for any cloud API it touches, and a separate log stream keyed to the agent run id. The blast radius drops immediately, and the audit trail becomes usable for the first time.

The interesting design question we are still iterating on is where the identity boundary lives for multi-agent runs. When an orchestrator spawns sub-agents, do you mint a new session per sub-agent, or do you keep one session and tag actions with the sub-agent id? We are leaning toward per-sub-agent session for anything that touches a tool, and a shared session only for the orchestrator's own planning loop. Curious what others are doing.

Disclosure: this post is from Armorer Labs, the team building Armorer (a local control plane for AI agents) and Armorer Guard (a Rust scanner that runs policy at the tool-call boundary). The patterns above are what we use internally for our own agent runs.