API discovery is the missing control for Zero Trust in cloud

At a glance

What this is: API discovery is presented as the missing control for Zero Trust in cloud, because only runtime visibility can reveal live APIs, shadow services, and drift between intended and actual exposure.

Why it matters: IAM, PAM, NHI, and cloud security teams need live API inventory to govern authorization, ownership, and service-to-service access in environments where documented state quickly diverges from reality.

By the numbers:

• The same approach can cut operational noise by up to 85% where applicable.
• AccuKnox says its approach supports audit readiness across 30+ framework mappings.

Context

API discovery is the discipline of finding what is actually live, not what a diagram, gateway, or specification says should exist. In multi-cloud and Kubernetes, that distinction matters because ephemeral services, bypass paths, and east-west traffic quickly outgrow static inventories and policy assumptions.

The governance gap is simple: least privilege cannot be enforced against endpoints, consumers, and data paths that are unknown or stale. This has a direct identity angle because API authorization depends on workload identity, service accounts, tokens, and entitlement context that must be tied to runtime traffic, not just configuration.

Shadow APIs, zombie APIs, and orphan APIs are all symptoms of the same problem. They are not just inventory errors, they are control failures that break ownership, incident response, and audit evidence when platforms change faster than security records.

Key questions

Q: What breaks when API discovery is missing from the security programme?

A: Security teams lose the ability to prove coverage. They may monitor known endpoints well, but undiscovered services still carry live access paths, stale credentials, and undocumented business logic. In practice, that means access reviews, policy enforcement, and incident triage all start from an incomplete asset list.

Q: Why do live API inventories matter more than documented API inventories?

A: Because documented inventories describe intent, while live inventories show what is actually reachable and in use. In cloud and Kubernetes, that difference determines whether security teams can see east-west traffic, detect authZ drift, and identify exposed data paths before attackers or auditors do.

Q: How can security teams tell whether API discovery is actually working?

A: API discovery is working when newly created or changed endpoints appear quickly in the inventory, each has an accountable owner, and sensitive-data handling is visible in the same record. A healthy programme also shows that posture checks, encryption reviews, and access controls are triggered from the inventory rather than applied after incidents or audits.

Q: Should organisations replace API management with runtime API discovery?

A: No. API management and runtime discovery solve different problems. Management governs publishing, versioning, and lifecycle, while discovery validates what is live, reachable, and exposed. The mature model is to keep both, then use discovery to test whether the management catalog still matches reality.

Technical breakdown

Why static API inventories fail in multi-cloud and Kubernetes

Static inventories fail because they describe intent, not runtime reality. In modern cloud and Kubernetes platforms, endpoints can appear, change, or disappear faster than documentation, ingress rules, and developer portals are updated. That creates blind spots around shadow APIs, zombie APIs, and bypass paths that never pass through the managed gateway. The core security problem is not just missing visibility, but missing correlation between what is deployed, what is reachable, and what is actually receiving traffic.

Practical implication: Treat runtime traffic as the source of truth for API visibility, not the catalog or spec alone.

How correlated discovery builds a live control plane

Correlated discovery combines traffic analysis, eBPF telemetry, service mesh signals, spec analysis, and CI/CD scanning into one inventory. Each source closes a different blind spot: traffic shows real reachability, eBPF shows workload behaviour, mesh data adds service identity, and CI/CD reveals what was introduced before runtime. The value is not any single sensor but the ability to deduplicate endpoints, classify exposure, and keep the inventory current as the platform shifts.

Practical implication: Normalize multiple discovery sources into one inventory so security policy follows live exposure instead of stale records.

Why identity context is central to API discovery

API discovery is also an identity problem because APIs are accessed by users, workloads, service accounts, and tokens, each with different authorization risk. Without tying endpoints to workload identity, token type, and effective permissions, teams cannot distinguish intended access from authZ drift or service-to-service abuse. That makes identity context essential for Zero Trust enforcement, because the policy decision depends on who or what is calling the API and whether that access still fits the intended trust boundary.

Practical implication: Link API endpoints to workload identity and authorization data so least-privilege controls can be enforced continuously.

Threat narrative

Attacker objective: Exploit unmanaged or stale API exposure to reach sensitive services and data without triggering the controls built around documented state.

1. Entry occurs through APIs that are reachable in practice but absent from managed inventories, including shadow and zombie endpoints.
2. Credential and authorization abuse follow when service-to-service traffic, tokens, or workload identities have broader access than the security team can observe.
3. Impact is exposed data paths, runtime abuse, and delayed response because ownership and runbooks are missing when the live surface is not known.

