Leaked secretsBy Dynv team4 min read

I leaked an AWS access key: what to do, in AWS's own order

Short answer: create a second access key for the same IAM user, switch your applications to it, deactivate the exposed key (do not delete it yet), confirm nothing broke, and only then delete it. Then review CloudTrail for what the key did. AWS documents this order, and a user can hold at most two access keys, which is what makes it possible without an outage.

This is the AWS-specific version of the leaked-key playbook. Everything below is from AWS’s own documentation: the IAM guide on updating access keys and the re:Post article Resolve issues with unauthorized activity in AWS accounts.

The order AWS documents

  1. While the first key is still active, create a second access key (IAM console, Users, your user, Security credentials, Create access key). A user can have a maximum of two access keys.
  2. Update your applications and tools to use the new key. Check the old key’s “Last used” information to find what still uses it. AWS warns that even if “Last used” says the key was never used, you should not delete it immediately.
  3. Deactivate the first key (Actions, Deactivate). Anything still using it stops working at this point; if you find such an application, you can reactivate the key temporarily, update the application, and deactivate again.
  4. After a period long enough to be sure everything has been updated, delete the first key. The re:Post article is explicit for exposed keys: update the key, deactivate the original, “Don’t delete the original access key during this step,” verify the application, and if it is fully functional, delete the original.
  5. Delete root user access keys you no longer need or didn’t create.

If you have lost the secret access key rather than exposed it, AWS says “you must delete the access key and create a new one,” because the secret can be retrieved only when it is created.

If the key was used by someone else

For unauthorized activity, AWS’s article adds:

  • Check that the AWSCompromisedKeyQuarantineV2 policy is attached to the affected IAM user (in the IAM console, the user’s Permissions tab). AWS lists this as a step in its unauthorized-activity procedure.
  • Review CloudTrail Event history for unsanctioned activity such as the creation of access keys, policies, roles or temporary security credentials, checking the event time against when the key was exposed. Delete anything you did not create.
  • Look for resources you didn’t launch, in every region, including regions you never use, and compare this month’s usage with last month’s. If you need to keep a resource for investigation, back it up first (for example an EBS snapshot) before terminating it.
  • Rotate the IAM users’ passwords you created, and deactivate IAM users you didn’t create.
  • Secure the root user with MFA.
  • If you use temporary security credentials, AWS has a separate procedure to revoke them.

What to watch for

  • Two-key limit. If the user already has two keys, you cannot create a second until you delete one; deactivate-then-delete the one that is not exposed only if you are sure nothing uses it.
  • Instance roles instead of keys. The best fix for a leaked access key is not having a long-lived key: workloads on AWS can use roles with temporary credentials, and CI can use OIDC instead of stored keys (GitHub’s explanation).
  • Speed matters. In one 2024 experiment AWS keys planted on GitHub were found and exploited within minutes (summary), so do step 3 first if you see abuse, accepting a brief outage.

After the provider is fixed: every other copy

Replacing the key at AWS is half the job. The same value is usually also in other services, a CI variable, a teammate’s .env or another vault. With Dynv you can preview one operation that finds each copy it knows about (including the same value under another name) and replaces them together: pipe the new value in so it never lands in shell history, for example pbpaste | dynv rotate AWS_SECRET_ACCESS_KEY --leaked --stdin --dry-run, then run it again with --yes (the plan also suggests copies under other names, which you add with --also SERVICE:KEY). --leaked means “everywhere, no fallback, no stages; the old value stops working now”, which is what you want after a leak. Dynv only knows copies stored in Dynv; search repositories, CI and chat for the old value’s prefix yourself. The generic order of operations, with the evidence on how fast leaked keys are used, is in the 15-minute playbook.

Limits of this page

  • We read AWS’s own documentation on 2026-11-01 (linked above) and did not exercise AWS’s console or API for this post. Console layouts and defaults change; follow AWS’s current instructions where they differ.
  • If the key was in a repository, rotating it is the fix; cleaning Git history is housekeeping (how).
  • If an AI chat or an agent saw the key, see what to do.

Facts last verified . Spotted an error? Tell us.

New here? Start here for the guides in a sensible order.