Source-linked AI summary
Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems
Panduranga Sai Varma Dantuluri, Jyotirmoy Sundi
TL;DR
Autonomous LLM agents can exercise delegated authority while their language-model controllers remain vulnerable to hijacking, leaving identity and authorization as an empirical security gap. This paper derives requirements under an untrusted-model assumption, evaluates common frameworks, and implements an authorization broker that closes the gap. The broker blocks the studied threats while confining authority through workload-bound, attenuated delegation.
Problem
Agent security lacks sufficient evidence that a fully prompt-injected model cannot exceed explicitly delegated authority across multi-agent delegation.
Method
The paper derives eight requirements, analyzes four frameworks and existing standards, and adversarially evaluates an authorization broker using infrastructure-enforced delegation.
Results
The default runtime fails all four threats; three of four frameworks provide no built-in confinement, while the broker blocks all four threats and confines compromised sub-agents.
Takeaways & Limitations
Model-side guardrails cannot replace authority scoping outside the model; governed delegation requires infrastructure enforcement independent of model compliance.
Takeaways & Limitations
The broker enforces an abstract tool/resource-tuple action model, so production policy enforcement points must map real tool invocations to it faithfully.
Abstract
from arXiv · showhide
Autonomous LLM agents increasingly act on a user's behalf: they hold credentials, call tools and services, and spawn sub-agents that act further on their behalf. This turns a long-standing distributed-systems question -- who is authorized to do what, on whose authority -- into an urgent and largely unsolved problem, because the component driving each agent is a language model an adversary can hijack. We argue that agent security must be evaluated under an untrusted-model assumption: a correct system is one in which a fully prompt-injected agent still cannot exceed the authority explicitly delegated to it. Against this standard we make three contributions. First, we give a threat model for multi-agent delegation centered on four adversaries -- confused deputy, token theft and replay, prompt-injection privilege escalation, and compromised sub-agents -- and derive eight security requirements a governed agent system must meet. Second, we show the gap is real: a default agent runtime modeling common practice (broad bearer credentials, authorization gated inside the model) fails all four threats, and across four widely used frameworks -- LangGraph, CrewAI, AutoGen, and the Model Context Protocol (MCP) authorization model -- three provide no built-in confinement and one only partial; no existing standard alone covers the requirement set. Third, we implement and adversarially evaluate an authorization broker that closes the gap. It blocks all four threats; it resists 11 direct attacks on its design and accepts 0 of 200,000 forged tokens; it confines a compromised sub-agent to its delegated task (a mean of 1.5 reachable actions versus all 8,100 under bearer delegation, across 2,000 randomized scenarios); and it enforces at microsecond cost (about 2.6 microseconds per decision), negligible against model inference. These principles are also realized in production in VotalAI's LLM Shield.
1 Introduction
Autonomous LLM agents now exercise delegated authority through credentials, tools, and sub-agents, while their language-model controllers can be hijacked. The paper therefore evaluates delegation under an untrusted-model standard, analyzes the resulting gap, and builds an adversarially tested broker.
- Motivation: An LLM agent is a credential-holding process that takes consequential actions and can delegate work to specialized sub-agents.These actions include reading mailboxes, moving money, filing tickets, and calling internal APIs.
- Untrusted-model standard: A fully prompt-injected agent must remain within explicitly delegated authority, avoid off-workload use of stolen credentials, and leave an attributable audit trail.The paper treats dependence on the model not being hijacked as insufficient security.
- Contributions: The threat model centers on confused deputy, token theft and replay, prompt-injection privilege escalation, and compromised sub-agents, yielding eight security requirements.The requirements are derived under the untrusted-model assumption.
- Contributions: The gap analysis finds that a default runtime fails all four threats; three of four frameworks provide no built-in confinement, while one provides only partial coverage.The paper also reports that no existing standard alone covers the complete requirement set.
- Contributions: The implemented broker blocks all four threats, resists 11 direct attacks and 0 of 200,000 forged tokens, confines compromised sub-agents, and enforces at microsecond cost.The paper evaluates the defense adversarially rather than only sketching it.
2 Background
The paper frames multi-agent systems as delegation chains rooted in a human grant and applies established identity, capability, and reference-monitor principles. Its threat model assumes trusted authorization infrastructure but fully untrusted agent models and possible credential replay.
- Agentic architectures: Modern agent frameworks use plan–act–observe loops with tools, while multi-agent variants add delegation chains from primary agents to sub-agents.MCP standardizes agent connections to tools and servers and defines an OAuth-based authorization profile.
- Access-control principles: Authority should be represented by unforgeable, narrowly scoped, delegable tokens, with every access mediated by a reference monitor.These principles address least privilege, complete mediation, and the confused-deputy problem.
- Identity and delegation: OAuth/OIDC anchor human identity, token exchange expresses on-behalf-of delegation, SPIFFE/SPIRE provides workload identity, and sender-constraining binds tokens to holders.Macaroons and Biscuit support attenuation through narrowing caveats.
- Principals: The modeled principals are the human user, primary agent, sub-agents, tools or MCP servers, and authorization infrastructure.The human user is the root of authority.
- Trust assumptions: The threat model assumes trusted authorization infrastructure and authenticated workloads, but allows adversaries to control model output, replay traffic, or exfiltrate credentials.It does not assume cryptographic or infrastructure compromise.
- Threats: The four threats are confused deputy, token theft or replay, prompt-injection privilege escalation, and compromised sub-agents with over-broad scope.A compromised sub-agent can exceed its task when delegated authority is over-broad or non-attenuated.
4 Security Requirements
The security requirements translate the paper’s goals into enforceable properties for multi-agent delegation: provenance, narrowing authority, workload binding, revocation, auditability, and enforcement outside the model. Model-independent enforcement is the load-bearing requirement because a hijacked model cannot safely gate access.
- Authority and provenance: Every delegation hop must remain cryptographically traceable to a human grant through on-behalf-of provenance.This requirement addresses confused-deputy and compromised-sub-agent threats.
- Authority and provenance: Each delegation can only narrow scope, never widen it, enforcing least-privilege attenuation across agent-to-agent hops.The requirement addresses confused deputy, privilege escalation, and compromised sub-agents.
- Credential protection: Tokens must be bound to workload identities, while minimal lifetimes and automatic key rotation limit replay and long-term compromise.Sender-constraining makes an exfiltrated token unusable elsewhere.
- Governance: Revocation must reach policy enforcement points promptly, and every privileged action must be attributable to a tamper-evident delegation chain.These requirements support response, detection, and forensics.
- Governance: Authorization decisions must be made by infrastructure policy enforcement points rather than the untrusted model.The paper identifies this as the load-bearing requirement for achieving the untrusted-model property.
5 Empirical Gap Analysis
The empirical analysis demonstrates that common default runtimes and most evaluated frameworks lack delegation confinement. LangGraph, CrewAI, and AutoGen provide no built-in authorization or confinement, while MCP provides only partial coverage through its OAuth authorization model.
- Baseline runtime: A default runtime with one broad bearer credential and model-gated authorization allows a hijacked agent to succeed at all four attacks.The runtime provides none of requirements R1–R8.
- Evaluation method: The framework evaluation records threat outcomes and requirement coverage using execution for LangGraph, capability inspection for CrewAI and AutoGen, and specification analysis for MCP.The methods are stated per framework rather than asserted without analysis.
- Threat outcomes: Table 1 encodes default threat outcomes with Y for vulnerable, ∼ for partial or hardening-dependent, and – for mitigated by default.LangGraph was executed, CrewAI and AutoGen were inspected, and MCP was evaluated from its specification.
- Requirement coverage: Table 2 encodes default requirement coverage with Y for provided, ∼ for partial, and – for absent.Its summary reports no coverage for three frameworks and partial coverage for MCP.
- Framework results: Three of four frameworks—LangGraph, CrewAI, and AutoGen—provide no built-in authorization or delegation confinement.Their default out-of-scope tool calls execute, leaving confinement to the developer.
- Framework results: MCP provides partial coverage: its OAuth resource-server model validates tokens outside the model and mandatory Resource Indicators restrict tokens to specific servers.This prevents cross-server token reuse but does not provide complete agent-to-agent delegation provenance.
6 Systematization: Standards vs. Requirements
The analysis maps existing standards and primitives to the broker’s security requirements, finding that no single standard covers the full set. In particular, agent-to-agent delegation lacks a profile combining attenuation, workload binding, short-lived tokens, and enforcement outside the model.
- Standards-to-requirements mapping: Table 3 maps each standard or primitive to the requirements it can satisfy, based on the authors’ reading of its specification.The mapping uses Y for direct support, ∼ for partial support or support requiring profiling, and – for out-of-scope requirements.
- Scope of analysis: The standards analysis is analytical rather than measured, reflecting specification interpretation and inviting scrutiny of individual table cells.This caveat applies to the requirement-coverage mapping rather than to an empirical runtime experiment.
- Coverage gap: No single standard covers the full requirement set.The requirements are distributed across token exchange, capability tokens, SPIFFE/mTLS/DPoP, and deployment enforcement properties.
- Agent-to-agent composition gap: No existing standard profile simultaneously provides attenuated delegation tokens, sub-agent workload binding, short lifetimes, and model-independent enforcement.The paper identifies this missing composition as the central gap addressed by the broker.
7 The Broker: Design, Implementation, and Evaluation
The paper composes identity, capability, delegation, and mediation primitives into a broker that enforces attenuated, workload-bound authority outside the model. In evaluation, it blocks the modeled threats, resists direct and forged-token attacks, sharply limits compromised-agent reach, and adds microsecond-scale enforcement overhead.
- Design: The broker sits between agents and tools as an authorization broker and policy enforcement point, realizing the untrusted-model property by construction.A hijacked agent can exercise only its attenuated, workload-bound grant, while a stolen token is inert off its identity.
- Design: Each delegation hop mints a new token attenuated to the sub-task, bound to the receiving agent’s SVID, and short-lived.Only the workload bound to a token may delegate it onward; revocation propagates down the delegation chain.
- Design: Every tool call is broker-mediated, with token verification, caveat enforcement independent of the model, and tamper-evident delegation-chain logging.Tokens use macaroon-style append-only caveats, so authority can narrow but not widen; enforcement requires no model call.
- Defense effectiveness: All four modeled threats are blocked by the broker, whereas the default runtime fails all four.The comparison is reported in Table 4 using the shared scenario harness.
- Adversarial robustness: 11 direct design attacks were resisted, and 0 of 200,000 random or mutated forged tokens were accepted.A boundary test succeeds if an attacker presents the victim’s SVID, confirming sender-constraining’s dependence on workload-identity attestation.
- Blast radius: A compromised sub-agent reached a mean of 1.5 actions under the broker versus all 8,100 under bearer delegation across 2,000 randomized scenarios.The defended reach remained bounded by the delegated task and independent of environment size.
- Overhead: Authorization enforcement costs ∼2.6 µs per decision, while token exchange costs ∼5.4 µs.These costs are reported as negligible relative to model inference, which takes hundreds of milliseconds to seconds.
8 Real-World Implementation: VotalAI LLM Shield
VotalAI’s LLM Shield realizes the broker’s governance principles through a production identity, gateway, policy, and observability stack. Its architecture combines centralized access control with content inspection, policy caching, and continuous red-teaming for agentic deployments.
- Production realization: LLM Shield implements the broker’s requirements through a production identity and policy stack rather than the reference implementation’s SPIFFE-style and macaroon-style primitives.The paper’s empirical results come from the reference implementation, while the production architecture is drawn from publicly presented material.
- Architecture: Applications connect through a single AI Gateway providing authentication, authorization, routing, rate limiting, observability, and an embedded MCP gateway.The Agent IDP federates with enterprise identity providers and supports OIDC, SSO, MFA, and ABAC.
- Policy enforcement: Requests pass through pre-call and post-call inspection plus an Agent & Tool Access Control stage enforcing role-based tool authorization and per-agent permissions.Redis caches tenant policy for fast lookups, and an administrative portal manages policy.
- Requirement mapping: Shield maps provenance and short-lived credentials to the Agent IDP, attenuation to ABAC and role-based authorization, and model-independent enforcement to gateway policy enforcement.The paper presents Shield as satisfying the same requirements through production components rather than reference primitives.
- Deployment and scale: Shield scales through container replicas for multi-tenant deployment, with Redis-backed policy mapping and GPU-served guardrail models.The guardrail services use VotalAI’s 8B model and NVIDIA’s Nemotron 3.5 content-safety model on H100/B200 GPUs.
- Continuous red-teaming: The system includes a red-teaming portal that continuously probes endpoints with adversarial prompts across single-turn, multi-turn, and combined modes.Its catalog contains over 100 manipulation strategies.
9 Discussion
The discussion argues that content filters cannot substitute for authority governance because they remain probabilistic and inside the assumed-broken model boundary. The broker adds operational deployment cost, but its enforcement and token-minting latency remain far below model-call latency.
- Model-side guardrails: Content filters can reduce successful injection rates but cannot provide the paper’s R1–R8 requirements.They complement, but cannot replace, authority scoping enforced outside the model.
- Deployment cost: The broker adds a mediation point on the tool-call path and a token exchange at each delegation hop.The dominant deployment cost is operating the broker and identity plane rather than request latency.
10 Threats to Validity
The evaluation is bounded by task-size effects, pinned framework versions, and the absence of live-model or production integration. These constraints limit how broadly the quantitative and framework-specific findings should be generalized.
- Scope and measurement: The broker reports absolute reachable counts because blast-radius magnitude depends on task scope relative to environment size.The paper uses a size-independence invariant rather than a single percentage.
- Framework coverage: Framework results apply to specific pinned versions and were established by execution for LangGraph but by code or specification inspection for CrewAI, AutoGen, and MCP.The authors note that frameworks evolve, so the MCP results especially require re-checking against the current authorization specification.
- Deployment boundary: The broker enforces an abstract tool/resource action model, so production policy enforcement depends on faithfully mapping real tool invocations to that model.
- Deployment boundary: The study evaluates the broker but does not yet integrate it into the evaluated frameworks or conduct an end-to-end live-model evaluation.Both integration and live-model evaluation are identified as future work.
11 Ethics and Responsible Disclosure
The paper situates its work as an infrastructure-layer complement to content defenses, framework audits, and governance taxonomies. Its demonstrations use public frameworks and controlled test harnesses, while avoiding attacks on third-party or production systems.
- Responsible evaluation: The demonstrations target public frameworks in a controlled test harness and involve no user data or attacks on third-party or production systems.The paper characterizes the findings as missing authorization primitives rather than exploitable framework defects.
- Relationship to prior work: Field measurements of 7,973 remote MCP servers found over 40% exposed tools without authentication, while all 119 tested OAuth-enabled servers had at least one authentication flaw.The paper presents these findings as a field-scale complement to its specification-level MCP analysis.
- Relationship to prior work: Content- and data-flow defenses address injection or constrain execution plans, whereas this paper moves authorization enforcement outside the model into infrastructure.Progent and FORGE are cited as related examples of deterministic or independent policy enforcement.
- Relationship to prior work: An independent framework audit likewise found no deterministic fail-closed per-call authorization gate by default across its partially overlapping framework set.That work proposes ScopeGate, a five-stage policy decision and enforcement point.
- Contribution: The paper complements governance taxonomies by providing an empirical, standards-grounded gap analysis and composing existing primitives into a broker for agent-to-agent delegation.Its novelty claim is that mature primitives were neither composed nor shipped for untrusted multi-agent delegation.
13 Conclusion
Under an untrusted-model standard, common agent runtimes and frameworks leave delegation authority insufficiently confined. The paper composes existing primitives into a broker that confines hijacked agents to delegated tasks at microsecond cost.
- Default runtimes fail all four core delegation threats, while three of four popular frameworks provide no confinement and the fourth provides only partial confinement.
- No existing standard alone closes the gap, although the primitives needed for stronger agent-to-agent authority governance exist.
- The broker confines a hijacked agent to its delegated task and enforces authorization at microsecond cost.