Agents are principals: delegate, never impersonate

TL;DR

When software acts on a person’s behalf, there are two ways to wire it. Impersonation: hand it the person’s credential and let every downstream system believe it is the person. Delegation: give it its own identity, grant it a scoped slice of the person’s authority, and record both names on everything it does. Choose delegation, every time:

• Agents get their own identities and credentials. Never a copy of a user’s session, token, or key — an agent is a principal, not a disguise.
• Delegation is a first-class grant: explicit, scoped, time-bounded, revocable — and both the grant and every use of it are on the record.
• Every audit record of a delegated action names two parties: the actor (the agent) and the principal (the human it acted for). An audit record with one name is the bug.

The test: six months from now, can you tell whether the human or their agent did it? If not, you built impersonation.

Context

The expedient path is always impersonation. The agent needs to act as the user, the user already has a cookie, a token, an API key — so the agent gets a copy. It works on day one, because every downstream system already accepts the user. That’s exactly the problem: it works by making the agent indistinguishable from the person.

What that destroys, quietly:

• Attribution. Every action the agent takes is recorded as the human’s. When an agent misbehaves — bad prompt, bad tool call, compromise — the forensic question “which of these actions were actually yours?” has no answer in the data. You’re reconstructing from timing and vibes.
• Scope. The credential carries the user’s entire authority. The agent that was supposed to triage email can also wire money, because the token doesn’t know the difference.
• Revocation. The only off switch is the user’s own credential. Killing a misbehaving agent means rotating the human’s keys and breaking every other thing that depended on them.
• Accountability across parties. Downstream systems can’t apply different limits, rates, or policies to the agent, because they can’t see it.

None of this is new. RFC 8693RFC 8693 — OAuth 2.0 Token ExchangeDefines token exchange including the 'act' (actor) claim, and draws exactly this distinction: in impersonation the original party becomes invisible, while in delegation the token carries both the principal and the actor — including chained actors — so every hop stays attributable.rfc-editor.org ↗ draws the impersonation/delegation line precisely and gives delegation an act claim so chained actors stay visible; sudo has logged both uids for decades; Kerberos grew constrained delegation because unconstrained was a disaster. The art is settled. It’s just being skipped in the agent gold rush, one pasted API key at a time — and the number of agents per human is about to go from one to dozens.

Recommendation

Make every agent a principal. Each agent — and each instance of it, if they run in different trust domains — gets its own identity and its own credential, provisioned and rotated like any workload identity (ZFN-5). Sign or authenticate its requests as itself (ZFN-7), never as its user.

Model “on behalf of” as an explicit grant. A delegation is created by a deliberate user action, and it is:

• Scoped — a named subset of the user’s authority. The agent gets capabilities for its task, not the account.
• Time-bounded — it expires on its own. Standing delegations are renewed, not eternal; an abandoned agent’s authority should age out like an unrenewed lease.
• Revocable in isolation — killing one delegation touches neither the user’s credentials nor the agent’s other grants.
• Recorded — the grant, each use, the expiry or revocation: all on the record.

Record actor and principal together. Every action taken under delegation carries both identities, end to end — in the audit log, in downstream authorization decisions, in what humans see (“agent X, on behalf of Y”). If sub-agents re-delegate, the chain is explicit and recorded, exactly the shape of RFC 8693’s chained act claims.

Refuse ambient authority. The agent must not acquire the user’s power by running in the user’s environment — inheriting their cookies, their environment variables, their cloud role. That’s the confused deputyThe Confused Deputy — Norman Hardy (1988)The classic paper on what goes wrong when a program wields ambient authority it inherited from its environment rather than authority explicitly granted for the task — the failure mode shared by every agent that 'just uses' its user's credentials.css.csail.mit.edu ↗ with a chat interface (ZFN-10 is the same principle at the cloud-resource layer). Authority arrives through the delegation, or it doesn’t arrive.

Keep the content rule too. This note is the identity-layer half of a pair: ZFN-26 says a human must be able to back what’s published under their name; this one says the system must always know which one of them acted. Both collapse if the agent simply is the user.

Consequences

Easier:

• “Who did this?” is a query, not an investigation. Actor and principal are columns.
• A misbehaving or compromised agent is revoked surgically; the human keeps working.
• Least privilege becomes real: delegations carry task-sized scopes, and downstream systems can rate-limit, monitor, and police agents as the distinct callers they are.
• Incident reviews and compliance audits stop arguing about whether the human was at the keyboard.

Harder:

• Every downstream surface has to learn two-party identity — authorize on the pair, display the pair. Systems that only know “a user token” need adapters or upgrades.
• Delegation needs product surface: grant flows, scope pickers, expiry defaults, a place to see and revoke what you’ve delegated. Skipping that UX is how teams end up back at “paste your API key.”
• Agents need real credential infrastructure — issuance, rotation, storage (ZFN-5) — which is more work than copying a token, on day one.

New obligations:

• The audit schema carries actor and principal (and the delegation that linked them) on every delegated action; one-name records are rejected, not tolerated.
• Delegation lifecycle is operated: expiries monitored, dormant grants reaped, revocation tested.

References

• RFC 8693 — OAuth 2.0 Token Exchange — the impersonation-vs-delegation distinction, and act claims for visible actor chains.
• Norman Hardy — The Confused Deputy (1988) — ambient authority is the root failure; explicit grants are the cure.
• ZFN-5 — the workload-identity platform agents should be provisioned from.
• ZFN-7 — agents authenticate as themselves, per message.
• ZFN-10 — the same no-ambient-authority principle at the cloud-resource layer.
• ZFN-26 — the content-layer companion: a human who can back the words; this note keeps the identities separable underneath.

Changelog

• 2026-06-12: First published as a Field Note.