Threat
Agent identity and privilege abuse occurs when an agent acts with authority that does not match the current human, workload, task, or target. Common causes are one shared service account, cached credentials from another user, broad administrator tokens, missing audience checks, stale sessions, and hidden delegation.
An agent host can be authenticated while the specific tool action still has no trustworthy actor or subject binding.
Separate identities and grants
Represent the human subject, agent instance, host application, MCP client, server, tool, and downstream service separately. Bind user-delegated credentials to the current session, resource, and audience. Use a service credential only for service-owned actions, not to simulate user permission. Keep tenant and user credential caches isolated.
Authorize each call from current identity and resource state. Use short lifetimes and explicit reauthorization for expanded scope. Preserve actor and subject through exchange. Clear credentials, memory, and task state when the user, tenant, or session changes.
Failure and residual risk
A confused deputy can use its service authority for an attacker-selected resource. A user can inherit another user's cached token. An agent can continue after group removal or consent withdrawal. A valid access token can target another resource when audience is not checked. Tool results can expose a credential for later calls.
Strong identity does not make model-selected actions correct. A legitimate user can also request prohibited actions. Keep action authorization and impact controls separate.
Pomerium boundary
Pomerium can authenticate callers, protect routes, and manage documented upstream OAuth connections per user and route. Operators must configure identity and policy. Agent hosts and MCP servers own task isolation, delegated credential use, downstream audience, and per-tool authorization.
Evaluation checklist
- Are human, agent, client, server, tool, and service identities distinct?
- Can one user or tenant ever receive another's cached credential or task state?
- Are service credentials excluded from user-owned actions unless policy explicitly delegates them?
- Do audience, resource, scope, expiry, and current authorization all match?
- Does logout, disable, consent withdrawal, or user switch stop future actions within a measured bound?
