I Opened an AI Delegation Spec PR at 3 AM. Here's What It Solves.

I opened the PR at 3:04 AM on March 15. What it proposes is a formal specification: a precise description of how AI agents should pass authorization to other AI agents as they spin up sub-agents in a chain.

Nobody asked for this yet. But every multi-agent pipeline running in production right now is carrying a structural vulnerability, and I needed the language to explain why before the first incident reports start coming in.

This is D-004 in the Open Agent Passport specification, up for review as PR #26. Here's what it fixes and why you should care.

TL;DR

• Orchestrators spawning sub-agents today hand down full permissions with no chain of custody
• Two failures follow: scope escalation (sub-agents grab capabilities they were never meant to have) and chain opacity (no audit trail back to who authorized what)
• D-004 formalizes signed delegation tokens that must scope-narrow at each step, with hard depth limits and a chain_root_passport_id that traces every downstream action back to the root principal
• Delegation tokens expire by design; scope can only narrow, never expand; cryptographic proof links every step in the chain
• This authorization layer is missing from every multi-agent system in production today

What breaks when AI agents call other AI agents

Single-agent authorization is a solved problem. You issue a token, scope it, verify it. The tooling exists. Companies ship it.

The problem is what happens when Agent A (orchestrator) spawns Agent B (research worker), which spawns Agent C (web browsing sub-agent). That's a completely normal pattern. Claude Code does it. LangGraph does it. AutoGen does it.

Here's what happens to authorization inside those chains: nothing deliberate.

Most multi-agent frameworks inherit the orchestrator's credentials down the whole chain. Agent C ends up with the same permissions as Agent A. This is the classic confused deputy problem, translated into agentic systems. AWS called it out explicitly in their Agentic AI Security Scoping Matrix: "ensuring that agents don't allow a human or system to do more than what the initiating entity is authorized or entitled to do" is a required property of any higher-scope multi-agent deployment.

The second failure is chain opacity. When Agent C takes an action, which principal authorized that action? The orchestrator? The user who triggered the workflow 5 steps ago? Without a chain trail, you can't answer that question. And if you can't answer it, you can't audit it, govern it, or stop the next one.

An IETF working group is actively drafting standards for AI agent auth delegation right now (draft-klrc-aiagent-auth-00). This problem is real enough that the IETF has people building OAuth chaining extensions specifically for agentic contexts. The industry knows it. The formal tooling isn't there yet.

The contractor analogy

Think about how construction authorization works. You hire a general contractor and give them the authority to build your house. They hire sub-contractors: an electrician, a plumber, a drywaller.

You never authorized the electrician to touch your gas line. You authorized the GC, and the GC's authority should bound what they can delegate downward. The electrician works within their scope. They can't expand it. If the GC delegates the entire site to the electrician, that's a legal and safety violation.

Today's multi-agent systems treat every sub-agent like the GC: full authority inherited, no restrictions, no paper trail. That is not how you would run a construction site, and it is a bad way to run an agent pipeline that has access to your production database, your customers' data, or your external APIs.

What delegation chains actually look like

D-004 formalizes five design decisions. Each one closes a specific gap.

1. Scope-narrowing is a MUST. An enforcement adapter at the delegation step rejects any token where the sub-agent's scope is not a strict subset of the parent's scope. You cannot grant what you don't have. This rule is enforced at two points: issuance (the token can't be created with broader scope) and verification (the adapter rejects it even if it somehow was created that way).

2. Depth cap at 3 by default, 8 maximum. This covers the realistic architectures: orchestrator, worker, tool-calling sub-agent. Three levels deep covers most real production pipelines. If you need 9 levels of nested agents, that's a system design problem before it's an authorization problem. The cap is configurable, but every deployment must set one.

3. expires_at is required. No delegation token without an expiry. There's no "never expires" option in the spec. Persistent sub-agents that need ongoing access should hold their own passport instance with its own lifecycle. Delegated tokens are ephemeral by design.

