More than 9,300 Amazon Web Services access keys leaked between August 2022 and August 2026 are still live right now, and 768 of them hand over full administrative control of a corporate AWS account to whoever finds them. That is the headline finding from a four-year tracking effort by Truffle Security, published in August 2026, and it lands weeks after GitGuardian’s own State of Secrets Sprawl 2026 report clocked 28.65 million new hardcoded secrets dumped into public GitHub commits in a single year. Put those two data points together and a pattern emerges: cloud credential hygiene is not improving as fast as the amount of code shipping to public repositories is growing.
For engineering teams running production workloads on AWS, the numbers matter beyond the headline. A root key or an AdministratorAccess-tagged IAM key sitting exposed on GitHub or inside a public Hugging Face dataset is not a theoretical risk. It is a working credential that can spin up compute, exfiltrate data, disable logging, and bill the account owner for whatever an attacker decides to run, all without needing to guess a password or break an encryption scheme.
What Truffle Security Found in Its Four-Year AWS Key Audit
Truffle Security has been scanning public sources for AWS credentials since August 2022, and its August 2026 disclosure is the first time the company has published a full four-year retrospective. The scanners pulled 431,875 individual findings out of code repositories, public datasets, container images, package registries, and continuous integration logs. After deduplication, that haystack reduced to 64,024 unique AWS key pairs tied to 50,654 distinct accounts.
Of those 64,024 key pairs, only a subset carried complete, usable credentials: 10,616 key pairs had both an access key ID and a matching secret. Truffle re-verified each one against live AWS APIs as of August 10, 2026, and found that 88% still authenticated successfully. That figure alone tells you how rarely a leaked key gets revoked once it escapes into the wild. Most companies simply never learn a credential is out there, so nothing forces a rotation.
The 768 Keys That Grant Full Administrative Control
The scariest slice of the dataset is the set of keys tied to companies rather than personal or throwaway accounts. Truffle identified 817 exposed keys linked to real corporate AWS accounts. Of those, 526 were root keys, meaning they belong to the single most privileged identity an AWS account can have, one with no permission boundary at all. Another 242 keys belonged to IAM users carrying the AdministratorAccess managed policy, which grants create, modify, delete, and view rights across virtually every AWS service in the account.
Add the root and admin-tier keys together and you get 768 live credentials that hand an outside party complete control of a company’s cloud footprint. That number has stuck in security circles because it is concrete: not “some accounts are at risk” but a specific, working count of 768 doors sitting unlocked. A single 40-character secret is enough to enumerate every resource in the account, create new IAM users for persistence, turn off CloudTrail logging, and launch GPU instances for cryptomining on someone else’s bill.
A separate write-up of the same dataset from RedEye Security’s threat-intelligence team reached the same conclusion: a large share of the internet’s exposed cloud credentials are sitting in plain sight with no owner actively watching for them. Truffle’s researchers also checked how well-monitored the exposed accounts were. Of 2,754 accounts where billing settings were readable, only 262 had budget alerts configured. That means roughly 90% of the accounts holding exposed keys would have no automated warning if an attacker started running up thousands of dollars in compute charges overnight.
Hugging Face Is the Single Biggest Leak Source
Git history and CI logs are the leak sources most security teams expect. What stands out in the 2026 dataset is how much volume comes from somewhere newer: public machine learning datasets hosted on Hugging Face. Truffle found 8,482 unique live AWS keys scattered across 3,394 public Hugging Face datasets, making the platform the single largest contributor to the entire 64,024-key haystack. Roughly 18% of those Hugging Face-sourced keys carried root privileges, a higher root-key ratio than the dataset’s overall average.
The pattern makes sense once you consider how machine learning datasets get built. Researchers write scripts that pull training data from S3 buckets, hardcode credentials to make the pipeline run faster, then upload the resulting dataset, config files, notebooks, and all, to a public repository without stripping the credentials first. Nobody audits a CSV file the way they audit a Dockerfile, so the keys sit there for years.
Why These Keys Never Get Rotated: The Five-Year Problem
Age is the throughline across nearly every number in the report. The median live key in Truffle’s dataset was approximately 1,831 days old, or just over five years. The single oldest live key the company confirmed was more than 17 years old, meaning it predates several major AWS service launches and has survived multiple waves of best-practices guidance telling companies to rotate credentials regularly. Only about 13.7% of exposed accounts showed evidence of a newer access key superseding the leaked one, which implies the vast majority of these organizations never rotated credentials at all after the original leak, whether or not they even knew about it.
This is where AWS’s own guidance and the reality on the ground diverge sharply. AWS’s Identity and Access Management documentation has recommended against using long-lived root and IAM user access keys for years, pushing instead toward short-lived credentials issued through IAM roles and federated identity. The data suggests that guidance has not reached the teams most likely to leak a key in the first place, often smaller engineering groups moving fast on a research project or an internal tool rather than a hardened production service.
GitGuardian’s 2026 Report: 28.65 Million New Secrets in a Single Year
Truffle’s AWS-specific findings sit inside a much bigger trend documented by GitGuardian’s State of Secrets Sprawl 2026 report. GitGuardian scans public GitHub commit activity year-round, and in 2025 it detected 28,649,024 new hardcoded secrets, a 34% increase over 2024 and the largest single-year jump the company has recorded since it started publishing the report. That growth tracked alongside a 43% year-over-year increase in total public GitHub commits, which reached roughly 1.94 billion in 2025, so some of the jump reflects more code shipping overall. But the secrets-per-commit rate still climbed, which means the problem is getting worse relative to the size of the ecosystem, not just growing in step with it.
The longitudinal piece of the GitGuardian report is arguably more damning than the raw leak count. The company has been retesting a cohort of credentials it first confirmed as valid back in 2022. When it checked in January 2025, nearly 70% of those credentials were still valid. Retested again in January 2026, more than 64% were still valid, four years after the original leak. Secrets, once exposed, apparently have a shelf life measured in years, not days.
AI Coding Tools Are Accelerating the Leak Rate
GitGuardian’s 2026 report ties a meaningful share of the secrets increase to the rise of AI-assisted coding. The report documents an 81% surge in leaks tied specifically to AI-service credentials, including a single case of 113,000 leaked DeepSeek API keys found scattered across public repositories. GitGuardian also measured a 5x faster leak rate for LLM infrastructure providers compared with core foundation model providers, and found that commits generated with the help of Claude Code carried a 3.2% secret-leak rate, more than double the 1.5% baseline rate for commits without AI assistance, a finding covered in detail by The Hacker News.
A newer and more specific risk shows up in Model Context Protocol configuration files, the connectors that let AI coding assistants reach external tools and data sources. GitGuardian found 24,008 unique secrets hardcoded directly into public MCP config files, and 2,117 of them were confirmed valid, connecting to live databases, search APIs, and enterprise SaaS platforms. MCP adoption expanded fast through 2025 and 2026 as developers wired AI agents into their existing toolchains, and the convenience of dropping an API key straight into a config file appears to be outpacing awareness that those files often end up committed to a public repo.
AWS Key Exposure by the Numbers
| Metric | Figure |
|---|---|
| AWS keys leaked and still active (Aug 2022–Aug 2026) | 9,300+ |
| Total public findings scanned | 431,875 |
| Unique AWS key pairs identified | 64,024 |
| Distinct AWS accounts affected | 50,654 |
| Complete credential pairs re-verified | 10,616 |
| Share of re-verified keys still authenticating (Aug 10, 2026) | 88% |
| Keys tied to identifiable companies | 817 |
| Root-account keys among company keys | 526 |
| Keys with AdministratorAccess IAM policy | 242 |
| Total keys granting full account control | 768 |
| Median age of a live leaked key | ~1,831 days (~5 years) |
| Oldest live key confirmed | 17+ years |
Where Leaked Secrets Hide: Sources Compared
| Source of leaked credentials | Reported scale | Notable detail |
|---|---|---|
| Hugging Face public datasets | 8,482 unique live AWS keys across 3,394 datasets | ~18% carried root privileges |
| Public GitHub commits (all secret types) | 28,649,024 new secrets in 2025 | 34% year-over-year increase |
| MCP configuration files | 24,008 unique secrets found | 2,117 confirmed valid and live |
| DeepSeek API keys specifically | 113,000 leaked keys | Cited as an AI-service leak case study |
| Docker images, package registries, CI logs | Contributed to 431,875 total findings | Alongside git history and datasets |
What an Attacker Actually Does With a Live Root Key
The practical damage from a leaked AWS key rarely starts with data theft. The fastest, most common abuse pattern is cryptomining: an attacker finds a working key, spins up as many GPU or high-memory EC2 instances as the account’s service limits allow, and starts mining cryptocurrency on the victim’s dime. Because only about one in ten exposed accounts in Truffle’s dataset had budget alerts configured, a company can go days or weeks without noticing anything is wrong beyond an unusually large invoice at the end of the billing cycle.
A key with AdministratorAccess or root privileges opens a wider set of options beyond compute abuse. An attacker can create new IAM users with programmatic access to maintain a foothold even after the original leaked key is rotated, disable CloudTrail to erase the audit trail, or reach into S3 buckets and RDS instances to pull customer data. The absence of scoped permissions is what turns a single leaked string of characters into what amounts to a master key for the entire account.
Historical Context: A Problem That Keeps Repeating
Leaked cloud credentials are not a new story, but the scale keeps climbing every time someone measures it. GitGuardian’s own multi-year tracking shows the annual new-secrets count on public GitHub rising from roughly 11 million in 2021, to 14 million in 2022, 18 million in 2023, 21 million in 2024, and 29 million in 2025. That is close to a threefold increase over five years, even as the industry has spent that same period publicizing best practices around secrets scanning, pre-commit hooks, and short-lived credentials.
What has changed is the shape of the exposure, not just the size. Early secrets-sprawl reporting focused almost entirely on source code repositories. The 2026 data shows the exposure surface has broadened to include AI training datasets, MCP configuration files, and AI-assisted commit workflows, all surfaces that barely existed or were niche five years ago. Security tooling built to catch a hardcoded key in a Python file was not designed with a Hugging Face dataset or an agent config file in mind, and that gap is exactly where a large share of the newest leaks are showing up.
Market Impact: Secrets Management Becomes a Board-Level Line Item
The scale of these reports is pushing secrets management and non-human identity governance further up the enterprise security budget. GitGuardian has increasingly framed its own product roadmap around non-human identity governance, treating every API key, service account, and machine credential as an identity that needs its own lifecycle management rather than a static string buried in a config file. Truffle Security’s business model, built on continuous scanning for exposed credentials across code and beyond, benefits directly from headline numbers like 768 admin-level keys sitting exposed in public.
For AWS specifically, the pressure lands on a company that has spent years pushing customers toward IAM Identity Center, short-lived session tokens, and role-based access instead of static access keys. The persistence of tens of thousands of long-lived key pairs, some over 17 years old, shows how hard that migration is in practice, especially for smaller teams, research groups, and side projects that never got folded into a centralized identity strategy. Expect this report to feature in vendor sales conversations well into 2027 as a concrete illustration of why static credentials remain a live risk even at large, sophisticated organizations.
How to Check Your Own AWS Account for Stale Keys
Security teams reading these numbers should treat them as a prompt to audit their own environment rather than assume the risk belongs to someone else. AWS’s IAM console can generate a full credential report showing every access key’s age and last-used date in a single CSV export.
# Generate and download an account-wide credential report
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 --decode > credential-report.csv
# Flag any access key older than 90 days that is still active
awk -F',' 'NR>1 && $9=="true" {print $1, $10}' credential-report.csvBeyond the credential report, teams should search their own repositories, notebooks, and any datasets they have published publicly for hardcoded AKIA-prefixed strings, enable AWS Config rules that flag root account usage, and move root and long-lived IAM keys to short-lived, role-based access wherever the workload allows it. GitGuardian and Truffle Security both publish free, open-source secrets scanners that can be run against a git history or a CI pipeline before code ever reaches a public repository.
Competitive Landscape: Who Is Building the Fix
The secrets-detection space has grown crowded precisely because the problem keeps getting bigger. GitGuardian and Truffle Security compete most directly on public-repository and git-history scanning, but the two have diverging emphases. GitGuardian leans into its GitHub-wide scale and its pivot toward non-human identity governance, while Truffle Security has built its recent research reputation on chasing credentials into newer corners like Hugging Face datasets and CI logs. GitHub itself ships native secret-scanning and push-protection features for repositories on its platform, and AWS offers its own GuardDuty and IAM Access Analyzer tooling to flag anomalous key usage after the fact.
None of these tools fully solve the problem on their own, which is part of why the leak numbers keep climbing year over year. Native platform scanning catches secrets committed to a monitored repository, but it does nothing for a key hardcoded into a dataset uploaded to a third-party platform, or one pasted into a chat tool that is not part of a CI/CD pipeline. GitGuardian’s 2026 report notes that a meaningful share of secret-leak incidents it tracks originate outside of code repositories entirely, in tools like Slack, Jira, and Confluence, a blind spot most repository-focused scanners are not built to cover.
Predictions: Where Cloud Credential Security Goes From Here
- Expect AWS to accelerate default enforcement of short-lived credentials for new accounts, making static long-term access keys an opt-in rather than a default choice, given how many of the exposed keys in Truffle’s dataset predate current best practices.
- Secrets scanning will expand further into AI-adjacent surfaces, including model weights, fine-tuning datasets, and agent memory stores, as GitGuardian’s MCP and Hugging Face findings push vendors to cover ground beyond traditional source code.
- The 2027 edition of GitGuardian’s State of Secrets Sprawl report will likely show another year-over-year increase, since the underlying drivers, more code, more AI-assisted commits, and more third-party data platforms, are all still growing.
- More companies will adopt automated key-rotation policies with hard expiration dates rather than relying on manual audits, following the pattern of major cloud providers pushing session-based credentials as the default.
- Watch for at least one high-profile breach disclosure in the next 12 months that traces back to a multi-year-old, unrotated AWS key, given how large the pool of still-valid, years-old credentials has become.
What This Means for Engineering Teams Today
The practical takeaway from both reports is less about any single company’s failure and more about a structural gap between how fast software ships and how carefully credentials get managed. A five-year median age for a leaked, still-valid AWS key means most organizations are not finding these leaks through their own processes. They are learning about them, if at all, from third-party researchers like Truffle Security publishing a report. Waiting for that phone call is not a strategy. Running a credential report today, rotating anything untouched in the last 90 days, and scanning public datasets or repos your team has ever published is a same-day fix that costs nothing but a few minutes of AWS CLI time.
Frequently Asked Questions
How many AWS access keys are currently exposed and still active?
Truffle Security’s August 2026 report found more than 9,300 AWS access keys, leaked between August 2022 and August 2026, that were still active and authenticating as of the report’s publication.
How many of the exposed keys have full administrative access?
768 live keys grant full control of a corporate AWS account: 526 are root keys and 242 belong to IAM users with the AdministratorAccess managed policy attached.
Where do most leaked AWS keys come from?
Hugging Face public datasets were the single largest source in the 2026 dataset, accounting for 8,482 unique live keys across 3,394 datasets. Git history, Docker images, package registries, and CI logs made up the remainder of the 431,875 findings Truffle scanned.
What is GitGuardian’s State of Secrets Sprawl 2026 report?
It is GitGuardian’s annual analysis of public GitHub commit activity, published in 2026, which found 28,649,024 new hardcoded secrets added to public repositories in 2025, a 34% increase over 2024 and the largest single-year jump the company has recorded.
Are AI coding assistants making the leak problem worse?
GitGuardian’s data shows commits made with Claude Code assistance carried a 3.2% secret-leak rate, more than double the 1.5% baseline for commits without AI assistance, alongside an 81% surge in AI-service credential leaks overall.
How long do leaked secrets typically stay valid?
GitGuardian’s longitudinal tracking found that 64% of secrets confirmed valid in 2022 were still valid and exploitable when retested in January 2026, four years later, indicating most leaked credentials are never rotated once exposed.
What should a company do if it suspects an AWS key has leaked?
Deactivate and delete the exposed key immediately in the IAM console, generate an account-wide credential report to check for other stale keys, review CloudTrail logs for unauthorized activity, and enable AWS Budgets alerts to catch unexpected compute charges quickly.
Can AWS root account keys be disabled entirely?
AWS recommends deleting root account access keys and using the root user only for a small set of account-level tasks that require it, relying instead on IAM users, roles, and IAM Identity Center for day-to-day programmatic access.
