Killing the Long-Lived Key: AWS IAM Federation Comes to Snowflake, OpenAI and Anthropic

If you ask a security team to name their top Non-Human Identity (NHI) headache, the answer is almost always the same: long-lived API keys sitting in secrets managers, environment variables, CI configs, and, too often, source control. The token your data team minted in Snowflake three years ago to wire up a dbt job. The OpenAI key one engineer pasted into a Lambda environment variable to ship a demo that quietly became a production workload. They never expire on their own, they rarely get rotated, and the only thing standing between an attacker and your data warehouse or your model spend is whatever discipline your team has imposed on a static string.

The good news: three of the platforms most likely to be holding those static strings, namely Snowflake, OpenAI, and Anthropic, now support AWS IAM-based workload identity federation. Snowflake lets an AWS principal authenticate to a Snowflake service user using its IAM role identity. OpenAI and Anthropic both let an AWS workload exchange a short-lived OIDC JWT minted by AWS STS for a platform-issued access token. All three flows eliminate the long-lived credential from the picture entirely.

This is a meaningful shift in how NHIs to these platforms should be modeled, deployed, and governed. Let’s get into what shipped, why it matters, and what your security and platform teams need to be doing about it.

The Actual Problem With API Keys

Before diving into the federation flows, it’s worth being precise about why static API keys are such a persistent NHI risk. The issue isn’t just “they can leak.” The issue is the structure of the trust relationship:

• No principal binding. A leaked Snowflake password or OpenAI key works from anywhere. There is no concept of “this credential should only be presentable by this workload in this account in this region.” Possession is the entire access control story.
• No natural expiry. Keys live until someone remembers to rotate them. In practice, that’s “until something breaks” or “until someone leaves and we panic.” A 2024 key in production in 2026 is the norm, not the exception.
• Discovery debt compounds. Every new microservice, notebook, or batch job that needs Snowflake or OpenAI access generates another key. Multiply by every team, every environment, every short-lived experiment that became permanent. The denominator on “where could a key be?” grows monotonically.
• Audit attribution is weak. A SQL query in Snowflake’s LOGIN_HISTORY tied to svc_etl_user tells you the user logged in. It doesn’t tell you which of the eleven services or three humans who know that password actually ran the query.

Workload identity federation attacks all four. The credential is gone. The “who can present this identity” question is enforced by AWS IAM and the cloud control plane, not by whoever has the secret. Tokens are minted on demand and live for minutes. And the principal in the attestation (an IAM role ARN, an EKS service account) points at a real, named, observable cloud-native identity.

What Snowflake Shipped

Snowflake’s workload identity federation lets you create a service user (a user with TYPE = SERVICE) that authenticates using an attestation from a cloud-native identity provider. For AWS, that’s an IAM role.

The setup is short. On the AWS side, you attach an IAM role to whatever’s connecting: an EC2 instance, a Lambda execution role, an ECS task role, an EKS pod via IRSA. On the Snowflake side, you create the service user and pin its identity to the IAM role’s ARN:

Then in the workload itself, the Snowflake Python connector (v3.17.0 or newer) handles everything:

No password. No private_key. No PAT. The driver presents an attestation derived from the workload’s IAM role identity, Snowflake validates it against AWS, and a session opens. Snowflake also accepts the assumed-role form (arn:aws:sts::account:assumed-role/role_name/role_session_name), which lets you pin authentication to a specific assumed-role session if you want even tighter binding.

You can layer an authentication policy on top to constrain how a service user is allowed to authenticate (for example, restricting it to WIF only and blocking password or PAT fallback paths). This is the piece most teams should not skip. If you create a WIF-enabled user but leave password authentication on, you’ve added a new auth path without closing the old one.

The same WIF mechanism works for Entra ID, GCP service accounts, and OIDC issuers from EKS, AKS, and GKE, but the AWS IAM path is the one most teams will reach for first, because that’s where the existing Snowflake-connected workloads already live.

What OpenAI Shipped

OpenAI’s workload identity federation for AWS is conceptually similar but mechanically different. Instead of validating an AWS attestation directly, OpenAI accepts an OIDC JWT and exchanges it for a short-lived OpenAI access token. There are two AWS flavors:

AWS outbound identity federation. This is a newer AWS capability. An AWS principal calls sts:GetWebIdentityToken to mint a signed OIDC JWT with a configurable audience, signing algorithm, and lifetime. The token’s iss is an account-specific issuer URL, sub is the IAM principal ARN, and OpenAI’s Workload Identity Provider validates it via the AWS issuer’s OIDC discovery metadata.

The IAM policy that authorizes a workload to mint these tokens is itself a useful security primitive. You can pin audience and duration:

That condition block matters. It means the IAM role can only mint OIDC JWTs intended for the OpenAI API, with a maximum 5-minute lifetime. Even if the role is compromised, the blast radius is bounded to OpenAI calls within a 5-minute window, not the open-ended access an exfiltrated API key would give.

On the OpenAI side, you create a Workload Identity Provider configured with the AWS issuer URL and audience, then a service account mapping that pins on the sub claim (i.e., the exact IAM role ARN):

Amazon EKS. For Kubernetes workloads, OpenAI accepts projected ServiceAccount tokens directly. The pod spec mounts a token with audience https://api.openai.com/v1, OpenAI validates it against the EKS cluster’s OIDC issuer, and the sub claim (system:serviceaccount:<namespace>:<service-account-name>) becomes the identity the OpenAI mapping pins on.

Either way, the workload code looks like this on the Python side:

No OPENAI_API_KEY in the environment. No key in the secrets manager. The SDK requests an AWS-signed JWT, hands it to OpenAI, gets back a short-lived access token, and uses that for the actual API call.

What Anthropic shipped