4. chain_root_passport_id propagates through every link. Every action taken by any agent in the chain carries the ID of the original root principal: the human, the API key, or the authorized service that started the entire workflow, not the orchestrator one link up. This is the forensic layer. Any logged action is traceable.

5. Same crypto as the core spec. JCS + Ed25519. No new key infrastructure, no new trust model. If you're already running OAP passport verification, D-004 extends that infrastructure instead of replacing it.

Here's what a delegation token looks like in the spec:

{
  "passport_id": "oap_sub_abc123",
  "chain_root_passport_id": "oap_root_xyz789",
  "parent_passport_id": "oap_orch_def456",
  "depth_remaining": 2,
  "scope": ["read:emails", "draft:reply"],
  "parent_scope": ["read:emails", "draft:reply", "send:emails", "delete:emails"],
  "expires_at": "2026-03-15T06:00:00Z",
  "sig": "ed25519_jcs_..."
}

The parent's scope included send:emails and delete:emails. The delegation token strips those. The sub-agent never sees them. When Agent C attempts to call the send-email tool, the enforcement adapter checks this token and returns error D-004-07: scope_not_delegated. Hard stop. No override path.

The spec defines 10 error codes covering every failure case in the chain verification algorithm: missing chain_root, depth exceeded, scope violation, expired token, signature mismatch, and more. Each one is machine-readable and maps to a specific enforcement action.

How D-004 compares to current framework behavior

Property	Most frameworks today	D-004 delegation token
Sub-agent scope	Inherits parent's full scope	Must be strict subset of parent scope
Depth limit	None	Default 3, max 8
Token expiry	Session lifetime / no expiry	Required expires_at, no "never expires"
Chain traceability	Log shows "orchestrator acted"	chain_root_passport_id on every action
Enforcement point	None / application-layer only	Adapter at tool-call dispatch
Scope violation behavior	Silent success	Error code D-004-07: scope_not_delegated

This table is also why you can't bolt D-004 onto an existing framework externally. The enforcement point sits inside the tool dispatch path.

What D-004 does not cover

This is not mutual TLS between agents or an authentication protocol for inter-agent communication. Authentication (who is this agent?) and authorization (what can this agent do in this specific workflow?) are separate concerns.

D-004 handles authorization scope and chain traceability within a delegation flow. The OAP passport itself handles agent identity and authentication. These two layers compose together; they are different layers.

You also cannot bolt this onto existing frameworks without changes. Enforcement adapters need to be integrated into the tool-call layer, not wrapped around it externally. If the framework doesn't support OAP passport verification at the tool dispatch level, delegation tokens have nothing to hook into.

Zero trust between agents

A Security Boulevard analysis makes the same core argument: zero trust for multi-agent systems requires treating every agent-to-agent call as an untrusted crossing, with no implicit inheritance.

I've written before about why pre-action authorization is the missing security layer for AI agents, and how logged tool calls reveal what agents actually do versus what they're supposed to do. Delegation chains are the next layer in that stack. You can't enforce pre-action authorization across a multi-agent system if you can't answer "which principal is actually requesting this action right now?"

My experience building cross-border payment systems taught me one thing about trust at scale: authorization that can't be traced can't be trusted. Fintech built KYC because financial risk is impossible to price without knowing who authorized what. The regulatory paperwork came second. Multi-agent AI is about to discover the same principle. The only question is whether the industry builds the infrastructure first, or builds it after the first major incident.

The spec is open and reviewable at aporthq/aport-spec. PR #26 has the full design rationale, including the comparison table for how D-004 relates to the aeoess Agent Passport System delegation approach. Read Section 3.2 (chain verification algorithm) and the error code table. Those are the enforcement points your multi-agent system needs.

What's your multi-agent auth setup?

If you're running multi-agent pipelines in production today: are your sub-agents operating with scoped tokens or inheriting full orchestrator permissions? Do you have a chain of custody that traces actions back to the root principal?