Cross-org agent federation is a pattern for letting two organizations delegate limited, revocable trust to each other's agents without sharing credentials or merging access controls. The core mechanism is a signed trust manifest: a versioned document that one organization publishes describing which of its agents it is willing to expose to peers, cryptographically signed so that consumers can verify authenticity before granting any access. This approach keeps each organization's security boundary intact while enabling genuine cross-boundary collaboration.
Why Shared Secrets Are the Wrong Foundation
The most common approach to cross-org agent collaboration today is also the riskiest: one organization gives another a static API key or shared credential, and the receiving side uses it to call agents directly. This works in the short term but creates several compounding problems.
Static shared credentials have no natural expiry. When a partnership ends or a personnel change makes a credential suspect, revoking it requires coordination across organizational boundaries — and in practice, credentials often linger. There is also no built-in scoping: a credential that was issued for one agent typically grants access to whatever the holder can reach with that key, which is rarely what was intended.
Perhaps most importantly, shared secrets offer no verifiability. The receiving organization has no way to confirm that the agent they are calling is the one they agreed to work with, rather than a different agent that happens to be accessible via the same credential. Trust manifests address all three of these problems. For a broader look at the underlying threat, see threat model: agent-to-agent delegation abuse.
What a Trust Manifest Contains
A trust manifest is a structured, versioned document that an organization publishes to describe the agents it is exposing to federation peers. At minimum it contains an enumeration of the federated agents — their identifiers and the capabilities they are offering — along with a version number, an issuance timestamp, and an optional expiry.
The critical property is that the manifest is cryptographically signed. The publishing organization signs it with an asymmetric key pair (Ed25519 is a common choice for this use case because its signatures are compact and fast to verify). The corresponding public key is embedded in the manifest itself, so a consumer can verify the signature without out-of-band key exchange. The consumer's verification step confirms that the manifest came from the organization that holds the private key, and that it has not been tampered with in transit.
Versioning matters because partnerships evolve. As agents are added, removed, or reconfigured, the publisher issues a new manifest version. Consumers that have cached a previous version can detect the mismatch and choose to re-fetch and re-verify before continuing to route tasks to federated agents. For a look at how trust is governed within a single organization before extending it across boundaries, see Governed Connections Between Agents and Resources.
Revocations: Granular Withdrawal of Trust
Publishing a manifest is not a one-time act. Organizations need to be able to withdraw trust for individual agents without invalidating the entire manifest — for example, if a specific agent is taken offline for maintenance or if a misconfiguration is discovered.
Signed revocations serve this purpose. A revocation is a separate signed document that references a specific agent entry from a manifest version and asserts that the named agent should no longer be trusted by consumers. Because revocations are signed by the same key as the manifest, a consumer can verify them independently of any live API call.
Revocations also need to be distributed reliably. A consumer that is not aware of a revocation might continue routing tasks to an agent that should have been excluded. The federation design therefore treats revocations as first-class artifacts alongside manifests, not as out-of-band signals.
Peer-Key Pinning and Trust-on-First-Use
The first time an organization receives a manifest from a peer, it faces a bootstrapping problem: how does it know the public key embedded in the manifest is genuinely from that peer, rather than from an attacker who sent a forged manifest first?
Trust-on-first-use (TOFU) is a pragmatic answer to this problem. On first contact, the consumer stores — pins — the peer's public key. All subsequent manifest versions and revocations from that peer are verified against the pinned key. If a future manifest arrives with a different key, the consumer flags it for operator review rather than automatically accepting the change, because a key change can indicate either a legitimate key rotation or an attempted substitution.
This pinning step requires an explicit operator approval. An automated system accepting key changes silently would defeat the purpose of pinning. The approval gate keeps a human in the loop at the moments that matter most: when trust is first established, and when it changes.
The Consumer Side: Verifying Before Acting
A manifest that arrives from a peer is not automatically trusted. The consumer side of federation has its own verification pipeline: it checks the signature against the pinned key, validates the version and timestamp, and inspects the agent list to determine whether any listed agents are within the scope of what the consumer organization agreed to accept.
Only after verification passes should a consumer consider a federated agent's tasks eligible for routing. This means the cross-tenant task submission path needs to be aware of the manifest's contents. An agent not listed in a valid, non-revoked manifest should be rejected at admission, before any task processing begins.
This admission gate is where the trust manifest becomes operationally meaningful. Without it, the manifest is just a document. With it, every cross-tenant task submission is implicitly a manifest-membership check, ensuring that only agents the peer has explicitly asserted — and that the consumer has approved — can route work through the federation channel.
For a comparison of how trust is handled within a single organization versus across org boundaries, see securely sharing AI agents across organizations.
How Praesidia Approaches Federation
Praesidia is designed around the principle that cross-org trust should be explicit, verifiable, and revocable — not implicit in a shared credential. The federation architecture uses cryptographically signed manifests rooted in each organization's own keys, version-stamped and distributable to peer organizations.
The design includes publish and revocation endpoints for manifest issuers, peer-pin approval flows for consumers, and a cross-tenant channel where federated task submissions are validated against the consumer's manifest store. Each step in the chain requires an explicit, policy-gated action — publishing a manifest requires owner-level permission, and approving a peer-key pin requires a deliberate operator decision.
This is in contrast to approaches that bolt federation on as an afterthought, where trust is implied by network access or a single shared token. Praesidia's model keeps each organization's security boundary intact and gives both sides visibility into exactly what has been agreed to and what can be revoked at any moment.
For teams evaluating federation, the architectural questions to ask any control plane are: can we list exactly which of our agents are exposed to each peer, can we revoke a single agent without disrupting the rest, can peers verify our identity without a shared secret, and can we see every cross-org task in our audit trail? A manifest-based system should be able to answer yes to all four. For how trust scores complement manifest-based access control when deciding which federated agents to trust dynamically, see Trust Scores and Attestations: Deciding Which Agents to Trust.
Common questions
Why not just issue a scoped API key per partner instead of using signed manifests? Scoped API keys can narrow the access granted to a partner, but they do not solve the verifiability problem. A consumer holding a key cannot confirm that the agent they are invoking is the one they agreed to work with, nor can they detect if the key has been issued to additional callers. Signed manifests give both sides an independently verifiable record of what has been agreed to, and revocations give the publisher precise control over individual entries without renegotiating the credential.
What happens to in-flight tasks if a manifest is revoked? A manifest revocation signals that specific agents should no longer be trusted. Tasks that have already been admitted to the cross-tenant channel before a revocation is processed may complete, depending on how the consumer's pipeline handles revocation propagation. Tasks submitted after a revocation is applied and verified should be rejected at admission. This is why designing revocation to propagate quickly — and treating it as a first-class signed artifact rather than a soft signal — matters for operational safety.
How should organizations handle key rotation without losing federation continuity? Key rotation in a TOFU-pinning model requires coordination. The publisher should issue the new key with advance notice, and consumers should have an explicit approval step for the key change rather than accepting it automatically. A clean rotation sequence is: notify peer organizations, publish a new manifest signed with the new key, have consumers review and approve the key change, then retire the old key. Rushing or automating this step removes the verification guarantee that makes the pinning model worthwhile.
How does federation relate to agent-to-agent communication within a single organization? Within a single organization, agent-to-agent communication is governed by connection-level trust and permission policies without the manifest layer. Federation extends that model across org boundaries, adding cryptographic identity proofs because the two sides do not share a common identity provider. See agent-to-agent communication, governed for how intra-org A2A trust is structured.