Delegated Identity and the Confused-Deputy Boundary
Explore how delegated identity flows secure AI tool integration by defining strict identity boundaries and permissions. Understand the roles of identity actors, impersonation limits, and constraints that prevent confused-deputy vulnerabilities. Learn to document and enforce delegated identity requirements to ensure auditability and governance in enterprise AI architectures.
Delegated identity defines an on-behalf-of flow where a tool call gets authorized as the end user under explicit delegation, while the assistant runtime still executes the call using a constrained service identity. The boundary matters because an assistant that can only present its own broad service privileges creates a confused-deputy risk, where that service privilege gets misapplied across a tenant, role, or request origin it was never meant to be trusted for.
Identity actors and impersonation limits
The architecture has four identity-bearing actors. The end user is the human principal whose permissions and tenant membership have to govern any business action. The assistant runtime is a non-human workload identity: it needs enough permission to call the gateway and no permission to act as an arbitrary user. The AI gateway is the policy decision and enforcement point that validates delegated context and constrains downstream calls. The MCP server is a tool broker that must never become an identity-laundering layer between the gateway and the system of record.
State what each actor must and must not be able to impersonate. The end user can delegate specific actions, time-bounded, to the assistant runtime. The assistant runtime cannot mint, alter, or extend an end-user identity claim. The gateway can accept only ...