Topic starter
11/10/2026 6:56 pm
TL;DR: Truffle Security says leaked credentials can remain fully functional after they leave secrets managers, repositories, chat, logs, or agent configuration files, creating a second unmanaged security state that expands NHI risk. The governance problem is not just discovery, but trusted access that survives outside the controls meant to contain it.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “One non-human identity, two states”.
Key questions
Q: What breaks when a non-human identity secret escapes its intended control plane?
A: The control model breaks because the leaked copy can keep authenticating after it leaves the governed location.
Q: Why do leaked NHI credentials create more risk than ordinary exposed strings?
A: Leaked NHI credentials can function as authenticated access, not just information.
Q: Why do AI agents make non-human identity governance harder?
A: AI agents make governance harder because they can request tools, act autonomously, and change behaviour across sessions while still relying on machine credentials.
Practitioner guidance
- Map secret copy locations across collaboration and build systems Inventory where credentials appear outside the secrets manager, including Slack, source control, CI artifacts, endpoints, and agent configuration files.
- Validate exposed credentials against live authentication Check whether leaked keys, tokens, and certificates still work in connected systems before you classify them as historical exposure.
- Shorten the useful life of machine credentials Prefer short-lived credentials and managed identities where possible, but pair them with controls that search for duplicate copies in code, chat, logs, and agent workflows.
Bottom line: The article frames leaked credentials as a second unmanaged identity state, which is more dangerous than simple disclosure because the copy can still authenticate.
What's in the full article
Truffle Security's full analysis covers the operational detail this post intentionally leaves for the source:
- How the researchers traced leaked credentials across chat, repositories, CI artifacts, and agent configuration files
- The PyPI and AWS recovery methods used to determine whether exposed secrets were still live
- The webinar discussion of how AI changes exposure patterns for machine credentials
- The practical guidance on closing unmanaged credential paths before attackers find them
👉 Read Truffle Security's analysis of leaked credentials and AI agent exposure →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/10/2026 6:57 pm
Leaked credential copies create an identity governance blind spot, not just a disclosure problem. NHI programmes often treat the secret manager as the control boundary, but the article shows that the real boundary is the set of places where the credential continues to authenticate. Once a secret escapes into chat, code, logs, or an agent config, ownership and rotation alone no longer describe the full risk. Practitioners need to think in terms of governed copy state, not just provisioned identity state.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should security teams reduce the risk of credential exposure across repositories and chat?
A: They should combine exposure discovery with stricter credential design. Search code, logs, chat, and build outputs for live secrets, then reduce the usefulness of any exposed copy by shortening lifetime, limiting scope, and revoking credentials that no longer need to exist in multiple places.
👉 Read our full editorial: Leaked credentials create a second, unmanaged NHI security state