XIV · Anti-PatternsAnti-pattern✕

Agent Privilege Escalation

also known as Identity and Privilege Abuse, ASI03, Attribution Gap

Anti-pattern: let an agent's effective permissions be the union of its own identity, the identities of its tools, and the identities of the services those tools call.

Context

An agent has its own identity for some purposes (logging, billing), but when it calls a tool, the tool runs under a service identity with its own permissions. When that tool calls a downstream service, yet another identity is used. The agent's effective permissions are not its declared permissions — they are the transitive closure across the call chain.

Problem

Giskard's framing names this the 'attribution gap': permissions are managed dynamically across an opaque identity chain without a single governed identity for the agent. The agent can act with privileges that no single audit row reflects — the tool it called had broader scope than the agent itself, and the downstream service trusts the tool's identity, not the agent's. Classical IAM models don't fit: there is no one principal to authorise.

Forces

  • Tools must have identities to call downstream services; merging tool identity with agent identity is operationally hard.
  • Per-call delegated tokens are expensive to design and short-lived.
  • Audit trails capture identity-at-call, not the originating-agent context.

Example

An agent has read-only permissions on a customer-data table. It calls an MCP server tool to 'generate a report'. The MCP server's service account has read-write on the same table for analytics purposes. The agent prompts the tool to 'also fix any obvious errors you find', and the MCP server writes back. Audit shows the MCP server made the writes; no row in the audit points to the agent. Postmortem: the agent's permissions did not threaded through to the tool; the tool acted on its own identity.

Diagram

Solution

Therefore:

Don't. Adopt delegated-identity threading (on-behalf-of tokens, downscoped credentials). Apply capability-bounded-execution at every tool boundary. Audit by originating agent so the attribution gap closes. Pair with authorized-tool-misuse mitigations.

What this pattern forbids. No useful constraint; the missing constraint is identity-threading.

And the patterns that stand alongside it, or against it —

  • complementsAuthorized Tool Misuse✕— Anti-pattern: grant the agent a tool with broad authorization and trust the agent to use it in benign ways.
  • alternative-toSandbox Isolation★★— Run agent-emitted code or actions in a contained environment with restricted filesystem, network, and process privileges.
  • complementsAgent-Computer Interface★— Design the tool surface for an LLM agent specifically, with affordances different from human-facing CLIs.
  • complementsInsecure Inter-Agent Channel✕— Anti-pattern: pass messages between agents on shared transports without authenticating the sending agent, the message content, or the sequence.
  • complementsTool Over-Broad Scope✕— Anti-pattern: grant the agent tools scoped so broadly that a single hallucinated argument can escalate into a privilege incident.
  • alternative-toCost-Aware Action Delegation★— Classify every agent action by risk/cost and route each tier to a different approval policy, bounding the autonomy surface per-action instead of by one global flag.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance