Sharing an AI agent with another organization does not have to mean handing over credentials or duplicating infrastructure. The right model is a governed share: a formal, time-bounded authorization that gives a partner org access to an agent under a defined policy, while your organization retains ownership, can see usage, and can revoke access at any time. This pattern sits at the intersection of cross-org agent federation and the broader question of how agents authenticate across trust boundaries.
Why Organizations Need to Share Agents
Few enterprises operate in complete isolation. You might offer a specialized AI capability to a customer, collaborate with a partner on a joint workflow, or provide internal divisions running as separate tenants access to a centrally managed agent fleet. In all of these cases, the naive alternatives are unsatisfying.
Credential sharing — handing over an API key that gives broad access to your account — is the most common fallback. There is no granularity: the same key that lets the partner call your agent also exposes everything else the key permits. There is no built-in expiry, no usage visibility once the key leaves your hands, and revocation is disruptive because rotating the key breaks every integration the recipient built.
Duplicating the agent in the partner's account avoids some of those problems but creates others: two agents to maintain, configuration drift over time, and no shared audit trail.
A governed share model solves these problems at the source. The agent stays in your organization. The partner gets access under terms you control, usage flows through your platform and audit log, and you can revoke at any time without disrupting your own infrastructure.
The Share Lifecycle
The mechanics of a governed share follow a short, explicit lifecycle designed to keep both sides aware of what is being agreed to.
Initiation. The source organization's owner selects an agent and creates a share targeting a specific partner organization. At this point they configure the share policy — the terms under which the partner can use the agent — and set an expiry date. The system issues a one-time share token. This token is shown exactly once and never retrievable again; after issuance it cannot be recovered from the platform.
Acceptance. The one-time token is sent to the partner organization out-of-band, typically through an existing secure channel. A partner organization owner pastes the token into an acceptance flow. The platform verifies the token and, on success, marks the share as active. The token is consumed in the process; replaying it does nothing.
Active use. From this point forward, users in the partner organization can create connections to the shared agent and dispatch tasks against it. Every dispatch is evaluated against the share policy and the share status. If the share is revoked or expired, dispatch is rejected with a clear error — the partner cannot work around this at the connection level.
Revocation. The source organization can revoke the share at any time. Revocation is immediate and idempotent. Existing connections referencing the revoked share will fail at next dispatch; no grace period allows in-flight work to continue after revocation.
This lifecycle is deliberate. Each step requires explicit action from an authorized party, and the token-based acceptance ensures the partner organization consciously opts in rather than being silently enrolled.
Policies That Govern Each Share
The policy attached to a share is what separates a governed access model from simple delegation. Rather than giving the partner a yes/no permission to use an agent, you attach specific limits that travel with the share and are enforced at runtime.
Request caps. Per-day and per-month request limits bound how heavily the partner can call the agent. Once a cap is reached, subsequent dispatch attempts are rejected until the window resets. This prevents a partner from inadvertently — or intentionally — consuming the bulk of the agent's capacity.
Expiry. Every share carries an expiration date set at creation time. An expired share behaves like a revoked share: dispatch fails, and no action is needed from the source organization. This is valuable in time-limited collaboration scenarios: the share self-terminates at the agreed date without requiring a manual revocation step.
Policy updates. The source organization can update the share policy while the share is active. Adjusting caps or extending expiry does not require re-issuing a token; the updated policy takes effect on the next dispatch evaluation. This allows the relationship to evolve — tightening limits if the partner's usage pattern changes, or relaxing them after a pilot period proves out.
Token Security
The one-time token is the only credential transferred between organizations, so its handling matters. The token is generated with sufficient entropy to resist brute-force search, and it is never stored in a retrievable form — a database breach does not expose live tokens. Because the token is shown once and never retrievable, its exposure window is limited to the moment of issuance. If it is lost before use, the source org creates a fresh share with a new token.
The acceptance endpoint returns a uniform response for all failure modes — wrong token, expired share, unknown organization — so an attacker cannot enumerate valid organization identifiers by observing error differentiation.
Enforcement at Dispatch Time
Share policies are not checked only at connection creation. Every task dispatch through a shared agent connection evaluates the current share state: is the share still active, and have the daily and monthly request caps been reached? If any check fails, the task is rejected before it reaches the agent. Revoking a share or hitting a cap has an immediate effect on ongoing usage, not just on new connections.
Connection creation is gated in the same way. When a user in the partner organization tries to create a connection to the shared agent, the platform verifies an active share exists first. If no share is active, the agent is not visible as a connection target — there is no way to pre-create a connection in anticipation of a share being issued.
Audit Visibility on Both Sides
Governance without visibility is only half the picture. A governed share produces audit events at each lifecycle step: share creation, token issuance, acceptance, policy updates, and revocation. Each event is attributed to the user who performed it and scoped to the organization that took the action. For a deeper look at what makes an audit trail credible for compliance purposes, see Audit Trails That Hold Up: Cryptographic Integrity.
For the source organization, this means you have a complete record of which agents you have shared, with which partner organizations, on what terms, and what the usage pattern looked like over time. For compliance purposes, this record demonstrates that cross-organization access was deliberate, bounded, and reviewed.
Both organizations can list their share relationships independently: the source sees outgoing shares with their current status and policy; the partner sees incoming shares that have been accepted. Neither side has visibility into the other's internal agent configuration or unrelated activity.
How Praesidia Models This
Praesidia implements cross-organization agent sharing as a first-class construct, not a workaround built on API key delegation. Each share has its own lifecycle, policy, and audit trail. Connections from partner organizations reference the share explicitly, making the dependency traceable: you can see which connections are backed by which shares, and revoking a share immediately affects all connections that depend on it.
Token handling follows the same principles Praesidia applies to other one-time credentials: high-entropy generation, secure non-retrievable storage, single display. The one-time constraint is structural — the token is consumed during acceptance, so reuse is impossible regardless of how the partner stores it.
Cross-organization sharing is gated at the plan level. The maximum number of active outgoing shares is bounded by the plan the source organization holds; an organization at its limit cannot create additional shares until an existing one is revoked or expired. This keeps the overhead of managing share relationships a deliberate choice rather than an accidental sprawl.
Policy enforcement is evaluated on every task dispatch, alongside budget caps and content guardrails, so no request can bypass the checks by taking an alternate path. Learn more about how content guardrails apply during task dispatch in content guardrails for AI agents, and how budget caps tie into broader spend control in credits and cost monitoring for agent spend.
Common questions
What happens to a partner's connections if I revoke the share? The connection records in the partner's organization are not automatically deleted, but they become non-functional. Any dispatch attempt through a connection backed by a revoked share is rejected at the policy evaluation step. The partner will see a clear failure at dispatch time. If you later re-share the agent under a new share, the partner would need to create a new connection — existing connections do not automatically bind to a new share.
Can the partner see my agent's internal configuration or version history? No. The shared agent is visible to the partner only as a callable endpoint. The partner can dispatch tasks and see the outputs; they cannot inspect the agent's system prompt, configuration, version history, or any other internal attributes. The agent remains wholly within the source organization's management scope.
How is this different from issuing the partner an API key to my organization? An organization API key grants broad access to your account's API surface, scoped only by the key's permission set. A governed share is a narrowly targeted authorization: it grants access to one specific agent, under specific request caps, with an expiry date, and it can be revoked without touching anything else. It also keeps usage visible in your audit log in a way that an externally held API key cannot. The partner never gets a credential that gives them any foothold in your account beyond the specific agent share.
How does cross-org agent sharing relate to federation? A governed share covers the common case: one organization granting another temporary, policy-bounded access to a specific agent. Federation extends this idea to more complex trust relationships — for example, where agents from multiple organizations collaborate in a shared workflow under mutual attestation. See Cross-Org Agent Federation with Trust Manifests for how that model works.