Read here,
write there.
Two approved tools with different scopes create a bridge between them. The classic pair is read-confidential plus send-external; there are usually several less obvious ones.
Two safe tools,
one unsafe
capability.
Privilege escalation in agent systems rarely comes from a single dangerous permission. It comes from a combination that no individual review considered.
READ THE DEFINITION ↓COMPOSITION · DEPUTY · CHAINS
01 / DEFINITION
The short answer first.What is privilege escalation in an AI agent system?
Privilege escalation in an AI agent system is any path by which the agent achieves an effect beyond what was approved. In practice it usually arises from composition — several individually reasonable capabilities combining — rather than from a single over-broad grant.
The reason this differs from conventional escalation is that the agent composes its own paths. No exploit is required: the model is doing exactly what it was built to do, which is to find a sequence of available operations that accomplishes an objective. If the sequence happens to cross a boundary the reviewers never considered as a sequence, the system has escalated without anything malfunctioning.
02 / FOUR PATTERNS
How capability sets exceed their approval.Read here,
The agent's rights,
the user's request.
An agent with broader rights than its caller performs an operation on the caller's behalf, and the caller's own restrictions never apply.
Each hop
widens slightly.
A sub-agent is granted marginally more than it strictly needs, and a chain of such grants ends far from the original scope.
A fourth pattern is persistence. An agent with memory, a scratchpad or a writable store can carry information or instructions from one session into another, which crosses the boundary between a run scoped to one user and a later run scoped to a different one. Memory that survives a session should be treated as a channel with its own access controls, not as an implementation detail.
03 / REVIEWING THE SET
A procedure that catches composition.List effects, not tools.
Translate every capability into what it lets the system do to the outside world: read this class of data, change this record, reach this destination.
Cross the list with itself.
For each pair, ask what becomes possible that neither allows alone. Most escalation paths appear at this step and nowhere else.
Check the identity at every hop.
Whose rights apply at each call, including inside sub-agents and inside tools that call other services on the agent's behalf.
Re-run the review on every change.
Adding one tool changes every pair. A capability set approved last quarter is not approved now.
Step two is tedious and is where the value is. A set of eight tools has twenty-eight pairs, which is a reviewable number, and the interesting findings are usually concentrated in three or four of them. Automating the enumeration — generating the pair list and asking the owner to justify each combination — makes it a routine rather than an exercise of memory.
04 / STRUCTURAL PREVENTION
Designs where composition is not available.Some architectures remove the escalation path rather than reviewing it.
- Split the agent. One component reads untrusted content and produces a structured, validated summary; a separate component holds any privileged capability. The bridge between them is a schema, not a language model's discretion.
- Make egress structurally impossible. An environment with no outbound network path cannot exfiltrate, whatever combination of tools exists inside it. This is one of the practical arguments for on-premise AI.
- Keep the authority ceiling low. An agent that can only propose cannot escalate into an action, whatever capabilities it accumulates. Privilege AI applies exactly this ceiling to MKC2, which reports and flags and does not act.
The first pattern is the most generally useful and the least adopted, because it requires designing the interface between components rather than handing one model every tool. The cost is a schema and some engineering; the benefit is that the escalation surface stops growing with each new capability.
05 / QUESTIONS
Asked during a capability review.How is this different from ordinary privilege escalation?
+
No vulnerability is involved. The agent uses approved capabilities in an unapproved sequence, which it discovers itself while pursuing a goal. Nothing malfunctions, so conventional detection based on failures and anomalous authentication sees nothing.
What is the confused deputy problem for agents?
+
An agent with broader rights than its caller acts on the caller's behalf, so the caller effectively borrows the agent's privilege. Propagating the requesting user's identity through every call removes it. See AI agent permissions.
Can a read-only agent escalate?
+
Yes, in the disclosure direction. Read plus any outbound channel is an exfiltration capability, and rendering a URL can be enough. Read-only bounds the write risk and does not bound the disclosure risk.
Do multi-agent systems increase escalation risk?
+
Materially, because delegation chains multiply the number of identity transitions and each one is an opportunity to widen scope. Requiring that delegation can only narrow, and recording the full chain, keeps it tractable.
How often should a capability set be reviewed?
+
On every change, because one new tool changes every pair. A scheduled quarterly review of a set that changes weekly is reviewing something that no longer exists.
Review the set,
not the tool.
Privilege AI designs agent boundaries where the escalation surface is a schema rather than a model's discretion.