Listen to this Post
Introduction: A Forgotten Cloud Credential Can Become a Security Disaster
A leaked cloud credential does not become harmless simply because it is old.
That is the uncomfortable lesson from new research by Truffle Security, which found that thousands of publicly exposed Amazon Web Services (AWS) access keys were still capable of authenticating years after appearing in public repositories, datasets, container images, package registries and CI logs. The researchers re-verified 10,616 exposed AWS key pairs with complete credentials and found that 88% still authenticated. More alarmingly, hundreds of corporate credentials had enough privileges to provide full administrative control over AWS environments.
The research turns an old cybersecurity warning into something much more concrete: a secret that has been published online should be treated as compromised until it has been revoked or rotated.
This is particularly important in 2026, when cloud infrastructure has become the backbone of websites, SaaS platforms, AI services, databases, development environments and increasingly autonomous AI workloads. A single forgotten AWS key can therefore represent far more than access to one server. Depending on its permissions, it can become a doorway into an entire cloud environment.
The Numbers Behind the AWS Credential Exposure
Truffle Security said its scanners identified 64,024 unique AWS keys across hundreds of thousands of public findings. The credentials were discovered in sources ranging from Git history and public datasets to Docker images, package registries and continuous-integration logs.
The researchers then focused on 10,616 key pairs containing complete credentials that could be re-verified. The result was startling: approximately 88% were still active and able to authenticate when tested.
That translates to more than 9,300 credentials that had been publicly exposed but apparently remained usable.
The research was not simply about whether a key existed. Truffle Security also investigated what the credentials could potentially access, including account identity, IAM policies and administrative privileges. That distinction matters because a working credential with tightly restricted permissions is very different from a working credential connected to an administrator or root account.
Hundreds of Corporate Keys Had Full Administrative Power
The most alarming part of the findings concerns corporate environments.
Among the exposed credentials linked to companies, researchers identified 768 keys with full administrative capabilities. The underlying breakdown included root credentials and IAM users carrying AdministratorAccess.
A compromised administrative AWS credential can potentially give an attacker extraordinary control.
Depending on the account configuration, an attacker could access sensitive storage, manipulate infrastructure, create or modify resources, alter security configurations, establish persistence, disrupt applications and potentially generate large unexpected cloud bills.
The risk becomes even more serious when a compromised identity belongs to an AWS organization management account. In that situation, the blast radius can extend beyond a single application or account and potentially affect multiple connected environments.
Root Access Keys Are Especially Dangerous
Root credentials deserve special attention because they sit at the highest level of an AWS account.
Truffle
This is why the recommendation to remove root access keys is so important.
For modern AWS environments, root credentials should not be treated as ordinary API credentials. Keeping a root access key around for convenience creates a powerful single point of failure that can be accidentally exposed through source code, build systems, scripts or developer machines.
Hugging Face Emerged as a Major Source of Exposed Keys
One of the most surprising findings involved Hugging Face.
According to Truffle Security, its research found 8,482 unique live AWS keys across thousands of public Hugging Face datasets.
That discovery highlights a growing problem in the AI ecosystem.
Developers and researchers routinely publish datasets, model artifacts, notebooks, configuration files and supporting code. Those projects can contain environment variables, credentials or configuration fragments that were never intended to become public.
Truffle Security separately reported that a scan of 7.6 petabytes of public AI training data on Hugging Face found 3,343 live AWS keys, with more than 900 capable of listing S3 buckets containing tens of terabytes of private data.
The lesson is straightforward: AI repositories need the same secret-management discipline as traditional software repositories.
The Five-Year-Old Credential Problem
Perhaps the most disturbing element of the research is how old some of the credentials were.
For the keys where creation dates could be determined, the median age was approximately five years. The oldest credential was more than 17 years old.
Think about what can happen to an organization in five years.
Developers change jobs. Applications are rewritten. Infrastructure moves between teams. Cloud accounts accumulate unused resources. Contractors leave. Projects are abandoned. Repositories become archived.
But the credential can remain alive.
That creates a dangerous disconnect between organizational memory and technical reality. A person may have forgotten why a key exists while AWS continues to recognize it as a valid identity.
Rotation Appears to Be the Weakest Link
The researchers found another worrying pattern when examining credentials for which they could enumerate other access keys belonging to the same IAM user.
Only 398 of 2,903 keys — about 13.7% — had a newer key associated with the same user. In other words, approximately 86% did not appear to have been superseded by a newer credential.
That suggests the problem is not merely accidental exposure.
It is also a lifecycle-management problem.
Organizations may detect secrets in repositories, remove them from the source code and assume the incident is finished. But deleting a secret from Git does not invalidate the credential itself.
Once an AWS key has been publicly exposed, the correct response is to revoke or rotate it and investigate its usage.
Deleting the Secret From Git Is Not Enough
This distinction is crucial.
Suppose a developer accidentally commits an AWS key into a Git repository. The developer later removes the line and pushes a new commit.
The secret may no longer appear in the current version of the file.
But the credential can still exist in Git history.
It may also exist in forks, mirrors, cached repositories, CI logs, Docker layers, developer machines, build artifacts or third-party datasets.
Most importantly, AWS does not know that the developer deleted the line.
The credential remains valid until the underlying access key is disabled or deleted.
The Cloud Bill Can Become the First Warning Sign
Attackers do not necessarily need to steal corporate data to make money from leaked AWS credentials.
Cryptocurrency mining is a familiar example.
An attacker who obtains sufficient cloud privileges can deploy resource-intensive workloads and push the victim’s AWS bill dramatically higher.
That is why budget monitoring is an important secondary defense.
Truffle Security reported that only a small minority of the examined accounts had usable budget alerts configured. In one reported subset, just 262 of 2,754 accounts had a budget alert.
A budget alert will not stop an attacker, but it can shorten the time between compromise and discovery.
And in cloud security, time matters.
The AI Era Makes Credential Hygiene Even More Important
The AWS findings arrive at an especially important moment for the technology industry.
Modern development environments increasingly involve AI coding assistants, autonomous agents, CI/CD systems, cloud deployment tools and automated infrastructure management.
These systems frequently need credentials.
That creates a rapidly expanding ecosystem of non-human identities.
A developer might understand that a password must be protected. The same discipline is not always applied to an API key embedded inside an automated workflow.
This is becoming a serious security challenge because AI agents can operate quickly, interact with multiple services and potentially execute infrastructure changes without a human manually entering every command.
A leaked credential used by an AI-powered development workflow could therefore have a much larger operational impact than the same credential would have had years ago.
AWS Quarantine Policies Are Not a Substitute for Remediation
Another interesting finding concerns
Truffle Security said some exposed credentials had already been associated with AWS’s AWSCompromisedKeyQuarantine policy, yet those credentials still authenticated.
This is an important nuance.
A security control recognizing suspicious credentials does not automatically mean the organization has completed incident response.
Detection is not remediation.
An alert is not remediation.
A quarantine policy is not remediation.
The credential owner still needs to investigate the identity, determine what happened, revoke or rotate the exposed credential and check for unauthorized activity.
Deep Analysis: How an Exposed AWS Key Becomes an Attack Path
Step 1: Find the Credential
An attacker may discover credentials inside public Git repositories, old commits, container images, public datasets, CI logs or configuration files.
A defensive team can search its own repositories with secret-scanning tools rather than waiting for an attacker to discover the credential.
Step 2: Verify the Credential Safely
Do not casually test credentials that you discover in public material.
For credentials belonging to your own organization, use approved security procedures and AWS logging to determine whether they remain valid.
A basic identity check for an authorized credential can be performed with:
aws sts get-caller-identity
This command can reveal the AWS account and identity associated with the credentials configured in the current AWS CLI environment.
Step 3: Identify Old IAM Keys
Security teams can inventory IAM access keys with:
aws iam list-users
Then inspect access keys for authorized users:
aws iam list-access-keys –user-name USERNAME
The objective is to identify credentials that are unnecessarily old, unused or associated with applications that should have migrated to stronger authentication mechanisms.
Step 4: Disable an Exposed Access Key
If an exposed access key is confirmed to belong to your organization, disabling it can provide an immediate containment step:
aws iam update-access-key
–user-name USERNAME
–access-key-id AKIAxxxxxxxxxxxxxxxx
–status Inactive
The exact response process should follow your
Step 5: Delete the Credential After Replacement
Once dependent systems have been migrated to a replacement credential or a more appropriate identity mechanism, the old key should be removed:
aws iam delete-access-key
–user-name USERNAME
–access-key-id AKIAxxxxxxxxxxxxxxxx
Do not simply delete credentials blindly from production systems. First identify legitimate dependencies and replace them safely.
Step 6: Investigate CloudTrail
Credential exposure should also trigger an investigation of AWS activity.
For example, defenders can search CloudTrail events through the AWS console or use authorized CloudTrail tooling to determine whether the identity performed unexpected actions.
Look for unusual regions, unfamiliar IP addresses, unexpected resource creation, IAM modifications, access to sensitive storage and sudden increases in compute consumption.
Step 7: Search Public Artifacts
Do not restrict secret scanning to the current Git branch.
A mature investigation should consider:
Git history
Docker layers
CI/CD logs
Package registries
Public datasets
Model repositories
Configuration files
Infrastructure-as-code
Developer scripts
Build artifacts
The goal is not merely to find the file containing the secret.
The goal is to understand every place where the secret escaped.
A Better AWS Credential Strategy for 2026
Eliminate Long-Lived Credentials Where Possible
Long-lived IAM access keys should no longer be the default solution for cloud automation.
Where possible, organizations should favor short-lived credentials and workload identity mechanisms that reduce the value of a stolen credential.
The shorter the lifetime of an identity, the smaller the window in which an attacker can abuse it.
Delete Root Access Keys
Root access keys should be treated as a major security liability.
If a root access key exists and is not absolutely required, remove it after confirming that no legitimate dependency remains.
A root credential should never be casually embedded in an application, script or CI pipeline.
Enforce Credential Age Policies
Organizations should establish maximum credential ages and continuously monitor exceptions.
For example, teams can build inventory checks around:
aws iam list-access-keys –user-name USERNAME
The important part is not simply running the command once.
The important part is turning credential age into an enforceable security control.
Monitor Cloud Spending
Budget alerts should be part of cloud security, not merely financial management.
Unexpected compute consumption can be an early indicator of compromise.
A sudden increase in GPU, EC2 or other high-cost resources deserves investigation, particularly when it occurs outside normal deployment patterns.
Treat Public Exposure as Permanent Compromise
This should become an organizational rule:
If a credential reaches a public location, assume it has been copied.
Even if nobody has visibly abused it, there is no reliable way to prove that nobody ever saw it.
Rotating the credential is therefore safer than trying to establish whether an attacker actually used it.
The Bigger Problem Is Not AWS — It Is Secret Lifecycle Management
Security Teams Often Focus on Discovery
Modern organizations have become increasingly good at finding secrets.
Secret scanners can identify credentials in source code, repositories and cloud environments with impressive speed.
But finding a secret is only the beginning.
The real security question is:
What happens after the alert?
Developers Often Remove Files Instead of Revoking Keys
A common response to a leaked credential is to delete the offending file and move on.
That is understandable but incomplete.
The credential itself must be invalidated.
Otherwise, the attacker does not care whether the source code has been cleaned up.
Forgotten Projects Become Security Time Bombs
The five-year median age of many leaked credentials demonstrates another problem: abandoned infrastructure.
Old side projects, prototypes, testing accounts and forgotten cloud environments can quietly become permanent security liabilities.
The organization may have moved on.
The credential did not.
Cloud Security Must Include Non-Human Identities
Service accounts, IAM users, CI credentials, deployment keys and AI agents are increasingly responsible for performing sensitive operations.
These identities need lifecycle management just like employees.
Every credential should have an owner, purpose, expiration strategy and monitoring.
AI Development Adds Another Layer of Complexity
The rapid adoption of AI coding tools makes this problem harder.
Developers increasingly allow automated systems to interact with repositories, package managers, cloud services and deployment environments.
If a credential leaks into one of those systems, it may travel farther and faster than traditional secrets did.
This is why cloud identity security is becoming inseparable from AI security.
What Undercode Say:
The Real Story Is Not the 9,300 Keys
The headline number is enormous, but the deeper story is credential persistence.
Five Years Is Too Long
A cloud credential should not quietly survive for years without a clear owner and purpose.
Public Secrets Should Be Considered Burned
Once a credential reaches a public repository or dataset, assume somebody copied it.
Rotation Is Still Failing
The roughly 13.7% newer-key figure demonstrates how frequently exposed credentials remain part of the environment.
Root Keys Are the Biggest Red Flag
A root credential exposed publicly is not a minor configuration mistake.
AdministratorAccess Is Almost as Concerning
An IAM user with broad administrative privileges can become a complete account compromise.
Cloud Attacks Can Become Financial Attacks
Attackers do not always steal data.
Sometimes they simply turn your cloud account into their computing infrastructure.
Budget Alerts Matter
A small financial warning can become an early security signal.
AI Is Expanding the Attack Surface
More automated workloads mean more credentials and more opportunities for secrets to escape.
Public Datasets Need Security Controls
Hugging Face demonstrates that secrets can leak outside traditional software repositories.
Containers Can Preserve Secrets
Deleting a secret from the current Dockerfile does not necessarily remove it from historical image layers.
Git History Is Dangerous
Deleting a secret in a new commit does not erase the credential from the repository’s history.
CI Logs Can Be Forgotten
Build pipelines often contain credentials that were never intended to become public.
Old Keys Are Particularly Dangerous
Attackers benefit from credentials that defenders have forgotten.
Detection Is Only Half the Battle
Finding a secret does not mean the incident is resolved.
Quarantine Is Not the Finish Line
AWS can detect a compromised credential, but the owner still has to remediate it.
Identity Inventory Is Essential
Organizations cannot secure credentials they do not know exist.
Every Key Needs an Owner
An orphaned credential is eventually likely to become a forgotten credential.
Every Key Needs a Purpose
If nobody can explain why a credential exists, that credential deserves scrutiny.
Every Key Needs a Lifecycle
Creation, use, rotation and retirement should be deliberate processes.
Short-Lived Credentials Are Safer
Reducing credential lifetime reduces the window available to attackers.
Least Privilege Remains Fundamental
A leaked credential with minimal permissions is dramatically less dangerous than an administrator credential.
Root Credentials Should Be Rare
There are few good reasons for root API keys to remain active.
Cloud Monitoring Is Security Monitoring
Unexpected AWS activity can reveal compromise even when traditional endpoint defenses see nothing.
Spending Anomalies Can Be Indicators
A sudden cloud bill can be the first visible sign of an attack.
Public Exposure Should Trigger Automation
The ideal workflow should automatically identify, disable, rotate and investigate exposed credentials.
Human Memory Is Not a Security Control
Organizations should not depend on developers remembering five-year-old keys.
AI Agents Need Identity Boundaries
An AI system should receive only the permissions required for the task it is performing.
Development Convenience Can Create Security Debt
The easiest credential-management solution today can become
Cloud Credentials Are High-Value Targets
An AWS key can provide access to compute, storage, databases and other infrastructure depending on its permissions.
Secret Scanning Needs Context
Knowing that a key exists is useful.
Knowing who owns it and what it can access is much more valuable.
Security Teams Need Faster Remediation
The longer an exposed key remains active, the greater the uncertainty surrounding its possible use.
The Best Credential Is Often No Credential
Where AWS-native identity mechanisms can replace static secrets, organizations should strongly consider that route.
Personal Cloud Accounts Matter Too
Security programs should not focus exclusively on corporate infrastructure.
Forgotten Side Projects Can Become Entry Points
An abandoned application may still have live credentials connected to valuable services.
The Attack Surface Keeps Growing
More repositories, datasets, containers, agents and automation systems mean more places where credentials can escape.
The Final Lesson Is Simple
A leaked AWS key is not an old secret. It is an active security incident until the credential is revoked or safely rotated.
✅ The 88% Active-Key Finding Is Supported
Truffle Security says it re-verified 10,616 complete AWS credential pairs and found that 88% still authenticated. The company’s own research and August 2026 announcement support the central statistic.
✅ More Than 9,300 Keys Were Still Usable
Applying the reported 88% figure to 10,616 complete credential pairs produces roughly 9,300 still-authenticating keys. Multiple reports covering the research independently describe the result in those terms.
✅ Hundreds Had Full Administrative Access
The research identified 768 live corporate-related credentials with full administrative capabilities, including root keys and IAM users with AdministratorAccess.
✅ Hugging Face Was a Major Exposure Source
Truffle Security specifically identified Hugging Face as a major source of leaked AWS credentials, including thousands of live keys discovered in public datasets.
✅ The Five-Year Median Age Is Supported
The research reports a median age of roughly five years for live credentials where creation dates could be determined, with the oldest credential more than 17 years old.
⚠️ The 88% Figure Does Not Mean 88% Had Administrator Access
This distinction is important. The 88% statistic refers to credentials that could still authenticate, while privilege measurements were taken from relevant subsets where IAM details could be enumerated. It would be misleading to interpret the 88% figure as meaning that 88% provided full administrative access.
⚠️ Public Exposure Does Not Automatically Prove Exploitation
A valid leaked credential demonstrates exposure and potential access, but it does not by itself prove that an attacker actually used the credential. Determining exploitation requires investigation of logs and other evidence.
Prediction
(+1) Cloud Credential Security Will Become More Automated
The most likely positive development is a shift away from manually managed long-lived cloud keys toward short-lived identities, automated secret detection and continuous credential-risk analysis.
As AI agents and automated development systems become more deeply integrated into cloud environments, organizations will have stronger incentives to understand not only where a credential is, but also what that credential can reach.
Tools that connect secret discovery with IAM context, ownership and remediation are likely to become increasingly important.
(+1) Root Access Keys Will Continue to Disappear
The security industry has spent years warning about root credentials, and incidents like this reinforce the argument for eliminating unnecessary root API keys altogether.
Organizations that remove legacy credentials now will be far less likely to discover them during a future breach investigation.
(+1) Secret Scanning Will Move Beyond Git
Traditional repository scanning is no longer enough.
Future security programs will increasingly scan containers, datasets, AI model repositories, package registries, CI systems and other public artifacts as part of one continuous process.
(-1) Forgotten Credentials Will Continue Creating Breaches
The negative prediction is equally clear: as long as organizations continue allowing long-lived credentials to survive without owners, attackers will keep finding them.
The technology for detecting exposed secrets is improving faster than the human habit of actually revoking them.
(-1) AI Could Magnify the Impact
If leaked credentials are discovered and exploited by increasingly autonomous AI-driven attack workflows, the speed between credential discovery and cloud compromise could become dramatically shorter.
That makes the lesson from this research even more urgent: cloud credentials should be treated as high-value security assets, not configuration strings that can be forgotten after deployment.
Final Takeaway: The Key That Nobody Remembers Can Still Open the Door
The most frightening aspect of the Truffle Security research is not that AWS credentials sometimes leak.
Everyone in cybersecurity already knows that happens.
The real problem is what happens afterward.
A secret appears in public. Someone eventually notices it. The source file may be cleaned. The repository may be updated. The developer may move on.
And the credential can remain alive.
For five years.
For ten years.
In one case, for more than 17 years.
That is the security gap organizations must close.
The modern cloud environment cannot depend on people remembering every credential they created years ago. AWS keys need ownership, lifecycle controls, least-privilege permissions, monitoring, rotation and rapid revocation.
The strongest defense is not simply discovering leaked secrets faster.
It is making sure that a leaked secret has as little power and as short a lifespan as possible.
Because once an AWS key is public, the safest assumption is simple:
Someone else may already have it.
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: www.infosecurity-magazine.com
Extra Source Hub (Possible Sources for article):
https://www.twitter.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