Breaches seen in the wild

• Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
• TeamTNT worm 2020: A TeamTNT cryptomining worm spread through exposed Docker APIs and stole AWS credential files from every host it infected, Cado Security found.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API discovery is now a governance control, not just an observability feature. The article correctly frames live visibility as the prerequisite for Zero Trust because policy cannot be effective without a current map of endpoints, consumers, and data paths. That is especially true in cloud and Kubernetes environments where runtime reality diverges from documentation almost immediately. Practitioners should treat discovery as a first-class control plane for access governance.

Shadow APIs create an identity blind spot as much as an application blind spot. When a service account, token, or workload identity can reach an endpoint that the security team never inventoried, authorization is already outside governance. This is where API discovery intersects directly with IAM and NHI management: the endpoint may be technical debt, but the access path is an identity problem. Practitioners should bind live endpoints to accountable identities before they attempt policy enforcement.

Runtime truth is the only defensible basis for API Zero Trust. Static scanners and specs-only tooling can support hygiene, but they cannot prove what is reachable, who is calling it, or whether east-west abuse is happening. The named concept here is runtime API drift: the growing gap between declared and live API exposure. Practitioners should measure and reduce that drift continuously, not review it after an incident.

Consolidation makes sense only when discovery, posture, and runtime enforcement stay coupled. The article's emphasis on unified control planes reflects a broader market direction toward reducing tool sprawl and operational noise. That consolidation is useful only if it preserves evidence, ownership, and policy execution across cloud and Kubernetes. Practitioners should avoid treating discovery as a reporting layer detached from enforcement.

Audit readiness depends on controlled exposure, not just framework mapping. Mapping controls across many frameworks matters less if the inventory behind the evidence is stale. The deeper governance lesson is that continuous discovery is what makes compliance claims credible in fast-changing environments. Practitioners should prioritise evidence tied to live traffic over evidence tied to static design documents.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Runtime API drift: the gap between declared APIs and live endpoints is now the core control problem in cloud Zero Trust. Teams that still depend on gateway inventories or static scans will keep missing east-west exposure, so discovery has to become continuous and correlated.

API security and IAM now overlap at the point where workload identity, service accounts, and tokens govern reachability. That means API discovery should feed entitlement decisions, not just asset registers, and it should do so before teams try to harden rate limits or schema controls.

Practical programmes should measure whether discovery can explain every live endpoint, every owner, and every exposure path. If it cannot, Zero Trust is being applied to a partial map, which is a governance failure rather than a tooling gap.

For practitioners

• Implement continuous runtime API discovery Correlate traffic, eBPF, service mesh, spec, and CI/CD signals into one live inventory so your control state reflects what is actually reachable.
• Classify every live API by exposure and sensitivity Tag north-south versus east-west reachability, data sensitivity, business criticality, and owner so risk ranking becomes deterministic instead of ad hoc.
• Tie API endpoints to workload identity and authorization Record service accounts, token type, mTLS usage, and effective permissions for each endpoint so least privilege can be validated against live traffic.
• Retire zombie and orphan APIs through ownership workflow Use inventory records to route deprecated endpoints to an accountable team, then close routes, update runbooks, and preserve audit evidence.
• Validate Zero Trust policy against runtime abuse patterns Use live request behavior and anomaly signals to test whether blocking, rate controls, and schema rules still match current exposure.

Key takeaways

• API discovery is the control that turns Zero Trust from a policy ambition into something enforceable across cloud and Kubernetes.
• Live visibility matters because static inventories cannot keep pace with shadow APIs, zombie APIs, and east-west traffic patterns.
• The operational shift is toward correlated discovery, ownership routing, and runtime enforcement tied to actual exposure.

Key terms

• API Discovery: API discovery is the process of finding and cataloging APIs across an environment so security teams know what exists, what data it exposes, and how it behaves. It is essential because shadow, zombie, unmanaged, and third party APIs are frequent blind spots that attackers can exploit without being noticed.
• 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.
• API Runtime Drift: API runtime drift is the gradual mismatch between how an API is expected to behave and how it actually behaves in production. It occurs when schemas, authentication rules, permissions, payload formats, or downstream dependencies change over time without coordinated updates, creating hidden failures, security gaps, and integration instability.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and the access models that underpin modern identity control. It helps practitioners align identity governance with cloud and API security programmes that need stronger runtime visibility.