Federating agent identity across clouds means letting a workload authenticated in one cloud or cluster prove that identity to a second cloud, without a static secret shared between them. The mechanism differs depending on which boundary you're crossing — cloud-to-cloud within one company's estate, or organization-to-organization across a trust boundary nobody administers jointly — and conflating the two produces architectures that solve the wrong problem.
Why cross-cloud identity doesn't have one answer
Every major cloud provider's workload identity is native to its own tenant: it authenticates workloads it can directly attest — its own compute, its own service accounts, its own instance metadata. That design is correct for the common case of a workload calling that same cloud's services, and it means there is no default answer for a workload running in one cloud that needs to authenticate to a resource in another. Crossing that boundary always requires an explicit federation relationship, because neither cloud's identity provider can natively attest properties of a workload running on someone else's infrastructure.
The naive answer — a static secret or service-account key issued by cloud B and distributed to a workload running in cloud A — reintroduces the exact problem workload identity exists to remove: a standing credential that has to be stored, rotated, and protected from leaking, sitting outside the platform boundary that could otherwise attest to it directly.
OIDC federation: trust the token, not a stored secret
The pattern most cloud providers support today is OIDC-based workload identity federation: the workload's home environment (a Kubernetes cluster, a CI/CD platform, another cloud) issues it a short-lived OIDC token asserting its identity, and the target cloud is configured to trust that issuer, exchanging the token for its own short-lived access token without ever seeing a static credential. This is the same trust-the-token-not-the-secret model used broadly for how to authenticate AI agents: a short-lived, verifiable assertion in place of something standing that can leak.
For an agent runtime, this means an agent deployed in one cloud's Kubernetes cluster can reach a second cloud's API without a static key for that second cloud ever being baked into its configuration or handed to the team operating it. The trust relationship is configured once, centrally, between the two identity providers — not distributed per workload.
The limitation is directionality and scope: federation is typically configured one direction at a time (cloud A trusts tokens from source B for a specific, narrow purpose), and it grants access to the target cloud's resources, not a general cross-cloud identity. An agent estate spanning three clouds needs federation configured for each pair that actually needs to talk, not a single federation relationship that magically covers all of them.
SPIFFE federation: a platform-independent alternative
SPIFFE takes a different approach to the same problem, covered in more depth in mTLS, SPIFFE, and workload identity for agents: rather than tying identity to any single cloud's native mechanism, each environment runs its own SPIFFE trust domain with its own certificate authority, and trust domains federate by exchanging trust bundles — the public keys needed to verify each other's issued identities. A workload in one trust domain can then present its SPIFFE-issued credential (an SVID) and have it verified by a workload in a federated domain, regardless of which cloud either one runs in.
This is a genuinely cloud-agnostic answer, and it is the more scalable approach for an estate spanning many clouds and clusters, because adding a new environment means federating its trust domain with the ones it needs to talk to, rather than configuring a new pairwise OIDC trust relationship for every cloud-to-cloud path. The trade-off is operational: running SPIRE infrastructure and managing trust-domain federation is a bigger commitment than configuring a cloud provider's built-in federation feature, and it's worth adopting deliberately rather than defaulting to it for a two-cloud estate that OIDC federation would handle more simply.
What neither mechanism establishes
Both OIDC federation and SPIFFE federation solve the same category of problem: proving a workload's identity across an administrative boundary without a shared static secret. Neither establishes anything about the logical agent running inside that workload, or the principal it's acting for. A federated identity says "this is a verified workload from a trusted source" — it says nothing about which of potentially many agents sharing that workload made a given call, or which user's task the call serves. That gap is the same one examined generally in machine identity vs. workload identity vs. agent identity, and it doesn't close just because the workload crossed a cloud boundary — if anything, it becomes more important to close, since a cross-cloud call is exactly the kind of hop where attribution is easiest to lose.
Layering agent-level identity and on-behalf-of authority on top of a federated workload connection follows the same pattern as within one cloud: an agent identity carried in the request rather than in the transport, and a short-lived, audience-restricted, scope-limited token obtained through exchange — see OAuth 2.0 token exchange for agent-to-tool authorization and how to give an agent an identity. Those layers matter more, not less, once the call has crossed an administrative boundary where fewer implicit assumptions hold.
Cross-organization federation is a different problem
Cross-cloud federation within one company assumes a shared administrator: someone at the company can configure trust between cloud A and cloud B because they control both. Cross-organization agent identity — a partner's agent calling yours, or vice versa — has no such shared administrator, and a claimed identity from an unfamiliar counterparty is worthless without independent verification.
This is where decentralized identifiers (DIDs) and verifiable credentials become the relevant mechanism instead of cloud-native federation: an agent presents a DID-based identity that can be cryptographically verified without either party operating shared infrastructure, and a verifiable credential can assert properties about that agent (which organization operates it, what it's authorized to do) that the receiving party can check independently. Agent identity spoofing and DID verification covers this mechanism in depth, and cross-org agent federation with trust manifests covers the delegation-scoping layer that has to sit on top of verified cross-org identity — because verifying who an external agent is doesn't yet say what it should be allowed to do once that identity checks out.
Choosing a mechanism
| Boundary | Mechanism | What it establishes |
|---|---|---|
| Workload in cloud A calling cloud B, same company | OIDC workload identity federation | Cloud B trusts this workload's identity from cloud A |
| Workloads across many clusters/clouds, same company | SPIFFE trust-domain federation | Any federated domain can verify any other's workload identity |
| Agent from a partner organization calling yours | DIDs and verifiable credentials | The claimed identity is real and independently verifiable |
| Any of the above, for a specific logical agent and task | Application-level agent identity plus token exchange | Which agent, on whose behalf, for what — layered on top of any of the above |
What good looks like
- No static secrets distributed between clouds or clusters for the purpose of cross-boundary authentication — every cross-boundary trust relationship uses OIDC federation, SPIFFE federation, or an equivalent token-based mechanism.
- Federation relationships are scoped narrowly to the specific source-and-purpose pairs that actually need to exist, not configured broadly for convenience.
- Agent-level identity and on-behalf-of authority are layered on top of every federated connection, so crossing a cloud or organizational boundary doesn't collapse attribution back to "the workload."
- Cross-organization agent calls are verified through DIDs and verifiable credentials, not assumed trustworthy because the call arrived over an authenticated channel.
- Every cross-boundary action carries an audit record naming the source environment, the agent, and the principal — the record that matters most exactly when something crosses a boundary nobody single team controls end to end.
Common questions
Is SPIFFE federation always better than cloud-native OIDC federation for cross-cloud agents? Not always — SPIFFE federation pays off most for estates spanning many clusters or clouds where pairwise OIDC configuration would multiply quickly. A simple two-cloud estate with a small number of well-defined cross-cloud calls is often served adequately, and more simply, by each cloud's native federation feature.
Does federating identity across clouds also federate authorization? No. Federation establishes that an identity from one side is verifiable on the other side; it says nothing about what that identity is authorized to do once verified. Authorization policy has to be configured separately on the receiving side, scoped as narrowly as the actual cross-boundary need requires.
How is cross-organization agent identity different from cross-cloud identity within one company? Cross-cloud identity within one company assumes a shared administrator who can configure trust between both sides. Cross-organization identity has no such shared administrator — a claimed identity from an external party has to be independently verifiable through a mechanism like DIDs and verifiable credentials, rather than through a federation relationship one company configured unilaterally.