AWS outbound identity federation shifts NHI access away from secrets

At a glance

What this is: This is a GitGuardian analysis of AWS IAM outbound identity federation and the move from stored secrets to short-lived workload tokens.

Why it matters: It matters because IAM and security teams still have to govern legacy NHIs, secret sprawl, and migration risk while workloads continue to ship.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

👉 Read GitGuardian's analysis of AWS IAM outbound identity federation and NHI migration

Context

NHI governance is moving from static credential storage to identity-based authorization, which changes the problem from where a secret lives to how a workload proves who it is. That shift matters for IAM because workloads, service accounts, API keys, tokens, and AI agents all fall into the same governance domain once access is mediated through short-lived tokens.

GitGuardian uses AWS IAM outbound identity federation as the trigger for a broader point: enterprises cannot modernize authentication by feature rollout alone. Legacy integrations, release pressure, and ownership disputes keep long-lived secrets in circulation, which means the migration has to be managed as a program with measurable control objectives, not as a cloud setting.

For most organizations, this is not a greenfield identity design problem. It is a transition problem in environments where some external services can validate federated tokens today and others still depend on plaintext credentials, which makes the starting position typical rather than exceptional.

Key questions

Q: How should security teams migrate workloads away from long-lived secrets?

A: Security teams should migrate in phases, starting with external-service calls that can already validate federated tokens. Build an inventory of every secret, assign ownership, and retire credentials only after the new path is proven in production. The goal is not simply token issuance, but verified removal of standing access.

Q: When does short-lived token use still leave material NHI risk?

A: Short-lived tokens still leave material risk when old secrets remain in code, CI/CD, or vaults, or when external services accept tokens without strict issuer and audience checks. Ephemeral access reduces exposure time, but it does not fix hidden duplication or weak verification. Governance must cover both the new flow and the legacy residue.

Q: What is the difference between secret rotation and identity federation?

A: Secret rotation changes the value of a credential on a schedule, while identity federation changes the authentication model so a workload proves identity instead of presenting a stored secret. Rotation helps reduce exposure, but federation removes the need for many long-lived credentials in the first place. Most programs need both during transition.

Q: How can teams keep workload identity changes from stalling?

A: Teams should treat workload identity migration as a cross-functional backlog with security, platform, IAM, and application owners all accountable. Break the work into service-by-service milestones, expose progress with metrics, and prioritize the systems with the largest secret footprint or highest blast radius. That is how the change survives normal delivery pressure.

Technical breakdown

How outbound identity federation changes workload authentication

Outbound identity federation replaces a stored shared secret with a token issued for a specific workload identity. In AWS’s model, the workload requests a short-lived JWT through STS, then presents it to an external service that verifies the token using published keys and identity metadata such as audience and lifetime. The architectural shift is that authentication moves from secret custody to identity proof, with policy controlling who can mint tokens and under what constraints. That reduces reliance on static credentials, but it does not remove authorization design, verification logic, or trust in the issuer. Practical implication: teams must validate every external dependency that will accept federated tokens before treating the migration as complete.

Practical implication: Inventory which services can verify federated tokens before you refactor any credential path.

Why secret sprawl persists in hybrid and multi-cloud access

Secret sprawl persists because access patterns rarely stay inside one cloud or one runtime. A workload in AWS may still need to call Azure, Kubernetes, or another SaaS platform, and the easiest short-term fix is to store a credential near the workload. That pattern leaks into code, configuration files, CI/CD systems, and environment variables, where it becomes difficult to rotate or even track. Even when a vault is used, the existence of a vault does not eliminate standing credentials unless the system also enforces rotation, lifecycle ownership, and retirement. Practical implication: governance has to follow the credential across every store, pipeline, and runtime.

Practical implication: Track credential location by workload, not by platform, so hidden copies do not survive the migration.

Identity provenance and policy enforcement in OIDC-based workload trust

OIDC-based workload trust depends on a verifier being able to confirm that a token came from the expected issuer, for the intended audience, and within the allowed lifetime. That is why identity provenance matters as much as token format. Standards such as SPIFFE and adjacent workload identity patterns point in the same direction by treating workload identity as a first-class primitive instead of a side effect of infrastructure. The operational risk is that teams may standardize on the token and forget the surrounding policy, including issuer hygiene, audience scoping, and key rotation for verification. Practical implication: every federation design should include explicit validation rules, not just token exchange logic.

Practical implication: Define issuer, audience, and lifetime rules as policy artifacts before enabling production federation.

Threat narrative

Attacker objective: The attacker wants persistent, reusable access to machine-facing systems by abusing non-human credentials rather than human accounts.

1. Entry occurs when a hardcoded API key, token, or password is discovered in code, configuration, or a CI/CD system.
2. Escalation follows when the exposed credential grants broader-than-intended access to cloud resources, external services, or agent tooling.
3. Impact is achieved when attackers reuse the credential to access workloads, mint tokens, or move through connected systems without user interaction.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

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

NHI Mgmt Group analysis

Identity federation is becoming the default pattern, but migration is the real control problem. The industry can now reduce standing secrets for many workload-to-service flows, yet the hard part is moving production systems without breaking dependencies. That makes governance a transition discipline, not a feature toggle. Practitioners should plan for phased retirement of long-lived credentials instead of assuming the new flow will displace the old one overnight.

