Give an AI agent its own admin token to another system and you've created a confused deputy: it can do anything, attributed to no one. We hit this connecting TITO's CRM agent to our CRM over MCP, and the fix is a pattern worth stealing — delegated identity in a trusted subsystem.
Two layers of permission
First, the platform gates who can use the agent at all (access grants). Second — and this is the key — the agent doesn't carry a user's credentials. The bearer token authenticates the platform as a trusted client; each tool call additionally carries an X-Acting-User header with the human's identity. The downstream system matches that to its own user and applies that person's permissions, auditing under them.
The boundary is the contract
This only works if the downstream trusts X-Acting-User exclusively from a valid token and an allowlisted IP. That pair is the security boundary: outside it, the header means nothing. Inside it, the agent can act as Ana with Ana's exact rights — and never as more than Ana.
Why not just impersonate?
Because impersonation copies a secret; delegation passes a claim across a boundary you control. Revoke the platform's token and every agent loses access at once. Inspect the audit log and every write is attributed to the real human who triggered it, not to a faceless service account.
Agents will increasingly act on our behalf. Identity is the part you cannot afford to hand-wave.