Delegation Tokens: Secure Multi-Agent Pipelines
Modern AI systems use orchestrator agents that delegate tasks to specialized sub-agents. Delegation tokens let you share secret access across agent boundaries without ever sharing the secrets themselves.
The Multi-Agent Problem
A single AI agent rarely works alone. In practice, an orchestrator agent breaks a complex task into sub-tasks and delegates each one to a specialized agent. A deployment agent might delegate database migration to a migration agent, API testing to a testing agent, and monitoring setup to an observability agent.
The question is: how do you give the migration agent access to the database password without handing over the raw secret? And how do you ensure the migration agent cannot pass that access to yet another agent with broader permissions?
Without a structured delegation mechanism, teams resort to sharing secrets directly, copying credentials between agent contexts, or giving all agents the same broad permissions. Each of these approaches expands the attack surface.
How Delegation Works
Delegation tokens create a chain of trust from the original scope grant holder down to sub-agents, with each link in the chain having equal or narrower permissions.
The orchestrator agent has an existing scope grant for production/api-key with exec and template actions, valid until March 1st, with 100 remaining uses.
The orchestrator requests a delegation token for the sub-agent with a reduced scope: only exec action, valid until February 15th, with a maximum of 10 uses. The NL System verifies this is a valid subset and issues the token.
The sub-agent presents the delegation token to the NL System when making action requests. The system validates the token, checks the narrowed scope, and allows the action within those bounds.
When the orchestrator's access is revoked -- whether manually, by expiration, or by exhausting its use count -- all delegation tokens derived from that grant are automatically revoked. No orphaned permissions persist.
Orchestrator Agent | Scope: [exec, template] | max_uses: 100 | until: Mar 1 | |-- delegates to --> Migration Agent | Scope: [exec] | max_uses: 10 | until: Feb 15 | |-- delegates to --> Testing Agent Scope: [exec] | max_uses: 5 | until: Feb 10 If Orchestrator is revoked => both tokens are automatically invalidated
Key Security Properties
Every delegation reduces scope. This is the subset rule in action: the delegated token can only have permissions that are a subset of the delegator's permissions. No agent in the chain can gain more access than the agent above it. Privilege escalation is structurally impossible.
The protocol enforces a configurable maximum delegation depth (default: 3). This prevents infinite delegation chains where trust becomes impossible to reason about. Agent A can delegate to Agent B, and Agent B can delegate to Agent C, but Agent C cannot delegate further if the depth limit is 3.
Delegation tokens can be optionally bound to a specific agent identity using HMAC-based proof. This means that even if a token is intercepted, only the intended recipient agent can use it. The binding ties the token to the agent's cryptographic identity, preventing token theft.
Revoking a parent's access automatically revokes all downstream delegations. This is recursive: if Agent A is revoked, Agent B's delegated token is revoked, and Agent C's sub-delegation is also revoked. There is no way for a downstream agent to retain access after its upstream chain is broken.
Real-World Example
Consider a deployment orchestrator agent that manages a code release. The orchestrator has access to the production database password, the deployment API key, and the monitoring service token.
When it delegates the database migration task to a specialized migration agent, it creates a delegation token that grants access to only the database password, with only the exec action type, and a max_uses of 5 (enough for the migration script plus a verification query).
The migration agent cannot access the deployment API key or the monitoring token. It cannot use the database password for anything other than executing commands. And after 5 uses, the token is exhausted -- even if the migration agent is compromised, the blast radius is strictly bounded.
{
"type": "delegate",
"from_agent": "nl://deploy/orchestrator",
"to_agent": "nl://deploy/migration-agent",
"scope": {
"secret": "production/db-password",
"actions": ["exec"],
"conditions": {
"max_uses": 5,
"valid_until": "2026-02-09T12:00:00Z"
}
},
"bind_to_agent": true
}