The common advice "always pin the `sub` claim" is right for GitHub Actions but wrong as a universal rule. Each federated integration decides which claim actually identifies the caller, and it is not always `sub`. This is the trust gate that [[Workload Identity Federation]] depends on. Wiz's survey of AWS OIDC vendors found the discriminating claim varies: - **GitHub Actions, Terraform Cloud, Vercel** — restrict on `sub` (plus `aud`) - **Microsoft Defender** — has no usable per-tenant `sub`; you must condition on `sts:RoleSessionName` instead - **DoIT** — uses a request tag (`aws:RequestTag/DoitEnvironment`) - **Teleport, sandboxes.cloud** — document only `aud` Copying a GitHub-shaped trust policy onto a vendor whose `sub` is shared or absent produces a policy that *looks* locked down but gates nothing — the operator believes `sub` is doing work it cannot do here. ## The transferable lesson Before trusting any third-party identity assertion, identify which field is actually unique to the principal you mean to admit, then condition on that field — not the one a template happened to use. The same discipline applies to webhook signatures, SSO assertions, and any integration where a foreign system vouches for a caller. ## Sources - [Wiz — Avoiding mistakes with AWS OIDC integration conditions](https://www.wiz.io/blog/avoiding-mistakes-with-aws-oidc-integration-conditions)