Secrets exposure is widening the NHI attack surface across teams

At a glance

What this is: This analysis argues that secrets exposure is one of the main ways non-human identities become exploitable across code, logs, and collaboration tools.

Why it matters: It matters because NHI governance fails when credentials spread faster than teams can rotate, revoke, and restrict them.

By the numbers:

• Non-human identities and secrets are outnumbering human identities by 92X in modern IT environments.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today.
• 28% of secrets incidents now originate outside code repositories.

👉 Read Entro Labs's full analysis of secrets exposure and NHI attack paths

Context

Non-human identity governance breaks down when credentials are embedded in places that were never designed to hold them. In this topic, secrets exposure means API keys, tokens, certificates, and machine credentials escaping controlled storage and turning into usable access paths.

For IAM and NHI teams, the risk is not just leakage. It is the combination of broad entitlement, weak rotation, and discoverability across code, logs, and collaboration systems that lets an exposed secret become an active foothold. The blog's starting position is typical for current enterprise environments, not exceptional.

Key questions

Q: How should organisations reduce the risk of leaked secrets in NHI environments?

A: Start by treating every credential as a governed identity with an owner, expiry, and scope. Then scan code, logs, tickets, and collaboration tools continuously, because exposed secrets are often reused faster than teams can clean them up. The goal is not only detection, but rapid revocation and entitlement reduction.

Q: Why are secrets in logs and chat tools so dangerous?

A: Because those locations are broad, durable, and rarely monitored with the same discipline as production secret stores. A pasted key or token can survive in search indexes, exports, and backups, giving attackers a reusable credential that bypasses normal authentication controls.

Q: What is the difference between secret detection and secret governance?

A: Detection finds the leak. Governance limits the impact of the leak by reducing exposure time, tightening permissions, and enforcing revocation workflows. Without governance, a discovered secret can remain valid long enough to be exploited repeatedly.

Q: When does a leaked secret become a major business risk?

A: It becomes a major risk when the credential can reach production systems, cloud control planes, or sensitive data stores and remains valid long enough to be used. Scope, lifespan, and privilege matter more than the fact of exposure alone.

Technical breakdown

How secrets move from development workflows into exploitable access

Secrets often begin in source code, configuration files, build logs, or debugging output because developers optimize for speed and automation. Once a credential is copied into a repository or pipeline artifact, it is no longer governed by the lifecycle controls applied to vault-stored secrets. That creates a replayable access path that attackers can use without touching the original application. In NHI terms, the problem is not only exposure but also identity persistence, because a token, key, or certificate may remain valid long after the system that created it has changed. The failure mode is common: discovery happens after propagation, not before.

Practical implication: Security teams should treat every development control plane as part of the NHI attack surface and scan it continuously.

Why logs and collaboration tools become secret warehouses

Logs, tickets, chat threads, and shared documents routinely capture operational detail that seems harmless to engineers but is highly useful to attackers. Stack traces, API responses, pasted credentials, and temporary troubleshooting notes can all store active secrets outside formal control. These systems are especially risky because access is broad and visibility is rarely limited by secret sensitivity. The result is a secondary shadow inventory of identities, one that is often harder to inventory than the production vault. From a governance standpoint, this is a classification and retention problem as much as a detection problem.

Practical implication: Treat collaboration platforms as credential-bearing systems and include them in secret discovery, DLP, and retention controls.

What rotation and least privilege actually change in NHI risk

Rotation reduces the lifetime of exposed credentials, while least privilege reduces the blast radius if a secret is reused. Neither control is sufficient alone. A secret that rotates slowly but has narrow scope is still risky if it remains discoverable for months. A secret that rotates quickly but grants broad permissions can still enable major compromise during its valid window. The architectural goal is to make every secret both short-lived and tightly constrained, with automated revocation tied to exposure events. That is the practical bridge between NHI hygiene and modern identity governance.

Practical implication: Prioritise short-lived credentials with explicit expiry and scoped permissions, then automate revocation when exposure is detected.

Threat narrative

Attacker objective: The attacker aims to turn a leaked non-human identity into durable access that bypasses perimeter controls and supports lateral movement.

1. Entry occurs when attackers harvest a hardcoded key, leaked token, or credential pasted into logs or collaboration tools.
2. Escalation follows when the secret authenticates to cloud services, APIs, or internal systems with more privilege than intended.
3. Impact occurs when the attacker uses the trusted NHI to exfiltrate data, move laterally, or alter production systems.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secrets exposure is now an NHI governance problem, not just a secure coding problem. The article's real lesson is that credentials drift across code, logs, tickets, and chat until they become a separate identity estate. That estate is usually less visible than the production environment and far easier to misuse. Practitioners should govern secrets as live identities, not as static configuration artefacts.

