Agent Identity Propagation
Agent identity propagation is the practice of carrying a distinct, verifiable identity for each AI agent through every call it makes — to models, tools and downstream systems — so every action is attributable to one approved agent rather than to a shared service account or a human's credentials.
What agent identity propagation means
When agents share a service account, accountability dissolves: logs say "svc-automation did something," nobody can say which agent, and revoking one misbehaving agent means revoking all of them. Identity propagation fixes this at the infrastructure layer: each agent registers with its own identity (issued from your existing IdP), its calls to models and tools carry that identity, and downstream systems see the agent — not a proxy — in their logs. Two refinements complete the picture: on-behalf-of semantics, where an agent acting for a user carries both identities so the target system can apply the *narrower* of the two permission sets; and token capping, where an agent calling another agent receives a token scoped to the caller's rights, so authority never silently widens across a chain. Identity propagation is the first control layer because everything else — scoped credentials, approvals, evidence, kill switches — attaches to it. You cannot gate or audit an action you cannot attribute.
Frequently asked questions
Why can't agents share a service account?
Attribution and containment both fail. Logs cannot distinguish which agent acted, approvals cannot attach to a specific agent, and stopping one agent means stopping all of them. A shared account also lets one agent's compromise become every agent's permissions.
What happens to identity when one agent calls another?
The caller's token should be capped to the caller's rights: the downstream agent can do only what the calling agent was allowed to do. Authority never widens silently across an agent chain, and both identities appear in the record.