TL;DR: Enterprises often have 40% to 60% more APIs than gateway inventories show, because internal service calls, sampled telemetry, Kubernetes ephemerality, and AI-generated runtime connections create structurally hidden traffic, according to AccuKnox. The result is a visibility problem that conventional gateways and static scanning cannot solve; kernel-level discovery becomes the decisive control boundary.
At a glance
What this is: This analysis argues that API security programs routinely miss a large share of runtime traffic because gateways, code scans, and sampled telemetry cannot see east-west calls, drift, or LLM-driven connections.
Why it matters: For IAM, NHI, and cloud security teams, the issue is that hidden API paths can carry privileged, service-to-service, and agent-to-tool access that never enters standard inventory or review workflows.
By the numbers:
- Most enterprises discover they have 40-60% more APIs than their gateway configurations show.
Context
API visibility is the ability to see every endpoint and call path that is active at runtime, not just what is registered in a gateway or written into a specification. This article argues that modern architectures create persistent blind spots because traffic now moves between services, pods, and AI components outside the places many security tools inspect.
The governance problem is not only missing inventory. It is that invisible API paths weaken authorisation, monitoring, and change control at the same time, especially where service accounts, workload identities, and AI agents depend on API-driven access. That makes runtime discovery a control issue, not just a detection issue.
Key questions
Q: Why do gateway inventories miss so many internal API calls?
A: Gateways only see traffic routed through them, so direct service-to-service calls, pod-to-pod traffic, and sidecar communications remain outside the inventory. In cloud-native environments, that means the control is enforcing policy on a subset of traffic while the real runtime surface keeps expanding elsewhere. The gap is structural, not accidental.
Q: When does sampled API monitoring stop being trustworthy?
A: It becomes unreliable as soon as the sampling rate can no longer represent low-frequency but high-value requests. Admin endpoints, privilege-related calls, and rare automation paths are exactly the traffic patterns most likely to be missed. If the control does not capture every request, it cannot support strong claims about completeness or risk reduction.
Q: How should teams govern AI agents that can reach APIs, events, and memory?
A: Teams should govern those agents as runtime identities, not as isolated integrations. That means enforcing policy at execution time, logging every tool and data access, and binding actions back to a clear initiating workflow or identity. If the control plane cannot show who acted, what they reached, and why, the programme does not have usable governance.
Q: What does runtime drift mean for API security and compliance?
A: Runtime drift means the deployed API surface has changed from what was documented, scanned, or approved earlier. That matters because security policy, authorisation, and compliance evidence all depend on the live attack surface, not the design-time one. When drift is not detected continuously, controls and documentation diverge from operational reality.
Technical breakdown
Why gateways miss east-west and ephemeral API traffic
Gateways enforce policy on routed traffic, but they do not discover traffic that never reaches them. In microservice architectures, pod-to-pod calls, sidecar communication, and direct service-to-service requests create an internal API fabric that stays outside gateway inventory. Kubernetes makes the problem worse because pods are intentionally short-lived, so point-in-time agent placement or static registration cannot keep pace with the runtime surface. The result is not a broken gateway; it is a tool operating at the wrong layer of the stack.
Practical implication: Treat gateway inventory as a policy baseline, not an authoritative runtime map.
Why sampled telemetry creates structural blind spots
Sampling tools only observe a fraction of requests, which means rare but high-value calls can disappear from analysis entirely. That matters because many sensitive operations, including admin functions and privilege-related paths, are low-frequency by design. When the sample window is too narrow, defenders infer safety from missing evidence rather than verified coverage. The technical issue is probabilistic observation, not poor tuning: if the control only sees some calls, it cannot guarantee visibility into the ones that matter most.
Practical implication: Use zero-sampling coverage requirements when evaluating API discovery and runtime monitoring.
How LLM and MCP connections create a new API visibility layer
AI applications generate API calls at inference time, not just at build time. Those calls may go to model endpoints, vector databases, tool-use APIs, and MCP servers based on runtime context, which means static specifications will never fully describe the true call graph. This creates a distinct visibility class because the workload identity making the call may be stable while the destination and sequence change dynamically. For security teams, the challenge is to map AI-driven API use back to the initiating pod, service account, and namespace.
Practical implication: Inventory AI-to-API connections at runtime and tie them to workload identity context.
NHI Mgmt Group analysis
API visibility debt is now a control failure, not a reporting gap. When enterprises cannot see 40% to 60% of active APIs, they are not just missing telemetry. They are operating with incomplete authorisation boundaries, incomplete monitoring, and incomplete change control. That creates a governance problem for both human operators and non-human identities that rely on API-based access. The practitioner conclusion is simple: visibility must be designed as a runtime control, not as an inventory exercise.
Runtime discovery has become the defining boundary for modern API governance. Static scanning and gateway registration still matter, but they describe intent rather than operational truth. Once services, pods, and AI workloads begin creating connections dynamically, the authoritative control point shifts to runtime observation. This is especially relevant for NHI programmes because service accounts and tokens often exercise privileges through APIs that never pass a central gateway. Practitioners should align API governance with live execution paths, not documentation states.
LLM API connection gaps are a distinct named risk, not a generic blind spot. AI-driven traffic changes endpoint selection at inference time, which means discovery methods that depend on code, spec, or deployment state will consistently lag reality. That makes AI API monitoring part of the identity and access problem, because the system that initiates the call may be a workload identity, an agent, or a service account. The practical conclusion is that AI runtime visibility and NHI governance now overlap materially.
Gateway coverage, sampling coverage, and runtime coverage are three different security claims. Vendors and internal teams often collapse them into one, but they are operationally distinct and should be evaluated separately. A platform can record registered routes and still miss east-west traffic, or sample traffic and still miss rare high-value calls. For practitioners, the buying and architecture question is whether the platform can prove full runtime capture across all traffic directions and workload types.
Kernel-level observability is the most defensible named concept in this category. The article’s central technical claim is that visibility improves only when observation moves to the kernel, where traffic can be seen regardless of language, framework, or deployment model. That does not remove the need for governance, but it changes the evidentiary standard. Practitioners should require proof of zero-sampling runtime coverage before trusting any API inventory, especially in cloud-native and AI-enabled environments.
From our research library:
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Identity Visibility and Intelligence Platforms (IVIP) Guide
What this signals
Runtime API discovery will increasingly sit inside identity governance conversations. Once API visibility extends to service accounts, namespaces, and AI-driven call paths, the boundary between API security and NHI governance becomes operational rather than conceptual. The teams that own workload identity and privilege review will need runtime evidence, not just registration data, to prove control over machine-driven access paths.
Kernel-level observability is becoming the practical benchmark for full coverage. Static inventories and sampled telemetry still matter, but they should be treated as incomplete inputs unless they can prove 100% capture of the runtime surface. The practitioner implication is that visibility claims now need to be tested against east-west traffic, drift, and AI-generated connections, not only gateway logs.
For practitioners
- Define a runtime API coverage baseline Compare gateway inventory against live runtime discovery across internal services, external routes, and AI-generated calls to establish the true gap before tuning controls.
- Require zero-sampling evidence from discovery tools Ask vendors and internal teams to show how they capture every call, including rare admin paths and east-west traffic, rather than relying on sampled telemetry.
- Inventory AI-to-API call paths by workload identity Map model endpoints, vector databases, tool APIs, and MCP server calls back to the pod, service account, and namespace that initiated them.
- Track runtime drift as a control outcome Continuously compare the deployed API surface to the baseline so added endpoints, changed authentication rules, and hidden internal paths are flagged as governance drift.
Key takeaways
- The article’s central warning is that API inventories built from gateways and static scans can miss a large share of live traffic.
- That gap matters because hidden service-to-service and AI-driven calls can bypass ordinary monitoring, authorisation, and drift controls.
- Practitioners should evaluate runtime discovery on zero-sampling coverage, east-west visibility, and workload identity context before trusting any platform claim.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The article centers on undocumented, unregistered, and drifted API surfaces that inventories fail to track. |
| API8 — Security Misconfiguration | Runtime drift and unmanaged endpoints create misconfiguration between policy, documentation, and live exposure. | |
| Recommendation — Inventory every runtime API path and reconcile it continuously against documented routes and approved exposure. Detect and remediate API configuration drift before changed routes, auth, or exposure expand the attack surface. | ||
| MITRE ATT&CK | TA0007;TA0008 — Discovery; Lateral Movement | The article describes internal API paths and east-west traffic that support discovery and lateral movement. |
| Recommendation — Map internal API exposure to discovery and lateral-movement paths, then monitor east-west traffic for abuse. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and information systems monitored to detect potential cybersecurity events | Continuous runtime observation is the article's central control requirement for API visibility. |
| Recommendation — Monitor live API traffic continuously so hidden endpoints and anomalous call patterns surface in time to act. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | The article depends on complete call capture to make API activity observable and attributable. |
| Recommendation — Generate audit records for every API call path, including east-west and AI-driven traffic. | ||
Key terms
- API Visibility: API visibility is the ability to know what APIs exist, what they do, and what data they handle across an environment. It combines continuous discovery, documentation enrichment, and sensitive data classification so security and engineering teams can govern APIs with current, evidence based context rather than static spreadsheets or partial scans.
- East-west traffic: East-west traffic is communication that moves between systems inside an environment rather than entering or leaving it. In microsegmentation programmes, it is the traffic most likely to expose hidden trust assumptions and is therefore the main target for workload-level policy.
- Runtime Drift: Runtime drift is the gap between an AI agent’s approved authority and its actual behaviour as conditions change. It appears when the agent adapts to new context, new integrations, or new instructions and begins acting outside the scope that governance originally defined.
- LLM API: An LLM API is an application interface that lets software send prompts to a large language model and receive generated text or structured outputs. It exposes model capabilities through authenticated requests, parameters, and response formats, and it often becomes a control point for logging, rate limits, data handling, and security governance.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 21, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org