Ephemeral credential trust debt is now a measurable NHI risk. Short-lived tokens reduce exposure time, but they also create a new burden: teams must prove that every old secret has actually been removed, rotated, or quarantined. If legacy access paths remain, the organization carries both models at once, which increases operational complexity and audit risk. Practitioners should treat every retained static credential as trust debt that must be paid down on a schedule.

Identity becomes the control plane only when verification is standardized. A federated token is useful only if issuer, audience, lifetime, and validation rules are consistent across services. Without that discipline, organizations exchange one category of secret sprawl for a more fragmented trust model. Practitioners should standardize verification policy before broadening federation across platforms.

Security programs need migration telemetry, not migration optimism. The article’s core insight is that teams need a scoreboard showing where secrets still exist, where they were found, whether they were rotated, and whether they have been retired. That is the difference between a modernization initiative and a governance program. Practitioners should insist on metrics that prove the shrinking of standing access over time.

Agentic AI raises the stakes for the same identity problem. As autonomous software gains execution authority, workload identity becomes the mechanism that determines whether an agent can act safely within bounds. That means the same controls used to retire secrets for workloads will increasingly govern AI agents. Practitioners should prepare for a single identity governance model that covers workloads, bots, and agents.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• For the broader migration problem, see the Secret Sprawl Challenge for the operational mechanics of finding and retiring exposed credentials.

What this signals

Ephemeral credential trust debt will become a useful planning concept for teams that are trying to retire static secrets without breaking production. The debt is not just technical debt, because it includes ownership, verification, and exception handling across multiple systems. As more workloads and agents need cross-platform access, programmes that cannot quantify this debt will struggle to prove progress.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, the secret problem remains structurally larger than most migration plans assume, according to the State of Secrets Sprawl 2026. That scale means the first control objective is visibility into where secrets persist, followed by automated retirement paths.

Practitioners should expect workload identity and agent identity to converge operationally. The same issuer controls, access review patterns, and verification rules that govern federated workloads will increasingly be reused for autonomous software. Teams that build a single identity governance pattern now will be better positioned to absorb agentic AI without creating a separate shadow control plane.

For practitioners

• Map every long-lived credential to a workload owner Create a current-state inventory of secrets in repositories, CI/CD pipelines, configuration files, and vaults, then assign each one to a named owner and retirement date. Use that inventory to identify duplicate credentials and unmanaged copies across environments.
• Pilot outbound federation on external-service call paths Start with workloads that call external platforms such as cloud services or Kubernetes and convert the least risky integrations first. Validate issuer trust, audience scoping, and token lifetime before moving higher-value production paths.
• Track secret retirement as a program metric Measure how many hardcoded secrets remain, how many have been rotated, and how many are fully removed from code and runtime systems. Tie those counts to release trains so modernization keeps pace with delivery.
• Standardize token verification rules across platforms Define common controls for issuer allowlists, audience restrictions, token lifetime, and signing-key rotation so external services validate federated identities consistently. Document exceptions separately so they do not become shadow policy.
• Prepare AI agent access paths for the same governance model Treat AI agents as non-human identities that will inherit the same authentication patterns as workloads, then decide where federation, vaulting, and approval gates apply before agents are allowed production access.

Key takeaways

• Outbound identity federation changes the authentication model, but the migration burden still sits with security, IAM, and platform teams.
• Static secrets remain a governance problem because hidden copies, inconsistent verification, and delayed retirement keep standing access alive.
• Programs that measure secret discovery, rotation, and retirement can prove progress instead of assuming modernization is happening.

Key terms

• Non-Human Identity: A non-human identity is any digital identity used by software rather than a person, including service accounts, API keys, tokens, certificates, workloads, bots, and AI agents. These identities need lifecycle control because they can authenticate, authorize actions, and persist long after the system that created them changes.
• Outbound Identity Federation: Outbound identity federation is a pattern where a workload proves its identity to an external service using a short-lived token instead of presenting a stored shared secret. It shifts governance from secret custody to identity verification, issuer trust, audience scoping, and token lifetime controls.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, pipelines, vaults, configuration files, and collaboration tools. It creates duplicated access paths, makes rotation harder, and leaves organizations unable to prove which secrets still exist or where they are actively used.
• Ephemeral Credential: An ephemeral credential is a short-lived authentication artifact issued for a limited purpose and time window. It reduces exposure compared with static credentials, but it still requires strong issuer controls, monitoring, and a clear retirement path for any older secrets that remain in circulation.

What's in the full article

GitGuardian's full post covers the operational detail this post intentionally leaves for the source:

• Discovery workflow for finding hardcoded secrets across repositories, CI/CD systems, and developer tools
• Vault integration details for correlating secret location, version history, and rotation state
• Analytics examples for measuring whether long-lived credentials are actually shrinking over time
• Push-to-vault remediation flow for turning a leak into a managed migration step

👉 GitGuardian's full post covers the secret discovery, vault integration, and analytics workflow in detail.

Deepen your knowledge

Outbound identity federation and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing static secrets while keeping production stable, the course maps directly to that transition.