Federated AI lets organizations share agent capabilities across organizational boundaries without handing over data, credentials, or infrastructure access. The key mechanism is a signed trust manifest: a versioned, cryptographically verifiable document that describes exactly which agents one organization is willing to share with peers, under what conditions, and with what scope. Data stays where it belongs; only governed access to specific agent capabilities crosses the boundary.
The Problem: Collaboration Without Exposure
When two organizations want to collaborate using AI agents, the naive approach is to hand over a credential — an API key, a service account, or a shared secret — so the receiving side can call the other's agents directly. This works until it doesn't.
Static shared credentials have no built-in expiry and no scope. The receiving organization cannot easily verify which agents they are actually reaching. The issuing organization has no reliable way to confirm the credential is still held only by the intended party. When a partnership changes — an employee departs, a project ends, a vendor relationship sours — revoking the credential requires coordination across organizational boundaries that rarely happens promptly.
There is also a subtler problem: data leakage. When one organization's agent has direct access to another's systems via a shared credential, it is easy for more data to flow than was intended. The agent might log outputs, cache context, or return information that the original owner did not mean to share. Without explicit scoping at the federated-access layer, "sharing an agent" can slide into "sharing data."
Federated AI with trust manifests solves both the credential problem and the data exposure problem by making the shared surface explicit, revocable, and verifiable.
What Trust Manifests Establish
A trust manifest is a structured document that an organization publishes to define its federation surface. It enumerates the specific agents being shared — by identifier and capability — along with a version number, issuance timestamp, and optional expiry. The manifest is signed with an asymmetric key (Ed25519 is well suited here: compact signatures, fast verification) so that consumers can verify its authenticity independently.
The manifest does not contain any private data. It is a declaration, not a data transfer. It says: "These are the agents we are willing to expose to peer organizations. Here is proof that this list came from us and has not been tampered with."
Because the manifest is versioned, the publisher can update it as the federation relationship evolves — adding new agents, removing old ones, changing conditions. Consumers that have cached a prior version can detect the version delta and re-verify before routing additional work. This keeps the shared surface current rather than drifting silently.
Scoping Access to Contain Data Flow
A trust manifest describes which agents are shared, but scoping controls what those agents can do in the context of the consuming organization. Least-privilege scoping is what prevents "sharing an agent" from becoming "sharing everything the agent can reach."
Scoped access means that a federated agent admitted via a consumer's trust policy can only take actions that fall within the agreed scope — specific tools, specific data domains, specific rate limits. Actions outside that scope are rejected at admission, before any processing occurs. This boundary is what keeps the data of each organization separate even as agents move work across the boundary. The same least-privilege principle that applies to governed connections between agents and resources applies here at the cross-org layer.
Spend caps are a closely related control. A federated agent that runs on behalf of a peer organization can, without controls, generate costs that land on the wrong party or exhaust shared resources. Setting per-federation budget limits is as important as scoping the data surface. See Budget Policies: Hard Spend Caps for AI Agents for how to configure those limits.
Revocations complement scoping. If a specific federated agent is misconfigured, compromised, or simply no longer needed, the publisher can issue a signed revocation for that agent without affecting the rest of the manifest. The revocation is a first-class artifact — signed by the same key as the manifest — so consumers can verify it independently and stop routing work to the revoked agent promptly.
Peer-Key Pinning: Establishing Identity at First Contact
The first time an organization receives a manifest from a peer, it faces a bootstrapping problem: how does it know that the public key in the manifest genuinely belongs to the peer, rather than to an attacker who sent a forged manifest first?
Trust-on-first-use (TOFU) pinning is a pragmatic answer. On first contact, the consumer pins the peer's public key. All subsequent manifests and revocations from that peer are verified against the pinned key. If a future manifest arrives signed by a different key, the consumer flags it for explicit operator review rather than automatically accepting the change.
This pinning step requires a deliberate human decision, not an automated acceptance. A system that silently accepts key changes provides weaker guarantees than one that requires a human to approve them. The bootstrap trust decision and any subsequent key rotation are both moments that warrant operator attention, not automation.
What Data Never Crosses the Boundary
Understanding federated AI requires being clear about what does and does not cross the organizational boundary.
What crosses: task requests routed through the cross-tenant channel, task results returned to the initiating organization, and the trust manifest itself (a declaration, not a data store).
What does not cross: the internal data the agent accesses to do its work, credentials used to authenticate to internal systems, logs and context that the agent accumulates during a task run, and any data that falls outside the explicitly agreed scope.
This separation requires that the control plane validates scoping constraints at admission rather than relying on the agent to self-enforce. Enforcement at the boundary is what gives the architecture its strength.
The Consumer Side: Verify Before Admitting
A manifest that arrives from a peer is not automatically trusted. The consumer side runs its own verification pipeline: check the signature against the pinned key, validate the version and timestamp, confirm no relevant revocations have been issued, and check that the agent in the inbound task is listed in the current manifest.
Only after all of these checks pass should a task be admitted for processing. This admission gate is where the manifest becomes operationally meaningful. Without it, the manifest is a document that describes intent. With it, every cross-tenant task submission is an enforced check against what was actually agreed to.
Audit logging at this boundary is also essential. Each cross-tenant task admission — including rejections — should land in both organizations' audit trails. When something goes wrong, the record needs to show exactly which agent submitted which tasks, when, under which manifest version, and what the consumer's decision was. For the properties that make an audit trail hold up under scrutiny, see audit trails that hold up: cryptographic integrity.
How Praesidia Approaches Federated AI
Praesidia is designed around the principle that cross-org trust should be explicit, verifiable, and scoped from the start — not retrofitted onto shared credentials. The federation model uses cryptographically signed manifests rooted in each organization's own keys, with separate publish, revocation, and peer-pin approval flows that require deliberate operator action at each step.
The cross-tenant channel is designed to enforce manifest-membership checks at admission, so that only agents explicitly listed in a valid, non-revoked manifest from an approved peer can route work through the federation path. Each step in the chain requires an intentional, permission-gated decision: publishing a manifest, approving a peer-key pin, and accepting a federated task are all audited events. For a deeper look at the manifest model, read cross-org agent federation with trust manifests. For the agent identity layer that underpins federation trust, see AI agent identity: why agents need their own credentials.
For teams evaluating federation approaches, the key architectural questions to ask any platform are: can you list exactly which agents are exposed to each peer organization, can you revoke a single agent without invalidating the entire relationship, can peers verify your identity without holding a shared secret, and does every cross-org task appear in your audit trail? A manifest-based system designed for data isolation should answer yes to all four.
Common questions
Does federating an agent mean the peer organization can see our internal data?
Not if the federation layer enforces scoping correctly. The peer organization receives task results within the agreed scope, not access to the internal systems the agent uses. The manifest defines which agents are shared; it is the scoping controls at the admission layer — tool restrictions, data-domain limits, spend caps — that determine how much of the agent's internal reach is exposed. Getting this wrong is a configuration failure, not an architectural inevitability, which is why admission-time enforcement matters more than agent-side self-policing.
How do you handle trust when a federated agent is compromised on the peer's side?
Signed revocations allow the publisher to withdraw trust for a specific agent quickly without renegotiating the entire manifest. The revocation is a signed artifact that consumers can verify and apply independently. The consuming organization should also monitor cross-tenant tasks for anomalous behavior — unusual volume, unexpected tool calls, out-of-scope actions — so that signs of a compromised agent surface even before a formal revocation arrives. Audit trails on both sides of the boundary are essential for post-incident investigation.
Can federation work across organizations using different AI providers or agent frameworks?
Federation at the trust layer is provider-agnostic. The manifest describes agents by identifier and capability, not by implementation. As long as both organizations operate compatible federation protocols — how manifests are published and consumed, how revocations are distributed, how cross-tenant tasks are admitted — the underlying model provider or agent framework does not need to be the same. Interoperability depends on the federation channel protocol, not on shared infrastructure. See agent-to-agent protocols and interoperability for more on cross-platform agent integration.