AWS Access Key ID Identifier

Work out what you are looking at from the first four characters. The difference between AKIA and ASIA decides whether a leak is an emergency.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Identify. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

A long-lived user key

Never expires, and is the credential type that leaks

AKIAIOSFODNN7EXAMPLE

A temporary session key

Expires, and is useless without the session token

ASIAIOSFODNN7EXAMPLE

A role unique id

Not a credential at all, and the thing aws:userid matches on

AROAIOSFODNN7EXAMPLE

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Treating a leaked AKIA key as low risk because the repository is private

    Private repositories get cloned, forked and made public. A permanent key is compromised from the moment it is committed, and deleting the commit does not remove it from every clone.

    Instead:Deactivate the key, check CloudTrail, then delete it. Treat it as used until you know otherwise.

  2. Deleting a leaked key immediately

    It stops the access and also removes the ability to attribute what the key did while it was out.

    Instead:Deactivate first, which is instant and reversible, then investigate, then delete.

  3. Creating IAM user keys for a service

    They never expire, so somebody owns rotating them forever, and everything on EC2, ECS or Lambda already has a role that gives temporary credentials automatically.

    Instead:Use the instance or task role. For CI, use an OIDC trust policy.

The prefix tells you the whole story

AWS assigns a four-letter prefix per resource type. AKIA is a permanent IAM user key, ASIA is a temporary STS session, and AROA or AIDA are not credentials at all.

AKIA is the one that matters

It never expires. Every one is a permanent secret somebody has to rotate, and it is the credential type that ends up in git history, in CI variables and in screenshots. Automated scanners find them in public repositories within minutes of a push.

ASIA is far less alarming on its own

It comes from STS, it expires, and it is useless without the matching session token. An ASIA key id in a log is close to harmless; an AKIA one is an incident.

AROA and AIDA are identifiers, not secrets

They appear in the aws:userid condition key and in CloudTrail. AROA is a role's unique id, which is how a policy can match a specific role regardless of its name, and renaming the role does not change it. That is precisely why it is used there.

Deactivate before you delete

Deactivating a leaked key is instant and reversible, and it stops the bleeding while CloudTrail is checked. Deleting first destroys the ability to correlate the key with what it did.

The account id is inside the key id

The characters after the prefix encode the account number, so a key id alone identifies which account it belongs to without any API call and without the secret. Useful when triaging a leak offline.

What this cannot see

Whether the key is active, or what it can do. Only the id is read, in your browser. Never paste the secret access key anywhere, including here.