DM Explains · No. 029 · Governance
Security-aware agent federation: AI agents cooperating without a spying boss
A cluster of new protocols lets AI agents from rival organisations work together and prove the system is healthy, without any single operator seeing what they actually did.
· 16 min read
Read me first
Federation protocols genuinely let AI agents from rival organisations cooperate and prove the system is healthy, but only because no one — not even the platform carrying the messages — is trusted enough to see inside.
Meera's school trip committee: her agent self-certifies ID (1) → links across the two vendor domains (2) → gets a scoped delegation covering only cost-splitting (3) → the operator transports the request blind to content, confirming delivery only (4) → a disagreeing pickup-scheduler agent is fenced off, 0.0 split-brain rounds vs 794.5 unfenced (5, f1) → shared attack detectors flag nothing suspicious without seeing either tenant's data (6) → ProVerif-style formal proof confirms the access token stayed secret (7, f13) → settlement released, 84% of Wardenships independently verified (f2)
Two companies' AI agents need to jointly schedule a school pickup and split the cost of a trip. Neither company trusts the other's server. Neither trusts the platform carrying messages between the two agents. A normal integration would route everything through one party's system, which means that party sees every message, every schedule, every rupee. The stakes are not abstract: an agent can be impersonated, a compromised agent can quietly act outside its mandate, two agents can disagree about what state the system is in and both proceed as if they're right (split-brain), or the "neutral" platform in the middle becomes an accidental spy on everyone's business.
Everyday picture. Meera and a cousin from another house both want Bruno to carry a note between them, settling who owes what for a shared gift. Neither family trusts the postman in between to read the note or keep a log of who writes to whom — the postman should only be able to confirm that the post is running, nothing more.
Where the picture breaks. Bruno still physically carries something observable: his route, his timing, how often he trots between houses. A courier always gives something away. Real federation protocols use cryptography to hide even that metadata, which no dog or postman can manage.
Why it exists now
The problem is old — any two parties who don't trust each other or their middleman have faced it since the first cross-border contract. What's new is that the parties doing the negotiating are now software that acts on its own, at machine speed, across organisational boundaries, with no human reading every message. That changes the threat model from "can this person be trusted" to "can this signature, this identity, this scope of authority be verified automatically, every time, without a human in the loop."
Through 2026 several concrete pieces arrived at once rather than staying theoretical. The PRIMUS paper published formal, measured results on eliminating split-brain failures in multi-agent federations (PRIMUS: Identity, Governance, and Verification for Multi-Agent Federations — arXiv, 2026). AFP published a working specification built on self-certifying identity and zero-knowledge cryptography (Agent Federation Protocol Specification — afp.dev). The OpenID Foundation published a protocol-agnostic threat classification for authorisation across organisational boundaries (A Protocol-Agnostic Threat Classification for Cross-Boundary AI Agent Authorization — OpenID Foundation, 2026), stating that agentic federation is a permanent architectural reality rather than a passing phase. Two IETF drafts began standardising the handshake and delegation steps. And a peer-reviewed paper at NDSS delivered the first formally verified protocol with a working reference implementation (SAGA: A Security Architecture for Governing AI Agentic Systems — NDSS Symposium, 2026). This is the moment these ideas stopped being position papers and started being specifications with measured numbers attached.
How it works
Self ID
An identity no one else can switch off
What it is. Each agent gets an identity that proves itself cryptographically, rather than one issued and controlled by whoever happens to be hosting it.
Why it exists. If an agent's identity depends on whichever server it's running on, moving it — or an attacker spoofing it — breaks or forges that identity trivially.
Where it breaks. AFP uses KERI-aligned, self-certifying identity, where the agent itself is the root of trust. SAGA instead has agents register with a central Provider that stores contact details and access policies — reintroducing the kind of trusted third party that self-certifying identity was meant to avoid.
How that's handled. Self-certifying identity survives changes of host; a Provider model is simpler to reason about but concentrates trust.
In technical terms
In technical terms: AFP's identity layer is built on KERI-aligned self-certifying identity together with its ZKA and ZKC cryptographic substrate; SAGA's Provider instead stores contact information and access-control policy centrally for each registered agent.
Cross-domain link
Strangers shake hands before they talk business
What it is. Before any task content flows, two agents from different organisations go through a staged handshake that establishes who they are and that they're allowed to talk at all.
Why it exists. Agents increasingly interact across organisational boundaries never designed with each other in mind; without a defined sequence, improvised handshakes are where impersonation attacks live.
Where it breaks. The IETF's draft specification is still a draft; implementations can diverge on exactly how these stages are carried out until it stabilises.
How that's handled. The draft defines the handshake as four sequential interaction types, so vendors building against it at least agree on the shape of the sequence.
In technical terms
In technical terms: draft-ni-a2a-ai-agent-security-requirements defines four sequential interaction types — provisioning, discovery, cross-domain interconnection and access control — that must complete, in order, before task content is exchanged.
Scoped delegation
A signature that only covers what it says it covers
What it is. Every message an agent sends carries a cryptographic signature tying it to a specific, user-authorised task — not a blanket permission to act on the user's behalf generally.
Why it exists. A compromised or overeager agent with a broad permission can do broad damage. Scoping the permission to a specific intent cuts off overreach.
Where it breaks. Scoping only constrains what was actually signed for. If the original intent is written too loosely, a signed, valid message can still grant more room to act than intended.
How that's handled. The IETF's AIDP draft defines this at the control-plane level — expressing intent, enforcing authority, delegating capability, executing the action — while the Agent Communication Protocol (ACP) attaches an explicit Proof-of-Intent signature to every message, verified using Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) under a zero-trust model.
In technical terms
In technical terms: AIDP specifies mechanisms for expressing intent, enforcing authority, delegating capabilities and executing agent actions; ACP binds a Proof-of-Intent cryptographic signature to each message, checked against DID/VC-based identity.
Blind operator
The postman confirms delivery, never reads the letter
What it is. The platform that carries agent-to-agent messages can confirm the system is working — messages delivered, nodes alive — without seeing the content or who is coordinating with whom.
Why it exists. Separating pipe from mail means a platform operator can satisfy governance requirements without becoming a single point of surveillance over every tenant's business.
Where it breaks. Content and the coordination graph can be hidden, but some metadata — timing, volume of traffic — may still leak through observation of the transport layer itself.
How that's handled. AFP builds this guarantee structurally into its transport layer, on a zero-knowledge cryptographic substrate, so the operator is blocked from seeing content or reconstructing who talks to whom, as a property of the protocol rather than a policy promise.
In technical terms
In technical terms: AFP's transport operator can verify health signals (liveness, delivery) while being structurally prevented from accessing tenant content or the coordination graph, a guarantee built on zero-knowledge proofs.
Meera's two vendor agents disagree on who paid the pickup fee → 1 divergence detected → without fencing, 2-3 disagreement spreads, averaging 794.5 split-brain rounds → with fencing, 4 the dissenting agent is cut off, 5 measured at 0.0 split-brain rounds → settlement reached, operator blind throughout
Fencing
Cut off the one who disagrees before it spreads
What it is. When two parts of a federation disagree about the current state — a split-brain — fencing forcibly isolates the disagreeing node before its wrong view spreads further.
Why it exists. A federation of many organisations' agents acting independently will, left unmanaged, drift into disagreement about shared state: who already paid, whose turn is next, which version of an agreement is current.
Where it breaks. PRIMUS's measured results are not universal: enforcement was independently verified across 84% of tested Wardenships, not the full set (PRIMUS — arXiv, 2026). So fencing is strong evidence, not a universal proof.
How that's handled. PRIMUS combines leases, VRF sortition, BLS signature aggregation and exponentially-weighted moving-average (EWMA) scoring to decide, and enforce, who gets fenced off. Measured across its test runs: 0.0 split-brain rounds with fencing enabled, against 794.5 split-brain rounds without it.
In technical terms
In technical terms: PRIMUS enforces fencing through leases, Verifiable Random Function (VRF) sortition, BLS signature aggregation and EWMA-based reputation scoring, reducing split-brain rounds from 794.5 (unfenced) to 0.0 (fenced) in its measured evaluation.
Shared safety
Learn from everyone's attacks, see no one's secrets
What it is. Operators across a federation can train one shared anomaly detector that benefits from every organisation's attack data, without any organisation pooling its raw conversation logs into a central store.
Why it exists. No single operator sees the full range of attacks across a federation, so a detector trained only on one operator's traffic is blind to the rest — but pooling raw logs to fix that recreates the surveillance problem federation exists to avoid.
Where it breaks. Federated training only helps when it accounts for differences between operators' domains. A detector trained in one domain and applied unmodified to another collapsed to an AUROC of 0.51 — near chance level — recovering only to 0.70 after retraining on in-domain data (Privacy-Preserving Topology-Guided Safety for LLM-Based Multi-Agent Systems via Federated Graph Learning — arXiv, 2026).
How that's handled. FGLGuard trains a graph attention detector locally at each operator on judge-labelled episode graphs, and shares only the resulting model updates — not the underlying data — across the federation. In that federated setup, it cut AgentDojo's measured attack-success rate by 43% at near-unguarded utility, with its detector landing close to the performance of a fully centralised model trained on pooled data.
In technical terms
In technical terms: FGLGuard applies federated learning to a graph attention network trained on judge-labelled episode graphs, sharing only model parameter updates across operators; federated training reduced AgentDojo's attack-success rate by 43% at near-unguarded utility, close to a centralised baseline's AUROC.
Formal proof
Mathematics checks the lock, not just the lock-maker's word
What it is. Rather than arguing informally that a protocol is secure, at least one of these designs has been run through a formal verification tool that checks the protocol's guarantees mathematically against all the ways an attacker could behave.
Why it exists. Earlier agent-governance proposals mostly rested on design intent and informal argument. A formal proof checks specific properties — like "an attacker on the network cannot learn this token" — against every strategy an attacker could try within the model.
Where it breaks. The proof covers the modelled protocol, not any particular implementation of it. A correct protocol can still be undermined by a buggy implementation.
How that's handled. SAGA uses the ProVerif protocol verifier to prove secrecy of its access-control tokens and mutual authentication between agents and the Provider against an active network attacker, and was then evaluated on real agentic tasks — scheduling meetings, submitting expense reports, collaborative writing — using agents in different geolocations running a mix of on-device and cloud models (SAGA — NDSS Symposium, 2026).
In technical terms
In technical terms: SAGA is verified using the ProVerif formal verification tool, proving secrecy of access-control tokens and mutual authentication between agent and Provider under an active-attacker model, then evaluated empirically across scheduling, expense and writing tasks.
Compared with what came before
| Ordinary agent integration | Security-aware federation | |
|---|---|---|
| Identity | Tied to whoever hosts the agent | Self-certifying or Provider-registered, survives host changes |
| Trust model | One party (or the platform) sees everything | Operator can verify health without seeing content |
| Authorisation | Broad API keys or session tokens | Per-message Proof-of-Intent, scoped to a task |
| Disagreement handling | Manual reconciliation, ad hoc | Formal fencing, measured to near-zero split-brain |
| Shared safety learning | Each operator alone, or pooled raw logs | Federated learning on local data, shared updates only |
| Security guarantees | Informal design claims | Some protocols (SAGA) formally proven with ProVerif |
What you give up is simplicity. A single trusted operator with full visibility is cheaper to build and easier to debug than a federation where no one sees the whole picture. Federation earns its cost only once the parties genuinely don't trust each other or the platform between them.
Where it breaks
Drafts, not finished standards
The IETF's cross-domain handshake and delegation specifications are still drafts. Implementations built against them today may need to change as the specification stabilises, and interoperability between early implementations is not guaranteed.
Scoped delegation only constrains what was explicitly signed for; a loosely scoped intent still leaves room to overreach, and tightening scope is a governance decision, not something the cryptography does for you. Operator blindness hides content and the coordination graph, but some metadata — timing and volume of traffic — can still be observed even when the protocol works exactly as designed. Fencing, in PRIMUS's own measured results, was independently verified across 84% of tested Wardenships, not the full set, so it is strong evidence rather than a universal guarantee. And federated safety training only generalises across operators when the training setup accounts for differences between their domains — applied carelessly, a shared detector can collapse to near chance performance, as happened when a detector trained in one domain was applied unmodified to another.
None of this is argued informally on all fronts; SAGA's token-secrecy and authentication claims were specifically checked with ProVerif against an active network attacker, a stronger bar than most adjacent agent-governance proposals have cleared.
Numbers to carry
| Figure | Source |
|---|---|
| 0.0 split-brain rounds with fencing vs 794.5 without | PRIMUS, arXiv, 2026 |
| 84% of Wardenships with independently verified enforcement | PRIMUS, arXiv, 2026 |
| 43% reduction in AgentDojo attack-success rate (federated, near-unguarded utility) | FGLGuard, arXiv, 2026 |
| AUROC 0.51 (near chance) collapsing cross-domain, recovering to 0.70 after in-domain retraining | FGLGuard, arXiv, 2026 |
| 4 sequential interaction types in cross-domain handshake | IETF draft-ni-a2a, 2026 |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| "Federation just means better OAuth for agents" | Standard sign-in (OAuth/SSO) verifies who an agent acts for at login; federation additionally governs ongoing, machine-speed, cross-organisation delegation and topology change |
| "The platform operator needs full visibility to keep things safe" | AFP's design shows an operator can verify system health while being structurally blocked from seeing content or the coordination graph |
| "These protocols just stop prompt injection" | They govern identity, authorisation and auditability between agents; the dossier describes them as complementary to prompt-injection defences, not a replacement |
| "A shared safety model needs pooled data" | FGLGuard trains locally and shares only model updates, approaching the performance of a centralised model without pooling raw logs |
| "Split-brain is just a theoretical risk" | PRIMUS measured 794.5 split-brain rounds without fencing in its tests, falling to 0.0 with fencing applied |
Worked example
- Meera's school trip committee sets up two agents, one from each of two vendors, to split costs and schedule pickups.
- Each agent carries a self-certifying identity (illustrative: issued once, verifiable by anyone, tied to no single host) rather than a login tied to whichever server happens to run it that week — matching AFP's KERI-aligned identity design.
- Before any task content is exchanged, the two agents complete a staged handshake — provisioning, discovery, cross-domain interconnection, access control — confirming each is who it claims to be, matching the four-stage sequence in the IETF draft.
- Meera's agent sends a request to split a trip fee, signed with a Proof-of-Intent that scopes it specifically to "settle trip expense with cousin's agent, amount as agreed," not a general payment authority.
- The platform carrying the message between the two agents' organisations can confirm the message was delivered and the system is healthy, without reading the amount, the names, or the schedule — the operator-blind guarantee.
- If the two agents briefly disagree about whether the payment has already been confirmed (illustrative: one thinks it's settled, one thinks it's pending), a fencing mechanism isolates the disagreeing side until the state is reconciled.
- Separately, both vendors' operators benefit from a shared anomaly detector trained across many households' trip-agent traffic, without either vendor seeing the other's raw conversation logs.
- The trip gets paid for, scheduled, and settled, and neither vendor — nor the platform between them — ever saw the other's full ledger.
Should you use it?
Reach for security-aware federation when agents from genuinely separate organisations need to coordinate and no shared trusted operator exists, or when an operator must prove to regulators or partners that the system is sound without exposing tenant data. Skip it inside a single organisation's own agent pipeline, where ordinary enterprise identity and access management already covers the authentication need, or where lightweight human review is enough and no cross-boundary data exchange between separate legal entities is happening at all.
The cheapest first experiment is not building a federation from scratch — it's picking one moving part, such as scoped delegation with Proof-of-Intent signatures, and applying it to one narrow cross-boundary workflow, before committing to a full identity and fencing stack.
Say it in the room
"Use it when two organisations' agents must cooperate and neither trusts the other's server or the platform between them; skip it when one team's agents just need ordinary sign-in inside one trust boundary."
Lines to carry
- "An identity no one else can switch off."
- "A signature that only covers what it says it covers."
- "The postman confirms delivery, never reads the letter."
- "Cut off the one who disagrees before it spreads."
- "Learn from everyone's attacks, see no one's secrets."
- "Fencing turned 794.5 split-brain rounds into 0.0 — in one measured test, not a universal guarantee."
- "Formal proof checks the lock, not just the lock-maker's word."
FAQ
Is this just a more complicated version of OAuth?
No. Sign-in protocols like OAuth and single sign-on verify which account an agent is acting for at the moment it logs in. Federation protocols additionally govern what happens afterwards — ongoing, machine-speed delegation across organisations, proof of intent on every message, and handling of disagreement between parties that sign-in alone was never built to address.
Does operator blindness mean the platform can't be held accountable?
No — it can still prove the system is healthy, that messages were delivered, that nodes are alive. What it structurally cannot do, in AFP's design, is read tenant content or reconstruct who is talking to whom. Accountability for health and accountability for content are deliberately split apart.
Does fencing mean split-brain can never happen?
PRIMUS's measured results show 0.0 split-brain rounds with fencing enabled, against 794.5 without, and independently verified enforcement across 84% of tested Wardenships. That's strong, measured evidence in that test setup, not a claim that every possible federation running this mechanism is immune under all conditions.
Can a shared safety detector just be reused across any organisation?
Not without care. A detector trained in one domain and applied unmodified to another collapsed to near-chance performance (AUROC 0.51) in the dossier's measured results, recovering only to 0.70 after retraining on in-domain data. Federated training helps generalisation, but doesn't erase the need to account for domain differences.
Is any of this actually proven secure, or is it all still design intent?
At least one protocol, SAGA, has been run through the ProVerif formal verification tool, proving secrecy of access tokens and mutual authentication against an active network attacker — a concrete mathematical check, not just an architectural argument. That proof covers the modelled protocol, though, not bugs in a specific implementation of it.
Glossary
- Agent federation — a set of autonomous AI agents belonging to different organisations coordinating work across trust boundaries.
- Split-brain — a failure where two parts of a distributed system disagree about the current state, each believing itself correct.
- Fencing — forcibly isolating or evicting a faulty or conflicting node so it cannot cause further damage.
- KERI — Key Event Receipt Infrastructure, a method for self-certifying digital identities that don't depend on a central registry.
- Zero-knowledge proof — a cryptographic method for proving a statement true without revealing the information behind it.
- Operator blindness — a design property where the entity running the communication infrastructure cannot see the content or pattern of what it carries.
- Proof-of-Intent — a cryptographic signature tying a request to a specific, user-authorised purpose.
- Decentralized Identifier (DID) — an identifier not issued or controlled by a central authority.
- Verifiable Credential (VC) — a digitally signed statement about an entity that can be cryptographically checked.
- Control-plane protocol — a protocol layer handling coordination, authorisation and policy, distinct from the data being exchanged.
- Graph attention detector — a machine-learning model that analyses a network of connections and learns which ones matter most for spotting anomalies.
- AUROC — Area Under the Receiver Operating Characteristic curve, a score from 0 to 1 measuring how well a detector separates positive from negative cases; 0.5 is chance level.
- Formal verification (ProVerif) — using mathematical proof tools to check a protocol's security properties against all possible attacker behaviours.
- Tenant — an organisation or party operating its own agent(s) within a shared federated system.
- Zero-trust — a security model assuming no actor should be trusted by default, requiring continuous verification instead.
Sources
- PRIMUS: Identity, Governance, and Verification for Multi-Agent Federations — arXiv, 2026
- Agent Federation Protocol (AFP) Specification — afp.dev
- A Protocol-Agnostic Threat Classification for Cross-Boundary AI Agent Authorization — OpenID Foundation, 2026
- draft-ni-a2a-ai-agent-security-requirements-01 — IETF
- Agent Interaction & Delegation Protocol (AIDP), draft-vandoulas-aidp-02 — IETF
- Beyond Context Sharing: A Unified Agent Communication Protocol (ACP) for Secure, Federated, and Autonomous Agent-to-Agent (A2A) Orchestration — arXiv, 2026
- SAGA: A Security Architecture for Governing AI Agentic Systems — NDSS Symposium, 2026
- Privacy-Preserving Topology-Guided Safety for LLM-Based Multi-Agent Systems via Federated Graph Learning — arXiv, 2026