Shadow APIs and Zombie APIs: Finding What Your Inventory Missed

TL;DR

• Shadow and zombie application programming interfaces (APIs) are two states of one inventory failure: endpoints the central API catalog does not accurately describe. Only 12% of respondents to Salt Labs’ 2024 State of API Security survey were very confident in the accuracy of their API inventory, and 70% rated zombie APIs a great or strong concern. Both are found by reconciling what the code defines against what the catalog and live traffic record.
• A shadow API is an endpoint that runs in production and serves requests, but was never registered in the API catalog, gateway configuration, or OpenAPI specification. A zombie API is an endpoint that was once documented and governed, then deprecated on paper but remains reachable in production infrastructure.
• Zombie APIs are often the more dangerous exposure class because deprecated endpoints lose security patches, schema updates, and access reviews while continuing to run against legacy libraries.
• Agent-generated APIs, a term OX Security uses for endpoints an AI coding agent adds to application code while implementing a feature, are the newest state of inventory drift. They reach production without tickets, architecture reviews, or specification entries.
• Code-based discovery is the only method that finds an endpoint at the moment of creation, making the continuous reconciliation of code against traffic essential for complete visibility.
• Safe API decommissioning requires a five-step sequence that includes mapping callers, setting owner-backed sunset dates, degrading functionality, and executing two-tiered removal across both gateway and code.

The Inventory Is a Snapshot of an Intention

An API inventory is rarely broken by a single catastrophic event; it drifts continuously over time. Most security teams treat their central API inventory or OpenAPI specification as an accurate map of their architecture. In practice, an inventory records only what a developer or architect intended to build at a specific point in time. Meanwhile, the actual running API estate shifts dynamically with every code merge, container deployment, and ingress routing modification. That gap between the catalog and the running estate is the problem API exposure management exists to close.

When an endpoint exists in runtime code but remains absent from the inventory, it creates a tri-fold security blind spot:

1. Excluded from Security Testing: Automated dynamic application security testing (DAST) scanners and penetration testing scopes rely on API catalogs to build test suites, ignoring unlisted routes entirely.
2. Omitted from Runtime Monitoring: Web application firewalls (WAFs) and API security gateways cannot enforce schema validation or anomaly detection on routes they do not know exist.
3. Bypassing Access Reviews: Identity governance and access management (IAM) audits review permissions based on documented service catalogs, leaving undocumented endpoints with unverified access controls.

This operational reality is formally recognized by the Open Worldwide Application Security Project (OWASP) as API9:2023 Improper Inventory Management. OWASP names a missing retirement plan for each API version and a missing or outdated host inventory among the conditions that make an API vulnerable, and warns that attackers can exploit deprecated endpoints in old API versions to gain access to administrative functions and exploit known vulnerabilities.

What Are Shadow and Zombie APIs, and How Do They Differ?

A shadow API is an endpoint that runs in production and serves requests, but was never registered in the API catalog, gateway configuration, or OpenAPI specification. A zombie API is an endpoint that was once documented and governed, then deprecated on paper, but remains reachable in production. They are not distinct, unrelated problems, but two failure modes of the same underlying failure: a running endpoint that the central inventory does not accurately describe. 

The crucial operational difference between them lies in ownership and administrative perception:

Aspect	Shadow API	Zombie API
Inventory Record	Never recorded in inventory	Formally documented in the past
Ownership	No assigned owner or team	Assigned owner, retired on paper
Visibility	Unknown to security & AppSec	Believed by owner to be dead
Maintenance	Never receives initial controls	Deprived of ongoing patches

A shadow API has no recorded history, meaning no security team ever validated its authentication logic, and no engineering team claims responsibility for its maintenance. Nobody owns it, and nobody knows to retire it.

Conversely, a zombie API has an assigned owner who believes the endpoint was decommissioned months or years ago. Because the organization treats the endpoint as dead on paper, it is routinely excluded from active patch management, schema updates, vulnerability remediation, and IAM access reviews. Yet, because the underlying code path or container service was never physically removed from production, it remains fully reachable to an adversary. This makes zombie APIs uniquely dangerous: they carry legacy vulnerabilities, unpatched dependencies, and outdated authorization logic while operating entirely outside the security team’s active monitoring window.

