Helpful first: Excessive agency: why a model sentence is never an authorization decision
Key points
- Explain the Confused Deputy vulnerability created when a multi-user AI agent shares a single static service credential
- Design an On-Behalf-Of (OBO) token exchange flow where effective permissions equal the intersection of user and agent scopes
- Preserve dual identity (
subfor the human principal,actfor the agent actor) in audit logs and resource-server policy checks
The Confused Deputy trap of ambient agent credentials
Suppose Meridian Space & Robotics (chronos.orbital) deploys an internal engineering assistant (ops-copilot) that can query Jira tickets, read S3 telemetry archives, and inspect Kubernetes logs. The quickest - and most dangerous - way to wire ops-copilot is to mount a single static service-account token (ops-copilot-admin-key) with read access to every department’s data.
The moment you do that, ops-copilot becomes a Confused Deputy. If a junior contractor who only has permission to view public marketing tickets asks ops-copilot to summarize confidential propulsion blueprints, the downstream S3 and Jira APIs only see ops-copilot-admin-key and happily return the blueprints. The agent’s ambient credential erased the caller’s authorization boundary.
| Identity Pattern | What Downstream Resource Server Sees | Effective Permission Ceiling | Audit & Security Verdict |
|---|---|---|---|
Ambient Static Service Key (god-token) | sub: ops-copilot (human caller invisible) | Union of every permission any user might ever need | Fails: Confused Deputy escalation and loss of human attribution in logs |
| Raw User Token Forwarding | sub: priya.nair@chronos.orbital (agent invisible) | Full scope of Priya’s interactive browser token across all services | Risky: violates audience (aud) binding and hides whether Priya or an autonomous agent acted |
OAuth Token Exchange / OBO (RFC 8693) | sub: priya.nair, act: { sub: ops-copilot }, aud: telemetry-api | Strict intersection (User Scopes ∩ Agent Allowed Scopes) for target aud | Gold standard: prevents privilege escalation and records both human and agent in audit logs |
How OAuth 2.0 Token Exchange (RFC 8693) bounds authority
To fix the Confused Deputy problem, Staff Infrastructure Engineer Kael Cho configures ops-copilot to use OAuth 2.0 Token Exchange (RFC 8693). When Propulsion Lead Priya Nair asks ops-copilot to fetch telemetry for satellite CHRONOS-4, the agent presents Priya’s incoming token along with the agent’s own workload credential (such as a SPIFFE X.509 SVID) to Meridian’s Authorization Server.
The Authorization Server mints a new, short-lived downstream access token scoped specifically to aud: https://telemetry.chronos.orbital containing two critical claims: sub: "priya.nair@chronos.orbital" (the resource owner / human principal) and act: { "sub": "spiffe://chronos.orbital/agent/ops-copilot" } (the acting party).
Enforcing the intersection of permissions and audit attribution
When telemetry.chronos.orbital receives that exchanged token, its policy engine evaluates both identities. First, does priya.nair@chronos.orbital have permission to read CHRONOS-4 telemetry? Second, is the actor ops-copilot permitted to invoke this read endpoint? The effective authority is the intersection (User ∩ Agent), never the union.
Better yet, if Priya has administrative permission to delete a database table when logged in directly with hardware MFA, the policy engine can still deny DELETE whenever an act claim is present - ensuring that autonomous agents remain constrained to safe subset operations while every audit log entry records both who initiated the request and which agent executed it.
CHECK YOUR JUDGMENT