AWS CLI: InvalidClientTokenId — the security token in the request is invalid

Hi, it's BlueByte. When the AWS CLI answers a command you know should work with An error occurred (InvalidClientTokenId) ... The security token included in the request is invalid, nothing in your account is broken — AWS looked at the credentials the request carried and refused them. We'll walk through what that message means, the handful of reasons AWS rejects a token, how to see exactly which credentials the CLI picked up, how to fix it per cause, and how to keep it from coming back.

What "the security token included in the request is invalid" means

InvalidClientTokenId is a credential-authentication failure, returned before AWS ever checks whether you're allowed to do anything. It can appear on any service call — the AWS docs show it against aws s3 ls (the ListBuckets operation) — so the operation named in the message isn't the culprit:

$ aws s3 ls
An error occurred (InvalidClientTokenId) when calling the ListBuckets operation:
The security token included in the request is invalid.

The phrase "security token" covers the access key ID and, for temporary credentials, the session token that travels with it. AWS is saying it can't map what you sent to a live credential. You never reached the permission check, so this is not an access-denied.

The handful of reasons AWS rejects the token

Most cases are one of these:

• The access key was deleted or deactivated in IAM after you configured it.
• You're using temporary credentials that expired — an STS session from an assumed role, aws sso login, or a manually pasted session token is short-lived, and once it lapses the token is invalid.
• A stale environment variable (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, or AWS_SESSION_TOKEN) lingers in your shell and, because environment variables outrank the credentials file in AWS's precedence order, overrides the good profile you meant to use.
• The key belongs to a different partition than the endpoint — a standard-partition key against a GovCloud (aws-us-gov) or China (aws-cn) endpoint is not recognized.
• The access key ID was copied wrong — truncated or transposed.

First, see which credentials the CLI is actually using

Don't guess which credential went out — ask the CLI. aws configure list prints the resolved values and, crucially, where each came from:

aws configure list

      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************ABCD              env    AWS_ACCESS_KEY_ID
secret_key     ****************wXyZ              env    AWS_SECRET_ACCESS_KEY
    region                us-east-1              env    AWS_DEFAULT_REGION

The Location column answers most of these failures. If it reads env when you expected ~/.aws/credentials, an environment variable is winning. Confirm the identity end to end:

aws sts get-caller-identity

If that returns the same InvalidClientTokenId, the credentials themselves are the problem, not one command. For the full trace of what was loaded, re-run with --debug and read the Looking for credentials via: lines.

Fix it by cause: stale env vars, expired session, dead key

1. Stale environment variables — clear them and let the profile take over:

unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
aws sts get-caller-identity

2. Expired temporary credentials — re-authenticate. For IAM Identity Center / SSO: aws sso login --profile my-sso. For an assumed role, run aws sts assume-role again and replace the exported values.

3. Deleted or deactivated key — check its state, then rotate:

aws iam list-access-keys --user-name my-user

If the key is Inactive or missing, create a new one and store it with aws configure.

4. Wrong partition — target the matching partition, e.g. --region us-gov-west-1, with a key issued there.

A real case: a leftover AWS_SESSION_TOKEN

A deploy script that ran fine yesterday started failing with InvalidClientTokenId on aws s3 cp. aws configure list showed access_key ... Location env AWS_ACCESS_KEY_ID — but the project uses a named profile. Someone had exported temporary credentials in that shell for an unrelated test; the AWS_SESSION_TOKEN among them had since expired, and because env vars outrank the profile, every command carried the dead token. Running unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN and then aws sts get-caller-identity returned the profile's expected ARN, and the deploy went through.

Verify the fix and keep it from recurring

Verify with aws sts get-caller-identity — a JSON block with your Account, UserId, and Arn means the credentials are live. To keep it away: prefer short-lived credentials (SSO or assumed roles) so an old key can't linger; don't export credentials into your shell for one-off tasks — pass --profile instead; and make aws sts get-caller-identity the first step in CI, so a bad credential fails loudly at the top of the job instead of deep inside a deploy.

How it differs from InvalidAccessKeyId and SignatureDoesNotMatch

InvalidClientTokenId means the key ID or session token isn't a live credential AWS recognizes. InvalidAccessKeyId is close but distinct — "The AWS Access Key Id you provided does not exist in our records" — AWS has no record of that key at all, usually a typo or a key from another account. SignatureDoesNotMatch is different again: AWS recognizes the key but the request signature didn't verify, most often a clock off by more than a few minutes (date to check) or a secret key mangled by special characters. And none of these is AccessDenied, where the credentials are valid but lack permission for the action.