🚨 AWS Error Guide: 'The security token included in the request is invalid' — Fix InvalidClientTokenId

Overview

InvalidClientTokenId means AWS could not recognize the access key ID that signed the request. Unlike an expired token (the key was valid but timed out) or a signature mismatch (the key exists but the secret is wrong), this error says the access key ID itself is unknown to the endpoint being called: it was deleted, never existed in that account, or belongs to a different partition/account than the one you are talking to.

It surfaces from the CLI or any SDK as an HTTP 403:

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid.

The same condition appears from long-lived IAM user keys and from temporary STS credentials whose access key ID is no longer valid.

Symptoms

• Every call fails immediately with InvalidClientTokenId, including aws sts get-caller-identity.
• A profile that worked last week now fails with no config change on your side.
• Works in one account/region but fails against another (partition or endpoint mismatch).
• CI suddenly fails all AWS steps after a key rotation or IAM user deletion.
• Temporary credentials fail even though they are “not yet expired” by their timestamp.

aws sts get-caller-identity

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid.

Common Root Causes

1. The access key was deleted or deactivated

The most common cause: someone rotated or deleted the IAM access key, but a local profile, CI secret, or .env still holds the old key ID.

2. A stale or wrong profile / environment variable

AWS_ACCESS_KEY_ID exported in the shell overrides the profile you think you are using, or AWS_PROFILE points at an old set of credentials. Environment variables win over ~/.aws/credentials.

3. The IAM user itself was deleted

If the IAM user was removed, all of its access keys become invalid immediately, producing this error for every call.

4. Partition or account mismatch

Keys from a standard (aws) partition are used against GovCloud (aws-us-gov) or China (aws-cn) endpoints, or against the wrong account. The key ID is valid somewhere, just not at the endpoint you called.

5. Corrupted or truncated credentials

A copy-paste that dropped characters, a trailing space, or a wrapped line in a secret store yields a key ID AWS cannot match.

6. STS session token missing or mismatched

Temporary credentials require all three of AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN. Supplying the temporary key pair without the matching session token (or with a stale token) triggers InvalidClientTokenId.

Diagnostic Workflow

Step 1: Confirm which credentials are actually in use

Environment variables silently override profiles, so find the real source first:

env | grep -E 'AWS_(ACCESS_KEY_ID|SECRET_ACCESS_KEY|SESSION_TOKEN|PROFILE|DEFAULT_REGION)'
aws configure list

aws configure list shows the resolved access key (masked) and where each value came from (env, profile, shared-credentials-file). If the source is env when you expected a profile, that is your answer.

Step 2: Identify the access key ID being sent

aws configure get aws_access_key_id

AKIAEXAMPLE1234REDACT

Note the ID (redact it in tickets). You will compare this against what IAM actually has.

Step 3: Check whether that key still exists on the user

Using a known-good admin credential (a different working profile), list the keys for the user:

aws iam list-access-keys --user-name <iam-user> \
  --query 'AccessKeyMetadata[].[AccessKeyId,Status]' --output text --profile working-admin

AKIAEXAMPLE9999REDACT   Active

If the ID from Step 2 is absent or shows Inactive, the key was rotated or deactivated — that is the root cause.

Step 4: Rule out partition / endpoint mismatch

aws configure get region
aws sts get-caller-identity --region us-east-1

If calls fail everywhere but the keys are for GovCloud or China, you must target that partition’s endpoint (for example --region us-gov-west-1). A standard-partition key will never validate against aws-us-gov.

Step 5: For temporary credentials, verify the session token

echo "token length: ${#AWS_SESSION_TOKEN}"

A length of 0 means the session token is missing. Temporary STS credentials without the matching AWS_SESSION_TOKEN always fail as InvalidClientTokenId.

Example Root Cause Analysis

A CI pipeline that had run for months began failing every AWS step overnight with InvalidClientTokenId on sts get-caller-identity. Nothing in the pipeline code had changed.

aws configure list inside the runner showed the credentials coming from env:

aws configure list

      Name                    Value             Type    Location
      ----                    -----             ----    --------
   access_key     ****************REDACT              env
   secret_key     ****************REDACT              env

Listing the deploy user’s keys from an admin profile revealed the key ID in the CI secret was gone:

aws iam list-access-keys --user-name ci-deploy \
  --query 'AccessKeyMetadata[].[AccessKeyId,Status,CreateDate]' --output text --profile break-glass

AKIANEWKEYEXAMPLEREDACT   Active   2026-07-07T02:14:00+00:00

A security automation had rotated the deploy user’s access key the night before and deactivated then deleted the old one, but the CI secret store still held the deleted key ID. The old key was valid until the rotation, so the error appeared only when the deleted key was finally used. Fix: update the CI secret with the new key pair (and move to OIDC role assumption so there is no long-lived key to rotate at all). Steps passed on the next run.

Prevention Best Practices

• Prefer short-lived credentials from IAM roles (OIDC in CI, IAM Roles Anywhere, instance profiles, IRSA) over long-lived user keys so there is no key ID to go stale.
• When you rotate a key, update every consumer before deactivating the old key, and deactivate (not delete) first so you can roll back.
• Store credentials in one authoritative place; avoid a mix of exported env vars and profile files that shadow each other.
• Alert on InvalidClientTokenId in CloudTrail and application logs so a rotation gap is caught in minutes, not after a failed deploy.
• Pin the correct partition/region in your tooling so standard-partition keys are never sent to GovCloud or China endpoints.

Quick Command Reference

# See which credentials are resolved and from where
aws configure list

# Show the access key ID currently configured (redact before sharing)
aws configure get aws_access_key_id

# Reveal env vars that may be overriding your profile
env | grep -E 'AWS_(ACCESS_KEY_ID|SECRET_ACCESS_KEY|SESSION_TOKEN|PROFILE)'

# Check whether the key still exists (use a working admin profile)
aws iam list-access-keys --user-name <iam-user> \
  --query 'AccessKeyMetadata[].[AccessKeyId,Status]' --output text --profile working-admin

# Confirm identity once fixed
aws sts get-caller-identity

Conclusion

InvalidClientTokenId means the access key ID signing your request is unknown at the endpoint you called. The usual root causes:

1. The access key was rotated, deactivated, or deleted while a consumer still holds it.
2. A stale env var or profile is shadowing the credentials you intended to use.
3. The IAM user was deleted, invalidating all its keys.
4. A partition/account mismatch (standard keys against GovCloud/China or the wrong account).
5. Corrupted or truncated credential values.
6. Temporary STS credentials sent without the matching session token.

Start with aws configure list to see which credentials are really in use, confirm the key still exists in IAM, then rotate the consumer to short-lived role-based credentials so the problem cannot recur.