Notifications
Clear all
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.
NHIMG editorial — 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.
- A 5% sample means 95% of API calls are unobserved.
Questions worth separating out
Q: What breaks when API security depends only on gateways and WAFs?
A: Teams lose visibility into business logic abuse, object-level authorisation failures, and low-and-slow reconnaissance that looks legitimate at the transaction layer.
Q: When should teams prioritise runtime API discovery over static scanning?
A: Prioritise runtime discovery when systems change after deployment, when microservices communicate laterally, or when AI workloads create API calls dynamically.
Q: What do security teams get wrong about sampled API monitoring?
A: They often assume a sample can represent a live API estate accurately.
Practitioner guidance
- Map the live runtime API surface Run a 72-hour runtime discovery exercise across production paths, then compare the result to gateway registrations and spec inventories to quantify the visibility gap.
- Separate unmanaged endpoints from drifted endpoints Classify uncovered APIs into shadow, zombie, and drift categories so remediation can target registration, retirement, or runtime policy correction instead of generic cleanup.
- Require identity attribution for AI-originated calls Tie every model, vector, and MCP call to the initiating workload identity or service account so AI-generated traffic can be governed as a privileged access path.
What's in the full article
AccuKnox's full guide covers the operational detail this post intentionally leaves for the source:
- The five-point API visibility assessment framework you can use to score tools before purchase.
- The runtime discovery workflow for comparing gateway counts against live production traffic.
- The detailed breakdown of kernel-level eBPF coverage across external and east-west API paths.
- The AI API connection mapping section that shows how model, vector, and MCP calls are surfaced in context.
👉 Read AccuKnox's full guide on API visibility gaps and runtime discovery →
API visibility gaps: is your security stack seeing the full runtime?
Explore further
21/08/2026 5:16 pm
API visibility has become an identity problem, not just an observability problem. When APIs are invoked by service accounts, workloads, and AI systems, unseen traffic means unseen trust relationships. That shifts the control question from 'what endpoints exist?' to 'which identities are allowed to reach them, and how are those paths governed?' Practitioners should align API discovery with identity and privilege review, not treat it as a separate inventory exercise.
A question worth separating out:
Q: How can organisations govern AI-generated API code safely?
A: They should apply the same controls to agent-authored code as to human-written code, with no exceptions. That means policy checks on every commit, automated secrets scanning, dependency scanning, and review of generated authentication logic. If AI can create endpoints and scopes faster than humans can inspect them, governance has to become machine-enforced.
👉 Read our full editorial: API visibility gaps expose shadow traffic, LLM calls, and drift
