Part 5 · The Identity & Supply Surface

Security · ~7 min

Keys That Expire in Minutes

A static API key on an agent runtime is the highest-blast-radius credential you can hold — leakable from logs, hooks, and transcripts, with rotation that never matches an incident. Federation removes the key entirely.

Why this, for you: Lesson 3 kept secrets out of the prompt. This goes further: remove the long-lived secret altogether. Workload Identity Federation mints short-lived tokens from an identity the runtime already has — but it moves the risk into a trust policy you can mis-scope, so the policy is now the boundary.

A static sk-ant-... key works until manual rotation, from any network an attacker controls. Workload Identity Federation (WIF) removes it: the workload presents a signed OIDC JWT from an identity provider it already runs inside, and the provider mints a short-lived token bound to a service account. A leaked federated token expires in minutes.

1 Three resources, one trust contract

ResourceRole
Federation issuer (fdis_…)Registers an OIDC provider URL + JWKS source
Service account (svac_…)The non-human identity the minted token acts as
Federation rule (fdrl_…)"When a JWT from issuer X has claims Y, mint a token for account Z, scope S"

The workload presents its IdP-issued JWT via the RFC 7523 jwt-bearer grant; the provider verifies the signature against the registered JWKS, matches claims against the rule, and returns a scoped, short-lived token.

The rule deciding which JWTs may act as a service account is now part of the threat model. WIF doesn't remove the secret problem — it converts it into a trust-policy design problem. The rule's match block is the security boundary.

2 Four scoping pitfalls that widen access

# Each pitfall silently grants more than intended broad subject_prefix → repo:your-org/* accepts fork PRs from any contributor missing audience → system:serviceaccount:* accepts every pod's default token CEL over static match → an over-true expression grants broader access than intended leftover API key → ANTHROPIC_API_KEY="" still wins — unset, don't blank

Pin subject_prefix to a single repo and protected branch; always set audience on both the rule and the token projection; prefer static matchers over CEL; and unset, do not blank, any leftover ANTHROPIC_API_KEY — it outranks federation even when empty. Confirm with ant auth status.

3 Lifetime caps the blast radius — but attestation doesn't come free

The minted token's lifetime is capped at 2 × JWT_remaining, so the federated token can never outlive the upstream identity it was derived from. That's the structural win: a leaked token is useless in minutes.

WIF doesn't close the workload-attestation gap

Token exchange verifies the JWT signature and matches its claims — but does not attest that the workload presenting the token is the one it claims to be. A service account scoped too broadly means WIF "will faithfully mint a valid token for the wrong workload." Treat WIF as authentication for one destination, not a substitute for an attested workload-identity program.

And it isn't always worth the complexity. A small team on a single fixed host can match the blast-radius reduction with vault-rotated keys via a wrapper script (Lesson 3). WIF earns its three extra resources only when the runtime already has an ambient workload identity — a Kubernetes service account, AWS IRSA, GitHub Actions OIDC — shared across multiple workloads.

↪ Your win: a credential that can't outlive its incident

Retrieval practice — recall, don't peek

Question 1Workload Identity Federation replaces a static API key with…

Question 2Under WIF, the security boundary is now the…

Question 3A leftover ANTHROPIC_API_KEY="" is dangerous because it…

Question 4WIF still leaves open the…

Question 5 · spaced recall from Lesson 11Why does an injected prompt fail to bypass the control plane?

Ask me anything. Want to design a federation rule for your CI runner's OIDC identity, or audit where a leftover static key might still shadow it? Next in Part 5: The Package That Doesn't Exist — how hallucinated dependency names become a supply-chain vector.
✎ Feedback