Shadow and zombie APIs expose the NHI governance gap

At a glance

What this is: This article explains how shadow APIs and zombie APIs create hidden identity and access risk by escaping normal governance, monitoring, and decommissioning controls.

Why it matters: It matters because hidden APIs behave like unmanaged non-human identities, so IAM, NHI, and lifecycle programmes must cover discovery, privilege scope, and offboarding together.

By the numbers:

• cyberattacks targeting APIs have surged by 137% in 2023 compared to the year before.

👉 Read Entro Security's analysis of shadow and zombie API detection

Context

Shadow APIs are APIs created or connected outside formal oversight, while zombie APIs are deprecated interfaces that remain reachable after they should have been retired. In identity terms, both are unmanaged access paths: they can hold secrets, expose data, and keep permissions alive after the business need has ended.

The problem is not simply bad hygiene. It is a lifecycle failure across discovery, review, rotation, and decommissioning, which is why shadow API detection and zombie API offboarding belong in the same governance model as NHI lifecycle management.

When APIs are treated as static technical objects instead of governed access relationships, security teams lose track of who or what can call them, what secrets authenticate them, and whether the access still matches the service's current purpose.

Key questions

Q: How should security teams manage shadow APIs before they become exposure points?

A: Security teams should treat every unregistered API as a governance exception until it is owned, inventoried, and assigned an authentication method. The key is to connect discovery with access control, secrets management, and review so a hidden interface cannot stay live simply because nobody formally noticed it. NHI Lifecycle Management Guide helps here.

Q: When does a zombie API become a real security problem?

A: A zombie API becomes a real security problem when deprecated access still works, because the organisation has lost the accountability link between current business use and active permissions. If secrets, tokens, or backend trust remain in place, the old interface can still expose data or services long after it should have been removed.

Q: What do teams get wrong about API least privilege?

A: Teams often define least privilege once at release time and then leave it unchanged while the API's real usage shifts. That creates stale access, especially when an endpoint becomes a hidden dependency or is reused by a different system. Least privilege has to be revisited as part of lifecycle governance, not treated as a one-time design choice.

Q: Who owns the risk when an abandoned API still has access?

A: The owning team, the platform team, and the governance function all share accountability because deprecated access is a lifecycle failure, not a single technical mistake. The practical standard is simple: if an API can still authenticate, someone still owns its risk, even if the original use case has ended.

Technical breakdown

How shadow APIs escape governance

Shadow APIs usually appear when development teams integrate external services, expose endpoints quickly, or bypass the standard review process. The technical risk is not just that the API is hidden. It is that its authentication, logging, patching, and data-access rules may never be registered in the security stack. That leaves security teams blind to whether the API has secrets, what data it can reach, and whether it is still needed. In practice, a hidden API behaves like an unmanaged workload identity with unknown blast radius.

Practical implication: build discovery and registration into API release gates so hidden interfaces cannot exist without an owner and an inventory record.

Why zombie APIs stay exploitable

Zombie APIs are formerly approved interfaces that were deprecated or abandoned but never fully removed. They often remain reachable, which means old tokens, outdated permissions, or stale backend connections can survive long after the application moved on. Their danger is predictability: attackers can target known weaknesses in an interface that defenders assume is gone. This is a classic lifecycle problem, because offboarding was incomplete and the access path outlived the service purpose.

Practical implication: tie API decommissioning to formal access revocation, secret revocation, and backend dependency removal.

Why secrets and least privilege matter for API trust

The article correctly points to secrets management and least privilege as the core control pair for API security. API authentication depends on credentials such as secrets or JWTs, so any exposed or over-privileged token turns an API into a reusable access path. Least privilege limits the damage if the credential is stolen, while centralised secrets governance reduces the number of places where the same access can be abused. Without both, monitoring only tells you that misuse is happening after the fact.

Practical implication: map every API credential to an owner, scope it to the minimum required data and actions, and rotate or revoke credentials when usage changes.

Threat narrative

Attacker objective: The attacker wants a low-friction, poorly monitored access path into systems and data that the organisation believes are already controlled or retired.

1. Entry occurs through an unmanaged shadow API or a zombie API that remains reachable after deprecation, often outside normal review and inventory controls.
2. Credential access or abuse follows when the API is authenticated with secrets, tokens, or JWTs that were never rotated, were over-scoped, or remained exposed in code or infrastructure.
3. Impact comes when the attacker uses the hidden API path to reach confidential data, unpatched functionality, or internal services that defenders assumed were no longer exposed.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Shadow API detection is really non-human identity discovery by another name. A hidden API is an unmanaged access path that can authenticate, hold secrets, and reach data without living inside the normal inventory. That makes the governance problem one of lifecycle control, not just network scanning. Practitioners should treat unknown APIs as identity objects until proven otherwise.

