Privilege escalation by an AI agent usually doesn't happen through one dramatic exploit; it happens through a chain of individually permitted actions that combine into something nobody intended to allow. An agent with permission to read configuration files, permission to write to a deployment pipeline, and permission to trigger a script, none of which look dangerous alone, can potentially combine those three into an action equivalent to modifying production systems directly, even though no single permission was ever meant to grant that. Preventing this means looking at what combinations of permissions actually make possible, not just auditing each permission in isolation.
Why chained tool calls are the real risk
A permission review that checks each tool grant separately misses the interactions between them. An agent might not have direct access to sensitive data, but if it has access to a tool that can read arbitrary files and a separate tool that can send that content somewhere external, the combination achieves what neither permission achieves on its own. This is the agent-specific version of a problem application security has dealt with for years, just with the chaining decided at runtime by a model instead of by a developer writing exploit code in advance.
Reviewing permission combinations, not just individual grants
When scoping an agent's access, explicitly consider what its full set of granted tools could accomplish together, not only what each tool does in isolation. This is harder to do exhaustively as the number of tools grows, which is itself an argument for keeping an individual agent's tool set as narrow as its task genuinely requires, rather than granting broad access across many tools because it's convenient.
Watching for permission creep over time
Privilege escalation doesn't always happen in one step; it can happen gradually, as an agent's task expands and each new capability gets added without anyone revisiting the full accumulated permission set. An agent that started with three narrow tools and now has fifteen has a combinatorial risk surface that grew much faster than the number fifteen suggests, and a review that only checks new additions against their own narrow justification misses that broader picture.
Structural boundaries that don't depend on the model behaving
Some escalation paths need to be closed structurally, not through policy an agent is expected to respect. If a tool technically allows an action that combined with another tool creates an unacceptable escalation path, that combination should be blocked at the enforcement layer, denying the second action given the first has already occurred, rather than relying on the agent's own judgment not to chain them that way.
Detecting escalation attempts after the fact
Not every escalation path can be anticipated in advance. Monitoring for unusual sequences of tool calls, especially ones that individually look fine but together resemble an escalation pattern, gives a chance to catch attempts that weren't designed against explicitly. Logging enough detail about call sequences, not just individual call outcomes, is what makes this kind of detection possible after the fact.
Testing for escalation deliberately
Treat privilege escalation the way a security team treats any other attack path: test for it directly. Deliberately attempt to chain an agent's permitted tools into an unintended outcome during testing, rather than assuming the individual permission reviews already caught everything. This kind of testing tends to surface combinations nobody thought to flag during a standard permission review.
Restricting escalation through data as well as tools
Privilege escalation doesn't always require a new tool; sometimes the data an agent already has access to is enough. An agent permitted to read internal documentation might come across credentials, internal URLs, or configuration details embedded in a document that let it reach further than any tool grant alone would suggest, simply because the information needed to act was sitting inside content it was already allowed to read. This path is easy to miss because no permission was technically exceeded, the agent just found a shortcut inside data nobody thought to scrub first.
Reviewing what sensitive information might be reachable through an agent's normal read access, not only what actions it's permitted to take, closes a path that a tool-focused review alone won't catch. Scrubbing or restricting sensitive content out of documents and data sources an agent can read is as much a part of preventing escalation as scoping the agent's tool permissions correctly in the first place.
Where TELEON fits
TELEON's policy enforcement at the tool-call boundary evaluates each request against current policy, and because it sits in the path of every call, it can be configured to consider recent call history and deny combinations that resemble an escalation pattern, not just individual requests in isolation. Its audit trail also supports reviewing call sequences after the fact to catch escalation attempts a live policy didn't anticipate.
Deciding which specific combinations are dangerous for a given agent's tool set is analysis work specific to each deployment's tools and data.
A short checklist
- Review what an agent's full set of permissions could accomplish combined, not only individually.
- Keep individual agents' tool sets as narrow as their task genuinely requires.
- Revisit the full accumulated permission set as an agent's capabilities grow, not just new additions.
- Block known dangerous tool combinations structurally, not through model instructions.
- Log tool call sequences, not just individual outcomes, to support after-the-fact detection.
- Monitor for call sequences resembling escalation patterns even when each call looks permitted.
- Deliberately test for privilege escalation paths rather than assuming permission review caught them.
Privilege escalation in agentic systems rewards attackers, and reveals gaps, precisely because it exploits the space between individually reasonable permissions rather than any single obviously excessive one. Closing that space takes deliberately thinking in combinations, not just grants, which is a habit worth building before an agent's tool set grows large enough that nobody can hold every combination in their head at once.