768 leaked AWS keys show full admin rights still persist

At a glance

What this is: TruffleHog’s analysis shows that thousands of publicly exposed AWS keys still authenticate, and a large subset of the live keys retain full administrative control over company accounts.

Why it matters: For IAM and NHI practitioners, this is a reminder that leaked credential exposure is not a theoretical issue but a standing access problem that can turn into account takeover, cost abuse, and broad cloud compromise.

By the numbers:

• The median live leaked key was created 1,831 days ago.
• Only 13.7% of the keys where access keys could be enumerated had any newer key alongside the leaked one.
• 90.5% of leaked-key accounts have no budget alert at all.

👉 Read TruffleHog’s research on 768 leaked AWS keys with full admin rights

Context

AWS key leakage is an NHI governance problem because the credential itself becomes the identity, the access path, and often the escalation route. When leaked keys remain valid for years, classic lifecycle assumptions about rotation, revocation, and ownership no longer hold.

This article is about what publicly exposed AWS credentials can still reach in real accounts. The core finding is that leakage is not just visibility loss, it is still-authenticating access with administrative privilege, which puts IAM, PAM, and cloud security teams in the same control conversation.

Key questions

Q: What breaks when a leaked AWS key is still active?

A: When a leaked AWS key is still active, the compromise is no longer about disclosure alone. The credential becomes a live identity that can authenticate, enumerate permissions, and potentially take over the account. If that key is root or AdministratorAccess, the blast radius includes data access, infrastructure changes, and cost abuse before the owner even knows the leak exists.

Q: Why do old AWS keys create such high risk for cloud teams?

A: Old keys are risky because age is a proxy for forgotten ownership, weak rotation discipline, and wider public exposure. A key that has survived for years is more likely to have been copied into repositories, datasets, or build artefacts. That makes it hard to remove everywhere, which is why age must be treated as a governance signal, not just an inventory field.

Q: How do security teams know if AWS key rotation is actually working?

A: Rotation is working when old keys disappear, replacement keys are issued quickly, and no credential remains live without a clear owner and business purpose. If keys continue to authenticate years after disclosure, rotation is not functioning as a control. Teams should measure age distribution, revocation latency, and the percentage of keys with active ownership records.

Q: Who is accountable when an exposed AWS key is used for extortion?

A: Accountability usually spans application owners, cloud platform teams, and identity governance teams because the failure sits at the intersection of deployment practice and access control. NIST Cybersecurity Framework 2.0 helps structure the response across identify, protect, detect, respond, and recover. The practical question is whether the organisation can prove who owned the secret and how quickly it was revoked.

Technical breakdown

Why leaked AWS credentials remain live for years

AWS access keys can remain valid until explicitly rotated or deleted, which means public exposure does not automatically invalidate them. If the key belongs to a root account or an IAM user with AdministratorAccess, the credential is not just an access token but a high-impact NHI asset. The problem is compounded when keys are copied into Git history, datasets, images, or logs, because those repositories create multiple independent exposure surfaces that outlive the original mistake.

Practical implication: build detection around public exposure plus age, not exposure alone.

Why root keys are the most dangerous AWS credential form

A root access key inherits the account’s full control plane permissions, including account closure and organization-wide actions where applicable. That makes root keys structurally different from scoped IAM users because no policy attachment can reduce the inherent blast radius. In practice, any live root key indicates that governance failed before the question of privilege scoping even began. The control issue is not tuning permissions, it is eliminating a credential type that should not exist.

Practical implication: remove root access keys entirely and treat any remaining instance as an urgent exception.

Why quarantine signals matter more than discovery alone

When AWS applies an AWSCompromisedKeyQuarantine policy, it is signalling that the key has been externally exposed and restricted. That indicator only becomes useful if teams treat it as a lifecycle event, not a log entry. Quarantine can reduce immediate damage, but it does not solve ownership, cleanup, or re-exposure across downstream copies of the same secret. The technical lesson is that detection and revocation are different controls, and both are required.

Practical implication: wire quarantine signals into incident response, offboarding, and secret inventory workflows.

Threat narrative

Attacker objective: The attacker wants durable, authenticated access to AWS accounts with enough privilege to steal data, run expensive workloads, or take over cloud operations.

1. Entry occurs when AWS credentials are exposed in public repositories, datasets, container images, or CI logs, giving attackers a valid authentication path.
2. Escalation happens when the leaked key belongs to a root account or an AdministratorAccess IAM user, allowing full control of the AWS account.
3. Impact follows as attackers can enumerate resources, change configurations, access budgets, and potentially close or abuse the account at scale.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Leaked cloud credentials are not just secrets exposure, they are standing non-human identities. Once an AWS key is public and still authenticates, it behaves like an unmanaged NHI with unbounded lifecycle risk. That shifts the governance question from where the secret was stored to whether the identity was ever brought under lifecycle control. Practitioners should treat leaked keys as identities that escaped governance, not as isolated security incidents.

