DM Explains · No. 022 · Governance
Secure multi-agent federation: who checks an AI agent's ID at the border
When an agent from one company calls an agent or tool in another, nothing standard proves who it is, what it may do, or who it answers to. A cluster of 2026 IETF drafts is trying to fix that.
· 15 min read
Read me first
Agents can already send each other messages across company lines, but almost nothing checks who sent the message or how much power it is allowed to carry. A cluster of 2026 IETF drafts fixes the plumbing: cryptographic identity, authority that can only shrink on the way down, and revocation that kills whole branches at once.
The household agent, spawned on Papa's behalf, calls the electrician's scheduling agent → 1 presents a cross-domain credential, no prior registration → 2 shows its spawn chain back to the household root → 3 the requested scope (confirm one appointment) narrows, passes → 4 discloses only the appointment-slot claim, not the whole calendar → 5 a three-part signed chain binds intent, evaluation and receipt → 6 when the repair is cancelled, revoking the root kills this delegated grant too → 7 the scheduling agent's gateway logs the call before acting
Papa asks the household agent to book a repair. That agent calls the electrician's own scheduling agent to find a slot. Nothing about this is strange from a human point of view — one business calling another to confirm an appointment happens every day. But the electrician's scheduling agent has never seen Papa's agent before. It has no record of who sent it, no way to know whether it is really acting for Papa, and no way to know how much it is allowed to commit to — one slot, one week of slots, or the whole calendar.
If the receiving system trusts a bare claim, it can be impersonated or talked into over-committing. If it refuses every caller it hasn't pre-registered, agent-to-agent workflows across companies simply never get built. Protocols such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) define how the message is shaped and delivered. None of the dominant ones define how the receiving side verifies identity, authority, and the chain of hand-offs behind a call — and in 2026 that gap moved from academic footnote to a crowded field of competing IETF Internet-Drafts.
Everyday picture. Dadi keeps the house key but will only lend a copy to a visiting cousin after checking a signed letter from the cousin's own parents vouching for them — not just taking the cousin's word for it. Papa gives Arjun a fixed snack budget; if Arjun asks Meera to run the errand instead, he can only hand her an equal or smaller budget, never a bigger one.
Where the picture breaks. Dadi's trust decision is a one-off human judgement call, and the household never keeps a formal, logged record of who delegated what to whom. The protocol's version of this is a repeatable cryptographic check, applied automatically to every single request, with the whole delegation graph kept on record so it can be unwound later.
Why it exists now
The problem is not that agents can't talk to each other — MCP and A2A already solve that. The problem is that once Agent A spawns Agent B, and Agent B calls a resource in another company, nothing in the current standards tells that resource how to verify that Agent B was legitimately spawned, or that its permissions weren't quietly escalated along the way. The Agent-to-Agent Trust draft names this gap directly as unresolved in production-style agent chains.
Through 2025 and into 2026, a wave of IETF drafts converged on the same diagnosis from different angles: draft-diaconu-agents-authz-info-sharing tackles sharing authorization information across domains, draft-pidlisnyi-aps proposes a full "Agent Passport System", draft-sato-soos-mad specifies delegation inside "sovereign object systems", and an academic survey, InterSAGE, compares itself against more than 50 prior efforts spanning agent protocols, decentralised identity, OAuth extensions, zero-trust governance and audit architectures. That number alone says the field recognises this as a real, unsolved layer rather than a solved problem waiting for adoption.
Existing governance frameworks don't fill the gap either. A review of federated governance for agentic AI systems found that standards such as the NIST AI Risk Management Framework 1.0 and ISO/IEC 42001:2023 state organisational control principles but provide insufficient technical specification for runtime policy enforcement in multi-agent systems — see the technical architecture review. Policy documents say agents should be accountable; they don't say what bytes get signed when an agent crosses a company boundary.
How it works
Cross-domain ID
Prove who you are without ever having met before
What it is. An agent arriving at a foreign domain for the first time establishes a verifiable identity on the spot, with no prior registration required.
Why it exists. A receiving Authorization Server cannot grant anything to a caller it has no way to recognise. Pre-registering every possible caller from every possible organisation doesn't scale once agents start calling agents.
Where it breaks. Dynamic identity only moves the trust question; it doesn't answer it. If the foreign domain has no way to check who is behind the signature on the credential, a convincing forgery looks identical to a legitimate first-time caller.
How that's handled. The identity artifact is anchored to something checkable — a certificate authority, a key the issuing domain controls — rather than left as a self-asserted claim.
In technical terms
In technical terms: draft-diaconu-agents-authz-info-sharing proposes extending OAuth 2.0 Client-ID Metadata Documents with W3C Verifiable Credentials, so an Authorization Server can establish dynamic identity across domains without pre-registration.
Spawn provenance
Every sub-agent must show its papers back to its parent
What it is. When one agent spawns a second to carry out a sub-task, the new agent's origin is traceable cryptographically back to a known root, not just asserted.
Why it exists. Multi-agent systems build long chains of delegation. A resource three hops down that chain has no direct relationship with whoever started it, and needs some way to verify the whole lineage.
Where it breaks. The Agent-to-Agent Trust draft states plainly that no current standard defines how a resource verifies that a spawned agent was legitimate, or that its scope wasn't quietly escalated — this is exactly the gap these drafts are racing to close, not an already-solved problem.
How that's handled. New agents are created from certificate-authority-signed templates, so verifying a spawn chain means walking back through signatures rather than trusting a claim at face value.
In technical terms
In technical terms: the draft specifies that agents obtain verifiable identities via CA-signed templates, with spawn chains cryptographically established and validated at each hop.
Scope narrows?
Can only shrink, never grow
What it is. Authority is modelled so that each delegation step can only reduce what a sub-agent is allowed to do, never expand it.
Why it exists. Privilege-escalation attacks in delegated systems typically happen because nothing structurally prevents a child agent from ending up with more power than its parent meant to grant.
Where it breaks. The lattice only constrains what the protocol can express. A policy engine that misclassifies one dimension — treats "spend" as unrestricted when it should be capped, say — can still let an escalation through, because the mathematics only works if the engine applies it correctly.
How that's handled. The constraint is built into the definition of delegation itself, as a function that is only allowed to move in one direction across the lattice.
In technical terms
In technical terms: the Agent Passport System models authority as a point in a product lattice across seven constraint dimensions — scope, spend, depth, time, reputation, values and reversibility — and defines delegation as a monotone function that can only move downward across that lattice. draft-sato-soos-mad specifies the same narrowing property as invariant INV-4.
Selective disclosure
Show the permit, not the whole file
What it is. An agent proves the one authorization claim a verifier actually needs — "authorised to confirm one appointment" — without exposing its home domain's entire attribute set.
Why it exists. Forcing an agent to hand over its full credential bundle just to prove a narrow permission leaks organisational detail that the receiving domain had no business seeing.
Where it breaks. Selective disclosure protects against over-exposure of information, not against a wrongly scoped claim. If the single disclosed permission was mis-issued upstream, hiding the rest of the file doesn't fix that.
How that's handled. Verifiable credential techniques let the proof be narrow by construction, cryptographically tied to the one claim rather than the whole document.
In technical terms
In technical terms: draft-diaconu-agents-authz-info-sharing builds selective disclosure on the same Verifiable Credential machinery used for dynamic cross-domain identity.
Signed policy chain
Identity proves who, policy decides what, today
What it is. Static cryptographic identity is kept separate from the dynamic policy decisions that govern behaviour, with each action producing its own signed record.
Why it exists. Organisations need to change behavioural rules — new spend limits, new approved vendors — without reissuing every agent's cryptographic identity each time a rule changes.
Where it breaks. Separating identity from policy adds a moving part that itself has to be secured. If the policy engine's signing key is compromised, every receipt it has ever issued becomes suspect, even though the underlying identities are still intact.
How that's handled. Each action's record binds intent, the policy evaluation, and a receipt together, so an auditor can later reconstruct exactly which policy version was applied and when.
In technical terms
In technical terms: the Agent-to-Agent Trust draft uses a dual-signature model separating cert-based identity from policy-engine gated dynamic policy; the Agent Passport System extends this to a three-signature chain binding intent, evaluation and receipt.
Illustrative: Papa's household agent spawns, gets an Ed25519 passport → delegates to the electrician's scheduling agent → authority narrows from full calendar access to confirm-one-appointment only → agent confirms Tuesday 2pm, receipt logged → repair is cancelled → revocation trigger fires on the root grant → cascade revocation invalidates the scheduling delegation and any sub-delegation it made → chain terminated, nothing lingers
Cascade revoke
Cut one, the whole branch dies
What it is. Revoking a single delegation automatically invalidates every descendant delegation that was spawned from it.
Why it exists. Cutting off a compromised agent is pointless if its sub-agents keep holding valid authority. A revocation has to propagate down the whole branch it created, not just stop at one node.
Where it breaks. This only works if every delegation was logged into the graph in the first place. An out-of-band hand-off of authority — one agent passing a credential along a channel the system never recorded — defeats cascade revocation entirely, because there's nothing in the graph to cascade through.
How that's handled. The delegation graph is tracked explicitly as part of the protocol, with propagation requirements specified rather than left as an implementation detail.
In technical terms
In technical terms: the Agent Passport System implements cascade revocation so that revoking any delegation invalidates all descendant delegations; draft-sato-soos-mad specifies the same propagation requirement at what it calls the GEC layer.
Gateway + audit
Nothing privileged happens off the record
What it is. Every privileged action routes through a single enforcement gateway that checks the delegation and policy chain and signs a receipt afterwards.
Why it exists. Scattering credential checks across many services means any one of them can be skipped by accident or bypassed on purpose. A gateway that alone holds the real API credentials closes that gap.
Where it breaks. The gateway becomes a single point of trust and a single point of failure. If it is bypassed, or its signing key is stolen, the audit trail it produces is worthless even though it looks intact.
How that's handled. The gateway's own implementation is tested and published openly rather than left as a black box, so the enforcement logic itself can be inspected.
In technical terms
In technical terms: the Agent Passport System routes privileged actions through a 120-tool MCP server as its enforcement gateway (as of 2026), with reference implementations covering 1,634 tests across 85 modules, published as open-source SDKs under Apache-2.0 (as of 2026).
Compared with what came before
| Old way (single domain) | Federated agent trust | |
|---|---|---|
| Who can call | Pre-registered clients only | Any agent, verified on first contact |
| Authority across hops | Implicit, trusted by convention | Explicit, mathematically narrowing |
| Revocation | Revoke one credential | Cascades through the whole delegation branch |
| Audit | Logs, if anyone built them | Signed receipts by design |
| Governance frameworks | NIST AI RMF, ISO/IEC 42001 state principles | Drafts aim at runtime enforcement, not just principles |
The judgement these drafts share is blunt: writing down principles about accountable AI, as NIST AI RMF 1.0 and ISO/IEC 42001:2023 do, is not the same as having a protocol that enforces them when an agent from another company calls in at 2am. None of this is settled standard yet — these are drafts, several competing with each other, and adoption is unproven.
Where it breaks
Not formal verification of behaviour
These architectures govern identity, authority and audit trails. They explicitly do not verify that an agent's behaviour is correct or safe — the federated governance review names this as an unresolved research challenge, not something the protocols claim to solve. An agent can be perfectly authenticated and still act badly within its scope.
The whole structure assumes every delegation gets logged into a graph that revocation can later cascade through. Out-of-band authority — a credential handed over outside the protocol — breaks cascade revocation silently, because nothing is there to cut. The enforcement gateway concentrates risk rather than removing it: it is a single point where a stolen signing key undoes every receipt it ever issued. And separating cryptographic identity from policy evaluation, while useful for updating rules without reissuing identities, means a compromised policy engine can issue signed-looking receipts for decisions it never should have made.
Cross-tenant model training is a related but different problem. Federated privacy work for agent systems recommends secure aggregation so that an aggregation service cannot observe each participant's individual model update — but that is a data-privacy concern during training, distinct from runtime identity and authorization during live agent calls.
Numbers to carry
| Figure | What it means |
|---|---|
| 7 | Constraint dimensions in the Agent Passport System's authority lattice: scope, spend, depth, time, reputation, values, reversibility |
| 3 | Signatures in the Agent Passport System's policy chain: intent, evaluation, receipt |
| 120-tool | Size of the Agent Passport System's MCP enforcement gateway, as of 2026 |
| 1,634 tests / 85 modules | Scale of the Agent Passport System's open-source reference implementations, as of 2026 |
| 50+ | Number of prior efforts InterSAGE compares itself against |
| Ed25519 | Signature algorithm used for Agent Passport System identity |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| "MCP and A2A already handle agent security." | They define message and tool-call formats; neither standard defines how a receiving domain verifies identity or authority. |
| "A signed credential proves the agent is trustworthy." | It proves who issued the claim, not that the claim was scoped correctly or that the issuer behaved well. |
| "Revoking a compromised agent is enough." | Without cascade revocation across the delegation graph, its already-spawned sub-agents can keep acting on inherited authority. |
| "This is a solved, standardised problem now." | These are competing IETF Internet-Drafts in 2026, not ratified standards; adoption and convergence are still unresolved. |
| "Governance frameworks like ISO/IEC 42001 already cover this." | They state organisational principles; the review found they provide insufficient technical specification for runtime enforcement. |
Worked example
- Papa's household agent is asked to book a repair, and it calls the electrician's scheduling agent across a domain it has never dealt with before.
- The scheduling agent's Authorization Server checks the household agent's identity using a Verifiable Credential presented dynamically, with no pre-registration required.
- The household agent discloses selectively: only the claim that it is authorised to confirm one appointment, not its full organisational profile.
- Illustrative: the household agent's authority is capped at confirming a single slot within one week and a notional ceiling of a few hundred rupees in call-out fees, and when it delegates part of the task to a narrower sub-process, that sub-process can only inherit an equal or smaller slice of that authority — never more.
- The scheduling agent's policy engine evaluates the request against its own rules, and the exchange produces a signed receipt: intent, evaluation and outcome, bound together.
- All of this routes through the electrician's enforcement gateway, which alone holds the real calendar credentials — the household agent never touches them directly.
- The repair is later cancelled. Papa's household agent revokes the original delegation, and the cascade takes the sub-process's inherited authority down with it in the same step.
Should you use it?
This layer matters when agents genuinely cross organisational lines — calling another company's MCP servers, delegating through chains of sub-agents, or operating under regimes that demand a tamper-evident record of autonomous decisions. It is not needed inside a single domain where every agent already shares one Identity Provider and one Authorization Server, and it says nothing about whether an agent's behaviour is sensible — that remains a separate, unresolved problem.
The cheapest first experiment is not adopting any one draft wholesale. It's mapping the delegation graph your own agents already create informally — who spawns whom, what authority each hop actually carries — before deciding whether any of these protocols fit the shape of it.
Say it in the room
"Treat every cross-company agent call like an unregistered visitor at the door: verify identity on the spot, hand over only the narrowest permission the task needs, and make sure cutting it off later cuts off everything it spawned."
Lines to carry
- "Authority can shrink on the way down, never grow."
- "Revoke the root, and every branch dies with it."
- "Prove the one claim a verifier needs, not your whole file."
- "Identity says who; policy says what, today."
- "Nothing privileged happens off the record."
- "These are drafts racing each other, not a finished standard."
FAQ
Does MCP already solve agent identity?
No. MCP standardises how an agent connects to tools and data sources; it doesn't specify how the tool's side verifies who the calling agent is or what it's allowed to do. That verification layer is exactly what these federation drafts are trying to add alongside it.
Is any of this a ratified standard yet?
No. Everything described here — the cross-domain identity drafts, the Agent Passport System, the sovereign-object-system delegation model, InterSAGE — is an active IETF Internet-Draft or academic proposal as of 2026, several competing for the same ground. None has been adopted as a ratified RFC in the dossier's sources.
What stops a sub-agent from just claiming more authority than it was given?
The monotonic narrowing property: delegation is defined as a function that can only move an authority value downward across the lattice, never upward. That's a mathematical constraint on what the protocol can express, but it only holds if the policy engine applying it is implemented correctly.
What happens if the enforcement gateway itself is compromised?
Everything downstream of it is suspect, because the gateway alone holds the real credentials and signs the receipts everyone else relies on for audit. Concentrating enforcement in one place removes many smaller risks but creates one large one.
Is this the same as federated learning?
No. Federated privacy work for agent systems is about training models across organisations without exposing individual contributions, using techniques like secure aggregation. Federation trust, as covered here, is about runtime identity and authority when agents call each other — a separate problem.
Glossary
- Agent — software, often built on a large language model, that can take actions or call tools on someone's behalf.
- MCP (Model Context Protocol) — a protocol letting agents connect to external tools and data sources in a standard way.
- A2A (Agent-to-Agent) — a protocol family for direct communication and delegation between agents, potentially across organisations.
- Federation — letting systems in separate administrative domains trust and interoperate without merging into one domain.
- Identity Provider (IdP) — a service that issues and verifies digital identities within a domain.
- Authorization Server (AS) — a service that decides what an authenticated identity may do and issues access tokens.
- Verifiable Credential (VC) — a digitally signed, tamper-evident claim that any verifier can check cryptographically.
- OAuth 2.0 Client-ID Metadata Document — an extension letting a client describe itself so it can be recognised without pre-registration everywhere.
- Delegation chain — a sequence of hand-offs of authority, from a human to an agent, to a sub-agent that agent spawns.
- Monotonic scope narrowing — a rule that each delegation step can only reduce, never increase, passed-along permissions.
- Cascade revocation — automatically invalidating all delegated permissions descended from a permission once it is revoked.
- Product lattice — a structure combining several ordered dimensions so "more authority" and "less authority" can be compared consistently.
- Ed25519 — a fast, compact, cryptographically strong digital signature algorithm.
- Enforcement gateway — a control point through which all sensitive actions must pass so checks can't be bypassed.
- Secure aggregation — a technique letting a central service combine many parties' contributions without seeing any individual one.
- Differential privacy — adding controlled noise to data so no individual's contribution can be reliably singled out.
- Internet-Draft (I-D) — a working document submitted to the IETF proposing a standard, not yet ratified as an RFC.
Sources
- draft-diaconu-agents-authz-info-sharing-01: Sharing Authorization Information Across Domains in Distributed Multi-Agent Systems — IETF Datatracker, 2026
- Agent-to-Agent Trust, Identity, and Verifiable Provenance — IETF, 2026
- A Technical Architecture for Federated Governance of Agentic AI Systems — Exa.ai Library, 2026
- draft-pidlisnyi-aps-00: Agent Passport System (APS) — IETF Datatracker, 2026
- InterSAGE: The Secure and Verifiable Interoperability Protocol for An Internet of Agents — arXiv, 2026
- draft-sato-soos-mad-05: Multi-Agent Delegation in Sovereign Object Systems — IETF Datatracker, 2026
- draft-kale-agntcy-federated-privacy-02: Federated Privacy for Agent Systems — IETF Datatracker, 2026