How should security teams discover APIs that are not in their official inventory?

Why discovery needs more than the official inventory

API inventory drift is a normal condition in modern delivery, because teams create routes in gateways, ingress controllers, tests, side projects, and even temporary migration tooling long before anyone updates the authoritative register. That is why a discovery process has to look for evidence of live use, not just declared ownership. A continuous register helps teams find shadow APIs, retire zombie APIs, and attach each endpoint to a real business context rather than a stale ticket.

The practical problem is that “known to the platform team” and “known to the business” are often different states. If discovery only trusts the CMDB or the gateway catalogue, teams miss endpoints that still process data, accept authentication, or expose versioned services through alternate paths. NHI visibility is also part of the operational picture, because API routes are frequently exercised by service accounts and keys that outlive the application they were created for, which is one reason Ultimate Guide to NHIs — Key Challenges and Risks is useful when teams are trying to understand why endpoint discovery and credential governance tend to fail together. In practice, many teams only discover a forgotten route after it has already become part of a production data path.

How to build continuous API discovery

The strongest approach is to combine three signals: gateway and ingress logs, live network traffic, and code repository artefacts. Each source sees a different slice of reality, and together they reduce false negatives. Gateway logs show what is formally routed, traffic analysis shows what is actually being called, and repository scanning reveals routes that exist in code but have not yet been promoted, documented, or removed.

Start with gateway, ingress, and load balancer logs to enumerate currently handled paths, methods, and upstreams.

Correlate those entries with packet captures, flow telemetry, or service mesh data to find calls that bypass the official front door.

Scan source code, OpenAPI files, deployment manifests, test fixtures, and CI/CD artefacts for route definitions and hard-coded endpoints.

Normalise results into one register that includes path, method, environment, owner, data classification, authentication model, and last-seen evidence.

Review deltas continuously so newly observed endpoints are triaged before they become unmanaged exposure.

This is a discovery problem, but it is also a governance problem: an API that has no owner, no sensitivity tag, and no exposure context cannot be risk-prioritised correctly. That is where teams often need the discipline of lifecycle management, because discovery without ownership quickly turns into a noisy list of unknowns. The most reliable programmes treat the endpoint register as an operational control, not a quarterly cleanup exercise. These controls tend to break down when discovery is limited to a single control plane, because alternate ingress paths, test environments, and legacy integrations continue to expose live routes outside the catalogue.

Common variations and edge cases

Tighter discovery often increases operational overhead, so teams have to balance coverage against noise. Not every seen endpoint deserves immediate remediation, and not every undocumented route is malicious or high risk. The real test is whether the route is live, reachable, owned, and processing sensitive data, not whether it appears in the latest design document.

Some environments also need special handling. Ephemeral preview environments can generate large volumes of short-lived endpoints, while legacy monoliths may expose paths through application code that are invisible to gateway telemetry. Internal-only APIs deserve the same discipline as internet-facing ones if they move sensitive records or support privileged workflows. Best practice is evolving toward continuous validation, because stale inventory is common and manual reconciliation rarely keeps up with modern release velocity. In practice, the hardest cases are not the obvious shadow APIs, but the endpoints that look legitimate, still work, and no longer have a clear owner.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	Control 12 — Network Infrastructure Management	API discovery depends on seeing live network and ingress paths.
	Control 13 — Network Monitoring and Defense	Continuous discovery needs traffic and log visibility for shadow APIs.
	Control 16 — Application Software Security	Repository artefacts and route definitions are part of API discovery.
Recommendation — Correlate network telemetry with inventories to find undocumented API routes. Monitor inbound and east-west traffic to surface unapproved API exposure. Scan code and deployment artefacts to identify endpoints before release.
NIST CSF 2.0	DE.CM-01 — Networks and systems are monitored to detect cybersecurity events	API discovery uses monitoring to detect undocumented live services.
	ID.AM-01 — Physical devices and systems are inventoried	A continuous endpoint register is an inventory control for APIs.
	PR.PT-01 — Audit/log records are determined, documented, implemented, and reviewed	Gateway and ingress logs are core evidence for discovering APIs.
Recommendation — Expand monitoring coverage so undocumented API activity is detected promptly. Maintain a live API inventory with owner and exposure context. Retain and review logs that reveal live API paths and methods.

Practitioner Guidance

What to prioritise: Triage by live reachability and data sensitivity first. An undocumented endpoint that can move production data or accept authenticated writes should outrank a harmless read-only test route, even if the latter appears noisier in telemetry.

What to verify: For every newly observed route, verify the owner, environment, authentication mode, and last deployment source before you accept it into the register. If those fields cannot be proven, treat the route as an exposure gap until someone can reconcile it.

Practitioner takeaway: The objective is not to discover every string that looks like an endpoint, but to turn observed usage into a trustworthy ownership record that can drive remediation, decommissioning, and access review.

#1 Authority in NHI Education, Research and Advisory, empowering organizations to tackle the critical risks posed by Non-Human Identities (NHIs), including AI Agents.