Secrets-only machine access security leaves NHI risk ungoverned

At a glance

What this is: This is an analysis of why secrets-only controls are insufficient for machine access security, with the key finding that vaulting credentials does not govern the identity using them.

Why it matters: It matters because IAM, PAM, and NHI programmes need controls that cover context, lifecycle, and runtime behaviour, not just secret storage.

By the numbers:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.

👉 Read Token Security's analysis of why secrets-only machine access security falls short

Context

Secrets-only security means storing passwords, API keys, and certificates in a vault and assuming that storage equals control. It does not, because the identity that retrieves the credential can still behave in ways the vault never evaluates. For NHI governance, the failure is structural: secret custody is not the same thing as identity governance.

That gap becomes more serious as enterprises add ephemeral workloads, microservices, and autonomous AI agents. Once a credential leaves the vault, it can be copied into configs, environment variables, logs, and other unmanaged paths. The result is a machine access model that can look secure on paper while remaining broadly exposed in practice.

Key questions

Q: What breaks when organisations rely on secrets-only controls for machine access?

A: Secrets-only controls break because they govern storage, not behaviour. A valid credential can still be used by the wrong workload, copied into secondary systems, or retained after the workload is gone. Without context, lifecycle, and runtime checks, the vault becomes a delivery mechanism for standing privilege rather than a control boundary.

Q: Why do machine identities complicate zero trust and least privilege?

A: Machine identities complicate zero trust because a vault usually verifies once, then trusts the holder until rotation. Least privilege also becomes hard to express when the requestor is a workload that can change context, replicate secrets, or act autonomously. The control needs to follow the identity at runtime, not just the credential at issuance.

Q: How do security teams know whether secret sprawl is already undermining governance?

A: Look for credentials in places that were never intended to be authoritative, such as build logs, tickets, chat tools, environment variables, and local files. If those copies exist, the vault is no longer the only access path. That is a governance signal that secret inventories, revocation, and monitoring are incomplete.

Q: Who is accountable when an orphaned machine credential is used after decommissioning?

A: Accountability should sit with the service owner, platform team, and identity governance process that failed to revoke access when the workload ended. If the credential outlived the machine, the problem is lifecycle control, not just secret hygiene. Automated offboarding and entitlement revocation are the only reliable way to close that gap.

Technical breakdown

Why vaults cannot govern machine intent

A secrets vault authenticates a request and returns a credential, but it does not evaluate why the workload needs access or whether the action matches its normal purpose. That is the central limitation of secrets-only design. In NHI terms, the vault knows the secret exists, not the identity's context, owner, or expected behaviour. As a result, least privilege becomes a static provisioning exercise instead of a runtime control. For ephemeral workloads and AI-driven automation, that is too late and too shallow to stop misuse.

Practical implication: treat vaulting as one control layer, not the control model, and pair it with identity context and runtime authorization.

How secret sprawl extends access beyond the vault

Secret sprawl begins when a checked-out credential is copied into files, variables, pipelines, chat tools, or local developer systems. The vault may still be protected, but the credential is now distributed across places that often lack equal monitoring and revocation. This creates parallel access paths that are invisible to the original control point. In practice, the security boundary moves from the vault to every system that handled the secret, which is why secrets-only programmes regularly miss the real attack surface.

Practical implication: inventory where secrets travel after checkout and put detection, revocation, and lifecycle controls around those secondary locations.

Why static secrets fail for autonomous AI agents

An autonomous AI agent is not just a script with a tool call. It can choose actions, select tools, and execute at runtime without human approval gates. If such a system is given a long-lived secret, the credential becomes standing privilege for an actor that can change behaviour mid-session. Prompt injection or tool misuse then turns a valid secret into a high-impact breach path. The issue is not simply exposure of the secret. It is the mismatch between static authorization and dynamic decision-making.

Practical implication: do not grant long-lived secrets to autonomous systems when runtime behaviour can shift after access is approved.

Threat narrative

Attacker objective: The objective is to turn a valid machine credential into broad, persistent access that bypasses context and behaviour checks.

1. entry: the attacker or compromised workload acquires a valid secret from a vault, replicated config, or another exposed location.
2. escalation: the credential is reused with standing privilege to reach data or systems beyond the workload's intended scope.
3. impact: the exposed identity enables data exfiltration, lateral movement, or infrastructure abuse before the secret is rotated or revoked.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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-only security is a storage model, not an identity model. The vault answers where a credential lives, but not who is using it, what the identity is allowed to do, or whether the behaviour is legitimate. That is why secrets management can reduce plaintext exposure without reducing machine access risk. Practitioners need to stop treating secure storage as proof of governance.

Secret sprawl creates an identity blast radius that extends far beyond the vault. Once a credential is copied into CI/CD, configs, logs, tickets, or chat systems, the security boundary becomes distributed and difficult to police. In that condition, the strongest vault controls still leave a large unmanaged surface. The practical conclusion is that visibility must follow the secret after checkout, not stop at issuance.