Anthropic’s workload identity federation follows the same architectural pattern as OpenAI’s: an AWS workload mints an OIDC JWT via sts:GetWebIdentityToken, and Anthropic exchanges that JWT for a short-lived API access token. The audience is https://api.anthropic.com, the signing algorithm is RS256, and the IAM-side policy looks nearly identical to the OpenAI version:

Where Anthropic differs is on the configuration side. Instead of a single “Workload Identity Provider plus service account mapping” object, the Anthropic side splits the trust relationship into four explicit, separately auditable resources in the Claude Console:

• Federation Issuer (fdis_...): registers the AWS account’s OIDC issuer URL, with discovery as the JWKS source so Anthropic fetches the keys directly from the AWS issuer.
• Service Account (svac_...): the NHI identity inside Anthropic that the workload authenticates as. Service accounts are members of one or more workspaces.
• Workspace (wrkspc_...): the scoping boundary. Federation rules bind to a specific workspace, which means a compromised role in one part of your AWS footprint cannot be silently re-targeted at a different workspace’s data or model spend.
• Federation Rule (fdrl_...): the actual trust mapping. It points at an issuer, requires audience https://api.anthropic.com, restricts the subject to a configured prefix (typically the full IAM role ARN), and pins everything to a specific service account, workspace, and maximum token lifetime.

The federation rule itself looks roughly like this in practice:

The split-resource model is more verbose than OpenAI’s, but it has real operational upside. Issuers, service accounts, and federation rules each have their own audit trail. Workspace scoping gives you a natural blast-radius boundary on top of the IAM-role binding. And subject-prefix matching makes it trivial to authorize an entire role’s session lineage (e.g., arn:aws:sts::account:assumed-role/role_name/) without re-listing every session name. On the workload side, the only practical difference from the OpenAI flow is the audience and the signing algorithm; the boto3 STS call, token exchange, and SDK plumbing have the same shape.

Why This Matters for Non-Human Identity Security

The two flows look different on the wire (Snowflake validates an AWS attestation directly, OpenAI accepts an OIDC JWT and exchanges it), but the security properties they deliver are the same, and they’re the properties NHI programs have been trying to retrofit onto static keys for years:

The credential is no longer a secret you have to defend. There is nothing to store, nothing to rotate, nothing to leak. The “credential” is the workload’s cloud-native identity, which is enforced by AWS IAM. If your IAM is healthy, your Snowflake and OpenAI access posture is healthy. If it isn’t, you have a bigger problem than these two integrations.

Identity is bound to a real principal. A Snowflake session authenticated via WIF is bound to a specific IAM role ARN. An OpenAI access token minted via WIF is bound to the IAM role ARN (or EKS service account) that requested it. That principal shows up in audit logs on both sides: Snowflake’s LOGIN_HISTORY, OpenAI’s audit surface, and AWS CloudTrail for the underlying STS call. For the first time, “which workload made this call” has a defensible answer.

Blast radius is bounded by token lifetime. The OpenAI WIF flow lets you cap the AWS-issued JWT at 300 seconds. The Snowflake session itself is short-lived. Even a successful credential extraction gives an attacker a window measured in minutes, not the multi-year tail of an exfiltrated API key.

Trust is auditable as a graph, not a key inventory. Instead of asking “where is the OpenAI key?” you ask “which IAM roles are allowed to call sts:GetWebIdentityToken for the OpenAI audience?” Instead of asking “who knows the Snowflake service password?” you ask “which workloads’ IAM roles are mapped to which Snowflake service users?” Both are answerable from cloud-native primitives.

Where This Fits in a Real Non-Human Identity Program

For Clutch customers, the practical workflow looks like this. Discover the existing OpenAI and Snowflake NHIs across your environments: keys in secrets managers, in env vars, in repos, in the platforms themselves. Map each one to the workload that’s actually using it. For workloads on AWS, replace the static credential with a WIF mapping pinned to the workload’s IAM role. Lock down the old auth path on the platform side. Monitor the federated identities the same way you monitor any privileged NHI: drift in the IAM policies, changes to the trust mappings, anomalous usage patterns from the principal.

Skip the Wiring: Terraform Templates in Our Federator Repo

f you’d rather not assemble the IAM roles, trust policies, Snowflake service users, OpenAI Workload Identity Provider configuration, and Anthropic Federation Rules by hand, we’ve added Terraform templates for both flows to clutchsecurity/federator, Clutch’s open-source repo for the IAM federation patterns we recommend.

The federator project is part of our NHI Index initiative, and the goal is exactly what this post is about: helping teams move from static, long-lived NHIs to ephemeral, federated ones with copy-pasteable HCL instead of a stack of how-to pages. The repo already covers cross-cloud federation (AWS ↔ Azure ↔ GCP, both directions) and GitHub Actions → AWS / Azure / GCP for CI/CD. The new Snowflake and OpenAI templates extend the same pattern to two of the most common SaaS destinations for production workloads. Templates are GPL-3.0 licensed, contributions are welcome, and the issue tracker is the right place to file requests as more platforms ship their own WIF endpoints.

The pattern OpenAI and Snowflake are now both endorsing, namely short-lived tokens, cloud-native principals, and federation over secrets, is where every major SaaS platform that takes NHI risk seriously is going to land. Salesforce, GitHub, the major IdPs, and the cloud providers themselves are all on the same trajectory. The teams that move first get the security benefit immediately and the rotation-incident reduction soon after. The teams that wait are still going to be paged at 2a.m. about a leaked key for a while yet.

If you operate Snowflake or OpenAI at any meaningful scale, this is the migration to start scoping now. The technology is here. The remaining work is process: discovery, mapping, cutover, and the discipline to close the old doors after you’ve opened the new one.