Your AWS access key is exposed

• Access key ID: 20 characters. AKIA means a long-term key for an IAM user (or, worse, the root user). ASIA means temporary credentials from STS, which also need a session token.
• Secret access key: 40 characters with no fixed prefix. AWS shows it once, when the key is created.

The ID alone can't sign requests. But the ID and the secret almost always travel together, in the same env file or the same config object, so a visible AKIA usually means the secret is sitting right next to it. Scanners, ours included, look for the ID because the secret has no recognisable shape.

The root user should have no access keys at all. If the exposed key belongs to root, treat the whole account as compromised.

Whatever the IAM user's policies allow. Keys made for a small job often carry AdministratorAccess because that's what made an error go away during setup. With broad permissions, someone can:

• Read, copy or delete your S3 data.
• Launch compute in any region, often for crypto mining, billed to you.
• Create new IAM users and access keys so they keep access after you kill the first key.
• Send email through SES, or read values from Secrets Manager and Parameter Store.

Automated tools search public code and repositories for AKIA keys. Assume a key in a public bundle or repo has already been found.

1. Deactivate it. In the IAM console open Users, pick the user, open the Security credentials tab and set the access key to inactive. If you don't know which user owns it, aws sts get-caller-identity run with that key tells you.
2. Look for persistence. Check IAM for users, access keys, roles, policies and console passwords created recently. Deactivating one key doesn't remove a second one the attacker made.
3. Read CloudTrail Event history, filtered by the access key ID, to see what the key did. Check every region, not just the one you use.
4. Check billing and Cost Explorer for services and regions you don't use, and shut down anything you didn't launch.
5. Create the replacement (ideally a role, not a key), update your apps, confirm they work, then delete the old key.
6. Remove it from your code and git history, and open a support case with AWS if there are charges you didn't cause.

# Which account and user does this key belong to?
AWS_ACCESS_KEY_ID=AKIA... AWS_SECRET_ACCESS_KEY=... aws sts get-caller-identity

# Kill it, then delete it once you're sure
aws iam update-access-key --user-name app-uploader --access-key-id AKIA... --status Inactive
aws iam delete-access-key --user-name app-uploader --access-key-id AKIA...

# What did it do? (management events, last 90 days, current region)
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA...

AWS also watches some public sources, such as GitHub, for exposed keys. When it finds one it may email you and attach a quarantine policy that blocks some actions. That helps, but it doesn't replace any of the steps above, and you can't count on it spotting a key in your site's JavaScript.

• Code running on AWS (Lambda, ECS, EC2) should use an IAM role. No key to leak.
• CI and hosting outside AWS can often use OIDC federation to assume a role with short-lived credentials. GitHub Actions supports this.
• Browser uploads to S3 should use presigned URLs created by your server, so the browser gets a single-use permission, never a key.
• Browser access to AWS services goes through Cognito identity pools, which hand out temporary, scoped credentials.

If you must use a long-lived key, give it its own IAM user with a policy for exactly one job, keep it in a server-only env var, and rotate it on a schedule.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject"],
      "Resource": "arn:aws:s3:::my-app-uploads/*"
    }
  ]
}