AccessDenied on Every Call Doesn't Make a Leaked AWS Access Key Safe

Treat the key as compromised and still active. An AccessDenied response proves AWS recognized the credential and then refused that specific action — it is evidence the key works, not that it is harmless. And because the account is not yours, you cannot rotate or delete the key yourself: remove it from the code and hand the details to whoever owns the account, since they are the only ones who can deactivate it.

Authentication succeeded, authorization failed

AWS separates two questions: who are you (authentication) and what may you do (authorization). A successful sts:GetCallerIdentity that returns an ARN such as arn:aws:iam::123456789012:user/test answers the first question decisively: the key pair is valid, it belongs to an active IAM user, and that user lives in a specific account. Every AccessDenied that follows is an authorization decision made after successful authentication.

Compare that with what a genuinely dead key produces:

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

Deactivated and deleted keys fail with InvalidClientTokenId. AccessDenied is the opposite signal: the credential is fine, the policy said no. Note also that sts:GetCallerIdentity is an identity check that succeeds for any valid credential, so its success is the cleanest possible proof the key is live.

What the test results do and don't prove

• Proven: the key is active, and the returned ARN identifies the exact IAM user and account it belongs to.
• Not proven: that the key is powerless. A few denied calls in IAM and EC2 say those particular actions are unauthorized. They say nothing about S3, SQS, Lambda, billing, or any other surface the user's policies might allow.
• Not proven: that the situation is stable. Policies change over time; the user may have been stripped down since the code was written, or its remaining permissions may still be enough to matter.

The fact that the code targeted the Mechanical Turk requester API, which has since been retired, is irrelevant to the credential's status. Access keys attach to IAM users, not to products — a service shutting down does not retire the keys its code used.

Why you can't rotate it yourself

Rotating or removing an access key requires iam:UpdateAccessKey or iam:DeleteAccessKey on that user, invoked by a principal whose own policies allow it. Holding the secret grants no self-management rights — and the tests already showed iam:DeleteAccessKey is denied for this user. The only parties who can act are the account's administrators or the root user.

There is also a boundary worth respecting: once you have established that the key is live and identified its owner, stop probing. A few diagnostic calls to confirm the credential's state is defensible; systematically mapping what someone else's key can do is unauthorized activity against an account you don't control, however good your intentions.

The right sequence of steps

1. Scrub the credentials from the code — not just the working copy but the repository history, since anything committed remains recoverable in every clone. Treat the secret as burned regardless of what happens next.
2. Report to the account owner. The GetCallerIdentity ARN is genuinely useful here: it names the account ID and the IAM user, so the owner can locate the key in the IAM console immediately. Share the key ID and the ARN — never the secret.
3. Let the owner act. They should deactivate and delete the key, review CloudTrail for anything it did while exposed, and audit what else that IAM user could reach.
4. If the owner can't be identified — a former client or employer, say — go through their security contact or AWS Support rather than sitting on the key or publishing it.

Closing the gap that let this happen

• Use IAM roles or short-lived credentials instead of static keys; when a static key is unavoidable, keep it in a secret manager or a credentials file outside the repository.
• Add secret scanning to pre-commit hooks and CI so keys never land in history in the first place.
• When a project or integration is retired, audit its code for credentials before archiving it — dead code outlives its service and keeps leaking.
• Account owners should enable GuardDuty or IAM Access Analyzer so exposed keys get flagged quickly.

Frequently Asked Questions

How do you tell a live key from a dead one?

A live key authenticates: sts:GetCallerIdentity returns an ARN, and protected calls return AccessDenied when the policy refuses them. A deleted or deactivated key fails with InvalidClientTokenId instead. Denials after successful authentication mean the credential itself works.

If every call is denied, what's the actual risk?

You only sampled a few actions in a couple of services. Untested permissions cannot be ruled out from outside, policies can change in the key's favor later, and the key stays valid until someone deletes it. Today's denials are no guarantee about tomorrow.

Doesn't the service's shutdown disable the key?

No. Access keys belong to the IAM user, not to any product the code called. Retiring an integration leaves the underlying credential fully functional against every other service that user is allowed to touch.

Can whoever holds the key rotate it?

Only a principal with iam:UpdateAccessKey or iam:DeleteAccessKey permission on that user can rotate or remove it. The key holder has no such rights unless the user's own policy grants self-management — which the denials here show it doesn't.

What should the report to the account owner contain?

The key ID (never the secret), the ARN returned by GetCallerIdentity, where the key was found, and evidence that it is still active. That lets the owner find, deactivate, and delete the key, then check CloudTrail for misuse.