DM Explains · No. 021 · Governance
Secure federation: how AI agents from different companies trust each other
Proving an agent's identity is nearly solved. The real fight is over how little authority it hands to the next agent in the chain.
· 13 min read
Read me first
Secure federation genuinely does stop one agent's authority from becoming every agent's authority down the chain, but only when each handoff narrows what gets passed along; proving identity is nearly solved, narrowing authority is not.
Illustrative: a procurement agent delegates a shipment reschedule to a supplier's logistics agent, which delegates payment approval to a payments agent → 1 each hop presents a short-lived Ed25519 token → 2 both agents already exist in the registry with owner and risk tier → 3 the payments agent receives only 'approve ≤$500, this invoice' — narrower than its parent grant → 4 at execution ACS re-checks the live grant, not the one issued an hour ago → 5 outcomes feed a federated model via secure aggregation, no raw invoice data crosses orgs → 6 the procurement agent revokes the original delegation and both downstream grants collapse, visible in one audit trail
A procurement agent at one company calls a logistics agent at a supplier to reschedule a shipment. The supplier's logistics agent then calls a payments agent to adjust an invoice. No human watches any single step; the chain just runs.
If each handoff simply copies the original authority forward, one careless or compromised agent several hops down that chain can approve payments, move data, or take actions nobody at either company ever intended to permit. And because nothing recorded why each step happened, nobody will be able to reconstruct the decision afterwards — only that it happened.
Everyday picture. Meera lends Arjun her school library card, but only to borrow one named book, due back Friday, rather than handing over the whole card indefinitely. Amma's kitchen notebook logs who borrowed what and when, so everyone can later check who had the car keys.
Where the picture breaks. A library card cannot automatically revoke every sub-loan Arjun makes to Bruno's owner down the chain the moment Meera reports it lost, and Amma's notebook cannot cryptographically prove nobody rewrote an entry afterwards. The real mechanisms need a tamper-evident chain that a physical card and paper notebook don't have.
Why it exists now
Enterprises are wiring agents from different vendors and organisations together to complete tasks autonomously. That's new enough that the plumbing for it is still being written in public. Microsoft's Agent Governance Toolkit published ADR-0008 in 2026 specifically to extend its earlier identity-federation work, ADR-0007, into cross-org policy federation — because once you can prove which organisation an agent belongs to, the next question is immediate: what is it allowed to do, and what is it allowed to hand to the next agent in line (Microsoft, 2026).
In parallel, two IETF drafts in 2026 are trying to standardise pieces of this: draft-pidlisnyi-aps-00 for cryptographic "agent passports" with scoped delegation chains (IETF Datatracker, 2026), and draft-kale-agntcy-federated-privacy-02 for letting agents from different tenants learn from shared data without centralising it (IETF Datatracker, 2026). Deloitte and Saviynt published a 2026 whitepaper treating "agentic identity" as a first-class enterprise security domain in its own right (Deloitte/Saviynt, 2026).
The counterintuitive part: proving who an agent is turns out to be the easy half. Narrowing what it is allowed to pass on, every time a request crosses an organisational boundary, is where the real engineering is still happening.
How it works
Illustrative: procurement delegates "reschedule shipment #4471" to the supplier's logistics agent with a 2-hour token → logistics narrows to "rebook carrier slot only" and delegates to payments → payments can pay only the $85 rebooking fee → an anomaly triggers revocation at hop 1, invalidating both descendant grants before any charge posts.
Prove who you are
A forged identity poisons everything built on top of it
What it is. Each agent gets a unique, verifiable identity before anything else happens.
Why it exists. Without a trustworthy, non-forgeable identity, no later authorisation step and no audit record can be anchored to anything real.
Where it breaks. Identity alone says nothing about what the agent is allowed to do once verified — a correctly identified agent can still be wildly over-permissioned.
How that's handled. ADR-0007 establishes cross-org identity federation for agents using DNS-anchored JWKS endpoints and short-lived Ed25519 tokens (Microsoft, 2026); the IETF Agent Passport System takes a related approach with Ed25519-based "agent passports" (IETF Datatracker, 2026).
In technical terms
In technical terms: each agent is bound to a unique Ed25519 key pair verifiable against a DNS-anchored JWKS endpoint, or carries a signed agent passport, so any receiving party can cryptographically verify organisational origin rather than trusting a claimed name.
Register it
You can't govern an agent you don't know exists
What it is. A central registry recording what every agent is, before it gets cross-org trust.
Why it exists. Organisations need to know what agents exist, who is accountable for them, and what they're meant to do, before granting them access across a boundary.
Where it breaks. A registry entry is only as current as whoever updates it; it does not stop drift between what's recorded and what an agent actually does in production.
How that's handled. Treat the registry as a living record reviewed on a cadence, not a one-time form.
In technical terms
In technical terms: the registry logs owner, purpose, risk tier, model, tools, data domains, environments, dependencies and lifecycle state for each agentic identity (Deloitte/Saviynt, 2026).
Narrow on handoff
Authority should shrink, never copy, at each boundary
What it is. When authority passes from one agent to another, the receiving agent gets a tighter, more context-bound credential, not a copy of the original.
Why it exists. Authority that stays the same size as it moves accumulates into excessive, unaccountable power across a chain of agents.
Where it breaks. Narrowing has to be deliberately configured. Nothing in the mechanics stops a lazy implementation from relabelling a credential instead of actually shrinking its scope.
How that's handled. Token-exchange standards and delegation specifications build narrowing into the handoff itself rather than leaving it to convention.
In technical terms
In technical terms: OAuth's token-exchange standard, RFC 8693, which the Agent-to-Agent protocol already relies on, lets a request swap one access token for a narrower one at each hop (guptadeepak.com). The IETF Agent Passport System goes further, narrowing authority monotonically across seven constraint dimensions every time it crosses an organisational boundary (IETF Datatracker, 2026).
Check at action time
Permission granted earlier isn't permission to act now
What it is. A runtime policy layer that checks identity, delegation, scope, provenance and intent immediately before the agent does anything.
Why it exists. A credential issued correctly an hour ago says nothing about whether the specific action right now is appropriate.
Where it breaks. Enforcing declared intent — why the agent says it's doing something — is still unsolved. Intent-Based Access Control remains research-stage, with no IETF or World Wide Web Consortium (W3C) standard track (GenAI Security Project).
How that's handled. Enforce the parts that can be checked mechanically — identity, delegation chain, scope, provenance — and treat "intent" as a label to log, not yet a thing to trust.
In technical terms
In technical terms: the Agent Control Specification exposes standardised hooks so policy engines, such as those written in the Rego policy language, can evaluate a request right before execution and let an operator permit, deny or modify it over an authenticated channel (GenAI Security Project; GitHub).
Learn without leaking
Shared experience shouldn't mean shared data
What it is. A protocol for agents from different organisations to learn from pooled operational data without exposing any one tenant's raw records.
Why it exists. Federated agent systems often improve from shared experience across organisations, but centralising sensitive tenant data to do that creates a new, large liability.
Where it breaks. This layer only matters when agents are jointly learning. Most day-to-day delegation chains, like the shipment reschedule, never touch it at all.
How that's handled. Secure aggregation is recommended specifically so the aggregator never sees any single tenant's individual update.
In technical terms
In technical terms: draft-kale-agntcy-federated-privacy defines cohort formation, update submission, secure aggregation, differential privacy, privacy accounting and auditability as protocol-level requirements, with secure aggregation marked as RECOMMENDED for cross-tenant deployments (IETF Datatracker, 2026).
Cut and reconstruct
Trust that can't be revoked isn't trust, it's exposure
What it is. Revoking one delegation has to kill everything derived from it, and every decision along the way has to leave evidence.
Why it exists. A federated system needs a way to immediately cut off a compromised or misbehaving agent, and to prove afterwards exactly what happened and why.
Where it breaks. Revocation is only as fast as the chain's propagation; a sufficiently stale cached credential can still be honoured for a brief window.
How that's handled. Cascade revocation and tamper-evident logging are built into the delegation layer itself, not bolted on afterwards.
In technical terms
In technical terms: in the Agent Passport System, revoking any delegation invalidates all descendant delegations derived from it (IETF Datatracker, 2026), and the Agent Control Specification's reference implementation keeps policy decisions, tool calls and outcomes as evidence an auditor can reconstruct after the fact (GitHub).
Compared with what came before
| Old way: static role-based access | New way: secure federation | |
|---|---|---|
| Who grants access | Fixed roles assigned in advance | Dynamic, scoped delegation per action |
| What travels at a handoff | The same permission set, unchanged | A narrower, context-bound credential |
| When it's checked | Mostly at login | At identity, delegation, and again at action time |
| How a breach is contained | Manually, often after the fact | Cascade revocation across the whole derived chain |
| What's left afterwards | Logs, if configured | A designed, tamper-evident audit trail |
Static role-based access control answers "is this role allowed to do this, generally" once and stops asking. Secure federation keeps asking, at every boundary a request crosses, and it is built on the assumption that authority should get smaller as it moves, not stay fixed. The cost is real: more moving parts, more places for a misconfiguration to quietly widen scope instead of narrowing it.
Where it breaks
Secure federation genuinely reduces unaccountable cascades of authority, but only where the narrowing and the runtime checks are actually implemented correctly — none of this is self-enforcing.
Intent is not yet checkable
A policy layer can verify identity, delegation chain, scope and provenance mechanically. It cannot yet verify that an agent's stated reason for an action matches its real purpose — Intent-Based Access Control is still research-stage, with no IETF or W3C standard track (GenAI Security Project).
Revocation has a propagation lag
Cascade revocation is designed to invalidate every delegation derived from a revoked link, but a cached credential downstream can still be honoured briefly before the revocation reaches it. The window is implementation-dependent, not zero by design.
Cost shows up less in licensing and more in engineering discipline: every org in the chain has to actually implement narrowing logic, maintain a current registry, and keep policy hooks wired into the runtime rather than bolted on as an afterthought. Skip any one layer and the chain degrades to the old pattern — authority copied forward, unchecked, until something goes wrong.
Numbers to carry
| Figure | What it means |
|---|---|
| ADR-0007 / ADR-0008 (2026) | Microsoft's identity federation, then policy federation, architecture decisions |
| RFC 8693 | OAuth standard for token exchange, used to narrow scope at a handoff |
| Seven constraint dimensions | How many dimensions the Agent Passport System narrows authority across at each boundary |
| draft-pidlisnyi-aps-00 (2026) | IETF draft defining agent passports and cascade revocation |
| draft-kale-agntcy-federated-privacy-02 (2026) | IETF draft defining secure aggregation and differential privacy for cross-tenant agent learning |
| "RECOMMENDED" | The draft's own term for using secure aggregation in cross-tenant deployments |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| "If the agent is authenticated, it's safe to let it act" | Authentication proves who the agent is; it says nothing about what it should be allowed to do right now |
| "Delegation just forwards the same permissions" | Standards like RFC 8693 and the Agent Passport System are built specifically to narrow scope at each handoff, not copy it |
| "An audit log after the fact is enough" | Enforcement has to happen before the action executes; logging alone doesn't stop a bad action, it only records it |
| "This is the same problem as single sign-on" | SSO authenticates a human into applications; agent federation constrains machine-to-machine actions that often happen with no human watching |
| "Intent can already be checked automatically" | Intent-based authorisation remains research-stage, with no IETF or W3C standard track |
Worked example
- Procurement agent at the buying company holds broad internal authority to manage shipment schedules, verified by its own organisation's Ed25519-based identity.
- Procurement agent → supplier's logistics agent: instead of forwarding its full authority, it issues a narrower, time-bound credential scoped only to "reschedule shipment #4471, valid 48 hours" — illustrative, but shaped like the seven-dimension narrowing the Agent Passport System defines.
- Supplier's logistics agent receives the request, and before acting, a runtime policy check verifies identity, delegation chain, scope and provenance against the credential it was handed.
- Logistics agent → payments agent: it needs to adjust an invoice to reflect the new schedule, so it issues a further-narrowed credential — scoped only to "adjust this one invoice line item for the shipping date change" — not the broader shipment authority it itself received.
- Payments agent checks that narrower credential at action time, acts, and the outcome is written to a tamper-evident audit trail alongside the policy decision that allowed it.
- If the original procurement agent's credential turns out to have been issued in error, revoking it cascades: the logistics agent's and payments agent's derived credentials become invalid immediately, collapsing the whole chain from one point rather than leaving three separate problems to find and fix.
Should you use it?
Reach for secure federation when agents from different organisations call each other's tools or exchange data as part of a workflow, when a chain of delegated authority crosses several agents or organisations and needs to be auditable end to end, or when a regulator will eventually ask why an autonomous agent took a specific action. Skip it for a single internal chatbot operating entirely within one organisation's boundary, for simple read-only agents with no tool access, or anywhere a static, pre-approved role is genuinely sufficient and authority never needs to cross a boundary.
The cheapest first experiment: pick one real cross-org handoff already happening informally, put a registry entry and a scoped, time-bound credential around just that one handoff, and check whether revoking it actually stops the downstream action. If it doesn't cascade cleanly on that single link, it won't on a longer chain either.
Say it in the room
"Use it when an agent's authority crosses an organisational boundary and must be auditable; skip it when a static role already covers the whole decision."
Lines to carry
- "Identity proves who; delegation decides how much."
- "Authority should shrink at every handoff, never stay the same size."
- "A permission granted earlier is not a permission to act now."
- "Revoke one link, and everything hanging from it should fall too."
- "You can't govern an agent you never registered."
- "Proving identity is nearly solved; narrowing authority is not."
FAQ
Isn't this the same as single sign-on for agents?
No. Single sign-on authenticates a human logging into applications. Agent federation authenticates and constrains machine-to-machine actions that cross organisational boundaries, often with no human present at the moment the action happens.
Why can't we just use fixed roles like we do for employees?
Static role-based access control assigns permissions in advance and stops checking. Secure federation evaluates delegation scope, provenance and intent dynamically for each action, and narrows authority every time it's passed along — because a chain of agents accumulates risk that a fixed role was never designed to contain.
Does this stop a model from being tricked into a bad action?
Not by itself. It stops a tricked or compromised agent from having unlimited downstream authority, and it limits the damage via narrowed scope and cascade revocation. It doesn't make the model itself more reliable at recognising a bad request.
What happens if the registry entry is wrong or stale?
Governance built on a stale registry is only as good as that entry. The registry gives accountability a fixed point of reference, but it doesn't stop drift between what's recorded and what an agent actually does — that still needs periodic review.
Is intent-based authorisation available yet?
Not as a standard. Intent-Based Access Control, which would authorise actions based on declared purpose rather than fixed scope, remains research-stage with no IETF or W3C standard track as of the current drafts.
Glossary
- Federation — an arrangement where separate organisations' systems trust and interoperate without merging into one system.
- Agent-to-Agent (A2A) protocol — a protocol letting AI agents from different systems discover and communicate with each other.
- SPIFFE — a standard for giving software workloads a cryptographically verifiable identity.
- JWKS — JSON Web Key Set, a published set of public keys used to verify signed tokens.
- Ed25519 — a fast, widely used digital-signature algorithm used to prove authenticity.
- OAuth 2.0 token exchange (RFC 8693) — a standard method for swapping one access token for a more narrowly scoped token as a request moves between systems.
- Delegation chain — a sequence of handoffs where each party grants a narrower slice of authority to the next.
- Cascade revocation — revoking one delegation automatically invalidates every delegation derived from it further down the chain.
- Differential privacy — a technique that adds controlled noise to data or model updates so individual records can't be identified.
- Secure aggregation — a cryptographic method letting a central service combine many parties' updates without seeing any individual update.
- Intent-Based Access Control (IBAC) — a proposed approach to authorising actions based on declared purpose rather than fixed roles or scopes.
- Policy Decision Point — the component that evaluates a request against rules and decides to allow, deny or modify it.
- Reference monitor — a trusted component that checks every action against policy before it proceeds.
- Rego — a policy-writing language used to express rules a policy engine evaluates against requests.
- Agent passport — a cryptographically signed credential establishing an agent's identity and current scope of authority.
Sources
- ADR-0008: Cross-Org Policy Federation - Agent Governance Toolkit — Microsoft, 2026
- Standards - Agent Control Standard — GenAI Security Project
- Identity for Agents - Agent Control Standard — GenAI Security Project
- GenAI-Security-Project/agent-control-standard — GitHub
- A strategic imperative for the agentic identity era — Deloitte / Saviynt, 2026
- draft-pidlisnyi-aps-00: Agent Passport System — IETF Datatracker, 2026
- Agent Control Specification: Portable runtime governance for AI Agents — Microsoft, 2026
- The Identity Mesh: Federated Trust for AI Agents — guptadeepak.com
- draft-kale-agntcy-federated-privacy-02: Privacy-Preserving Federated Learning for Multi-Tenant Agent Systems — IETF Datatracker, 2026