Agent Authority Delegation Depth: Limits and Enforcement

When an AI agent invokes a sub-agent, or that sub-agent invokes a tool or another agent in turn, the original authority granted to the first agent is implicitly or explicitly carried forward. Delegation depth refers to how many of these sequential hops occur before a task is actually executed. In a simple system, a single agent calls a single tool and the chain ends there. In more complex enterprise deployments, an orchestrating agent may delegate to a planning agent, which delegates to a retrieval agent, which invokes a tool that writes to a production system. Each hop in that chain is an opportunity for authority to be preserved, narrowed, or expanded.

This matters because most authorization models in production today, including OAuth 2.0 and its token exchange extension (RFC 8693), were designed for human-to-service or service-to-service delegation with a small, predictable number of hops. Multi-agent systems introduce arbitrary-depth, often dynamically determined chains where the number of hops is not known in advance and may vary per task.

Why Unbounded Delegation Depth Is a Security Problem

When authority propagates through a chain without independent revalidation at each hop, the security posture of the entire chain collapses to the weakest link. If a downstream agent several hops removed from the original request is compromised, manipulated through prompt injection, or simply misconfigured, it can act with the full authority of the originating request because no checkpoint reduced or re-checked that authority along the way.

OWASP's guidance on large language model applications identifies this pattern as "excessive agency," describing the harm that results when an agent holds more functionality, permissions, or autonomy than its specific task requires. Delegation depth is one of the primary mechanisms by which excessive agency accumulates in practice, because each additional hop is a chance for permissions to persist beyond their original scope rather than shrink to match the narrower task being performed downstream.

A second consequence is traceability. NIST's AI Risk Management Framework recommends mapping and documenting AI system dependencies and third-party components. Applied to agent chains, this means every hop should be logged with enough context to reconstruct, after an incident, which agent authorized which action and under what original grant. Without depth limits and per-hop logging, that reconstruction becomes difficult once chains exceed a few hops.

How Current Protocols Handle Delegated Authority

The Model Context Protocol (MCP) defines a client-server architecture for connecting models to external tools and data sources, including authorization flows for individual tool invocations. As published, MCP does not include a native field or mechanism for capping how many times authority can be re-delegated across a chain of servers or tools. Google's Agent2Agent (A2A) protocol takes a related but distinct approach, structuring interactions around explicit task requests and capability discovery through agent cards, rather than implicit chained re-delegation.

Both protocols solve real coordination problems, discovering what an agent or tool can do and how to invoke it, but neither specification reviewed here mandates a maximum hop count or standardized depth-limit enforcement. This means depth control is currently left to the implementing organization. Teams building on these protocols need to add their own policy layer if they want to bound delegation depth, rather than relying on the protocol to enforce it.

Architectural Patterns for Enforcing Depth Limits

Enforcing delegation depth requires decisions at several points in the system design, since existing protocols provide the transport and discovery layer but not the enforcement layer.

Implementation Decisions Security Teams Need to Make

Applying these patterns requires upfront decisions rather than defaults. Teams need to define, for each agent role, the minimum permission set it requires rather than allowing it to inherit the full authority of the agent that invoked it. This is the least-privilege principle from NIST SP 800-207 applied specifically to agent chains: authority should attenuate as it descends, not remain constant.

Teams also need to decide where policy enforcement lives. A centralized enforcement point that every hop calls out to is easier to audit and update but adds latency and a dependency. Enforcement distributed to each agent or gateway is faster but harder to keep consistent across a system as it grows. CISA and NSA joint guidance on securing AI systems recommends continuous monitoring and least-privilege enforcement across AI system components, which supports centralizing visibility even if enforcement logic is distributed.

Practical Guidelines for Bounding Delegation Chains

• Define a maximum delegation depth per workflow type rather than applying one global limit across unrelated agent systems.
• Attenuate credentials at every hop so downstream agents receive only the scope needed for their specific sub-task.
• Re-validate authorization at each invocation instead of relying on a single upstream approval for the entire chain.
• Assign correlation identifiers to every delegation chain so the full sequence can be reconstructed during incident review.
• Treat protocol-level gaps in MCP and A2A specifications as a reason to add a custom policy layer, not a reason to skip depth enforcement.
• Document delegation relationships between agents as part of system dependency mapping, consistent with NIST AI RMF guidance.

Where Trussed AI Fits

Trussed AI provides runtime governance and security for enterprise AI agents, including runtime policy enforcement, agent identity and permissions management, and audit logging across agent-to-agent and agent-to-tool interactions. For teams working through the architectural decisions above, this means policy checkpoints and least-privilege enforcement can be applied at runtime, at each delegation hop, rather than only at the point where a task originates, with the resulting activity captured in audit logs for traceability. This complements the standards-based building blocks described above (OAuth scoping, zero trust per-request evaluation) rather than replacing them.