Delegated authorization is the mechanism that lets an AI agent act on a user's behalf using that specific user's actual permissions, rather than falling back to the agent's own, usually broader, service-level role. It's the same concept OAuth token exchange solved for conventional applications: an application acting for a user should be bounded by what that user is allowed to do, not by whatever access the application's own credentials happen to carry. For agents, getting this right is what stands between "the agent can only do what its user could already do" and "the agent quietly becomes a more powerful actor than any human using the system," which is one of the more common ways agent deployments end up over-permissioned without anyone deciding that on purpose.
Why falling back to the agent's own role is the default failure
It's technically simpler to authorize an agent's tool calls against one fixed service role than to propagate and evaluate a specific user's permissions on every call. That simplicity is exactly why it happens so often, and exactly why it's a problem: the agent's service role, built to cover every task it might ever perform for any user, ends up broader than any individual user's actual access. An agent authorized this way can retrieve or modify data a specific user was never entitled to touch, simply because the check never looked at the user at all.
The token exchange pattern
A common, workable pattern issues the agent a delegated token scoped to the calling user's permissions, obtained through an exchange step where the agent presents its own identity plus evidence of who it's acting for, and receives back a token that downstream services can evaluate directly. This keeps the user's actual entitlements as the binding constraint on every subsequent tool call the agent makes during that task, rather than the agent's own broader capabilities.
Narrowing delegation further than the user's full access
Delegated authorization doesn't have to hand the agent everything the user could theoretically do. A well-scoped delegation grant narrows further, to only what the current task needs: a document-summarization agent doesn't need delegation to the user's billing permissions just because the user happens to have them. Scoping delegation per task, not per user's entire access profile, limits how much damage a single compromised or manipulated agent task can cause.
Handling delegation chains
Multi-agent workflows sometimes involve one agent delegating to another, which delegates to a third. Each hop in that chain should carry forward the original user's permissions as the actual boundary, not silently expand scope at any hop, and each service in the chain should be able to verify the delegation is legitimate rather than trusting whatever arrived from the previous hop.
What happens when delegation isn't checked downstream
Delegated authorization only works if every downstream service that receives the delegated token actually evaluates it against the user's permissions rather than treating a validly signed token as sufficient on its own. A downstream service that checks "is this token valid" but not "does this user's permission actually cover this specific action" has effectively undone the whole point of delegating in the first place.
Auditing delegation grants over time
Delegated authorization is easy to get right at launch and quietly wrong six months later, because the scope of a delegation grant tends to expand as new tool integrations get added to an agent's workflow without anyone revisiting what the original delegation was actually meant to cover. A grant that started out scoped to "read the user's calendar" can end up, through a series of individually reasonable additions, covering write access to several other systems the original design never anticipated.
Reviewing delegation grants periodically against their original stated purpose, not just their current technical scope, catches this kind of drift before it becomes the reason a compromised or manipulated agent can reach much further than anyone expected. This is a different check than a standard permission audit, because the question isn't whether the agent's role is appropriate in isolation, it's whether the specific delegation a user granted still matches what that user actually agreed to when they authorized it.
Where TELEON fits
TELEON's policy enforcement at the tool-call boundary evaluates authorization using the identity context presented to it, which is meaningful specifically when that context reflects a properly delegated user identity rather than only the agent's own service credential. TELEON records these decisions in its audit trail, giving visibility into which delegated identity was evaluated for a given action.
Implementing the delegation and token exchange mechanism itself, and correctly propagating delegated context to every downstream service, is application architecture work outside what a policy layer alone determines.
A short checklist
- Authorize agent actions against the delegating user's permissions, not the agent's own service role.
- Use a token exchange or equivalent pattern to establish delegated context explicitly.
- Scope delegation to what the current task needs, not the user's full entitlement set.
- Preserve the original user's permission boundary across multi-agent delegation chains.
- Ensure every downstream service actually evaluates delegated permissions, not just token validity.
- Test that a user with restricted access produces correspondingly restricted agent behavior.
- Log the delegated identity alongside the agent identity at every authorization decision.
Delegated authorization is the piece of the architecture that decides whether an agent's convenience comes at the cost of a broader attack surface. Done well, it means a compromised or manipulated agent can never do more than the specific user it was serving could have done directly. Skipped or done badly, it means the agent's own permissions become the real ceiling, and that ceiling is almost always higher than anyone intended.