Why do exposed secrets often slip past traditional security controls?

Why This Matters for Security Teams

Exposed secrets slip past traditional controls because most security programmes still assume the credential only matters when it appears in source code or a vault. That assumption misses where modern workflows actually emit secrets: tickets, chat, build logs, collaboration pages, package registries, and machine-to-machine handoffs. Current guidance suggests that the attack surface is operational, not just repository-based, which is why incidents keep recurring even in mature environments.

NHIMG research shows the scale of the problem is no longer theoretical. In The State of Secrets Sprawl 2026, GitGuardian reported that 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and those leaks are 13% more likely to be critical than code-based exposures. That pattern lines up with NHIMG case studies such as the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign, where the exposure path extended well beyond a single repository. In practice, many security teams encounter secret abuse only after a downstream system has already authenticated with stolen credentials, rather than through intentional detection at the point of emission.

How It Works in Practice

Traditional scanners work best when secrets are committed in predictable places. They fail when the credential is transient, duplicated, forwarded, or copied into a workflow artifact that no repository rule can see. Effective control requires tracing the full operational path from creation to use, then to revocation. That means watching CI/CD output, developer chat, ticketing systems, document platforms, and runtime telemetry, not just Git history.

Practitioners should pair discovery with enforcement. The OWASP Non-Human Identity Top 10 treats exposed or over-privileged machine credentials as an identity problem, not only a data leakage problem. In practice, that means mapping where each secret is issued, where it can be replayed, and what business action it enables. If a token can reach multiple systems, it should be treated as a workload identity with explicit scope, not as a reusable string.

• Use secret discovery across code, logs, tickets, chat, and build artifacts.
• Issue short-lived credentials where possible so exposure has limited value.
• Bind secrets to workload identity and context rather than static role grants.
• Revoke and rotate automatically when the secret appears outside the intended path.

GitGuardian’s Guide to the Secret Sprawl Challenge and the 2025 State of NHIs and Secrets in Cybersecurity both show how duplication and overuse make exposure much harder to contain. These controls tend to break down in high-churn CI/CD environments because secrets are created, forwarded, and consumed faster than manual review or nightly scanning can react.

Common Variations and Edge Cases

Tighter secret control often increases delivery friction, requiring organisations to balance developer speed against the cost of extra validation, revocation, and exception handling. That tradeoff is real, especially where teams rely on vendor plug-ins, ephemeral build runners, or cross-team automation that was never designed for fine-grained identity binding.

There is no universal standard for every workflow yet, but current guidance suggests prioritising controls where the blast radius is largest. For example, CI/CD runners, chatbot integrations, and shared automation accounts often deserve stronger treatment than low-risk internal scripts. The Anthropic report on the first reported AI-orchestrated cyber espionage campaign shows how autonomous tooling can chain access and move laterally faster than human operators expect, which makes static assumptions about “safe” credentials less reliable. That same lesson appears in NHIMG’s 52 NHI Breaches Analysis and the 230M AWS environment compromise, where standing permissions and reused credentials amplified exposure.

For environments with autonomous agents, the answer becomes even more specific: static, role-only controls are not enough. Best practice is evolving toward intent-based authorisation, just-in-time credential issuance, and workload identity primitives such as SPIFFE or OIDC-backed proof of execution. That approach reduces the lifetime of a secret and ties access to what the workload is actually trying to do, not what a broad RBAC role says it may do.

Related resources from NHI Mgmt Group

• How should teams reduce the risk from exposed NHI secrets?
• Why do secrets create disproportionate risk in NHI environments?
• How should security teams decide whether JIT access is safe for non-human identities?
• How does OneDrive auto-sync create secrets exposure in SharePoint?