Topic starter
21/08/2026 5:00 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by AccuKnox: “Full API Visibility: A Practical Guide to API Security Platforms That Show You Everything (2026)”.
By the numbers:
- Most enterprises discover they have 40-60% more APIs than their gateway configurations show.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: The article’s central warning is that API inventories built from gateways and static scans can miss a large share of live traffic.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
21/08/2026 5:16 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: API visibility gaps expose shadow traffic, LLM calls, and drift