For a dedicated breakdown of shadow API definitions, risk vectors, and discovery strategies, read OX Security’s guide on understanding shadow APIs.

Shadow APIs: Concrete Origins

Shadow endpoints rarely stem from malicious intent; they are created by everyday engineering workflows that lack a mandatory step for inventory registration:

• Temporary Migration Endpoints: Custom routes built to support database syncs or service migrations that are left running after the migration concludes.
• Exposed Debug and Internal Routes: Administrative or telemetry endpoints intended strictly for local testing that become publicly reachable following an ingress or reverse proxy configuration update.
• Third-Party Integration Callbacks: Webhooks and callback handlers introduced to support external software-as-a-service (SaaS) integrations without being routed through the primary API gateway.
• Unreleased Versioned Routes: Pre-release endpoints (such as /v2/users/draft) published to production environments ahead of their official launch and documentation cycle.

Each of these scenarios shares a common operational failure: code was written and deployed through a pipeline that had no automated mechanism for registering the new interface in the central inventory.

Zombie APIs: Mechanics of Infrastructure Decay

A zombie API persists in production because the administrative process of deprecation is disconnected from the technical process of infrastructure decommissioning:

• Unidentified External Clients: Engineering teams delay hard deletion because legacy traffic logs show occasional requests, but no one can identify which client application or business partner relies on the endpoint.
• Unenforced Gateway Deprecation: An endpoint is flagged as deprecated in developer portals and API specifications, but the API gateway is never configured to reject incoming requests to that route.
• Orphaned Microservice Infrastructure: The engineering team that originally built the service is dissolved or reassigned, leaving the running container pods and database bindings active without an active custodian.

This creates severe security decay over time. A zombie API is permanently frozen at the security posture, software dependencies, and authentication standards of its deprecation date. While the rest of the enterprise moves forward to modern OAuth standards and patched framework libraries, the zombie API continues running against legacy libraries, outdated encryption protocols, and superseded authorization patterns.

How Do Zombie-, Shadow-, and  Agent-Generated API Endpoints Actually Happen?

Creating undocumented or unmaintained endpoints stems from three primary operational paths, each leaving distinct traces across the software delivery pipeline:

1. High-Velocity Engineering & Deadlines: Teams shipping rapid feature iterations bypass manual API specification updates or gateway registration steps.
   
   Evidence: Code diffs containing new controller routes without corresponding updates to openapi.yaml or developer portals.
   
   
2. Organizational Restructuring & Acquisitions: Mergers and team reshuffles leave legacy microservices running without assigned owners.
   
   Evidence: Live container pods and DNS records mapping to inactive repositories or archived projects.
   
   
3. Agentic Development Lifecycle (ADLC): The Agentic Development Lifecycle (ADLC) is the software development lifecycle operating when autonomous AI agents author, review, refactor, and deploy code, with human approval gates absent unless explicitly re-engineered. Within it, a developer prompts an AI coding assistant to implement a feature, and the agent independently introduces a new HTTP route or helper endpoint to achieve the result. The pull request diff is reviewed strictly for feature functionality rather than interface expansion, and the endpoint merges into production without an architectural design review, an updated specification entry, or a ticket referencing its creation.
   
   Evidence: Route declarations in agent-authored commits with no linked ticket, design doc, or specification change.

What makes agent-generated endpoints fundamentally distinct is their complete lack of out-of-code telemetry. No ticket exists in Jira, no design doc exists in Confluence, and no route exists in the gateway schema. The endpoint’s only record is the application source code itself. Consequently, any discovery tool or audit framework that begins outside the source repository is structurally incapable of finding it before it is deployed and exploited.

CyberOXtales podcast: Jim Manico on vibe coding, AI coding agents, and a zero-trust approach to testing them.

API Discovery Methods: Gateway Catalog, Traffic Analysis, and Code-Based Discovery