Root access keys are an identity design failure, not a rotation problem. A root key cannot be scoped down, delegated safely, or made low risk through policy tuning. The presence of a live root key shows that the account was built with an identity form that should never have persisted. The practical conclusion is that account-level access governance has to start with elimination of irreducible credentials.

Ephemeral exposure still creates durable trust debt. Publicly leaked keys are often copied into code history, training corpora, images, and package artifacts, which means the original disclosure is only the first copy event. That makes revocation necessary but insufficient, because the identity may be rediscovered and reused elsewhere long after the first fix. The governance lesson is to manage the downstream persistence of secrets, not just the original leak.

Accountability collapses when leaked keys outlive ownership. The median live key in this research was five years old, which is long enough for teams, vendors, and projects to change hands multiple times. A credential with no clear owner becomes an orphaned identity, and orphaned identities are where cloud privilege creep becomes invisible. NHI programmes should treat ownership metadata as a control surface, not an administrative detail.

From our research:

• Only 13.7% of the keys where access keys could be enumerated had any newer key alongside the leaked one, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37%.
• For lifecycle-specific controls, see Ultimate Guide to NHIs , Why NHI Security Matters Now for the governance case behind rotation, ownership, and revocation.

What this signals

Identity blast radius: leaked AWS keys show that the operational problem is not secret storage alone but how far a credential can reach once it becomes live outside the intended lifecycle. For practitioners, that means access age, ownership clarity, and revocation time are more valuable signals than raw leak counts, especially when secret sprawl can persist across code, datasets, and build systems.

With 1 in 4 organisations already investing in dedicated NHI security capabilities and 60% planning to do so within 12 months, credential governance is moving from hygiene work to programme-level priority. The teams that succeed will treat leaked AWS keys as inventory, lifecycle, and accountability problems in one control plane, not as a one-off incident response exercise.

Practitioners should expect leaked key detection to converge with ownership validation, budget control, and exposure provenance tracking. That aligns naturally with the control model described in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where identity assurance and auditability have to work together.

For practitioners

• Delete root access keys immediately Inventory every AWS account and remove any root access key that still exists. If a root key is discovered in a legacy account, treat it as a material governance failure and not a normal secret rotation event.
• Sort NHI secrets by age and rotate stale keys first Build a review queue that prioritises keys older than your accepted maximum age, because long-lived credentials are the ones most likely to have escaped into public corpora and forgotten environments.
• Turn AWSCompromisedKeyQuarantine into an operational trigger Feed quarantine policy events into incident response, ownership validation, and credential replacement workflows so that exposure signals result in actual cleanup rather than passive alerting.
• Add budget alarms to every account Set low-friction budget alerts on all accounts, including development and forgotten test environments, so that cryptomining and runaway spend surface before the compromise becomes expensive.
• Track every leaked key to its downstream copies Assume a secret committed once may exist in multiple repos, datasets, and images. Build a response process that searches for duplicated copies before declaring the exposure closed.

Key takeaways

• Publicly exposed AWS keys remain a live governance problem when they still authenticate, especially if they retain admin or root-level access.
• The evidence points to long-lived, unrotated credentials as the dominant failure mode, which makes lifecycle ownership more important than secret discovery alone.
• Teams should eliminate root keys, prioritise stale credential rotation, and wire exposure signals into incident and budget controls before the next leak is exploited.

Key terms

• Leaked AWS Key: An AWS access key that has been exposed outside the intended environment, such as in code, logs, datasets, or images. In practice it is a live non-human identity until revoked, which means exposure is both a secrecy problem and an access problem.
• Root Access Key: A credential tied to the AWS root account and therefore capable of full account control. Because it cannot be meaningfully scoped down, its continued existence represents a structural identity governance failure rather than a routine secret management issue.
• AWSCompromisedKeyQuarantine: An AWS-applied restriction indicating that a key has been identified as publicly exposed and should be treated as compromised. It is a signal for operational response, but it does not replace ownership cleanup, replacement, and downstream exposure hunting.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.

What's in the full report

TruffleHog's full research covers the operational detail this post intentionally leaves for the source:

• How TruffleHog re-verified 10,616 leaked AWS keys across public repositories, datasets, images, and CI logs
• The method used to classify live keys by principal type, policy attachment, and account ownership
• The account-level reach analysis that shows what a leaked key can do inside AWS
• The re-verification and notification workflow for identified owners

👉 TruffleHog’s full post covers the verification method, account reach analysis, and remediation context.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.