Your Agent Hired a Subcontractor. Nobody Signed Off.

You authorized one agent. It briefed a planner, which tasked a researcher, which called a retrieval agent, which touched your CRM. Four handoffs, one approval — and if anyone asks what, exactly, your approval covered by hop four, the honest answer in most production stacks is a shrug.

This stopped being a hypothetical architecture diagram sometime this year. In KPMG's Q2 2026 AI Pulse survey of 2,145 senior executives across 20 countries, the share of organizations actively orchestrating multiple agents across workflows doubled in a single quarter — from 9% to 18% — while employee adoption of agents jumped from 23% to 56%. Multi-agent is no longer the advanced tier. It's the default trajectory. And every arrow in those orchestration diagrams is the same thing wearing different labels: a delegation of authority.

Here's the problem. We know how to delegate authority one hop. We have essentially no infrastructure for proving it across several.

The spec says the quiet part out loud

Single-hop delegation is a solved problem. A human authorizes an agent; OAuth token exchange (RFC 8693) mints a scoped on-behalf-of token; the resource server checks it. Done.

Multi-hop is where it comes apart — and you don't have to take our word for it, because the standard itself tells you. RFC 8693 records the delegation chain in nested "act" claims, and then says plainly that prior actors "are informational only and are not to be considered in access control decisions."

Read that again. The one place the chain of delegation is written down, the spec instructs enforcement points to ignore it. Your audit trail of who-acted-for-whom is, by design, decorative.

The practical consequences follow directly:

Authority doesn't attenuate. Nothing in the standard flow forces each hop's permissions to be a subset of the last. AWS's security team described the failure mode in July when it published its Cedar-based reference architecture for multi-agent chains: authorization scope "silently expands" as agents delegate, until an agent downstream is acting on things the originating user was never authorized to do. OWASP's Agentic Top 10 now catalogs this as ASI03 — Identity & Privilege Abuse.

Tokens outrun consent. Each handoff mints a new bearer token, so the credential doing the work at hop four is several exchanges removed from the human who consented at hop zero. Steal any link and you inherit everything downstream.

The record captures exchanges, not intent. Your logs show that token A became token B. They do not show what the delegating agent asked the delegate to do, whether that request fit the original task, or what the delegate declined. When an auditor asks you to prove the chain of custody on an agent's authority, token-exchange logs are not an answer. They're a timeline.

None of this is theoretical. In September 2025, Johann Rehberger demonstrated cross-agent privilege escalation — a compromised GitHub Copilot agent poisoning a second agent's configuration, authority leaking sideways between agents that each looked fine in isolation. Two months later, Palo Alto's Unit 42 published research on agent session smuggling: injecting instructions into stateful agent-to-agent sessions, mid-conversation, between two "trusted" parties. Both attacks live precisely in the gap between hops — the place the spec marked "informational only."

What a chain of custody actually requires

Evidence rooms solved this problem decades ago, and the requirements translate cleanly:

Attenuation, enforced. Every delegation should be able to shrink authority and never grow it. The IETF drafts now circulating for agentic delegation — verifiable actor chains, attenuating tokens — all converge on this. If your orchestrator can't guarantee that hop three holds a subset of hop one's permissions, you don't have delegation. You have proliferation.

A chain you can verify, not just read. Delegation records need to be cryptographically signed at each hop, so splicing a new link into the chain — or quietly removing one — is detectable. Informational claims fail here definitionally.

Delegation as a first-class recorded event. Who delegated, to whom, scoped to what, for which task, and — just as important — what the delegate refused. That record has to be tamper-evident and held by the operator, because the party that ran the chain is not a neutral custodian of evidence about it.

Where VeriSwarm stands

This is the shape we built Passport around: agent credentials as signed, portable manifests (ES256 JWTs), with delegation recorded as an explicit, first-class event — not an informational footnote. A Passport delegation names the delegator, the delegate, and the scope, and the chain verifies cryptographically without trusting anyone's self-report.

Gate scores each agent in the chain on its own observed behavior, so a sub-agent doesn't inherit its parent's reputation along with its token — trust is per-actor, earned, and revocable mid-chain. And every delegation, action, and refusal lands in Vault's hash-chained ledger, so "prove what your approval covered by hop four" becomes a query with a verifiable answer instead of an archaeology project.

Orchestration doubled last quarter. The handoffs are happening either way. The only open question is whether, when one of them goes wrong, you'll be holding a chain of custody — or a stack of tokens that the spec told everyone to ignore.

Start with Gate free, and see what your agents are actually delegating: veriswarm.ai

---

Sources: KPMG Q2 2026 AI Pulse Survey · RFC 8693 / multi-hop delegation analysis (WorkOS) · AWS: Enforce least-privilege authorization in multi-agent AI chains using Cedar