Dimension	Gateway Catalog	Traffic Analysis	Code-Based Discovery
What it observes	Explicitly routed traffic and gateway configuration rules	Live network packets, eBPF streams, and HTTP logs	Source code, abstract syntax trees (ASTs), route annotations, and infrastructure-as-code (IaC) manifests
Coverage capability	Documented routes and explicitly routed proxies	Shadow and zombie APIs receiving active traffic	Shadow, zombie, and agent-generated APIs in supported frameworks
Structural blind spot	Unrouted internal paths, sidecar bypasses, and shadow APIs	Uncalled endpoints, dormant routes, and zero-traffic paths	Active runtime execution state and real-time request volume
First visibility stage	Routing configuration time	Production deployment (upon first HTTP request)	Pull request/commit time
Uncalled endpoint reporting	Reported only if explicitly routed	Completely invisible/unreported	Discovered and cataloged immediately

The technical reality this matrix reveals is structural: gateway catalogs capture only what has been intentionally routed through them, while traffic analysis captures only what has already been called. Neither approach can detect an agent-generated or shadow endpoint prior to its first execution.

Code-based discovery is the only approach that detects an endpoint the moment it is introduced into the codebase. However, relying on code analysis alone omits runtime execution state. Achieving true, comprehensive visibility requires continuously reconciling code-based discovery against active traffic analysis rather than relying on either mechanism in isolation.

For a detailed breakdown of how reachability and attacker visibility differ across measurement methods, see our guide on API Exposure.

How Do You Decommission a Zombie API Safely?

Most zombie API cleanup initiatives stall because engineering teams fear breaking undocumented downstream systems. Simply “turning off” a legacy endpoint without visibility introduces unacceptable operational risk. To safely remove zombie APIs without causing outages, AppSec and platform teams must execute a structured, controlled deprecation sequence:

1. Establish Active Callers and Origin Context

Complete this before making any public announcements.

Monitor traffic logs, gateway telemetry, and eBPF network streams to identify all IP addresses, authentication tokens, and client user-agents making active calls to the endpoint. Determine whether traffic originates from internal microservices, partner applications, or third-party callers.

2. Assign Ownership and Set Formal Sunset Dates

Assign a specific engineering lead or platform owner to oversee the deprecation. Communicate the sunset schedule directly to identified callers via developer portal notices and standard HTTP Deprecation and Sunset response headers.

3. Degrade Functionality Rather Than Hard Deleting

Implement progressive degradation to force silent or forgotten clients to surface through operational complaints rather than system outages. Introduce aggressive rate limits, schedule short brownouts that return 410 Gone, or require callers to pass an explicit header (e.g., X-Allow-Deprecated: true) to maintain access.

4. Execute Two-Tiered Removal in Gateway and Code

Removing the route at the gateway while leaving the backend handler code active leaves the endpoint vulnerable to sidecar or direct-pod bypasses. Conversely, deleting the backend code without updating gateway routes leaves the gateway returning 404 or 502 errors in place of a deliberate retirement response. Remove the entry from the gateway configuration, then merge a pull request (PR) deleting the handler function and route annotations from the repository.

5. Record Retirement as an Explicit State Change

Update the central API inventory to record the endpoint as explicitly Retired rather than deleting its entry entirely. Maintaining a historical record of retired signatures ensures that if a legacy branch is merged or a container image is re-deployed, the inventory flags the resurrected route immediately.

Prevention: API Governance in the ADLC

To stop shadow and zombie APIs from continuously regenerating, organizations must modernize their governance models for the Agentic Development Lifecycle (ADLC). When AI agents generate code at scale, manual review processes cannot keep pace. Preventing inventory drift requires embedding automated governance checks directly into developer workflows:

• Treat Route Additions as First-Class Review Events: Configure continuous integration and continuous delivery (CI/CD) pipelines and pull request linters to flag newly declared HTTP routes, controller classes, or API annotations with the same security weight as adding a third-party software dependency.
• Mandate Metadata Before Deployment: Enforce gate checks that block code merges if a new or modified route lacks an assigned codeowner, functional description, and declared lifecycle state (Experimental, Production, Deprecated).
• Automate Code-to-Runtime Reconciliation: Implement continuous, scheduled reconciliation between the code-defined API inventory and the live gateway/traffic state. Any discrepancy between what code declares and what traffic routes should automatically trigger a low-priority AppSec ticket.
• Scale Governance for Agentic Workflows: Extend automated route linting and schema generation directly to AI agent commits. Because AI coding tools write code faster than human leads can review interface expansions, governance must execute as automated policy-as-code inside the PR pipeline.

