Cross-Organisation AI Agent Trust Guide

Partner, supplier and customer AI agents are starting to call your APIs, read your data and take actions in your systems, and most organisations are trusting them with the same static API keys and broad OAuth grants they once gave to integrations. An agent from another organisation is a non-human identity you did not issue, running code you cannot inspect, often acting for a user you do not know. The question is not whether to let it in but how: which trust pattern proves where it came from, how its authority is scoped and attenuated, what you log, what the contract says and how you cut it off. This guide is for IAM architects, API owners and third-party risk teams setting up inbound agent access. Protocol mechanics are covered in the Agent-to-Agent Authentication Guide and the OAuth Identity and Authorization Chaining Across Domains Guide; this page covers the trust decision and how to run it.

Key takeaways

Trust the partner's identity system, not a shared secret. Federation, where your authorisation server validates tokens issued by the partner's, beats static keys because nothing long-lived crosses the boundary.
Issue your own token at your edge. Exchange whatever the partner presents for a short-lived token your authorisation server issues, scoped to one audience, so your resource servers never accept foreign tokens directly.
Record both actor and subject. Tokens and logs should show the partner agent and, where relevant, the user it acts for, using the RFC 8693 act claim or an equivalent.
Bind and limit. Sender-constrained tokens (DPoP or mutual TLS), narrow scopes, rate limits and per-partner quotas reduce the damage when a partner is compromised.
Plan the breakup on day one. One switch per partner that stops new tokens and invalidates existing ones, tested before go-live.

What makes a partner agent different

Unknown runtime: you cannot see the model, prompts, tools or memory behind the agent, so you cannot assume it resists prompt injection. Treat every request as possibly steered by content the partner's agent read elsewhere.
Delegated and chained authority: the agent may act for its own organisation, for one of its users, or for one of your users who delegated to it. Each needs a different token and a different policy.
Inherited compromise: if the partner is breached, the attacker holds the partner's trust. The Salesloft Drift Breach 2025 showed this: stolen OAuth tokens let an attacker call Salesforce APIs as the trusted Drift integration, and Google's threat intelligence group reported over 700 potentially affected organisations. ATT&CK tracks the pattern as T1199 Trusted Relationship.
Speed and volume: agents make far more calls than human-driven integrations, so per-request approval does not scale and rate limits matter.

Trust patterns compared

Pattern	How it works	Strengths	Weaknesses	Use when
Static API key or client secret	You issue a key; the partner stores it	Simple; works everywhere	Long-lived, bearer, shared across the partner's agents; leaks are common	Low-risk, read-only, short pilots only
OAuth client credentials in your authorisation server	Partner is a registered client; gets short-lived tokens	Short-lived tokens, scopes, central revocation	Client secret or key is still a long-lived credential at the partner	Partner agent acting for itself, with a private key JWT or mTLS client authentication
Workload identity federation	Your IdP trusts tokens from the partner's IdP by issuer, subject and audience	No secret crosses the boundary; partner's own controls issue identity	Depends on partner's issuer security; subject naming must be agreed	Partner runs on a cloud or platform with an OIDC issuer
Cross-domain identity chaining	Partner's authorisation server issues a JWT authorisation grant for your authorisation server, which issues your token	Carries user context across domains; claims can be transcribed and downscoped	Needs both authorisation servers to support it; specification still finishing	Partner agent acting for a user across organisations
SPIFFE federation with mTLS	Each trust domain publishes a bundle; workloads verify each other's SVIDs	Strong workload identity, automatic rotation	Both sides must run SPIFFE; service-to-service, not user context	Tightly integrated partners and platform-to-platform links
Cloud cross-account role	Partner assumes a role in your account	Native logging and policy	Confused deputy risk if the role is not bound to the partner's external ID	Partner agent operating your cloud resources

Mechanics worth getting right

Federated credentials: in Microsoft Entra workload identity federation, the federated identity credential's issuer, subject and audience must match the external token case-sensitively. Pin the subject to the specific partner workload, not a wildcard. See the Workload Identity Federation Guide.
Token exchange: RFC 8693 token exchange (grant type urn:ietf:params:oauth:grant-type:token-exchange) lets your authorisation server swap the partner's token for one of yours. The act claim identifies the current actor; nested act claims are history, and RFC 8693 says only the top-level claims and current actor should drive access control. See the OAuth Token Exchange and Delegation Guide.
Identity chaining: draft-ietf-oauth-identity-chaining-17 (19 July 2026, in the RFC Editor queue when checked on 28 October 2026) combines token exchange at the partner's authorisation server with an RFC 7523 JWT grant at yours, and allows claims transcription to map identifiers, remove claims and downscope. Details can still change before RFC publication.
AWS roles: require sts:ExternalId in the trust policy. AWS documents that the third party generates a unique external ID per customer, which stops another customer of the same partner pointing the partner's agent at your role.
A2A agents: A2A 1.0 lets an Agent Card declare security schemes (API key, HTTP authentication, OAuth 2.0, OpenID Connect, mutual TLS). Servers must reject missing or invalid credentials and must not reveal resources the caller cannot access. Prefer OAuth or mTLS schemes for partner agents. See the A2A Protocol Security Guide.
Sender constraint: DPoP (RFC 9449) binds access and refresh tokens to the client's key through the cnf jkt claim, so a token stolen from the partner is useless without the private key. mTLS certificate-bound tokens (RFC 8705) give the same property at the transport layer.

