More than 9,300 publicly exposed Amazon Web Services access keys were still capable of authenticating when researchers checked them earlier this month, according to research from Truffle Security, raising fresh questions about how organisations manage long-lived cloud credentials.
The researchers re-verified 10,616 AWS key pairs on 10 August 2026 and found that 9,308, or 88 per cent, still authenticated. The credentials had been exposed through sources including public code, datasets, Docker images, registries and CI logs. A recent report describing the research said the keys had originally been exposed between August 2022 and August 2026.
The figures become more concerning when the permissions attached to some of those credentials are examined. The research identified 768 corporate keys with full account control, including 526 root keys and 242 IAM keys carrying AdministratorAccess. It also found that 130 root keys were associated with AWS Organisations management accounts, according to reporting on the findings.
The issue is not evidence of a breach of AWS itself. Rather, it illustrates the risks created when customers expose credentials and fail to revoke or replace them. AWS has long warned that access keys can provide whatever level of access is granted to the associated identity, while root credentials have full access to an account. Its own guidance recommends disabling exposed credentials and moving applications away from long-lived access keys where possible.
The research also points to how difficult credential exposure can be to contain once a secret enters the public record. Removing a key from a repository does not necessarily remove it from Git history, published images or other copies. A credential can remain usable until its owner takes action, even after the original source has been changed.
AWS does have mechanisms intended to limit the damage. When certain publicly exposed IAM credentials are detected, AWS can apply its AWSCompromisedKeyQuarantine policy. The policy blocks a range of actions associated with activities such as creating users, changing permissions or launching certain resources. AWS describes the policy as a measure designed to limit potential fraud while avoiding disruption to existing resources.
That distinction matters. A quarantine policy is an access-control measure, rather than a universal replacement for credential revocation. AWS’s own incident-response guidance advises customers dealing with exposed long-term credentials to invalidate them and investigate account activity.
The research therefore points to a familiar security problem with a very large potential blast radius: static credentials can survive long after the people, projects or systems that created them have changed.
AWS itself has been moving customers towards alternatives to long-lived access keys. Its security guidance recommends IAM roles and federated access, where temporary credentials can reduce the need to maintain permanent secrets. AWS also recommends regular credential rotation and auditing for old or unused keys.
This is where the architecture of the Internet Computer Protocol, or ICP, presents a different approach to some forms of cryptographic trust.
On ICP, applications run as canisters on subnets, with canister state and computation replicated across the nodes of the subnet. No individual node can unilaterally alter the replicated state.
The network also uses chain-key cryptography, a collection of threshold cryptographic protocols in which private key material is divided into shares held across subnet nodes. The complete private key is not stored on a single machine, and signing requires cooperation between nodes.
That model has particular relevance when canisters need to sign transactions for external networks. ICP’s chain-key signatures allow canisters to use threshold ECDSA and Schnorr signatures without placing a complete private key on an individual node. For chain-key tokens, for example, withdrawal transactions can be signed collectively by subnet nodes, meaning a single compromised node cannot authorise a withdrawal on its own.
The distinction should not be overstated. ICP does not eliminate every credential or security risk. Developers still need to secure controller identities, application permissions and other access paths. A distributed key architecture addresses a particular class of risk: dependence on a single, persistent private secret that can be copied and reused outside the system.
That makes the AWS research relevant beyond one cloud provider. The problem is not simply where applications are hosted. It is also how identity, permissions and cryptographic authority are designed.
A five-year-old credential sitting in a forgotten repository can remain a liability because the secret itself does not know that its owner has moved on. Rotating it, disabling it or replacing it requires an organisation to discover the exposure and act.
Architectures based on threshold cryptography take a different route by making certain private keys unavailable as complete secrets to any single machine in the first place. ICP’s approach does not make security automatic, yet it changes where trust is placed and how cryptographic authority is distributed.
For organisations assessing cloud infrastructure, the question raised by the leaked AWS credentials is therefore broader than whether a particular provider can detect exposed secrets. It is whether critical systems should continue to rely on long-lived credentials at all, and where possible, whether sensitive authority can be designed so that there is no single secret waiting to be copied.
The 9,308 active credentials are a reminder that cloud security does not end when a secret is discovered. It depends on what happens next, how quickly access is removed, and whether the underlying architecture makes a stolen credential useful in the first place.
Credit: @ICPLEGEND1966 on X
Dear Reader,
Ledger Life is an independent platform dedicated to covering the Internet Computer (ICP) ecosystem and beyond. We focus on real stories, builder updates, project launches, and the quiet innovations that often get missed.
We’re not backed by sponsors. We rely on readers like you.
If you find value in what we publish—whether it’s deep dives into dApps, explainers on decentralised tech, or just keeping track of what’s moving in Web3—please consider making a donation. It helps us cover costs, stay consistent, and remain truly independent.
Your support goes a long way.
🧠 ICP Principal: ins6i-d53ug-zxmgh-qvum3-r3pvl-ufcvu-bdyon-ovzdy-d26k3-lgq2v-3qe
🧾 ICP Address: f8deb966878f8b83204b251d5d799e0345ea72b8e62e8cf9da8d8830e1b3b05f
Every contribution helps keep the lights on, the stories flowing, and the crypto clutter out.
Thank you for reading, sharing, and being part of this experiment in decentralised media.
—Team Ledger Life
Community Discussion