How ordinary tool calls create shadow delegation
Categories: Agentic Security
Tags: security ai agents delegation
Calls to agents increasingly come from other agents, as general-purpose assistants route work to specialists. On the wire, these are ordinary tool calls, but if you zoom out and look at them architecturally, each one is a delegation boundary. The calling agent hands part of a user’s task to a separate agent that’s non-deterministic and running in another security context.
Enterprise vendors ship it as a feature. Glean can expose custom agents as MCP tools, Salesforce can publish Agentforce agents for external assistants to invoke, creating “a pathway for tools such as Slackbot, ChatGPT, or Claude to delegate specialized tasks to Agentforce agents,” and Snowflake recommends exposing a Cortex Agent as the client-facing MCP tool for governed business-data applications. Microsoft is the most explicit: in Agent Framework, they envision one agent calling another “as if it were a regular function tool”.
Enterprise IAM can authenticate every participant in the chain and confirm that each call is permitted. What it doesn’t always show is the relationship between the final action and the originating task. Each authorization decision sees only the immediate calling principal. The service at the end of the chain makes the most consequential decision with the least context.
An agent exposed through MCP is discoverable as one more tool, even though invoking it starts its own chain of reasoning, action, and delegation.
Shadow delegation #
Consider an on-call engineer who asks an operations assistant (Claude Code, Codex, or an internal equivalent) to investigate elevated latency in the payments service. The assistant invokes an Incident Agent exposed as an MCP tool. During its investigation, that agent retrieves a past incident where rolling back a deployment cleared a similar latency issue, concludes the same remedy applies here, and invokes a Deployment Agent available as one of its own tools.
engineer → operations assistant → Incident Agent tool
“Investigate elevated latency in payments.”
↳ Deployment Agent tool → production rollback
This execution follows ordinary agentic behavior. The agents interpret the task, select tools, and delegate work as the situation develops. Every local authorization check can also succeed: the engineer is authorized to use the assistant, the assistant to invoke the Incident Agent, the Incident Agent to invoke the Deployment Agent, and the Deployment Agent to perform production rollbacks.
At the production boundary, every familiar signal supports the request: the engineer can authorize rollbacks, the Deployment Agent can execute them, and the logs show how the call arrived. The originating task was an investigation, and that is the one fact the final tool call leaves out.
This is shadow delegation in practice:
One agent assigns work to another, and the handoff travels as an ordinary tool call and is recorded as one. Every participant and call can be visible, yet the on-behalf-of relationship remains implicit.
An explicit handoff is a real improvement: it names the boundary and gives authorization somewhere to attach. Multi-agent frameworks already model delegation that way, and CrewAI hands a delegating agent a tool with the signature Delegate work to coworker(task, context, coworker), naming the work, the context, and the recipient. That tells you who is doing what for whom, and leaves what that agent may do to the credentials it already holds. The signature is missing a fourth argument for the authority the task confers.
Incidents caused by shadow delegation will rarely be classified as delegation failures. The final audit record shows an authenticated agent performing an operation it’s permitted to perform, so investigators reach for excessive permissions, credential misuse, or faulty agent behavior. Each of those diagnoses comes with a fix, and teams apply them: tighter roles, rotated credentials, more guardrails on the model. The handoff itself goes unexamined, and authority still travels the same way.
Authorization for emergent delegation chains #
Now take the perspective of a security architect responsible for securing agentic workflows across an organization. The agents, tools, and services involved may come from different teams and vendors, cross several security domains, and assemble into a call graph only at runtime. The organization needs a consistent authorization model that accommodates this flexibility and still gives every enforcement point trustworthy evidence of what authority the task carried and how it reached the agent presenting the request. The rollback scenario is enough to test the familiar approaches against that standard.
You cannot enumerate the graph in advance. A user knows which agent they invoked, while the workers, remote agents, and tools chosen after that emerge at runtime. Microsoft lists this among the trade-offs of the pattern: routing between agents is model-driven, and “routing can be unpredictable”. An inventory of approved identities cannot establish whether a downstream action stayed inside the invocation that produced it.
The boundary is also opaque in both directions. The inner agent does not inherit the outer agent’s conversation or context, and receives only what arrives in the tool call arguments. The outer agent, in turn, sees only the inner agent’s final text response, not its reasoning or its tool calls. Neither side can supply what the enforcement point needs, so whatever represents authority has to travel in the call itself.
OWASP’s Top 10 for Agentic Applications discusses “un-scoped privilege inheritance” under ASI03, Identity and Privilege Abuse, where a high-privilege manager delegates without least-privilege scoping and hands its full access context to a narrow worker, “often for convenience or due to architectural limits.” The diagnosis is that an agent lacking a governed identity of its own “operates in an attribution gap that makes enforcing true least privilege impossible.” Its remedies include the candidates below: per-agent identities holding scoped tokens, re-verification through a centralized policy engine, and human approval before privileged actions.
NIST frames the same problem as open questions. A concept paper on agent identity and authorization (Feb 2026) asks how to establish least privilege for an agent “especially when its required actions might not be fully predictable when deployed,” which mechanisms let an agent “prove its authority to perform a specific action,” and how to “handle delegation of authority for ‘on behalf of’ scenarios.”
Return to the architect’s problem. The test is whether the production platform can refuse this rollback using only what arrives with the call, because the task behind it was an investigation. Identity alone cannot produce that refusal, since both the engineer and the Deployment Agent are entitled to roll back. Let’s look at the approaches in use today.
1. Forwarding the caller’s token
The simplest answer is to pass the incoming access token to the next agent unchanged. The engineer’s token carries broad production permissions, including rollback, so the Deployment Agent arrives at the platform holding everything the engineer holds, and the rollback goes through. Every agent in the chain receives that same authority, even where its part of the task needs far less. The platform sees a valid token belonging to an engineer who may roll back, and it cannot tell from that token how many hands it passed through or whether the presenter is its intended holder. Forwarding across a heterogeneous chain adds an audience problem on top, unless every service involved accepts a shared audience and authorization vocabulary.
Snowflake’s MCP guidance shows the shape of this at ingress. A session runs under the connecting user’s default role, and the scope mechanism meant to narrow it bends to what clients support: some, including Claude, “request session:role:all instead, so the session uses the user’s DEFAULT_ROLE even when other scopes are advertised”. The recommended corrections are to disable secondary roles, restrict the integration to a least-privileged access role, and run separate MCP servers with dedicated roles when users need different levels of access. Each swaps the user’s broad role for a narrower one that the session still holds at all times, which is the next approach.
Forwarding also separates credential evidence from execution lineage. Gateways and tracing systems may observe the intermediate calls, but the token presented at the end still represents the original authorization, unchanged by the handoffs in between. The security decision then depends on correlating logs from systems that may belong to different products or organizations. The result is shadow delegation behind a valid credential, issued once at the start and covering every handoff that follows.
2. Using each agent’s standing identity
Each agent can hold its own credential instead. Suppose the Deployment Agent was granted permission to roll back payments releases when it was deployed. During the latency investigation, the Incident Agent asks it to reverse deployment 8c1e
. The Deployment Agent calls production under its own identity, production finds a standing policy that permits the rollback, and the request goes through. Every check succeeds, and the task behind them carried only the authority to investigate.
The Deployment Agent is a confused deputy: it holds rollback permission for its general duties and uses it on a request that came out of an investigation. Separate identities show exactly which deputy acted, and leave the delegation itself in shadow. To refuse the call, production would need to know whether that permission applies to the task being served.
3. Exchanging tokens at every hop
A third option is to exchange the incoming token for a new one intended for the next agent. OAuth extensions can support a strong version of this design: Rich Authorization Requests can describe fine-grained permissions, and Token Exchange can issue a token for another audience while recording the current actor. The standards leave the relationship between successive grants to the implementation. RFC 8693 states that a token exchange creates no tight linkage between its input and output tokens, and that earlier actors in a nested delegation chain are informational for access-control decisions. RFC 9396 states that there is no standardized way to compare arbitrary authorization details and determine whether one grant is narrower than another.
MCP has recently standardized this approach with the Enterprise-Managed Authorization extension. It makes the corporate IdP “the authoritative decision-maker”: a client exchanges its login assertion for an Identity Assertion JWT Authorization Grant, then exchanges that for an access token at the MCP server’s authorization server. The IdP “evaluates access policies (group membership, role assignments, conditional access rules) before issuing tokens,” and the extension’s own sequence diagram shows both authorization servers dropping out afterward while the client loops on calling the server with the token it holds. The identity provider issues one token per client-server connection, so it cannot narrow as work passes from one agent to the next.
Suppose every hop in the rollback ran under this extension. The Deployment Agent reaches production holding a token minted seconds ago under a policy the enterprise wrote, and the rollback goes through like any other call.
The authorization server could hold the line here by evaluating every handoff, comparing each requested grant with its parent, and recording the lineage. That would be a much better architecture, but it also places the authorization server in the path of dynamic delegation and requires every participating domain to agree on how constraints are represented and compared.
Absent that discipline, each exchange mints a fresh credential and carries the shadow delegation forward with it.
4. Centralizing the decision in a policy engine
A different kind of answer is to centralize the decision rather than the credential. OPA “decouples policy decision-making from policy enforcement”: a service queries it and supplies structured data as input. Cedar evaluates whether a given principal may take a given action on a given resource in a given context, and states plainly that “your application must gather all of the relevant information and provide it to Cedar’s authorization engine when making the request.” Both are expressive enough to describe the rule this workflow needs. Rego can encode arbitrary conditions, and Cedar supports entity hierarchies and conditions over attributes.
Expressiveness is beside the point here. The production platform assembles the input, and what it knows is the presenter, the operation, and the target. Given a principal of Deployment Agent and an action of rollback, every policy that could be written returns allow, because rolling back deployments is what the Deployment Agent is for. Conditional blocks test attributes of the principal, the resource, and the request, all of which describe the moment of the call but not the task it descends from. In substance this is the standing-identity answer with a richer language for describing the standing part.
The usual follow-up is to load the delegation data into the engine, as bundle data or a fetch at evaluation time. That works when the facts are stable. These facts are created per invocation, change at every handoff, and expire with the task, so the engine needs a live write path from every participating agent. Authority then lives in the side channel, and the decision rests on whatever it last wrote. This is the token-exchange architecture again, with a policy engine in the position of the authorization server.
A policy engine reaches the right decision only once something has already placed the invocation’s authority into its input. Supply that, and the engine becomes an excellent place to enforce it. Without it, the rollback is approved by an engine as blind to the task as the production platform was, and the delegation stays in shadow with better syntax.
5. Keeping agents away from consequential actions
The last approach removes the action from the agent’s reach in lieu of improving what arrives with the call. Glean will not allow an agent with write tools to be exposed as an MCP tool at all, because “MCP hosts typically expect read-only operations, and write tools may require user confirmation that cannot be handled in the MCP protocol.” Human-in-the-loop steps are barred as well, since MCP tool invocations are expected to complete without user interaction. Neither a bounded write nor a human check is available. The restriction reaches sub-agents: an agent that routes to a sub-agent holding a write tool cannot be added to a server either. The recommended pattern is to return structured recommendations that a user acts on in the host application.
This is the only one of the five that refuses the rollback, and it refuses every rollback along with it, including the ones the engineer asks for directly. A rule written about the operation cannot tell one invocation from another, so the capability disappears entirely. The delegation is still in shadow, and it now ends at a recommendation. For a search product the trade is cheap.
Some organizations have adopted the same rule without a platform imposing it: agents may read, summarize, draft, and recommend, while a human performs anything that changes state. This is unambiguously safe, in the sense that an agent with no consequential actions has no consequential failures. It also keeps the least valuable half of the work, because the tasks worth delegating are usually the ones that change something. Read-only is a sensible place to start and an expensive place to stay.
What must travel with the call #
Working through these approaches clarifies what the call has to carry. The production platform needs evidence that rollback authority was granted for this invocation, that each intermediary was entitled to pass it onward, and that the final grant belongs to the Deployment Agent presenting it.
The investigation might begin with authority such as:
root grant (issued when the engineer starts “investigate elevated latency in payments”)
service: payments
environment: production
operations: [metrics.read, logs.read, deployments.read]
The assistant can pass all or part of that to the Incident Agent, and the Incident Agent all or part of what it received to the Deployment Agent. Each participant may narrow the authority it passes on, but it cannot add an operation its parent lacks or relax a constraint its parent imposes. A diagnostic root therefore cannot produce a grant carrying deployments.rollback
, regardless of what the Incident Agent concludes or what its standing role permits.
When the Deployment Agent asks the production platform to roll back, the platform verifies the derivation chain, confirms that the grant belongs to the presenter, and compares the operation with its constraints. The rollback fails there, because the chain it arrived on carries no rollback authority.
The Incident Agent can still conclude that a rollback is the right remedy. What it cannot do is act beyond the authority the task carries, so a legitimate need outside the grant becomes a request to an entitled party:
rollback grant (issued by the engineer on request)
service: payments
environment: production
deployment: 8c1e
operations: [deployments.rollback]
holder: Deployment Agent
An approval prompt on its own asks a person to bless an operation, handing them the same thin context the enforcement point has: this agent, this operation, this target. Issuing a grant gives them something they can judge, and produces authority with stated bounds that every later hop must derive from but cannot exceed. The production action becomes available only once rollback authority enters the workflow explicitly.
The agent remains autonomous throughout. It inspects telemetry, correlates deployments, selects tools, decides that intervention is warranted, and initiates the request. The authorization model constrains which actions are available without prescribing the agent’s reasoning or execution plan, and the authority it works within appears when the task starts, narrows as phases progress, and vanishes when the task ends.
The mechanism is an implementation choice: tokens minted by an authorization server, locally derivable capabilities, signed grants, or some combination. What matters is whether the enforcement point can verify the relationship between the invocation, the delegation chain, the presenter, and the attempted operation.
One route is the Attenuating Authorization Tokens draft I have at the IETF. It profiles RFC 9396 and adds derivation rules that let a holder narrow a token locally, with authority at or below its parent’s and no round trip to the issuer. An enforcement point holding the root issuer’s key verifies the whole chain offline, so the decision rests on the call itself with no server sitting in the path of every handoff.
What this means for vendors #
Most vendors see themselves as a single product with a defined scope and a permissions model built around the customer who configures it. But once an external agent can invoke it, or the product invokes downstream tools on a customer’s behalf, it occupies a hop in a multi-agent workflow. The delegation responsibilities come with that position, however inadvertently the product arrived there.
Vendors that have shipped this are answering them with restrictions. Snowflake recommends exposing a Cortex Agent as the only client-facing tool on a governed MCP server, because exposing SYSTEM_EXECUTE_SQL
alongside it “allows the MCP client to bypass the agent’s semantic views, verified queries, and orchestration”. The governance is handled inside the agent, so a sibling tool on the same server routes around it, and the remedy is a deployment convention that operators have to follow correctly, with no authorization decision behind it. The same documentation anticipates one Cortex Agent reaching another through a second MCP server, and caps that chain at ten invocations: a depth limit constrains how far delegation travels while leaving open what it may do at each step. At the far end of the same spectrum, Glean removes the capability altogether.
Standing authority and a forwarded session reappear inside a single product. Claude Code subagents come with real controls: a definition can allowlist tools, deny others, scope MCP servers, and run the subagent in an isolated worktree. All of it is written in advance. At the moment of delegation the parent picks a subagent type, writes the prompt, and can even set a per-invocation model
. Authority is not a parameter of the call. A definition that omits tools
“inherits every tool available to subagents,” and one that names them binds the same set to every job that subagent is ever handed. Execution decomposes while authority does not, and the shell, the filesystem, and every API the subagent reaches still see one developer’s session.
Products in this position need a first-class capability primitive: a verifiable grant describing what this invocation may do, against which resources, under which constraints, and on whose behalf. An agent should be able to accept that grant at ingress, pass a narrower grant to a downstream participant, request additional authority when the task requires it, and present the resulting chain where consequential actions are enforced. OWASP asks for the same thing from the enforcement side, instructing implementers to “bind OAuth tokens to a signed intent that includes subject, audience, purpose, and session” and to “reject any token use where the bound intent doesn’t match the current request.” Following that instruction requires a product that can state what a call is for.
An MCP interface defines how an agent is reached. A workload identity names which agent is calling. A capability grant establishes what this invocation is authorized to do and how that authority reached the caller. Products that cannot accept this evidence leave customers forwarding broad user tokens, granting standing permissions to agent identities, or confining agents to advisory work and pilot purgatory.
A customer can preserve task authority across every system it controls and still lose the chain at a vendor boundary. A grant for deployments.rollback
on the payments service has enforceable meaning only inside the product that defines that operation and controls its execution. That product has to accept the grant, evaluate it against its own domain, derive narrower authority for downstream calls, and enforce the result. Security reviews and procurement will ask vendors to demonstrate those properties, and standards will follow.
Principles for governing agent delegation #
Organizations will use agents from different teams and vendors, backed by different identity systems, policy engines, and token formats. Those agents will call one another anyway. Security teams should hold every delegation path to three requirements:
Recognize delegation wherever it occurs. Calls to remote agents, internal subagents, and tools that act in another security context all create delegation boundaries. Security inventories and architecture reviews should record them as such.Narrow authority at every handoff. Standing permissions can establish that an agent is eligible for a class of action, and a consequential request also needs evidence that the action belongs to the current task. Each delegation should name its scope, recipient, and parent authority, an agent may pass onward only what the task already carries, and additional authority should enter through a new decision by an entitled party.Verify authority where the action lands. The resource server or tool gateway should validate the presenter, the task authority, and the delegation path using authenticated evidence, since an agent’s own account of the workflow cannot carry that trust. The same evidence lets a security team reconstruct which task produced an action and where its scope changed, and an agent that goes wrong reaches only as far as its task allowed.
Agent-to-agent architecture is delegation architecture, and today much of that delegation runs in shadow. It leaves organizations choosing between agents that hold more authority than their current task requires and agents barred from anything that matters. The third option is a call that carries verifiable evidence of what the task authorizes, and a chain of participants, vendors included, that hold it to that.
A follow-up essay will examine how vendors can add delegation-aware authorization to products already exposed as agent tools, and which patterns fit which product shapes.
Tenuo is an open-source authorization framework for AI agents. Task-scoped warrants that narrow at every delegation and verify offline at the enforcement point.