DM Explains · No. 020 · Agents
Secure agent federation: how AI agents from different companies can trust each other
Agents can already talk across company lines. The hard part is proving who asked, what they're allowed to do, and who's accountable when something goes wrong.
· 14 min read
Read me first
Agents from different companies can already send each other messages; that part is solved. What's unsolved is proving who sent the message, what they're allowed to do with it, and who answers for it later — and no amount of clever prompting fixes that, because it's a credentials problem, not a conversation problem.
The plumber-booking agent: Amma's building-management agent 1 defines its trust domain, 2 presents a verifiable identity card, 3 a broker mediates trust with the plumbing company's agent, 4 delegates only a scheduling-and-payment scope, 5 each call is re-checked, not just at login, 6 every hop is logged into a cryptographic audit trail, 7 the relationship is graded and can be revoked at any time.
Amma's housing society app has an agent that books the plumber. That agent now asks the plumber's own scheduling agent to check a time slot and take a deposit. Two different companies, two different administrators, and a request that crosses the gap between them with nobody in either household watching it happen.
If that crossing only proves the message arrived intact, and says nothing about who actually sent it, what it's allowed to do, or how anyone would prove any of that afterwards, then a single leaked or overly broad credential on either side can quietly become every downstream system's problem. And when something does go wrong, there's no shared log to point to and no shared administrator to call.
Everyday picture. Amma lends Meera a key, but not the master key — only the one that opens the front door, and only for the afternoon, so Meera can let the plumber in while Amma is out. Separately, Dadi has already phoned the school library's librarian to vouch for Arjun before he's allowed to borrow a rare book, so the librarian isn't just taking a ten-year-old's word for it.
Where the picture breaks. A photocopied key can't be cryptographically checked, and a phone call can't be revoked mid-conversation the way a digital credential can be cut off instantly, mid-transaction, by either side.
Why it exists now
Agent-to-agent protocols such as MCP (Model Context Protocol) and A2A (Agent2Agent) already solved the plumbing: an agent can discover another agent and call it. What they were never built to answer is whether the caller should be trusted, how far its permissions extend once it hands a task onward, and how anyone audits that chain after the fact. Through 2025 and into 2026, that gap became obvious enough that several competing IETF drafts appeared to fill it — among them draft-kiliram-agent-trust-auth-framework, draft-cui-dmsc-agent-cdi, draft-diaconu-agents-authz-info-sharing, and the credential-broker-focused CB4A draft — alongside the research protocol InterSAGE and vendor work including Red Hat's zero-trust extension for agentic AI.
The reason this matters now rather than earlier: classic identity and access management assumes that once something is authenticated, it behaves as expected. Agents break that assumption — an authenticated agent can still delegate onward, improvise, or be tricked into forwarding more access than it should. Red Hat's analysis names the recurring real-world failure directly: agents forwarding the original caller's token to a downstream tool rather than exchanging it for a narrower one, which it calls a "broken trust chain."
How it works
Trust domain
Draw the boundary before you police it.
What it is. A trust domain is the bounded scope of policy and administrative control — one company's agents, gateways, identities and credentials, governed under one set of rules.
Why it exists. Nothing about identity or authorisation means anything until you've named the boundary it's being enforced inside. Amma's building-management system is one domain; the plumbing company's scheduling system is another, with no shared administrator.
Where it breaks. Drawing the line on paper does nothing by itself — it's only useful once identity and enforcement are actually built on top of it.
How that's handled. Both parties define their own domain independently, then negotiate across the boundary rather than merging into one.
In technical terms
In technical terms: both draft-kiliram-agent-trust-auth-framework and draft-cui-dmsc-agent-cdi define a trust domain as a policy and governance scope, not merely the set of agents that happen to speak the same communication protocol — agents, gateways, identities and credentials sit under common administrative control or an explicit federated agreement.
Verifiable identity
No accountability without a provable actor.
What it is. Each agent carries a persistent, cryptographically checkable identity, tied to who built it, what code it's running, who operates it, and in what context.
Why it exists. A receiving domain can't authorise, or later investigate, an action it can't attribute to a specific, provable actor rather than "some agent, probably Amma's."
Where it breaks. Identity only answers who the agent is — it says nothing about what that agent should be allowed to do next.
How that's handled. Identity is checked first, separately, before any authorisation decision is made.
In technical terms
In technical terms: the InterSAGE protocol binds developer, code package, operator and deployment context into an Agent Identity Card, and uses DID (Decentralised Identifier)-bound Verifiable Credential manifests for discovery, so another domain can check what an agent is capable of before engaging with it.
Broker negotiates
Strangers trust through a go-between, not a handshake.
What it is. A gateway or credential broker sits between two domains that have no prior relationship and mediates the trust negotiation on their behalf.
Why it exists. Companies that have never dealt with each other need a controlled meeting point to reconcile different local policies, rather than exposing every internal agent directly to a stranger's systems.
Where it breaks. A broker that isn't itself redundant becomes a new single point of failure for every domain that relies on it.
How that's handled. Broker designs reuse existing distributed-identity standards rather than inventing a new central authority.
In technical terms
In technical terms: draft-cui-dmsc-agent-cdi's Trust Brokerage function uses verifiable credentials and reputation systems to mediate between domains, while the CB4A draft assembles SPIFFE/SPIRE workload identity with a Policy Decision Point and Credential Delivery Point kept architecturally separate, plus DPoP (RFC 9449) token binding — borrowing established standards rather than reinventing them.
Illustrative: Amma's building system delegates a plumber booking → 1 plumber's agent identity and domain confirmed → 2 scope trimmed to 'book + pay up to $200' → 3 a DPoP-bound token issued just for this hop → 4 policy decision allows it → 5 plumber agent books the slot and pays → 6 next call re-checked, not trusted on login alone → 7 the whole chain is logged → released, revocable if Amma's company ends the vendor relationship
Scope delegation
Pass on less, never more.
What it is. When one agent hands a task to another, it issues a narrower credential for that specific hop, never the original, broader token it was given.
Why it exists. If every hop just forwards the same token, one compromised step gives an attacker everything every later step was trusted with.
Where it breaks. Forwarding the original token instead of exchanging it for a scoped one is exactly the failure Red Hat describes as a recurring, real "broken trust chain."
How that's handled. Delegated token exchange: each downstream call gets its own token, minted for that call alone.
In technical terms
In technical terms: draft-diaconu-agents-authz-info-sharing extends OAuth 2.0 Client-ID Metadata with W3C Verifiable Credentials to support multi-hop delegation under monotonic scope narrowing — each hop's permissions can only shrink, never grow — while Red Hat's zero-trust extension recommends delegated token exchange so each downstream agent or tool call carries a token scoped to that hop alone.
Check continuously
Login once, verify forever.
What it is. Every call checks expiry, revocation and current context, not just the first call in a session.
Why it exists. Agent tasks can run long after the initial handshake; a one-time check leaves a window where a since-revoked credential still works.
Where it breaks. Checking on every hop adds latency and complexity, and under load teams are tempted to skip it.
How that's handled. The decision logic is kept separate from the credential-issuing logic, so checks can't quietly be bypassed by whichever system is under pressure.
In technical terms
In technical terms: Red Hat's analysis calls for continuous verification of expiry and revocation on every call rather than only at login, and the CB4A draft formalises this as a Policy Decision Point separated from the Credential Delivery Point that actually issues the credential.
Audit the trail
If it can't be traced, it can't be trusted.
What it is. Every delegated action is logged and cryptographically bound to the identity that performed it.
Why it exists. Once an autonomous, delegated action has already run, a log is the only way left to investigate it or assign responsibility.
Where it breaks. A log proves what happened after the fact — it does nothing to stop the unauthorised action before it executes.
How that's handled. Logs are made tamper-evident and shared, so no single domain can quietly edit its own record of events.
In technical terms
In technical terms: InterSAGE's accountability layer uses kernel-mediated cryptographic audit trails binding usage, delegation and execution traces to agent identity without needing a consensus ledger; draft-cui-dmsc-agent-cdi requires that all cross-domain interactions be logged and auditable by every participating domain.
Revoke and grade
Every relationship has an off switch.
What it is. Trust relationships between domains are time-bound, revocable by any participant, and graded by how much is at stake.
Why it exists. Fail-safe design means a compromise in one federated domain shouldn't automatically cascade into every domain trusting it.
Where it breaks. Revocation is only as fast as the mechanism propagating it — a slow revocation leaves open exactly the window continuous checking was meant to close.
How that's handled. Domains choose how deeply they integrate based on trust level, rather than treating every federation partner identically.
In technical terms
In technical terms: draft-cui-dmsc-agent-cdi specifies that domains select graduated levels of interoperability and that any participating domain can unilaterally revoke a trust relationship.
Compared with what came before
| Pre-federation (bespoke integration) | Secure agent federation | |
|---|---|---|
| Identity | Shared API key or static credential per partner | Persistent, cryptographically verifiable per-agent identity |
| Authorisation | One broad token forwarded through the whole chain | Scoped token re-issued, narrower, at every hop |
| Checking | Verified once, at initial login | Checked on every call for expiry, revocation and context |
| Accountability | Whoever happens to keep logs, if anyone | Logged and auditable by every participating domain |
| Trust across companies | Manual bilateral agreement, hard to scale | Broker-mediated, with graduated levels of interoperability |
| Failure containment | One partner's breach often propagates everywhere | Any domain can revoke unilaterally, bounding the damage |
None of this makes delegation safe by default; it makes delegation checkable. The judgement call that remains is how much friction a company is willing to accept at every hop in exchange for being able to prove, later, exactly what happened.
Where it breaks
Federation genuinely narrows the blast radius of a cross-company agent call, but only when every one of its moving parts is actually implemented, not just one of them.
A broker is not automatically distributed
A credential broker that mediates between unfamiliar domains solves the strangers-trusting-strangers problem, but if it isn't itself built redundantly, it becomes a single point of failure that every federated relationship now depends on.
Continuous checking has a cost
Checking expiry, revocation and context on every call, rather than once, adds latency and operational complexity to every single hop — which is exactly the kind of overhead teams are tempted to skip when a system is under load, undermining the whole point.
Logs explain, they don't prevent
A cryptographic audit trail tells you, after the fact, who did what. It cannot itself stop an unauthorised action from executing in the first place — accountability and prevention are two different jobs.
The research protocol InterSAGE was compared by its authors against more than 50 prior efforts spanning agent protocols, decentralised identity, OAuth and OpenID Connect extensions, zero-trust governance, delegation and audit architectures — and its authors report that no prior single architecture jointly enforced persistent identity, capability-aware discovery, trust negotiation and accountability together. That multi-draft, not-yet-converged state is itself a caution: this layer is still being argued over, not finished.
Numbers to carry
| Figure | Detail |
|---|---|
| 50+ | Prior architectures InterSAGE's authors compared it against, spanning agent protocols, decentralised identity, OAuth/OIDC extensions, zero-trust governance, delegation and audit |
| RFC 9449 | DPoP (Demonstrating Proof of Possession), the token-binding standard CB4A reuses for sender-constrained credentials |
| NIST SP 800-207 | The Zero Trust Architecture publication CB4A's Policy Decision Point / Credential Delivery Point split draws on |
| Multiple competing drafts | agent-trust-auth-framework, dmsc-agent-cdi, agents-authz-info-sharing and CB4A are all live IETF drafts, as of the dossier's 2026 dating — none yet a ratified standard |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| "If agents can message each other, federation is solved." | Agent protocols like MCP and A2A move messages; they say nothing about identity, scoped authorisation or audit, which is a separate layer entirely. |
| "One shared token for the whole task chain is simpler and fine." | Forwarding one broad token through every hop is the specific failure Red Hat documents as a recurring "broken trust chain" — each hop needs its own narrower token. |
| "Authenticating once at the start covers the whole session." | Agent tasks can run well past the initial handshake; without continuous checks, a credential revoked midway through still keeps working. |
| "An audit log stops the bad action." | A log only proves what happened after it already happened; it is forensic, not preventive. |
| "There's already an agreed standard for this." | As of the dossier's dating, this is multiple competing IETF drafts and a research protocol, not a single ratified standard. |
Worked example
- Amma's building-management agent needs the plumber's availability and wants a deposit charged, so it prepares a delegated request rather than sending its own full credentials.
- Amma's domain attaches a verifiable identity to the request, naming the agent, its operator and the task context.
- A gateway on Amma's side negotiates with a gateway on the plumbing company's side, since neither domain has dealt with the other before.
- The gateway exchanges Amma's agent's broad internal token for a narrow one scoped to only "check availability" and "charge deposit up to a limit" — illustrative figure: a cap of ₹2,000 rather than the account's full balance — never forwarding the original token.
- The plumbing company's scheduling agent checks that scoped token's expiry and validity before acting, not just once but on each of the two calls it makes.
- Both domains log the interaction — the request, the scope granted, the action taken — so either side can later trace exactly what was authorised and what happened.
- If the plumbing company's agent is later found compromised, Amma's domain revokes the trust relationship unilaterally, without needing the plumbing company's cooperation to stop further damage.
Should you use it?
This layer earns its complexity when agents genuinely cross an administrative boundary — different companies, different owners, no shared IAM — and the task involves delegation chains where accountability for each hop actually matters. It is overkill for a single company's internal agents already governed by one IAM system, for simple API calls a human approves each time, or for a fixed call to one pre-registered, already-trusted service with no further delegation. The cheapest first experiment is not adopting a full broker architecture; it's auditing one existing cross-company agent integration to see whether it forwards one broad token end to end — if it does, that's the first thing to fix, independent of which draft eventually wins.
Say it in the room
"Use it when an agent delegates across a company boundary and you need to prove, after the fact, who was allowed to do what; skip it when everything stays inside one IAM system you already control."
Lines to carry
- "Messages travel easily; trust does not."
- "Pass on less, never more."
- "Login once, verify forever."
- "If it can't be traced, it can't be trusted."
- "Every relationship needs an off switch."
- "A log explains; it doesn't prevent."
FAQ
Isn't this just OAuth with extra steps?
Not quite. Standard OAuth 2.0 assumes a client is already registered with a known authorisation server. These drafts extend OAuth-style patterns — Client-ID Metadata plus Verifiable Credentials, in draft-diaconu-agents-authz-info-sharing — specifically to handle agents meeting domains they've never registered with before, which plain OAuth doesn't cover.
Do MCP or A2A already handle this?
No. Those protocols define how agents exchange messages and invoke tools across a connection. They don't verify who's really on the other end, scope what that agent can do, or produce an audit trail — federation is meant to sit alongside them, not replace them.
What actually stops a compromised downstream agent from doing damage?
Three things together: the scoped token it was given only covers one narrow hop, every call it makes gets checked for revocation rather than trusted indefinitely, and any domain it depends on can revoke the relationship unilaterally the moment something looks wrong.
Is there one agreed standard yet?
No. As of the dossier's dating in 2026, there are several competing IETF drafts plus a research protocol (InterSAGE), all converging on the same missing layer but not yet unified into one ratified standard.
Does an audit trail alone keep a system secure?
No — it records what happened so someone can investigate or assign blame afterwards. It does nothing to stop the unauthorised action in the moment; prevention depends on the identity, scoping and continuous-checking steps happening before the audit log is ever written.
Glossary
- Trust domain — a bounded area of policy and administrative control, such as one company's systems, within which identities and permissions are managed consistently.
- Agent gateway — a controlled entry and exit point that mediates and enforces trust and policy when agents from different domains interact.
- Delegation — one agent authorising another agent to act on its behalf, usually with narrower permissions than it holds itself.
- Verifiable credential (VC) — a digitally signed, tamper-evident statement a recipient can check cryptographically without contacting the issuer directly.
- DID (Decentralised Identifier) — a unique identifier not issued by a single central authority, cryptographically verifiable as controlled by a specific entity.
- Monotonic scope narrowing — a rule that each step in a delegation chain can only reduce, never expand, the permissions passed along.
- Token binding / DPoP — a technique tying an access token to the specific device or key that requested it, so a stolen token can't be reused elsewhere.
- Policy Decision Point (PDP) — the component that evaluates whether a request should be allowed, based on current policy.
- Credential Delivery Point — the component that issues or delivers a credential once the Policy Decision Point has approved a request.
- Zero Trust Architecture (ZTA) — a security approach assuming no user or device is trusted by default, requiring continuous verification.
- SPIFFE/SPIRE — an open-source standard and toolset for issuing cryptographic identities to software workloads so they can authenticate to each other.
- Revocation — cancelling a previously granted credential or permission before it would otherwise expire.
- Capability attestation — a verifiable claim about what an agent is actually able or authorised to do, rather than just who it is.
- Accountability chain — a traceable record linking each delegated action back through every agent that authorised or performed it.
The plumber's agent and Amma's agent were never going to share one owner, one password system, or one person to call when something broke. Federation isn't about erasing that boundary; it's about making every crossing of it provable, narrow and reversible — so the handshake nobody sees can still be checked, afterwards, by everyone who needs to.
Sources
- draft-kiliram-agent-trust-auth-framework-00 — IETF Datatracker, 2026
- draft-cui-dmsc-agent-cdi-00: Cross-Domain Interoperability Framework for AI Agents — IETF Datatracker, 2026
- draft-diaconu-agents-authz-info-sharing-01 — IETF Datatracker, 2026
- InterSAGE: The Secure and Verifiable Interoperability Protocol for An Internet of Agents — arXiv, 2026
- Credential Broker for Agents (CB4A) — IETF Datatracker, 2026
- Zero Trust for autonomous agentic AI systems: Building more secure foundations — Red Hat Emerging Technologies, 2026