TL;DR: Truffle Security reports that AWS access key IDs can be base-32 decoded and bit-shifted to recover the corresponding account number, even for live or revoked keys. The practical issue is not that the account number is secret, but that key structure can widen discovery and enumeration risk across NHI workflows.
At a glance
What this is: Truffle Security found that AWS access key IDs encode account numbers in a reversible way, which changes how teams should think about key exposure and account enumeration.
Why it matters: IAM and cloud security teams need to treat access key handling, discovery, and revocation as part of a wider NHI governance model, not just a credential hygiene task.
👉 Read Truffle Security's analysis of AWS account numbers hidden in access keys
Context
AWS access key IDs are not just opaque identifiers. In this case, the article shows that the structure of the key itself can reveal the associated account number, which matters because discovery and enumeration become part of the identity problem, not just the authentication problem.
That creates a governance gap for cloud teams that assume an access key is only a bearer credential. If the identifier carries useful metadata, then visibility, inventory, and response processes have to account for API key management as an identity exposure surface.
Key questions
Q: What should security teams do first when an AWS access key is found exposed online?
A: The first move is immediate containment, not analysis delay. Revoke or disable the exposed key as quickly as possible, then assess what the key could reach, look for signs of abuse, and rotate any dependent secrets or credentials. Teams should treat the event as an active compromise window, because attackers may act before standard quarantine or manual review completes.
Q: Why do exposed AWS access key IDs create additional risk beyond the secret value itself?
A: An exposed AWS access key ID can reveal the associated account number, which helps attackers identify the target account faster and validate their next steps. That does not grant access by itself, but it reduces ambiguity and supports more efficient abuse. Security teams should treat key disclosure as both a credential issue and an account identification problem.
Q: How should security teams inventory cloud credentials across accounts?
A: Use a single inventory that tracks key state, ownership, account mapping, last use, and exposure history. Without that view, teams cannot tell whether a leaked identifier belongs to an active workload, a retired integration, or a credential that still needs formal offboarding.
Q: What is the difference between quarantining and revoking an AWS key?
A: Quarantine is a temporary containment state that limits use or flags the credential for review, while revocation removes the credential’s ability to authenticate. For cloud credentials, only revocation ends the authentication path. Quarantine can buy time, but it is not a substitute for lifecycle closure.
Technical breakdown
How AWS access key structure leaks account context
AWS access key IDs are formatted identifiers, not random strings. In the research described here, the prefix and early characters can be transformed through base-32 decoding and bit shifting to recover the account number tied to the credential. That means the identifier contains more information than many teams assume, and the account context can be derived without database lookup. The operational concern is not that AWS has made the account number confidential, but that a credential identifier can become a pivot point for enumeration, investigation, and targeting when exposed in logs, repositories, or support artefacts. See the API Key Management Guide.
Practical implication: Treat exposed access key IDs as account-revealing artefacts, not harmless labels.
Why quarantine is not the same as revocation for access keys
The article’s title captures an important operational distinction: quarantining a key means flagging or limiting its use, while revocation removes its ability to authenticate. Those are not equivalent states in identity governance. A quarantined key may still exist in logs, pipelines, or alerting systems, and a revoked key can still leak metadata such as the account number if its identifier remains visible. For NHI programmes, the lifecycle question is broader than validity. It also includes what an identifier discloses after use, after compromise, and after deactivation. See the Cloud Credential Compromise Playbook.
Practical implication: Use explicit revocation and post-exposure handling, not just quarantine labels.
What reversible identifiers mean for secret discovery workflows
Secret discovery tools often focus on finding live credentials, but this research shows that even non-secret identifier structure can matter. If an organisation allows AWS access keys to spread through code, tickets, chat, or logs, then the key ID itself can support account mapping and attacker reconnaissance. That is a governance issue because the credential estate includes both the secret value and the identifier surface around it. Strong secrets programmes therefore need to treat leaked key material as a full context problem, not only a token validity problem. Read Guide to the Secret Sprawl Challenge.
Practical implication: Expand scanning and response to include identifier exposure, not just secret value exposure.
Threat narrative
Attacker objective: The attacker or researcher wants to map exposed AWS access keys back to specific accounts and use that context for enumeration, targeting, or faster abuse.
- Entry occurs when an AWS access key ID is exposed in a place the defender did not intend, such as source control, logs, or public artefacts.
- Credential access follows when the identifier is decoded to recover the linked account number and used to enrich targeting or triage.
- Impact is broader reconnaissance and faster credential-focused response, because the exposed identifier reveals operational context even when the credential is no longer live.
Breaches seen in the wild
- 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
- Sumo Logic breach 2023: A compromised credential opened a Sumo Logic AWS account; customers were told to rotate API keys and stored credentials. No data impact was found.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Account-number leakage turns an access key into a discovery artefact: The security issue is not limited to authentication. When the identifier itself can be reversed into account context, a leaked key becomes useful even before it is used for login. That shifts the control problem from pure secret protection to identity metadata exposure, and practitioners should treat exposed access key IDs as part of the NHI attack surface.
Quarantine is a governance state, not a security outcome: Quarantining a cloud credential can reduce immediate misuse, but it does not eliminate the information carried by the identifier. The article’s framing shows why lifecycle states need precision: valid, revoked, quarantined, and exposed are different conditions with different risk profiles. The implication is that teams need to manage credential states as an identity lifecycle, not as a binary live or dead decision.
Secret sprawl now includes identifier sprawl: Hardcoded or logged credentials are already a problem, but this research shows that the surrounding identifier can also disclose meaningful account information. That is a broader version of the secret sprawl challenge because the exposure surface includes both secrets and the metadata attached to them. Practitioners should assume that leaked credential artefacts can support account enumeration even when the secret value itself is not usable.
Static credential design keeps creating downstream intelligence for attackers: The deeper lesson is that long-lived cloud credentials accumulate value for observers over time, not just for holders at authentication time. A key that can be decoded, mapped, or correlated gives away more than a token should. The NHI governance implication is that credential formats, revocation, and inventory need to be designed together, because disclosure risk does not stop at the secret boundary.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Cloud Workload Identity Guide
What this signals
Identity metadata is now part of secret exposure. When credential formats leak account context, the governance boundary widens from secrets management to account-intelligence management. That means teams need to search for identifiers as aggressively as they search for live secrets, because a revoked key can still disclose enough information to shape an attack path.
Short-lived credentials reduce the value of leaked key structure. The long-term answer is not only better detection, but reducing how much a credential can reveal after exposure. Workload identity and federated access shrink the time window in which an identifier can be collected, correlated, and exploited.
For practitioners
- Audit where access key IDs are exposed Search source control, CI logs, tickets, chat archives, and support exports for AWS access key IDs and treat them as sensitive identity artefacts, not harmless identifiers.
- Separate quarantine from revocation Define a response path that revokes exposed keys immediately and does not rely on quarantine alone when a credential or its identifier appears outside approved systems.
- Tighten access key inventory controls Maintain an authoritative inventory of active, revoked, and observed keys so that security teams can correlate exposure events with the correct AWS account quickly.
- Reduce long-lived key dependence Move workloads toward short-lived federation and workload identity so that exposed key material loses operational value sooner.
Key takeaways
- AWS access key IDs can disclose account context, so credential exposure is also an identity metadata problem.
- The article adds a useful nuance for defenders: revocation ends authentication, but it does not erase what a leaked identifier may reveal.
- Practitioners should combine exposure detection, authoritative inventory, and shorter-lived workload identity to reduce the value of leaked access keys.
Related NHI Mgmt Group resources: Cloud Workload Identity Guide · Cloud Credential Compromise Playbook · Guide to the Secret Sprawl Challenge · API Key Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on exposed access key IDs and the disclosure value of leaked credential material. |
| NHI-07 — Long-Lived Secrets | The problem becomes worse when access keys remain valid long enough to be copied and reused. | |
| Recommendation — Scan for exposed access key IDs and revoke any credential whose identifier has escaped approved systems. Reduce dependence on long-lived AWS keys and move workloads toward short-lived federation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle controls govern issuance, storage, rotation, and revocation of access keys. |
| Recommendation — Apply IA-5 to manage key lifecycle, rotation, and revocation for every AWS account. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and credential inventory are central to tracking which keys map to which cloud accounts. |
| Recommendation — Use CIS-5 to maintain authoritative cloud credential ownership and remove stale access paths. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Exposed access keys support credential-related targeting and account discovery. |
| Recommendation — Map exposed key material to TA0006 and prioritise containment for any leaked credential artefact. | ||
Key terms
- Access Key Identifier: A cloud credential label that can be used to reference or map a secret access key to an account or identity. In AWS, the identifier itself may contain structured information, so leaking it can create disclosure risk even when the secret value is not present.
- Account Enumeration Oracle: A response channel that reveals whether a username exists or whether a password is valid. In identity systems, error handling can become an oracle when different responses expose account state, especially if the platform logs or returns enough detail for unauthenticated probing.
- Authenticator Lifecycle Management: Authenticator lifecycle management is the governance of a credential from issuance to renewal, replacement, and retirement. For human identity programmes, it ensures that keys, smart cards, and certificates stay tied to the right user and are removed when the user, role, or device is no longer trusted.
- 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 article
Truffle Security's full post covers the operational detail this post intentionally leaves for the source:
- The reverse-engineering method used to decode AWS account numbers from access key IDs
- The TruffleHog update that returns account IDs for both live and revoked keys
- The research interview details on bit manipulation and verification against AWS endpoints
- The implementation context behind the small update to TruffleHog and what it changes for users
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org