Lifecycle failure is the real control gap when machine credentials outlive workloads. A secret that remains valid after the workload is gone becomes an orphaned access path with no accountable owner. That is a governance failure, not just a hygiene issue. NHI programmes need to treat offboarding and revocation as one lifecycle event, because access that outlives the machine is access without governance.

Autonomous behaviour breaks the assumption that access can be reviewed after the fact. Access review was designed for conditions where privilege persists long enough to be observed and certified. That assumption fails when an AI agent can acquire, use, and abandon access within a single runtime session because the review window never captures the act. The implication is that governance models must be built around runtime decisioning, not periodic visibility.

Machine access governance now sits at the intersection of OWASP-NHI, zero trust, and lifecycle control. Secrets-only programmes cover credential storage, but they do not satisfy the broader need for continuous verification, scoped access, and accountable ownership. The field is moving toward identity-first controls because that is the only model that can span human-owned workloads, service accounts, and autonomous actors. Practitioners should align machine access with identity governance, not vault operations.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• For a broader pattern on credential exposure and remediation, see Guide to the Secret Sprawl Challenge for how leaked secrets move beyond the vault into operational environments.

What this signals

Secret sprawl is now a governance problem, not just a leakage problem. With 28% of secrets incidents originating outside code repositories and 13% more likely to be critical than code-based leaks, the control boundary has clearly shifted into collaboration tools and operational workflows. The practical signal for programmes is to extend discovery and revocation beyond repositories into the places where secrets actually circulate, including the Guide to the Secret Sprawl Challenge.

Machine access programmes should now separate vault hygiene from identity governance. A vault can still be necessary, but it cannot carry the full burden of accountability, lifecycle, and behavioural control. That is why NHI teams need policy, ownership, and runtime verification layered on top of storage. The clearest signal is whether your programme can answer not just where a secret is stored, but who is allowed to use it and when it expires.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, protocol adoption is already creating new credential exposure paths faster than many organisations can map them. That means AI-enabled workflows and machine-first integrations should be treated as first-class identity surfaces from day one. For practitioners, the next step is to align discovery, scoped access, and lifecycle revocation before the environment hardens around inherited secrets.

For practitioners

• Map every secret to a live identity and owner Correlate each API key, token, and certificate with the workload, service account, or agent that uses it, plus the business owner responsible for it. Remove credentials that cannot be tied to an accountable runtime identity.
• Measure where credentials persist after checkout Scan cloud configs, CI/CD jobs, logs, tickets, and developer systems for copied secrets, then track how often those credentials escape the vault. Use those findings to target the highest-risk replication paths first.
• Replace standing secrets with task-scoped access Move high-risk workloads toward short-lived, purpose-bound access so credentials expire with the task rather than remaining valid across sessions. Reserve persistent access only where a documented exception exists and review it regularly.
• Tie offboarding to automatic revocation When a workload is decommissioned, revoke its secrets and associated entitlements as part of the same lifecycle event. Do not rely on manual cleanup or delayed rotation to close orphaned access paths.

Key takeaways

• Secrets-only security protects the credential store, but it does not govern the machine identity that uses the credential.
• The biggest failure mode is lifecycle drift, where valid secrets remain usable after workloads are changed, copied, or decommissioned.
• Practitioners need identity-first controls that combine discovery, runtime context, and automatic revocation to shrink machine access risk.

Key terms

• Secret Sprawl: Secret sprawl is the uncontrolled spread of passwords, API keys, tokens, and certificates beyond the systems meant to store them. In machine environments, it usually appears in logs, configs, tickets, and developer tools, creating multiple hidden access paths that survive long after the original checkout event.
• Machine Identity Governance: Machine identity governance is the discipline of controlling non-human access across discovery, ownership, permissions, context, and lifecycle. It treats a service account, workload, or agent as an identity with an accountable purpose, rather than as a credential stored in a vault.
• Standing Privilege: Standing privilege is access that remains continuously available instead of being issued only when needed. For machine identities, it creates persistent blast radius because any exposed credential can be reused repeatedly until someone detects, rotates, or revokes it.
• Just-in-Time Access: Just-in-time access is a pattern where credentials are issued only for a specific task and expire when the task ends. For autonomous or machine actors, its value is that it removes permanent access from systems that may act unpredictably or at high speed.

What's in the full article

Token Security's full blog covers the operational detail this post intentionally leaves for the source:

• A deeper walkthrough of the machine-first security model and how it differs from vault-centric controls.
• The article's comparison table between legacy secrets management and modern machine identity governance.
• Operational examples for discovery, contextualization, right-sizing, automation, and monitoring across machine identities.
• The discussion of business impact, including compliance, engineering velocity, and blast-radius reduction.

👉 Token Security's full post covers the machine-first model, lifecycle controls, and runtime governance detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.