Agent identity

Three patterns, and the question they each answer differently.

When an agent calls a tool — say, "create a refund" — three identities could be on the resulting request, and the choice shapes every authorization decision the downstream system makes:

• Service account (agent's own identity). The agent authenticates as itself; the downstream tool sees the request as "from the agent." Authorization is decided against the agent's permissions, not the user's. Simplest model; loses per-user scoping entirely.
• On-behalf-of (OBO, impersonating the user with a delegated token). The agent acts with a token derived from the user's session — typically short-lived, narrowly-scoped, audience-bound. The downstream tool sees the request as "from this user, via this agent." Per-user authorization is preserved.
• Hybrid (agent identity on the wire, both principals in the audit metadata). The transport-level credential is the agent's; the request carries claims for both the agent and the human user. Authorization can be configured to require both ("the agent is authorized for this tool AND the user is authorized for this data"); the audit log always records both.

None of these is universally right. The choice is a function of who legitimately should be authorized for what, and how much blast radius you can tolerate if the agent is compromised.

The trade-offs, side by side.

Each pattern protects one property and risks another. The honest version of the trade-off:

• Service account — simplest to implement, easiest to operate. The risk: every user effectively gets the union of permissions the agent has; a user who is not authorized to delete records is now talking to an agent that is. Compromise of the agent's credential means full access at the agent's scope, with no per-user firewall.
• OBO — preserves per-user authorization, keeps the principle of least privilege at the human boundary. The risk: the agent has to be trusted with delegated tokens that are real user credentials at scope; a prompt-injected agent is now a prompt-injected actor wielding many users' authority in sequence. Token lifetime and scope are the only thing standing between an injection and a mass-impersonation event.
• Hybrid — best audit properties; supports policies like "the agent may only call this tool when the user is also authorized for the target resource." More moving parts to implement and operate; downstream tools have to know how to read both principals.

The rule of thumb: low-stakes, internal-only, no per-user scoping needed → service account. Per-user authorization required, agent is trusted enough → OBO with aggressive token hygiene. Regulated or high-stakes, audit duty is heavy, multi-principal policy is realistic → hybrid.

Audit consequences: the log cannot answer "who did this?" if you got this wrong.

The audit consequences are not abstract. The audit-trails material asks the system to reconstruct any decision; identity is the part of the trail without which "who" is just unanswerable. The specific failure modes you trade for the simplification of a service-account-only model:

• Attribution collapse. Every tool call in the log is "from the agent." Asked which user caused which side effect, you can only correlate via run-id back to the prompt — and only if your tracing pipeline kept that link intact across asynchronous fan-out.
• Authorization-decision blindness. Downstream systems made authorization decisions against the agent's permissions, not the user's. A privacy review six months later asking "was user X authorized to see Y" cannot be answered from the audit log alone.
• Regulatory exposure. Finance, healthcare, and legal use cases — the ones covered in their Playbooks — typically have legal duties on traceable, per-user attribution. A service-account-only design that ships into those domains is shipping with an audit gap regulators will eventually find.

Implementation patterns that work in practice.

The hybrid pattern is more common in serious deployments than the textbooks suggest, partly because it composes the simplicity of service-account transport with the audit completeness of OBO. The implementation primitives that hold up:

• Short-lived OBO tokens. When OBO is used, the delegated token's lifetime is measured in minutes, scope is per-action, and re-derivation happens for each tool call rather than once per session. The pattern is built on top of an authorization layer that sits between the agent and the tool, not implemented inside the agent.
• Action-scoped delegation. The user does not delegate "everything you can do" to the agent; the user authorizes a specific class of action ("refund up to $50 on orders you placed"), and the OBO token's scope reflects that class.
• Two-principal audit metadata always. Even under a pure service-account model, the audit record carries both the agent identity (who acted) and the human user (on whose behalf), as separate fields. Future-proofs the audit trail against the regulatory question even before you change the authorization model.
• Joinable to traces. The identity recorded on each tool call is joinable by run_id to the trace in tracing-and-observability; the audit answer and the behavioral answer come from the same record.

The anti-pattern: the "robot user" with a real human account.

The tempting shortcut, especially under deadline, is to provision a literal user account — call it agent-bot — and let the agent log into downstream systems with it like a person. It works in the demo; it explodes in production. The damage:

• The audit log lies. Every downstream action is attributed to a user that is not a person; the log carries no information about which human user the agent was actually acting for.
• Permissions sprawl. The robot user accumulates the union of every permission anyone ever needed the agent to use; it becomes the highest-privileged account on the system, with no human accountable for it.
• Credentials sit in too many places. The password or token for agent-bot is now a secret that lives in every agent worker, every staging environment, every developer's machine. Compromise of any of those is compromise of all of it.
• Compliance failure. Most regulated domains forbid this explicitly: a "user account" must correspond to a natural person, and shared user accounts violate identity-management requirements baked into HIPAA, PCI-DSS, SOC 2, and most internal control frameworks.