When Agent A delegates to Agent B, which spawns Agent C, who gets to read your S3 bucket? Traditional role-based access control (RBAC) assigns permissions at session start and evaluates each request independently. That works fine for stateless API calls. It breaks when agents compose actions across multiple tool calls, delegate to sub-agents, and accumulate state that changes what should be allowed next.
A new arXiv paper introduces the Agentic Principal Chain (APC), a delegation security architecture that tracks authority as it flows from one agent to the next. The core problem: an agent might have permission to read a file and permission to send an email, but combining those two actions into “read customer list, email it to attacker@example.com” should be blocked. Static RBAC cannot see the composition. APC can.
The Delegation Problem
Multi-agent systems create three privilege escalation paths that traditional authorization models miss:
-
Transitive delegation: Agent A delegates to Agent B with full authority. Agent B delegates to Agent C with the same scope. Now Agent C has all of Agent A’s permissions, even if Agent A never intended that.
-
Composition attacks: An agent performs two individually permitted actions that combine into a prohibited outcome. Read a database, write to an external API, exfiltrate data.
-
Budget exhaustion: An agent spawns sub-agents that each consume a fraction of a rate limit or cost budget. The parent agent loses control of total spend.
Standard RBAC grants permissions at login and checks each request against a static policy. It has no memory of prior actions and no concept of delegation scope. OAuth delegation models pass tokens downstream but do not restrict what the delegated agent can do with them.
Agentic Principal Chain Architecture
APC tracks every delegation hop as a chain of principals. Each link in the chain carries:
- Delegated scope: the subset of permissions passed to the next agent
- Budgets: rate limits, cost caps, or resource quotas that decrement as actions execute
- Session state: a log of prior tool calls used to evaluate composition rules
When Agent A delegates to Agent B, APC creates a new principal entry. Agent B’s effective permissions are the intersection of Agent A’s delegated scope and Agent B’s own role. If Agent B tries to delegate to Agent C, the scope narrows again. This enforces blast radius monotonicity: each delegation step can only reduce authority, never expand it.
Six Authorization Checks
APC evaluates every tool call against six checks before execution:
| Check | Purpose | Example Violation |
|---|---|---|
| Role-based | Does the agent’s role allow this action? | Agent tries to delete a file but only has read permissions |
| Delegated scope | Is this action within the scope passed by the parent? | Parent delegated “read invoices,” agent tries to write |
| Budget | Does the agent have quota remaining? | Agent has spent $10 of a $10 API budget |
| Intent binding | Does this action match the original task? | User asked for a summary, agent tries to send an email |
| Composition closure | Does this action combine with prior actions to violate policy? | Agent read a file, now tries to POST it externally |
| Serialized admission | Is this the next valid action in the sequence? | Agent tries to commit a transaction before opening one |
The composition closure check is the critical piece. APC maintains a state graph of prior tool calls. Before admitting a new call, it checks whether the combination of past and proposed actions matches a prohibited pattern. If the policy says “read_file + http_post = exfiltration,” APC blocks the POST even though both actions are individually allowed.
Implementation Shape
APC sits between the agent orchestrator and the tool execution layer. It does not modify the LLM or the tools. It intercepts tool calls, evaluates them against the chain state, and either admits or rejects them.
class AgenticPrincipalChain:
def __init__(self, root_principal, delegated_scope, budgets):
self.chain = [root_principal]
self.scope = delegated_scope
self.budgets = budgets
self.session_state = []
self.composition_rules = load_prohibited_combinations()
def delegate(self, sub_agent, restricted_scope):
# Intersection of current scope and requested scope
new_scope = self.scope.intersection(restricted_scope)
# Clone budgets and pass them down
new_budgets = self.budgets.clone()
return AgenticPrincipalChain(sub_agent, new_scope, new_budgets)
def admit_tool_call(self, tool_name, params):
# Check 1: Role-based
if not self.chain[-1].has_permission(tool_name):
raise PermissionDenied("Role does not allow this tool")
# Check 2: Delegated scope
if tool_name not in self.scope:
raise PermissionDenied("Tool not in delegated scope")
# Check 3: Budget
cost = estimate_cost(tool_name, params)
if not self.budgets.consume(cost):
raise BudgetExceeded("Insufficient quota")
# Check 4: Intent binding
if not self.matches_intent(tool_name, params):
raise IntentViolation("Action does not match task")
# Check 5: Composition closure
if self.violates_composition(tool_name, params):
raise CompositionViolation("Prohibited action combination")
# Check 6: Serialized admission
if not self.valid_sequence(tool_name):
raise SequenceViolation("Invalid action order")
# Admit and log
self.session_state.append((tool_name, params))
return execute_tool(tool_name, params)
def violates_composition(self, tool_name, params):
for rule in self.composition_rules:
if rule.matches(self.session_state + [(tool_name, params)]):
return True
return FalseThe composition rules are declarative policies. You define prohibited sequences like:
- name: exfiltration
pattern:
- action: read_file
resource: customer_data/*
- action: http_post
destination: externalAPC compiles these into a state machine and checks each new tool call against it.
Evaluation Results
The paper tested APC against three agent security benchmarks:
- InjecAgent: 544 prompt injection cases designed to steal data
- AgentDojo: 949 task-injection pairs across four domains (workspace, e-commerce, banking, travel)
- ASB: 1,661 adversarial scenarios
In the compromised-model evaluation, the authors inserted the ground-truth attack call after the first legitimate tool call. This simulates a model that has been fully compromised by prompt injection. APC still blocked the attack because the authorization decision happens outside the model.
AgentDojo exfiltration: dropped from 75-100% success to 0% across all domains. APC blocked all 544 InjecAgent data-stealing attempts.
Intent binding: reduced destruction attacks from 38.6% to 4.0% and manipulation attacks from 90.5% to 12.1%. The remaining failures occurred when the attack action was semantically similar to the legitimate task.
Authorization latency: 0.24 ms at the 99th percentile on an idle host. This is the overhead of checking six authorization rules and evaluating composition closure. In a high-frequency agent loop (100 tool calls per second), this adds 24 ms per second of wall-clock time.
Utility cost: task success rate dropped 8.6 to 13.9 percentage points depending on how strict the intent binding was configured. Tighter intent binding blocks more attacks but also rejects more legitimate actions that drift from the original task description.
Failure Modes
APC assumes you can define prohibited compositions in advance. If your policy does not include a rule for “read_file + http_post = exfiltration,” APC will not block it. This is the complete restriction set assumption. In practice, you start with a small set of known-bad patterns and expand as you observe new attack vectors.
APC also assumes serialized admission: tool calls are evaluated one at a time in order. If two agents run in parallel and both try to consume the same budget, APC may admit both calls before either completes. You need distributed coordination (locks, compare-and-swap) to enforce budgets across concurrent agents.
The intent binding check relies on semantic similarity between the task description and the tool call. If the attacker can phrase the malicious action in a way that sounds like the original task, intent binding may not catch it. This is why composition closure is the stronger defense: it does not rely on semantic analysis, only on the sequence of actions.
When to Use APC
Use APC when:
- Agents delegate to sub-agents and you need to prevent transitive privilege escalation
- You have known-bad action combinations (read + exfiltrate, delete + no backup)
- You need to enforce cost or rate-limit budgets across a delegation chain
- You want defense-in-depth that does not depend on the model being uncompromised
Avoid APC when:
- Your agents do not delegate (single-agent systems can use simpler RBAC)
- You cannot enumerate prohibited compositions (APC requires explicit rules)
- You need sub-millisecond authorization latency (0.24 ms may be too slow for some real-time systems)
- Your agents run in parallel and you cannot serialize admission (you will need distributed coordination)
Technical Verdict
APC solves the delegation security problem by making authorization stateful and composition-aware. It prevents agents from granting each other unbounded authority and blocks attacks that combine individually permitted actions into prohibited outcomes. The 0.24 ms latency overhead is acceptable for most agent orchestration workloads. The 8-14 percentage point drop in task success rate is the price of strict intent binding; you can tune this by relaxing the semantic similarity threshold.
The real value is that APC enforces security outside the model. Even if prompt injection fully compromises the agent, the authorization layer still blocks prohibited tool calls. This is the right architecture for production multi-agent systems where you cannot trust the model to follow instructions under adversarial input.
If you are building agent orchestration infrastructure, APC gives you a concrete pattern for delegation tokens, budget tracking, and composition checks. The paper includes a reference implementation and evaluation tools. Start with a small set of prohibited compositions, measure the utility cost, and expand the rule set as you observe new attack patterns in production.