Scoping what a partner agent may do

Control	Setting	Why
Audience	One resource server per token	A token for your orders API cannot be replayed at your HR API
Scope	Named actions, no wildcards; read and write separate	Limits what a steered or compromised agent can do
Token lifetime	Minutes, not hours; no refresh tokens unless needed	Bounds the window after a partner compromise
Data filter	Only the partner's own records or the delegating user's records	Stops cross-tenant reads if authorisation logic fails
Rate and volume limits	Per partner and per agent	Bulk export was the core of the Drift data theft
High-impact actions	Require a human approval in your system or a separate token	The partner's own approvals are invisible to you
Network	Partner egress IP ranges or private connectivity where available	Raises the cost of using stolen tokens

Onboarding a partner agent

Classify the use case: agent acting for the partner, for the partner's users, or for your users. Each determines the trust pattern and whether user consent is needed.
Run a third-party assessment that covers the agent: who operates it, which model and tools it uses, how it handles prompt injection, how it stores your tokens, its incident contact and notification commitment. The Know Your Agent (KYA) Guide lists verification questions.
Agree identity details in writing: issuer URL, subject naming, audience, key rotation, and the claims each side will send and accept.
Register the partner agent as an NHI in your inventory with an internal owner, partner contact, scopes, expiry date and review date.
Configure the trust using the pattern chosen above, with token exchange at your edge and sender-constrained tokens where both sides support them.
Test in a sandbox tenant: wrong audience, expired token, revoked partner, over-scoped request, other partner's data, and burst traffic. All must fail safely.
Test the off switch: disable the federation or client, confirm new tokens fail and measure how long existing tokens keep working.
Go live with monitoring and a first access review within 90 days.

Contract and governance terms

Notification: the partner tells you within an agreed number of hours of any compromise of the agent, its credentials or its identity provider.
Change notice: advance notice of changes to the agent's model, tools or autonomy level that affect what it does in your systems.
Credential handling: tokens stored in a vault, never in prompts, logs or agent memory; no sharing between agents.
Logging: the partner keeps run and tool call logs for agent actions in your systems and provides them on request during an incident.
Termination: your right to suspend access immediately, and the partner's duty to delete your data and tokens.

NIST CSF 2.0 GV.SC-05 expects these supply chain requirements to be written into contracts, and NIST SP 800-53 SA-9 covers external system services.

Detection and measurement

Log every partner token issuance with partner, agent, subject, actor, scopes and source IP, and every API call with the same identifiers.
Alert on: token use from outside the partner's agreed network ranges, volume above the partner's baseline, access to records outside the partner's filter, new scopes requested, and failed audience or signature checks.
Watch the partner's identity configuration: changes to federated credentials, trusted issuers or client keys on your side are high-value events.

Metric	Target direction
Partner agents using federation or token exchange rather than static keys	Up
Partner agents with an owner, expiry and review date in the inventory	100 percent
Median partner token lifetime	Down
Time to fully cut off a partner in a drill	Down
Partner access reviews completed on time	Up

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	GV.SC-05, PR.AA-01, PR.AA-03, PR.AA-05, DE.CM-06	Contract requirements; managing and authenticating external identities; monitoring external providers
NIST SP 800-53 Rev. 5	IA-8, IA-9, AC-6, AC-20, CA-3, SA-9	Non-organisational users and services, least privilege, external systems, information exchange
ISO/IEC 27001:2022 Annex A	5.19, 5.20	Supplier relationships and security in supplier agreements
OWASP Top 10 for Agentic Applications	ASI03, ASI07	Identity and privilege abuse; insecure inter-agent communication
MITRE ATT&CK	T1199, T1528, T1550.001	Trusted relationship abuse; stolen and reused application access tokens

Common failure patterns

One key for all of a partner's agents: no attribution, and revoking it breaks every integration at once.
Accepting the partner's tokens directly at resource servers: your APIs then depend on another organisation's token format, audience handling and revocation.
Wildcard federation subjects: trusting any workload from the partner's issuer rather than the specific agent.
"Full access" grants to small AI vendors: in the Vercel Context.ai OAuth Breach 2026, an employee's broad Google Workspace grant to a third-party AI app became the attacker's route in.
No volume limits: bulk export through a trusted integration looked like normal use until it was too late.
No expiry or review: partner agents outlive the project, the contract and the people who approved them.

Practitioner checklist

Inventory every external agent and integration that calls your systems, with owner, partner contact, credential type and scopes.
Replace static keys with federation or OAuth client credentials using private key JWT or mTLS.
Exchange partner tokens for your own short-lived, single-audience tokens at the edge.
Carry actor and subject in tokens and logs for agents acting on behalf of users.
Use sender-constrained tokens (DPoP or mTLS) where both sides support them.
Set per-partner rate limits, data filters and human approval for high-impact actions.
Write notification, change, logging and termination terms into the contract.
Test the per-partner off switch before go-live and in every annual exercise.
Review each partner agent's access at least every 90 days and remove unused scopes.

Cross-organisation agent trust: Letting partner AI agents act in your systems safely