For most of the last decade, the practical answer to "how does my build server get AWS credentials" was either a long-lived access key in a secret manager, an EC2 instance role, or — for the lucky few using OIDC — a direct trust between GitHub Actions and an IAM role. The first option is a known-bad supply chain weakness. The second leaks blast radius across every job that runs on a shared runner. The third works, but only between the specific identity providers AWS has hard-coded support for. IAM Identity Center's Trusted Token Issuer (TTI) feature, which moved out of preview during 2025 and broadened ecosystem support throughout early 2026, changes that calculus. Any OIDC-compliant issuer — Okta, Auth0, an internal Keycloak, GitLab self-managed, a Sigstore Fulcio instance, a Spiffe SPIRE federation — can become a token source that Identity Center exchanges for short-lived AWS sessions scoped to a permission set. For supply chain defenders, this is a meaningful upgrade. It is also a configuration surface where the worst mistakes are the easy ones.
What problem does Trusted Token Issuer actually solve?
Before TTI, federating a non-AWS identity into Identity Center meant standing up a SAML application or letting users authenticate through an AWS SSO-managed user pool. Neither pattern works cleanly for workloads. A build agent does not have a browser. A vendor's external CI runner cannot reach your Active Directory. Pushing a static key into the agent then becomes the path of least resistance, and that static key shows up in incident postmortems for years afterward. TTI replaces that pattern. Identity Center accepts a JWT signed by a registered issuer, validates the audience and signature, and exchanges it for an Identity Center session token. The session token is short-lived (default one hour, configurable down to fifteen minutes) and bound to a specific permission set. Long-lived keys never need to exist on the workload, the issuer's signing key is the durable secret, and rotation of that key is a single operation that revokes every downstream credential.
Where does the trust boundary actually sit?
In a TTI deployment, the trust boundary is the OIDC issuer's signing key plus the audience claim. If the issuer is compromised, every workload that authenticates through it is compromised. If the audience claim is too permissive — for example, the same audience used for browser logins is also accepted for workload tokens — an attacker who steals a user's ID token can pivot into a workload session. The temptation in early TTI rollouts is to reuse an existing Okta or Auth0 tenant because it is already integrated with HR systems. That is reasonable, but it means the Okta tenant's super admin is now functionally an AWS root user across every account in the organization. Defenders should treat the TTI issuer as a tier-zero asset: dedicated admin group, hardware-bound MFA, JIT access, signing key in an HSM-backed key vault, and a separate audit log that no one in the AWS account can tamper with.
How does the token exchange actually flow?
The workload requests a JWT from its issuer. The JWT carries a subject (typically the workload identity), an audience (the value Identity Center is configured to accept for that issuer), and standard expiration claims. The workload then calls CreateTokenWithIAM against Identity Center's OIDC endpoint, presenting the JWT in the subject_token parameter with subject_token_type=urn:ietf:params:oauth:token-type:jwt. Identity Center validates the signature against the issuer's published JWKS, checks the audience, applies any attribute mappings configured on the application, and returns an Identity Center bearer token. That token is then used with sso:GetRoleCredentials to retrieve STS credentials for the target account and permission set. None of this requires the workload to hold an AWS key or to call STS directly with a SigV4 signature.
# Workload exchanges its OIDC token for AWS credentials
aws sso-oidc create-token-with-iam \
--client-id "$IDC_APP_ARN" \
--grant-type "urn:ietf:params:oauth:grant-type:jwt-bearer" \
--assertion "$WORKLOAD_JWT" \
--region us-east-1
What goes wrong in production rollouts?
Three recurring failure modes. First, audience reuse: teams configure TTI with the same audience as their human SSO application, and a stolen browser session token grants workload-scope access. Fix this by minting workload tokens with a distinct audience, ideally one per workload class. Second, overly broad permission set mappings: a single permission set with administrator-equivalent privileges gets attached to the TTI application "because it is just for the build server," and then every workload that authenticates through TTI inherits those rights. Fix this by binding attribute mappings to subject patterns and using one permission set per workload role. Third, missing replay protection: JWTs are bearer tokens, and Identity Center honors any unexpired token presented to it. A leaked token from a build log is valid for its full lifetime. Issue short-lived tokens (five to ten minutes), enable Identity Center's requestedTokenUse=once semantics where supported, and treat token leakage as a credential incident with full STS session revocation, not just a log redaction.
How does this interact with build provenance and SLSA?
This is the part defenders most often miss. A workload token's subject claim is durable, observable evidence about which identity ran a job. When the issuer is a CI system that already embeds repository, workflow, and commit metadata in its OIDC tokens — GitHub Actions, GitLab, Buildkite, CircleCI all do this — TTI lets you carry that provenance into AWS authorization decisions. A permission set can be scoped through session policies and trust conditions so that only a token claiming repo:myorg/payments-service and ref:refs/heads/main may push to a specific ECR repository. Pair that with AWS Signer attesting the resulting image, and you have an end-to-end chain: the build provenance is bound to the AWS identity that signed the artifact, and the signature is enforceable at deployment time via ECR signing policies. None of this is possible when the build server is using a long-lived key shared across every pipeline.
What should a defender do this quarter?
Five concrete steps. Inventory every long-lived IAM user with programmatic access keys that are used by automation — not humans — and put them on a sunset plan. Stand up a dedicated OIDC issuer for workload identity if you do not already have one; do not reuse the human SSO tenant. Migrate one high-value pipeline (artifact signing or production deploys) to TTI first so you can validate the audit log shape before scaling. Configure CloudTrail to alert on CreateTokenWithIAM calls that originate from unexpected source IPs or for unexpected audience values. Finally, document the issuer's key rotation runbook and rehearse it; the durable secret has moved, and your incident response procedures must move with it.
How Safeguard Helps
Safeguard maps every workload identity in your AWS organization — IAM users, roles, Identity Center permission sets, and TTI-mapped subjects — into a unified graph that highlights which identities have programmatic access, when they last rotated, and what artifacts they touch. Policy gates block CI/CD changes that introduce new long-lived access keys or that attach permission sets above a configured privilege threshold to TTI applications. Griffin AI correlates CreateTokenWithIAM events with downstream artifact pushes and image signatures, so you can prove that the identity claiming repo:myorg/payments-service is the one that actually signed yesterday's production image. Continuous monitoring flags audience misconfigurations, overly long token TTLs, and JWKS endpoints that fall out of compliance with your hardening baseline — turning IAM Identity Center's flexibility into a defended-by-default capability rather than another configuration surface waiting to break.