Notifications
Clear all
Topic starter
23/06/2026 9:13 pm
TL;DR: AWS IAM-based workload identity federation now replaces long-lived API keys for Snowflake, OpenAI, and Anthropic by binding access to cloud-native principals and short-lived tokens, according to Clutch Security. That shift matters because static secrets have no natural expiry, weak attribution, and an expanding blast radius that existing NHI controls were built to tolerate, not eliminate.
NHIMG editorial — based on content published by Clutch Security: Killing the Long-Lived Key: AWS IAM Federation Comes to Snowflake, OpenAI and Anthropic
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: How should security teams replace long-lived API keys with workload identity federation?
A: Start by mapping each static credential to the workload principal that uses it, then move authentication to cloud-native identity such as an AWS IAM role or service account.
Q: Why do long-lived secrets create more NHI risk than short-lived federated tokens?
A: Long-lived secrets create risk because they can be copied, reused, and forgotten, while federated tokens are tied to a specific principal and expire quickly.
Q: What breaks when a federated NHI still has password or key fallback paths?
A: The migration breaks in practice because the durable credential remains a valid access path, so the organisation keeps the same exposure it was trying to remove.
Practitioner guidance
- Inventory every long-lived platform secret Map Snowflake, OpenAI, and Anthropic credentials back to the workload principal that actually uses them, including secrets in environment variables, repos, and CI configs.
- Replace static credentials with federated workload identities Bind each workload to an AWS IAM role or service account and use that principal as the only approved authentication path to the platform.
- Close fallback authentication paths Remove password, PAT, and legacy key login options after federation is enabled so the old trust path cannot remain in parallel.
What's in the full article
Clutch Security's full blog covers the operational detail this post intentionally leaves for the source:
- Terraform templates for wiring AWS roles, Snowflake service users, and AI platform trust mappings.
- Platform-specific setup steps for Snowflake, OpenAI, and Anthropic, including the configuration objects each one requires.
- Examples of the exact IAM policy conditions used to constrain audience, duration, and subject claims.
- Guidance on extending the same federation pattern across AWS, Azure, GCP, and CI/CD workloads.
👉 Read Clutch Security's analysis of AWS IAM federation for Snowflake and AI platforms →
AWS federation for Snowflake and AI platforms: what changes now?
Explore further
25/06/2026 2:24 am
Static API keys are the wrong trust primitive for modern NHI governance. A key proves possession, not workload context, so it cannot express who may present it, where it may be used, or how long it should live. Federation is not just a better auth pattern, it is a correction to a trust model that was already failing under cloud sprawl. Practitioners should treat long-lived keys as an architectural debt item, not a normal state.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why secret-to-principal mapping remains a governance gap, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: How should organisations govern AWS-based federation for Snowflake and AI platforms?
A: Treat the IAM role, issuer, audience, and subject mapping as governed assets, then review them with the same discipline you apply to privileged access. Validate token lifetime, remove unused mappings, and confirm that offboarding closes the platform-side trust relationship. The control objective is to keep the trust graph small, explicit, and auditable.
👉 Read our full editorial: AWS IAM federation cuts the long-lived key risk for NHI
