The convenience of dropping API keys directly into configuration files for AI tools is currently outpacing developer awareness regarding the risks of public repository commits. As engineering teams accelerate their delivery pipelines through the integration of automated assistants, the fundamental principles of credential hygiene are often overlooked in favor of immediate functional success. This trend has created a massive reservoir of exposed technical debt that threat actors are increasingly adept at mining for profit. Recent findings highlight a persistent and growing gap between the speed of software development and the maturity of secrets management practices across the industry. Organizations often focus on the security of their production environments while inadvertently leaving the metaphorical keys to the kingdom in public-facing repositories or research datasets.
The scale of this issue is not merely theoretical, as recent forensic audits have uncovered a staggering volume of valid credentials lingering in the public domain. Security researchers have identified thousands of active Amazon Web Services keys that remain operational years after their initial exposure, suggesting that the “leak and forget” mentality is a widespread systemic failure. The complexity of modern cloud environments means that a single forgotten key in a secondary repository can provide a direct path to an organization’s most sensitive data. As we move deeper into an era defined by decentralized development and machine-assisted coding, the necessity of rigorous, automated auditing has never been more urgent for maintaining a defensible security posture.
1. Findings from Truffle Security’s Four-Year AWS Key Investigation
The investigation conducted by Truffle Security provides a comprehensive look at the lifecycle of leaked credentials, drawing from data gathered between August 2022 and August 2026. During this period, scanners identified 431,875 potential credential findings across a variety of public platforms, including code repositories, container images, and package registries. After a rigorous process of deduplication and validation, researchers narrowed this massive dataset down to 64,024 unique AWS key pairs. These keys were associated with 50,654 distinct accounts, illustrating that many organizations are leaking multiple credentials across different projects or developmental stages.
Out of the unique key pairs identified, 10,616 sets included both the access key ID and the matching secret, making them fully functional for API interaction. A live verification process conducted in August 2026 revealed that 88% of these credentials still authenticated successfully against active AWS accounts. This high survival rate indicates a critical lack of awareness or a failure in the incident response pipelines of the affected companies. Many organizations seem to operate under the assumption that an old leak is no longer relevant, failing to realize that a credential remains a viable entry point until it is explicitly revoked or rotated through the IAM console.
2. The 768 Credentials Granting Total Administrative Authority
Among the most alarming discoveries in the research was a subset of 817 keys that were clearly linked to identifiable corporate entities rather than personal sandbox accounts. Within this high-stakes group, 526 keys were identified as root credentials, which represent the absolute highest level of privilege within an AWS environment. A root key has no permission boundaries and can perform any action, including deleting the entire account, changing billing information, or accessing every byte of stored data. The exposure of even a single root key is considered a catastrophic security failure that requires immediate and total remediation of the account’s identity infrastructure.
In addition to the root keys, another 242 credentials were found to be associated with IAM users that had the AdministratorAccess policy attached. While technically distinct from root keys, these credentials provide virtually the same level of functional control over the cloud environment. Combined, these 768 keys represent 768 distinct “unlocked doors” that allow any possessor to manipulate corporate infrastructure at will. The fact that these keys remained active long after their exposure suggests that the organizations involved were not monitoring their IAM usage logs for unauthorized access or auditing their credential reports for long-lived, high-privilege keys.
3. Hugging Face Identified as the Top Source for Leaks
While GitHub has traditionally been the primary focus of secrets detection, Hugging Face has emerged as a significant and often overlooked source of credential exposure. Researchers found 8,482 unique live AWS keys embedded within 3,394 public datasets hosted on the platform. This shift is largely driven by the workflows common in the machine learning community, where researchers often hardcode credentials into training scripts or data-pulling notebooks. When these assets are shared with the broader community to foster collaboration or reproducibility, the sensitive configuration details are frequently included in the upload, creating a massive vulnerability.
The nature of the content on Hugging Face makes these leaks particularly dangerous, as the root-key ratio on this platform was found to be higher than the dataset average, sitting at approximately 18%. Many data scientists operate outside the traditional software development lifecycle, meaning they might not have access to the same automated pre-commit hooks or security gates that protect standard code repositories. Furthermore, because datasets are often large and non-textual in part, traditional security tools may struggle to parse them effectively. This has allowed Hugging Face to become a silent repository for thousands of high-privilege cloud credentials that remain active and ready for exploitation.
4. The Persistence of Stale Keys: The Five-Year Dilemma
One of the most striking metrics revealed in recent audits is the longevity of exposed credentials, with the median age of a live leaked key reaching approximately 1,831 days. This timeframe, spanning five years, suggests that many organizations lack any form of mandatory rotation policy for long-lived access keys. The investigation even identified valid keys that had been active for over 17 years, predating many of the security features and best practices that are considered standard in the current cloud landscape. This persistence highlights a fundamental flaw in how non-human identities are managed, as they are often created for a specific task and then forgotten by the teams that deployed them.
The “Five-Year Dilemma” is exacerbated by the fact that only about 13.7% of the accounts analyzed showed evidence of a newer key replacing the leaked one. This indicates that the vast majority of these organizations are either unaware of the leak or possess such a fragmented view of their cloud infrastructure that they cannot identify which keys are still in use. Without automated expiration or rigorous auditing, these stale keys become “dormant” threats that can be revived by an attacker at any time. This longevity provides a massive window of opportunity for threat actors to conduct long-term reconnaissance or wait for a strategic moment to strike without fear of the credential being revoked.
5. GitGuardian’s 2026 Analysis: 28.65 Million New Secrets Annually
The broader context of secrets sprawl is further illuminated by the findings of GitGuardian, which reported a record-breaking 28.65 million new secrets detected in public commits throughout 2025 and 2026. This represents a 34% increase over the previous year, a growth rate that highlights the sheer volume of sensitive data being pushed to the public web daily. As the volume of code being produced globally continues to rise, the absolute number of errors in credential management is following a similar upward trajectory. This suggests that despite increased awareness and better tooling, the sheer scale of modern development is overwhelming traditional security controls.
The GitGuardian data also points to a disturbing trend in credential lifespan, matching the findings of Truffle Security. When retesting a cohort of credentials first identified in 2022, researchers found that 64% were still valid in early 2026. This longitudinal data confirms that the problem of secrets sprawl is not just about the initial leak, but about the total failure of the revocation process. The digital ecosystem is currently saturated with millions of active secrets, creating a target-rich environment for automated scrapers and malicious actors. As the density of secrets in public repositories increases, the probability of a high-impact breach originating from a simple commit error grows significantly.
6. Impact of AI Development Tools on Leak Frequency
The rise of AI-assisted coding has introduced a new and potent vector for credential exposure, with research showing a significant correlation between AI usage and higher leak rates. Developers using tools like Claude Code or other integrated assistants often rely on the AI to generate boilerplate code or configuration files, which may include hardcoded placeholders or real credentials used during the prompting process. GitGuardian measured a 3.2% secret-leak rate for AI-assisted commits, which is more than double the 1.5% baseline for traditional, manual coding. This suggests that the speed and convenience of AI tools may be encouraging developers to skip essential manual reviews.
Beyond the code itself, the infrastructure supporting these AI models is also a source of vulnerability. Researchers identified a single incident involving 113,000 leaked DeepSeek API keys, demonstrating the massive scale at which AI-related credentials can be exposed. Additionally, the adoption of the Model Context Protocol has led to the exposure of thousands of secrets within config files designed to connect AI agents to external databases and enterprise platforms. As developers rush to build “AI-first” applications, the secondary configuration files required to make these agents functional are becoming a primary source of high-value leaks that bypass traditional source-code scanners.
7. Statistical Breakdown of AWS Key Exposure
A granular look at the statistics reveals the depth of the exposure across the cloud ecosystem, providing a clear picture of the risks involved. Out of the 64,024 unique AWS key pairs identified over the four-year study, the vast majority were associated with accounts that lacked basic financial monitoring. Analysis showed that 90% of the accounts with readable billing settings had no budget alerts configured, meaning an attacker could incur massive costs before the owner noticed. This lack of financial oversight, combined with high-privilege access, makes these accounts ideal targets for resource-heavy attacks such as unauthorized large-scale data processing or infrastructure hijacking.
The data also shows that the problem is not limited to a specific type of user or company size. While root keys are the most dangerous, the 242 keys with AdministratorAccess demonstrate that even delegated permissions are frequently over-provisioned. The median age of these keys, hovering around five years, suggests that the industry is struggling to move away from static, long-lived credentials toward the temporary, token-based authentication that AWS recommends. These statistics serve as a wake-up call for the industry, showing that the majority of exposed accounts are essentially unmonitored and unprotected from the consequences of a successful credential compromise.
8. Comparing Sources: Where Exposed Secrets Reside
The landscape of secrets exposure is diverse, with credentials hiding in places that security teams might not traditionally monitor. While GitHub remains a major source, the emergence of Hugging Face as a primary leak site indicates that data science and AI research are now significant front lines in the war on secrets sprawl. Furthermore, the discovery of secrets within container images and package registries like npm or PyPI shows that the build pipeline itself is often contaminated. A credential baked into a Docker image layer can be extracted by anyone with access to the public registry, even if the final application code is ostensibly clean.
CI/CD logs represent another frequently exploited source of exposure, where credentials used during the build or deployment process are accidentally printed to the console and stored in the log history. These logs are often public or shared among large teams, making them an easy target for reconnaissance. When comparing these sources, it becomes clear that a narrow focus on git repositories is insufficient for a modern enterprise. Threat actors are increasingly looking at the “connective tissue” of the development process, such as configuration files for AI agents or shared datasets, to find the credentials that more traditional scanners might miss.
9. Potential Exploits Using an Active Root Credential
The exploitation of a leaked root key usually follows a predictable and devastating pattern, often starting with the immediate deployment of unauthorized resources. The most common motive is financial gain through cryptomining, where the attacker uses the compromised account to spin up the largest available GPU or compute instances. Because these instances are billed to the victim, the attacker can generate significant profit with zero overhead. If the account lacks budget alerts, as 90% of the surveyed accounts did, the first sign of trouble is often a five-figure cloud bill at the end of the month that the company is legally obligated to pay.
Beyond financial theft, a root key allows for deep and persistent infiltration of the corporate network. An attacker can create new IAM users, set up cross-account roles, and modify VPC settings to create backdoors that survive even if the original leaked key is eventually deleted. They can also disable security features like CloudTrail or GuardDuty to hide their tracks, making it nearly impossible for the victim to perform a successful forensic analysis. The ability to exfiltrate entire databases or intercept sensitive traffic makes the exposure of a root key a high-priority emergency that threatens the very existence of a digital business.
10. Historical Context: A Persistent and Growing Issue
The problem of leaked cloud credentials has been a documented security risk for over a decade, yet the industry has failed to reverse the trend. From 2021 to 2026, the number of new secrets detected annually on public GitHub has nearly tripled, rising from 11 million to over 28 million. This historical trajectory shows that the adoption of cloud-native technologies has outpaced the implementation of the security controls needed to manage them safely. Despite the development of sophisticated scanning tools and the promotion of “Shift Left” security philosophies, the rate of human error remains a constant variable in the software development process.
This persistent growth is also a reflection of the changing nature of software architecture. The move from monolithic applications to microservices has increased the number of service-to-service interactions, each requiring its own set of credentials or API keys. Each new integration point is a potential site for a hardcoded secret. Historically, security was often treated as a final gate before release, but the modern continuous deployment model means that code is shipping faster than it can be audited. This historical context suggests that without a fundamental change in how identities are issued and managed at the infrastructure level, the volume of leaked secrets will continue to grow alongside the digital economy.
11. Market Consequences: Secrets Governance as an Executive Priority
The massive scale of credential leaks is transforming secrets management from a technical niche into a board-level governance issue. Organizations are realizing that the financial and reputational risks associated with a single leaked key are too high to be managed solely by individual development teams. This has led to the rise of non-human identity governance as a distinct category within the security market. Companies are now investing in centralized platforms that provide visibility across all repositories, cloud environments, and communication tools to ensure that no secret remains unmonitored.
The market impact is also being felt by cloud providers and tool vendors, who are under increasing pressure to provide “secure by default” configurations. AWS and other major players are pushing harder for the adoption of IAM Identity Center and short-lived credentials to reduce the reliance on static keys. For the enterprise, the cost of failing to manage secrets is no longer just a potential breach, but also the increased insurance premiums and regulatory scrutiny that follow a public exposure. As we look toward the next several years, the ability to demonstrate a robust secrets management lifecycle will become a standard requirement for doing business in a highly regulated and interconnected global market.
12. Procedures for Auditing Your AWS Account for Old Keys
Security departments should use these steps to evaluate their internal environments and mitigate the risk of exposed credentials. The first priority is to gain a complete understanding of all active keys within the environment to identify potential vulnerabilities before they can be exploited.
- Produce and acquire a comprehensive account credential summary. Use the AWS CLI to request a report of all users and their credential status. This provides a baseline for all subsequent auditing activities and ensures that no identity is overlooked.
aws iam generate-credential-reportaws iam get-credential-report --query 'Content' --output text | base64 --decode > credential-report.csv
- Identify any active access credentials exceeding a 90-day lifespan. Filter the generated report to find keys that have not been rotated recently. Any key older than 90 days should be considered a candidate for immediate rotation or deactivation to minimize the window of exposure.
awk -F',' 'NR>1 && $9=="true" {print $1, $10}' credential-report.csvInspect public-facing assets for sensitive strings. Scrutinize company repositories, notebooks, and public datasets for strings starting with the “AKIA” prefix. This proactive searching can help identify leaks that have already occurred but have not yet been flagged by automated scanners.
Activate monitoring for highly privileged accounts. Set up AWS Config rules to trigger alerts whenever the root account is utilized. Since root access should be rare, any usage of these credentials should be treated as a high-priority security event.
Transition to temporary authentication methods. Replace permanent IAM user keys with short-lived, role-based access tokens through IAM Identity Center. This significantly reduces the impact of a leak, as the credentials will automatically expire after a short period.
Implement automated scanning tools. Integrate open-source secrets scanners into your continuous integration (CI) pipelines to block secrets from reaching public repositories. This “push protection” is the most effective way to prevent the initial exposure of sensitive data.
13. Competitive Landscape: Vendors Addressing the Security Gap
The competitive market for secrets detection and management has seen rapid innovation as vendors scramble to address the vulnerabilities identified in recent reports. GitGuardian and Truffle Security remain the primary players, with both companies expanding their capabilities to cover more than just standard source code. GitGuardian has focused on providing a comprehensive platform for non-human identity management, while Truffle Security has built a reputation for its deep-scanning capabilities that uncover secrets in complex locations like CI logs and ML datasets. Both are vying to become the standard for enterprise-wide secrets visibility.
Platform providers like GitHub and AWS have also stepped up their game by offering native scanning and protection features. GitHub’s push protection, which blocks commits containing known secret patterns, has become a standard feature for many organizations. AWS provides services like GuardDuty and IAM Access Analyzer, which help detect when a credential is being used in an anomalous way. However, the persistence of thousands of valid leaks suggests that while these tools are effective, they are not yet universally adopted or configured correctly. The competition between specialized security vendors and platform-native tools is likely to continue driving better integration and more automated remediation workflows.
14. Future Outlook: The Direction of Cloud Credential Security
The future of cloud credential security is moving toward a world where static, long-lived keys are the exception rather than the rule. We can expect cloud providers to become much more aggressive in their enforcement of session-based identities, potentially phasing out the ability to create long-term IAM user keys for new accounts. This transition will be supported by a new generation of security tools that prioritize the identity of the machine or process over a simple string of characters. As identity becomes more ephemeral, the value of a leaked credential will drop significantly, making the current scraping-based attack models less profitable.
Furthermore, the expansion of secrets scanning into the AI and machine learning ecosystem will become a standard practice for any organization involved in data science. We will likely see the development of specialized scanners that can parse large-scale datasets and agent configuration files with the same precision currently applied to Python or JavaScript files. As the industry matures, the goal will shift from simply finding leaked secrets to preventing them from ever being generated in the first place. The integration of security directly into the AI-assisted development workflow will be a critical step in ensuring that the speed of innovation does not come at the cost of fundamental cloud security.
15. Current Recommendations for Engineering Departments
Engineering teams recognized the inherent dangers posed by secrets sprawl and took proactive steps to modernize their credential management. The findings from recent audits demonstrated that a “set and forget” approach to AWS keys was no longer viable in an environment where automated scrapers operated with such high efficiency. Organizations that prioritized the transition to IAM Identity Center and short-lived session tokens found themselves significantly less vulnerable to the fallout of accidental repository commits. By treating every API key as a temporary asset rather than a permanent fixture, these teams limited the potential blast radius of a credential leak to a matter of hours rather than years.
Furthermore, the integration of automated pre-commit scanning became a non-negotiable standard for high-performing engineering departments. They implemented rigorous checks that prevented developers from pushing sensitive configuration files to public repositories, effectively stopping the problem at the source. Management teams also emphasized the importance of financial monitoring, ensuring that every cloud account was equipped with budget alerts to provide an early warning of unauthorized resource usage. These actions, combined with regular auditing of IAM reports, transformed security from a reactive burden into a proactive component of the development lifecycle. This shift in mindset ensured that while the volume of code continued to grow, the security posture of the organization remained resilient against the evolving threat landscape.
