What this looks like in practice
The problem
Once agents start calling agents across organizational boundaries — a partner's fulfillment agent, a vendor's support agent — the trust question stops being "is this request authenticated" and becomes "should this specific external party reach this specific internal agent, for this task, right now." A static, all-or-nothing partner API key cannot express that granularity: it authenticates the partner relationship in general, not any specific agent, task, or moment.
Static partner keys also don't produce per-partner audit evidence when something goes wrong. If a shared key is used by several of a partner's systems, or by whichever agent that partner deploys next without notice, an internal security team has no way to attribute a specific action to a specific grant — only to "the partner," which is rarely precise enough for an incident review or a contractual dispute. Securely sharing AI agents across organizations covers this attribution gap in more depth.
What good looks like
Good cross-org agent access treats every exposed agent as its own grant with its own policy, not as part of an undifferentiated "trusted partner" bucket. The practical target: each grant names one agent and one partner organization, the partner has to accept it explicitly, it carries policy — which task types the partner can invoke, how many requests it may send, when the grant expires — and creating, accepting, changing or revoking the grant leaves an audit entry.
This is the same zero-trust principle covered in zero-trust for AI agents — verify explicitly, grant least privilege, assume breach — extended across the org boundary itself. The difference from internal zero-trust is that neither side controls the other's environment, which is why the policy has to be enforced at your boundary on every request, and why each organization needs evidence it can rely on without the other party's internal logs. Securing inter-agent A2A communication covers the protocol-level mechanics, and cross-org agent federation with trust manifests describes the signed-manifest model some teams pursue for larger multi-party relationships.
| Static partner API key | Governed per-agent share | |
|---|---|---|
| Grants access to | The partner relationship as a whole | One specific agent, for one partner organization |
| Revocation scope | Often breaks every integration sharing the key | Revokes only the one share |
| Policy granularity | None beyond "has the key" | Task types, daily and monthly request caps, expiry |
| Audit attribution | To "the partner" | To the specific share, in both organizations' logs |
How Praesidia helps
Praesidia governs cross-org agent access as explicit, per-agent shares rather than implicit trust between organizations:
- One governed share per agent and partner organization. Each share names a single agent and a single target organization, so each external relationship is its own grant, not a member of a shared-key bucket.
- Per-share policy, checked on every dispatch. The share can restrict which task types the partner may invoke and cap requests per day and per month, and it can carry an expiry date. Praesidia evaluates that policy each time a task is dispatched over the connection, and an unknown action value fails closed.
- Explicit acceptance and immediate revocation. Creating a share returns a one-time token. Only the stored hash is kept, and the share stays pending until the partner organization accepts it. Once it is revoked or past its expiry, the next task over that connection is blocked.
- An audit record on each side. Share creation, policy updates and revocation are written to the sharing organization's audit log, and acceptance is written to the accepting organization's log.
Cross-organization agent shares are a plan entitlement; pricing lists the share limit per plan.
What is not available today. Praesidia's signed trust-manifest federation, and the cross-tenant task channel built on it, are switched off in the hosted service. Do not plan a rollout that depends on a partner's agent presenting a signed manifest to Praesidia before it is admitted. If your relationship needs that model, raise it with us, but scope today's deployment on governed shares.
Getting started
- Inventory every cross-org agent relationship, including ones still running on a shared partner API key rather than a per-agent grant.
- Create one share per agent and partner, starting with the relationships that touch the most sensitive systems.
- Set policy per share — allowed task types, daily and monthly request caps, an expiry date — instead of granting a partner broad access by default.
- Send the one-time token to the partner through a separate channel, and confirm that the share is active only after they accept it.
- Retire the old shared key once each partner is on its share, and confirm that the share lifecycle events appear in your audit log.
The AI agent security guide covers the broader zero-trust control set this cross-org model extends.
FAQ
What replaces a shared partner API key? A governed share: one specific agent shared with one specific partner organization, under its own policy. Revoking it cuts off that partner's access to that agent without rotating a key that other integrations also depend on.
How does the partner organization get access? The sharing organization creates the share and receives a one-time token. The partner organization accepts it with that token. Only then does the share become active, and only until it expires or is revoked.
Does Praesidia support signed trust-manifest federation between organizations? Not in the hosted service today. The federation ingest endpoint and the cross-tenant task channel are switched off in production. Cross-org access in Praesidia today runs through governed agent shares.
Who holds the audit record when two organizations are involved? Each organization keeps its own record. The sharing organization's audit log records the share's creation, policy changes and revocation, and the accepting organization's audit log records the acceptance.