Non-human identity federation across AWS, GCP, and Azure

At a glance

What this is: This guide explains how external OIDC identity federation gives non-human identities short-lived, auditable access across AWS, GCP, and Azure.

Why it matters: It matters because IAM teams need a cloud-wide pattern for workload access that reduces static-secret exposure, narrows privilege, and improves auditability across NHI, autonomous, and human governance programmes.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Riptides' guide to non-human identity federation across AWS, GCP, and Azure

Context

Non-human identity federation is the practice of letting workloads prove who they are through an external identity provider, then exchanging that proof for short-lived cloud credentials. The problem it addresses is simple: static secrets do not scale well across AWS, GCP, and Azure, and they leave too much room for leakage, reuse, and over-broad access.

For IAM and cloud security teams, the governance issue is not just authentication mechanics. It is how to keep workload access temporary, scoped, and auditable while preserving a usable model for CI/CD pipelines, backend services, and AI-driven automation across multiple cloud estates. That is the operating problem this guide is trying to solve.

Key questions

Q: How should security teams implement federation for non-human identities across clouds?

A: Start by using an external OIDC provider to issue short-lived identity tokens, then exchange those tokens for cloud-specific access through tightly scoped trust policies. The important part is claim precision. If issuer, audience, and subject are not narrowly bound, federation replaces one secret problem with a broader trust problem.

Q: Why do static credentials create so much risk for workload identities?

A: Static credentials are durable, reusable, and hard to observe once they leave the vault or secret store. That makes them easy to leak into code, CI/CD systems, and configs, where they can persist long after the workload or team has changed. Federation reduces that standing exposure window.

Q: What do IAM teams get wrong about cloud federation?

A: They often treat federation as an authentication feature instead of an access governance model. The real control is the trust policy, the claim mapping, and the lifecycle process behind them. If those pieces are too broad or poorly maintained, the environment still has excessive privilege.

Q: How do organisations know if federation is actually improving security?

A: Look for fewer long-lived workload secrets, tighter role bindings, and shorter credential lifetimes across AWS, GCP, and Azure. If teams still rely on embedded keys or broad service account access, federation has not materially changed the risk profile, only the login path.

Technical breakdown

OIDC federation for non-human identities

OpenID Connect federation lets a non-human identity authenticate to an external IdP, receive a signed ID token, and exchange that token for cloud access. The cloud provider checks issuer, audience, signature, claims, and expiration before issuing short-lived credentials. That design removes the need to distribute long-lived keys directly to workloads, while preserving a verifiable chain of trust. In practice, the trust policy becomes the control point because it maps identity claims to permissible access. Practical implication: scope claim matching tightly and treat the IdP as part of the access perimeter.

Practical implication: scope claim matching tightly and treat the IdP as part of the access perimeter.

Workload Identity Federation in cloud platforms

AWS, GCP, and Azure each implement federated workload access differently, but the architectural pattern is the same: external identity proof is exchanged for cloud-native, temporary authorisation. AWS uses STS with web identity, GCP uses workload identity pools and service account impersonation, and Azure uses federated credentials with managed identities or app registrations. The key technical distinction is where the trust mapping lives and how granular the claim-to-role binding can be. Practical implication: standardise the policy intent, not the cloud syntax, so you can govern access consistently across platforms.

Practical implication: standardise the policy intent, not the cloud syntax, so you can govern access consistently across platforms.

Why static credentials fail under cloud federation pressure

Static API keys, tokens, and service account files fail because they are durable, portable, and difficult to observe once issued. When they sit in code, config, or CI/CD systems, exposure often outlives the workload that needed them. Federation changes the failure mode by making access ephemeral and tied to a token exchange rather than a stored secret. That does not eliminate risk, but it drastically shrinks the standing exposure window and improves auditability. Practical implication: treat any remaining long-lived secret as an exception that needs a documented business reason.

Practical implication: treat any remaining long-lived secret as an exception that needs a documented business reason.

Threat narrative

Attacker objective: The attacker seeks durable cloud access through a non-human identity path that bypasses human login controls and outlives normal operational review.

1. Entry occurs when a workload or pipeline relies on a leaked long-lived secret, allowing unauthorised token use outside the intended trust boundary.
2. Escalation follows when that secret grants broader cloud permissions than the workload actually needs, enabling access to additional services and environments.
3. Impact is the misuse of cloud resources, configuration, or data through credentials that remain valid long enough to be reused or repurposed.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Federation is now the default answer to static-secret overexposure. The article describes the right architectural direction: short-lived credentials, claim-based trust, and cloud-specific token exchange. That matters because most NHI risk still comes from durable secrets that are hard to rotate, hard to audit, and easy to reuse across cloud boundaries. The practitioner conclusion is that federation should be the baseline pattern for new workload access.

