Delegation without trust: what a hijacked sub-agent still must not be allowed to do
If a sub-agent can be hijacked, what is it still not allowed to do?
Opening
An agent that acts for a user holds credentials, calls tools and services, and spawns sub-agents that act further on its behalf. That turns an old distributed-systems question, who is authorized to do what and on whose authority, into an urgent one, because the component driving each agent is a language model an adversary can hijack. Builders usually answer that question inside the prompt: the model is told what it may do. The paper’s premise is that a told model is not a guarded model, and the gap between the two is where delegation fails.
What the paper does
The authors argue that agent security must be judged under an untrusted-model assumption, where a correct system is one in which a prompt-injected agent still cannot step outside the authority handed to it. Against that standard they offer three contributions. They derive a threat model centered on four adversaries and eight security requirements. They show the gap is real: a default agent runtime modeling common practice fails all four threats, and across four widely used frameworks, three provide no built-in confinement and one only partial. They then implement an authorization broker and evaluate it adversarially. It blocks all four threats, resists 11 direct attacks on its design, and accepts 0 of 200,000 forged tokens.
Findings
The bar to hold agents to — Security is judged on the worst case, an agent whose instructions have been taken over, and on that definition a takeover that buys extra authority is a broken system.
a fully prompt-injected agent still cannot exceed the authority explicitly delegated to it
Four ways delegation goes wrong — The threat model names the failure modes a governed system has to survive: confused deputy, token theft and replay, prompt-injection privilege escalation, and compromised sub-agents.
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
The common frameworks leave the door open — Surveyed against the requirement set, most widely used stacks offer no built-in confinement at all, and the one that does covers only part of what the set demands.
three provide no built-in confinement and one only partial
Caveat
The authors state no conventional limitation. What they state instead is the bar: security must be evaluated under an untrusted-model assumption, where a prompt-injected agent cannot step beyond the authority handed to it. Their evidence answers that bar for the four threats in their model and the four frameworks they test, and stops there.
What this means for 5ac
5ac agents hold credentials and spawn children, so all four adversaries are live in the Kanban stack: a child card inheriting broad access, a token reused where it should not be, injected text in a fetched page, a sub-agent that outlives its task. The change is to move authorization out of the prompt and into the runtime gate. Each profile gets the narrowest scope its cards need, delegation carries an explicit authority envelope, and the check happens at decision time, where the paper’s 2.6 microseconds per decision is nothing against model inference. A reviewer card then becomes an authority boundary rather than a courtesy.
Source
- Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems — https://arxiv.org/abs/2609.00267