Zombie APIs expose the failure of offboarding, not just the danger of old code. Once an API is deprecated, every remaining credential, backend link, and permission is an accountability gap. The issue is not only that the interface is old, but that its access relationship was never fully terminated. Practitioners need to see decommissioning as identity revocation plus dependency removal.

Least privilege only works when API purpose is current and measurable. The article's emphasis on overexposure reflects a broader NHI pattern: access that is technically valid but operationally stale. In API estates, this creates identity blast radius that grows silently until an incident or audit forces discovery. Practitioners should align privilege reviews to API purpose, not just endpoint existence.

Secret governance is the control surface that makes API ownership real. If a shadow or zombie API can still authenticate, then the credential is effectively the live asset, not the code. The named concept here is identity blast radius: the amount of business access a forgotten API can still exercise after it falls out of governance. Practitioners should map that blast radius before they try to reduce it.

API security programmes fail when they separate discovery from lifecycle management. Discovery without revocation leaves the organisation knowing what exists but not what can still be used. Offboarding without inventory leaves credentials behind. The practical conclusion is straightforward: shadow and zombie APIs belong in the same governance workflow as NHI lifecycle, secrets rotation, and access review.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• A separate finding from the same research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which reinforces how quickly hidden access paths outgrow oversight.
• For a practical lifecycle lens, the NHI Lifecycle Management Guide shows how to connect provisioning, rotation, and offboarding to reduce the persistence of unmanaged access.

What this signals

Hidden APIs are a warning sign that identity governance is expanding beyond service accounts and into every machine-facing access path. The teams that will feel this first are those with large integration estates, because unmanaged endpoints behave like dormant NHI sprawl until an audit or incident forces discovery.

Identity blast radius: once an API can still authenticate after it should have been retired, the real exposure is no longer the code path but the access it can still exercise. Organisations that cannot tie API ownership to lifecycle events will keep rediscovering the same control failure in different forms.

The operational signal to watch is not only the number of APIs discovered, but the lag between first detection and credential revocation. If that gap persists, the governance programme is documenting exposure rather than reducing it.

For practitioners

• Build an authoritative API inventory Record every API owner, purpose, authentication method, data access scope, and retirement date so no interface sits outside governance.
• Tie API decommissioning to credential revocation Remove secrets, JWT signing trust, service dependencies, and downstream permissions as part of the same retirement workflow.
• Enforce least privilege for all API access paths Scope each API token or secret to the smallest feasible set of actions and data, then review those scopes whenever usage changes.
• Monitor for unknown and stale endpoints continuously Use continuous discovery to flag endpoints that appear without registration or remain active after their business owner says they should be gone.

Key takeaways

• Shadow and zombie APIs are identity governance failures as much as they are technical exposures.
• The strongest evidence of risk is not the presence of APIs alone, but the persistence of valid access after ownership has disappeared.
• Discovery, secrets revocation, and lifecycle offboarding need to operate as one control chain if organisations want to reduce API blast radius.

Key terms

• Shadow API: A shadow API is an application interface that exists and may be callable, but was never fully brought under security and governance oversight. In practice, it behaves like an unmanaged access path with unknown ownership, unclear data reach, and uncertain authentication controls.
• Zombie API: A zombie API is a deprecated or abandoned interface that remains accessible after the organisation believes it should be retired. It is risky because old permissions, secrets, or backend trust can survive the business purpose, turning legacy access into an active exposure.
• Identity Blast Radius: Identity blast radius is the amount of access damage an identity can cause if it is misused, forgotten, or compromised. For APIs and other non-human identities, it depends on scope, persistence, and how quickly credentials and permissions are revoked when the service changes.

What's in the full article

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

• The step-by-step detection and extermination workflow for shadow and zombie APIs across discovery, triage, and remediation.
• The article's practical guidance on monitoring patterns and static code analysis for finding hidden interfaces before they are abused.
• The secrets-management and JWT handling advice that supports API authentication hardening in live environments.
• The remediation playbook for isolating suspicious APIs and confirming whether they were introduced accidentally or left behind after deprecation.

👉 Entro Security's full post covers detection methods, remediation tactics, and API lifecycle controls in more 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.