Ephemeral credential trust debt is the right concept for this problem space. Every short-term credential that is copied, logged, forwarded, or cached creates residual trust after the original task ends. That debt accumulates when teams rely on manual cleanup or assume low-risk storage locations are harmless. The practical conclusion is that short-lived access must be matched with automated revocation and exposure detection.

Detection without revocation is partial control. The article correctly points to scanning and monitoring, but the real control objective is to collapse time-to-invalidity after exposure. If a secret remains usable for days or months, disclosure becomes exploitation eventually. Security teams should treat every finding as a race between discovery and rotation.

Secrets in collaboration tools are a shadow identity inventory. When tickets, chats, and documents hold credentials, the organisation has created an unmanaged parallel control plane. That plane usually escapes standard IAM review cycles because it is not labelled as a privileged system. The field needs governance models that include human communication systems in identity and access scoping.

NHI programmes should measure secret exposure by business blast radius, not by leak count alone. A small number of highly privileged credentials can create more risk than thousands of low-value tokens. That shifts reporting away from raw findings and toward scope, reach, and revocation status. Practitioners should prioritise the secrets that can actually move the business.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• For deeper context, compare this pattern with Guide to the Secret Sprawl Challenge, which breaks down remediation priorities for sprawl outside source control.

What this signals

Secret sprawl now behaves like an identity lifecycle failure, not a point-in-time leak event. When credentials surface in code, logs, and collaboration tools, the organisation has already lost track of ownership and expiry. That means the next programme step is broader than scanning. It is to align discovery, revocation, and access review with the control intent in NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10.

The pattern is also visible in AI-adjacent systems, where secret leakage emerges before governance catches up. In our research, AI-related credential leaks surged 81.5% year-over-year in 2025, which suggests the problem is expanding faster than manual review processes can absorb. Teams should assume that agentic workflows and machine-generated artefacts will increase secret propagation unless controls are built into the pipeline.

Credential exposure is becoming a blast-radius management problem. The relevant question is no longer whether a secret leaked, but whether it could be used to reach production, data, or orchestration layers. Security leaders should use this as a trigger to prioritise short-lived credentials, scoped permissions, and automated invalidation across their NHI estate.

For practitioners

• Inventory all secret-bearing systems Map code repositories, CI/CD logs, chat platforms, ticketing systems, and documentation stores into one discovery programme so exposed credentials are not treated as isolated incidents.
• Enforce fast rotation and expiry Set short lifetimes for API keys, tokens, and certificates, and automate revocation when a secret is found in a public repo, log, or collaboration thread.
• Reduce entitlement before leakage happens Review service account and API permissions so leaked credentials cannot reach high-value systems, then remove non-admin access that is not required for operation.
• Scan collaboration tools as credential stores Include Slack, Jira, Confluence, and Teams in your secret discovery and DLP rules because those channels often retain active credentials long after troubleshooting ends.

Key takeaways

• Secrets exposure turns ordinary development and collaboration workflows into identity attack paths.
• The scale problem is not just discovery volume, but the persistence of leaked credentials after disclosure.
• Teams should optimise for faster revocation, tighter scope, and wider discovery coverage across the full NHI lifecycle.

Key terms

• Non-Human Identity: A non-human identity is any machine or software credential used to authenticate and authorise workloads, services, scripts, or agents. It includes API keys, tokens, certificates, service accounts, and bot identities, all of which require lifecycle governance because they can be reused independently of any human operator.
• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, logs, tickets, chat tools, and documents. It creates a parallel identity estate that is difficult to inventory, rotate, or revoke, which is why exposure management must include discovery across collaboration and development systems.
• Identity Blast Radius: Identity blast radius is the amount of damage an attacker can cause after compromising a single credential or account. It is determined by privilege scope, token lifespan, and system reach, so reducing it means tightening entitlements and limiting how far a leaked secret can travel.

What's in the full article

Entro Labs's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how secrets appear in source code, logs, Jira, Slack, and Confluence
• Specific mitigation workflows for scanning, redaction, rotation, and revocation across exposed credentials
• Product demonstrations showing how the platform detects idle and over-privileged NHIs
• Operational playbooks for alerting owners and responding to exposed credentials at scale

👉 The full Entro Labs blog includes mitigation examples, detection workflows, and platform demonstrations

Deepen your knowledge

Secrets exposure and automated revocation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is building controls for code, logs, and collaboration platforms, the course is a practical next step.