Trust mapping, not token issuance, is the real control plane. The cloud does not just need proof that a token exists. It needs proof that the issuer, audience, subject, and claims align tightly with the workload and the target resource. That is why federation fails when teams treat IdP configuration as plumbing instead of governance. The practitioner conclusion is that every trust policy must be reviewed as an access policy.

Claim scope defines the blast radius of machine identity. The same external IdP can issue tokens to many workloads, but those workloads should not inherit the same access. The article’s strongest practical lesson is that federation only improves security when each cloud binding is narrowly scoped and explicitly mapped to a workload purpose. The practitioner conclusion is to measure federation by reduction in standing privilege, not by how many clouds it reaches.

Identity lifecycle discipline matters more, not less, in federated NHI models. Offboarding, issuer rotation, and claim changes become the real governance events once static keys disappear. That shifts responsibility from secret distribution to trust maintenance, which is easier to overlook because it looks less like a breach response and more like normal infrastructure change. The practitioner conclusion is that federation must sit inside lifecycle control, not outside it.

Cross-cloud federation exposes the identity blast radius. A workload that can authenticate once and move across AWS, GCP, and Azure can be efficient, but it also concentrates trust decisions in one place. That means weak issuer governance or overly broad claim mappings can propagate across the entire environment. The practitioner conclusion is to design for least common access, not convenience-driven reuse.

From our research:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• For the broader control context, see the Guide to the Secret Sprawl Challenge, which explains why exposed secrets persist across code, CI/CD, and cloud estates.

What this signals

Claim-scoped federation is becoming the practical test for workload governance. When the same external IdP can be used across AWS, GCP, and Azure, the difference between secure and unsafe implementation is not the protocol. It is the quality of the claim mapping, the trust policy, and the review process around them. Teams should expect federation to move from architecture choice to audit question quickly.

Secret sprawl remains the structural reason federation matters. With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey, the governance gap is no longer theoretical. Platforms that still tolerate embedded keys and ad hoc tokens will keep producing avoidable exposure.

Federation should now be measured as lifecycle control, not just access control. That means tracking issuer rotation, claim drift, and the number of workloads that still require exceptions. Teams that cannot answer those questions are not operating a mature workload identity programme, regardless of how many clouds they support.

For practitioners

• Inventory all long-lived workload secrets Find API keys, tokens, certificate files, and service account keys stored in code, CI/CD variables, containers, and shared repositories. Classify each by business criticality, rotation difficulty, and cloud reach before migrating it to federation.
• Build trust policies around exact claims Match on issuer, audience, and subject with the narrowest viable values, then test every cloud role binding against a real workload identity. If a token from a different pipeline or environment is accepted, the policy is too broad.
• Separate federation by workload purpose Do not let one external IdP path become a universal credential for all pipelines or services. Assign distinct bindings for production, non-production, and partner-facing workloads so the trust boundary stays visible and reviewable.
• Tie federation to lifecycle events Review issuer metadata, claim mappings, and cloud bindings whenever workloads change ownership, environments are retired, or IdP keys rotate. Offboarding a workload should revoke trust relationships, not just delete local configuration.
• Measure standing privilege reduction Track how many workloads still depend on static secrets and how many cloud permissions remain outside short-lived federation. Use that baseline to prioritise the highest-risk migrations first, especially where secrets appear in CI/CD and code.

Key takeaways

• Federated workload identity reduces reliance on long-lived secrets, but only if trust policies are tightly scoped.
• The biggest governance failure is not token exchange itself, but broad claim mapping and weak lifecycle maintenance.
• IAM teams should measure success by reduced standing privilege and fewer embedded credentials, not by federation adoption alone.

Key terms

• Non-Human Identity Federation: A method of letting software workloads authenticate through a trusted external identity provider and exchange that proof for cloud credentials. It replaces durable secrets with short-lived tokens, which improves auditability and reduces the standing exposure window across AWS, GCP, Azure, and other systems.
• OIDC Trust Policy: The cloud-side rule that decides which external identity claims are accepted and what access they may receive. It is the real governance layer in federation because it binds issuer, audience, subject, and other claims to specific permissions and therefore determines the effective blast radius of the workload.
• Standing Privilege: Access that remains available continuously rather than being created only when needed. In federated workload identity programmes, standing privilege usually appears as long-lived keys, broadly scoped service accounts, or reusable tokens, and it is the main condition federation is meant to reduce.
• Claim Mapping: The process of translating token claims such as issuer, subject, and audience into cloud permissions. It is where identity intent becomes access reality, so weak mapping can turn a technically sound federation flow into an over-permissioned and difficult-to-audit trust relationship.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.

This post draws on content published by Riptides: Non-human identity federation with external IDPs, a guide for AWS, GCP, and Azure. Read the original.