The continuous, machine-readable artifact produced by enforcing this code-level governance framework is an API-BOM.

For an in-depth breakdown of schema structures, generation pipelines, and governance integration, read our dedicated guide on the API-BOM.

Common Mistakes and Limitations

Organizations attempting to eliminate shadow and zombie APIs frequently make five critical operational errors:

1. Deprecating in Documentation Without Decommissioning Infrastructure: Marking an endpoint as retired in developer portals, OpenAPI specifications, or release notes while leaving its container pods, routing rules, and database bindings live in production. This disconnect is the single most direct cause of zombie APIs.
2. Treating Discovery as a One-Time Project: Executing API discovery as a periodic annual or quarterly audit rather than an automated, continuous control. Because code merges and deployments occur daily, point-in-time inventories start drifting with the next merge.
3. Excluding Internal Endpoints from Governance: Assuming non-internet-facing APIs carry low risk and ignoring them in security monitoring. Lateral movement techniques rely heavily on unmonitored internal endpoints once an initial perimeter breach occurs.
4. Hard-Deleting Endpoints Without Caller Analysis: Removing suspected zombie routes without first mapping active client IPs and user-agent logs. Abruptly tearing down legacy routes converts a dormant security finding into a business-impacting application outage.
5. Equating the Gateway Catalog with Total API Inventory: Assuming that any endpoint omitted from gateway routing manifests does not exist. This assumption leaves security teams blind by default to shadow APIs, unrouted microservices, and direct pod access routes.

The Limitation of Code-Based Discovery

While code-based discovery offers the earliest visibility, at commit time, it carries a primary technical constraint: coverage is bound strictly to the specific programming languages, router abstractions, and web frameworks supported by the static analysis engine. In a highly polyglot architecture (or one utilizing custom internal framework wrappers), security teams must explicitly map language and framework gaps rather than assuming uniform coverage across the entire estate.

How OX Security Approaches Creation-Time API Discovery

Solving inventory drift requires identifying endpoints at the exact moment of creation rather than waiting for production request traffic. OX Security’s API exposure management platform, built on the API Discovery capability in OX Code, integrates directly into source repositories, reading application code, framework routes, and OpenAPI specifications during developer workflows.

This code-centric approach alters the security operational model across three distinct dimensions:

1. Attributed Shadow Findings: When an undocumented route is introduced, it is linked to its repository, the functions it calls, and the date it was first detected. This delivers actionable context instead of an unanchored hostname or IP address.
2. Zero-Traffic Agent Detection: Endpoints generated by AI coding tools are inventoried from the code itself, independent of traffic, so they can be visible before they process their first production request.
3. Dated Baseline: Because OX records when each endpoint was first detected,  teams have a dated baseline to compare against their own deprecation records, rather than relying on the catalog’s account of what was retired.

Securing the Estate Beyond the Inventory

Shadow APIs and zombie APIs are not separate architectural anomalies; they are two operational states of the exact same inventory failure. Whether an endpoint was never recorded in developer documentation or was deprecated on paper while remaining active in production infrastructure, the net result is identical: unmonitored execution paths running outside security governance.

As engineering teams adopt AI-assisted development tools within the Agentic Development Lifecycle (ADLC), undocumented endpoints will continue to proliferate at unprecedented speed. Because agent-generated routes exist only in source code prior to deployment, traffic-based and gateway-centric monitoring tools are structurally incapable of detecting them before their first request.

Solving inventory drift requires a code-first approach that identifies endpoints at commit time, attributes ownership directly to repositories, and continuously reconciles code-defined routes against runtime traffic.

Let us help you find and close your blind spots, and establish continuous visibility across your modern software estate. Schedule a personalized demo with an OX Security expert today..