TL;DR: API WAF protection is only as complete as the API inventory behind it, according to LEVO. In fast-changing environments with shadow, deprecated, GraphQL, and gRPC endpoints, static documentation leaves enforcement gaps that perimeter tuning cannot fix.
At a glance
What this is: This analysis argues that API WAF effectiveness breaks down when inventory is stale, incomplete, or based on documentation instead of runtime reality.
Why it matters: For security teams, the key issue is governance of the live attack surface: if APIs are not accurately inventoried, they are not fully monitored, enforced, or incident-ready, which creates blind spots across access control and detection.
👉 Read LEVO's analysis of why API WAF security depends on runtime inventory
Context
API inventory is the control plane that decides where an API WAF can actually enforce policy. When that inventory reflects design intent instead of live production behavior, the result is not just a documentation gap, but an access control gap that affects visibility, inspection, and incident response.
This matters to IAM, PAM, and NHI programmes because APIs increasingly expose machine-to-machine access paths, service accounts, tokens, and workload identities. If the organisation cannot map the real API surface, it cannot reliably govern who or what is accessing data through those interfaces.
Key questions
Q: What breaks when API inventory is incomplete in front of a WAF?
A: The WAF only protects the APIs it knows exist, so incomplete inventory creates unprotected endpoints, missing schema checks, and uneven rate limiting. The control may still function correctly, but only inside an artificially narrow scope. That is why inventory quality determines whether enforcement reaches the live attack surface or just the documented one.
Q: Why do undocumented APIs create security risk even if the WAF is deployed?
A: Undocumented APIs sit outside the policy boundary used to configure the WAF, so they can receive traffic without inspection or alerting. Attackers look for these gaps because they often expose the same data or functionality as protected endpoints. The risk is not theoretical, it is structural whenever runtime reality diverges from the inventory.
Q: How should security teams verify that WAF coverage is actually complete?
A: Start with external discovery, not policy documents. Build a live inventory of internet-facing assets, map each one to an active WAF policy, and confirm a named owner for exceptions. Coverage is only real when the asset, the policy, and the operational responsibility all line up.
Q: How should organisations govern API security when documentation lags production?
A: They should treat runtime discovery as the source of truth, then use inventory to drive monitoring, policy assignment, and incident response. Documentation still matters, but only as a design reference. The operational control is continuous reconciliation between what engineering intended and what is actually serving traffic.
Technical breakdown
Why static API inventory fails under continuous deployment
Static inventory is a snapshot of intended architecture, not an observed record of production traffic. In CI/CD environments, new endpoints appear, older versions linger, and service paths change faster than documentation can be updated. API WAFs depend on the inventory to know what to inspect and where to attach controls, so any drift means enforcement is partial by design. This is especially true for internal APIs and partner integrations that never pass through the same governance process as public endpoints.
Practical implication: replace periodic inventory reviews with runtime discovery and continuous reconciliation against live traffic.
Shadow APIs, zombie APIs, and runtime-only GraphQL queries
Shadow APIs are endpoints created outside formal review, while zombie APIs are deprecated versions that still receive traffic. GraphQL adds another complication because schemas describe possible operations, but not which queries and mutations are actually used. Security teams that inventory only documented routes miss the real interface behaviour that attackers can probe. The same problem appears in gRPC, where binary service traffic may bypass HTTP-centric discovery and monitoring. The result is a live surface that is broader than any static map.
Practical implication: build inventory from observed runtime behaviour, not from specifications alone.
Why WAF enforcement gaps persist even when dashboards look healthy
API WAF dashboards usually report only on known and protected APIs. That means the absence of alerts can be misleading, because untracked endpoints sit outside the telemetry scope altogether. Enforcement can appear strong on the documented surface while equally sensitive traffic flows through unmonitored paths. This creates asymmetric protection across functionally similar interfaces, which is exactly the kind of condition attackers exploit. In governance terms, the problem is not misconfiguration at the rule layer, but a broken scope definition upstream.
Practical implication: validate WAF coverage against the actual number of active APIs, not the number of protected APIs shown in the console.
NHI Mgmt Group analysis
API inventory drift is a governance failure, not a tuning problem. The article’s central point is that perimeter controls inherit the quality of the asset map they are given. If the organisation treats inventory as a document instead of a runtime control, the WAF becomes selective by default. That is a governance model problem, and it aligns with NIST Cybersecurity Framework 2.0 thinking around asset visibility and protection scope. Practitioners should treat runtime inventory as part of control design, not as a cleanup exercise.
Shadow API exposure creates a live attack surface that security teams often never formally accept. The issue is not only whether an endpoint exists, but whether it exists inside the authorised boundary of monitoring, policy, and incident response. That boundary gap is familiar in identity governance too, where unmanaged service access becomes de facto access. For API security, the right question is whether the live surface is being governed at the same pace as delivery.
API WAF blind spots are a form of protection asymmetry. One interface may be heavily validated while another, functionally equivalent path sits outside enforcement because it was never discovered. That asymmetry is what makes static inventory dangerous: attackers do not need to break the strongest control when a weaker route exists. The practitioner conclusion is simple, if uncomfortable: coverage claims are meaningless unless they are tied to runtime discovery and continuous reconciliation.
Named concept: runtime inventory truth. This article shows that API security depends on the accuracy of the live asset map, not the completeness of documentation. Runtime inventory truth means the security control set is continuously aligned to observed production behaviour, including internal, deprecated, and dynamically generated interfaces. That concept should now sit alongside Zero Trust and least privilege as a core control assumption for API programmes.
For IAM and NHI teams, API governance is increasingly identity governance by another name. APIs are often accessed by service accounts, tokens, and workload identities rather than humans, so gaps in inventory also become gaps in credential governance. When those identities can reach undocumented endpoints, access reviews and least-privilege policies lose their practical value. Practitioners should therefore connect API inventory quality to machine identity visibility and entitlements management.
What this signals
Runtime inventory truth should now be treated as an operational control, not an observability enhancement. For API-heavy programmes, the practical question is whether discovery data is authoritative enough to drive enforcement, especially where service accounts and workload identities interact with internal endpoints. The NIST Cybersecurity Framework 2.0 is a useful lens here because asset visibility, protection scope, and continuous monitoring are inseparable in practice.
Machine identity governance becomes more important as API surfaces fragment across gateways, GraphQL, and gRPC paths. If the organisation cannot attribute traffic to the identities consuming those APIs, least privilege becomes difficult to prove and even harder to enforce. That is why runtime inventory should be paired with entitlement review and service account oversight, not treated as a standalone discovery project.
The practical signal for IAM and security teams is simple: if a WAF can only protect what inventory has already captured, the organisation needs continuous reconciliation between runtime behaviour and policy scope. That shifts API security from periodic audit thinking to always-on governance, where the live surface and the approved surface must converge.
For practitioners
- Implement runtime API discovery Use live traffic analysis to identify active endpoints, versions, and consumers, then compare that map with documentation and gateway configuration on a continuous basis.
- Bind WAF scope to observed production behaviour Configure protection based on verified runtime usage rather than OpenAPI files, wiki pages, or release notes that may lag behind deployment.
- Track shadow and zombie endpoints separately Create distinct workflows for undocumented APIs and deprecated APIs still receiving traffic, because they represent different governance failures and require different remediation paths.
- Link API inventory to machine identity oversight Associate each API with the service accounts, tokens, and workload identities that access it so least-privilege reviews can include the real consumers of the interface.
Key takeaways
- API WAFs fail structurally when inventory is stale, because enforcement can only reach the endpoints the control plane already knows about.
- Shadow APIs, zombie APIs, GraphQL, and gRPC create enforcement gaps that static documentation rarely exposes in time.
- Runtime discovery and continuous reconciliation are now the practical prerequisites for trustworthy API protection and machine identity governance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-1 | Asset inventory and visibility are central because the WAF only protects what is discovered. |
| NIST SP 800-53 Rev 5 | AC-4 | Access enforcement depends on knowing which interfaces exist and should be protected. |
| CIS Controls v8 | CIS-1 , Inventory and Control of Enterprise Assets | Enterprise asset inventory is the foundation for identifying live APIs and exposed services. |
| MITRE ATT&CK | TA0007 , Discovery; TA0006 , Credential Access; TA0010 , Exfiltration | Unknown APIs are attractive discovery and exfiltration targets in real attack paths. |
Apply AC-4 to ensure API policy enforcement follows the runtime attack surface, not just documentation.
Key terms
- API consumer inventory: A complete register of the applications, partners, service accounts, and automation clients that use an API. It is the starting point for access review because you cannot govern lifecycle, entitlement scope, or offboarding if you cannot name every consumer identity.
- Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
- 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.
- Runtime inventory truth: A governance approach in which the authoritative view of APIs comes from observed production behaviour rather than static documentation. It is the basis for aligning discovery, monitoring, and enforcement with the real service landscape.
What's in the full article
LEVO's full analysis covers the operational detail this post intentionally leaves for the source:
- How API Inventory derived from live traffic is used to reconcile documented APIs with production behaviour
- How API Discovery, API Monitoring, and API Protection fit together in an operational workflow
- Why shadow, zombie, GraphQL, and gRPC endpoints break static WAF assumptions in different ways
- How runtime scope alignment changes enforcement decisions for APIs already in production
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a practitioner-focused format. It gives identity and security teams a common baseline for governing service access across modern environments.
Published by the NHIMG editorial team on September 3, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
