How do we use Operant to discover all APIs (including east–west) and flag ghost/zombie endpoints?

Most teams think they have an API inventory. What they really have is a static list of north–south gateways and a handful of OpenAPI specs that are already stale. The real attack surface lives in the “cloud within the cloud”: internal east–west APIs, service-to-service calls, and the ghost/zombie endpoints nobody owns anymore—but are still reachable.

Operant is designed to solve exactly this problem at runtime. You don’t wire up exporters or ship logs into yet another dashboard. You drop Operant into your Kubernetes fabric, let it watch live traffic for a few minutes, and it builds a living API blueprint—then lets you flag and contain ghost and zombie endpoints inline.

Below is how to use Operant step by step to:

Discover all APIs (north–south and east–west) with zero instrumentation
Automatically identify unmanaged, ghost, and zombie endpoints
Enforce runtime policies to block or contain abuse on those APIs

Why runtime API discovery has to be different

In fast-moving Kubernetes environments, traditional API catalogs break for three reasons:

Static inputs. Specs, annotations, and CMDBs lag reality. Pods churn; services get renamed; old paths linger.
Perimeter bias. Legacy tools sit at the edge and see north–south traffic only. East–west and intra-cluster calls are invisible.
No enforcement. Even when you know an endpoint is risky, you’re left with a backlog of tickets—not a way to block bad calls today.

Operant’s Runtime AI Application Defense Platform attacks this differently:

Single-step helm install. Zero instrumentation. Zero integrations. Works in <5 minutes.
Inline position in your runtime path, so it sees every call, including east–west and intra-cluster service traffic.
3D Runtime Defense (Discovery, Detection, Defense): one system that continuously discovers APIs, detects risky behavior, and blocks attacks or shuts off endpoints in real time.

Everything below assumes you’ve already decided to secure the “cloud within the cloud,” not just your edge gateways.

Step 1: Deploy Operant into your cluster

You start by putting Operant where the real application traffic lives: in your Kubernetes runtime.

Install via Helm

helm repo add operant https://charts.operant.ai
helm repo update

helm install operant operant/operant-platform \
  --namespace operant-system \
  --create-namespace

No code changes, no sidecars, no app restarts

Operant attaches at the runtime fabric—not in your app code. That’s how you avoid six‑month “instrumentation projects” and still see:
- North–south traffic through ingress/controllers
- East–west service-to-service traffic inside the cluster
- Calls to and from 3rd‑party APIs
Wait a few minutes for live data

Within minutes, Operant starts building a live API blueprint based on real traffic, not guesses. This is your foundation for discovering ghost/zombie APIs.

Step 2: Use Operant’s live API blueprint to discover all APIs

Once deployed, Operant continuously builds and updates a full map of your APIs and their relationships.

What the live API blueprint gives you

Complete endpoint inventory
Every observed HTTP(S)/gRPC path, method, and host—across internal meshes, gateways, and services.
Topology across the “cloud within the cloud”
How services, APIs, identities, and external dependencies connect—beyond the WAF, inside your application perimeter.
Context you can act on
For each API, Operant tracks:
- Service / namespace / cluster
- Auth patterns (tokens, keys, OIDC, mTLS)
- Callers (other services, agents, external consumers)
- Data classes flowing through (PII, secrets, regulated fields)
- Usage frequency and recency

This blueprint is continuously updated. No manual catalogs. No spreadsheets. No integration projects.

Step 3: Discover east–west APIs that perimeter tools miss

Most of the “unknown unknowns” live in east–west traffic: internal services, legacy microservices, and back-office apps talking to each other.

Operant surfaces them automatically because it sits in the runtime path, not just on the edge.

How Operant finds east–west APIs

Captures intra-cluster traffic between pods and services, including:
- Internal REST/gRPC APIs
- Service mesh control/data plane calls
- Internal callbacks, webhooks, and background jobs
Groups APIs by service and identity so you can see:
- Which internal services expose which endpoints
- Which callers (services, agents, MCP tools) hit them
- Which APIs are reachable from outside vs internal-only
Highlights risky internal APIs:
- Authentication or authorization skipped because “it’s internal”
- Sensitive data exposed in responses or logs
- Legacy endpoints still reachable but no longer “officially supported”

The result is a single runtime view where east–west APIs are first-class citizens, not blind spots.

Step 4: Enable ghost and zombie API detection

Once Operant has a few days of baseline traffic, it’s straightforward to identify:

Ghost APIs: Endpoints that exist and may be reachable, but have no clear ownership, spec, or registration.
Zombie APIs: Old or deprecated endpoints that still respond to requests—often with sensitive data—but shouldn’t be used.

Operant uses runtime and control-plane signals to flag these automatically.

How Operant flags ghost endpoints

Ghost endpoints typically have these traits:

Operant sees live traffic to the path, but:
- No associated OpenAPI / spec in your repos (when optionally connected)
- No registration in your API gateway / service registry, or
- No tagged ownership (team, app) in your metadata

Operant’s API blueprint surfaces them as:

“Unmanaged” or “Unregistered” APIs
APIs with unknown owner or non-mapped service label

From there, you can:

Filter the blueprint for unmanaged / unowned endpoints
Drill into who is calling them and what data they expose
Attach tags or ownership once confirmed—or move straight to containment

How Operant flags zombie endpoints

Zombie endpoints are detected from behavioral and lifecycle signals:

Historically high usage, now near-zero—but still reachable
Marked deprecated in code/spec, yet still see occasional calls
Belong to services that are “retired” but still running in forgotten namespaces or clusters

Operant surfaces these as:

“Stale but live” APIs with:
- Long periods of inactivity followed by sporadic calls
- Correlation to deprecated versions or legacy services
Endpoints on services with no active deployment pipeline
(e.g., images not updated in months, labels indicating previous-gen apps)

You can use filters like:

Last seen > 30 days ago AND Endpoint still responds 2xx/3xx
Deployment age > 6 months AND API hit count < threshold

to build an explicit view of your zombie API surface.

Step 5: Prioritize ghost/zombie APIs by risk

Not every ghost endpoint is a crisis. You prioritize based on what can actually hurt you.

Operant’s runtime context lets you score ghost and zombie APIs by:

Exposure
- Reachable from the public internet vs internal-only
- Accessible by untrusted identities / broad API keys
- Used by 3rd‑party SaaS, agents, or MCP tools
Data sensitivity
- Presence of PII, secrets, tokens, financial or health data
- Response payload size and structure (bulk data vs lookup)
Business logic
- High-value actions: auth flows, payments, data exports, admin operations
- APIs that mutate critical state vs simple reads
Known attack patterns
- Matches against OWASP Top 10 API attacks
- Anomalous usage spikes, unusual calling identities, 0-click style behaviors

From a single interface, you can sort ghost and zombie endpoints by this composite risk and focus on the ones that must be contained first.

Step 6: Contain ghost and zombie endpoints with runtime policies

Discovery and flags are only the first two “D’s.” Operant’s value is the third: Defense—actually changing what happens at runtime.

For any ghost or zombie API you’ve identified, you can enforce:

1. Inline blocking

Shut down an endpoint in production without touching app code:

Deny specific paths (e.g., /v1/export, /legacy/*)
Block by method (e.g., DELETE or POST on legacy endpoints)
Block by caller (specific client IDs, IP ranges, service accounts)

Operant applies these at runtime, so even if the service is still listening on that port, the dangerous paths are effectively dead.

2. Tighten trust zones and allowlists

For APIs you can’t fully decommission yet:

Restrict access to specific services or namespaces
Build trust zones where only designated internal callers can reach the endpoint
Enforce allowlists/denylists for identities, keys, or agent toolchains

This is especially useful for east–west zombies that still support a single legacy integration.

3. Rate limiting and anomaly-based throttling

For ghost endpoints that occasionally see weird spikes:

Apply global or per-identity rate limits
Configure anomaly triggers (e.g., sudden burst from a new identity) that:
- Auto‑throttle suspicious call patterns
- Alert your team, while keeping the endpoint usable for known callers

4. Inline auto-redaction of sensitive data

If you can’t refactor or shut down a risky ghost API immediately, Operant can:

Inspect responses in real time
Auto‑redact sensitive fields (PII, secrets, tokens) before they leave your runtime
Log redacted events for auditing and compliance

This turns a high‑risk zombie into a much lower‑risk temporary dependency while you work the backlog.

Step 7: Keep the API blueprint clean over time

The only way to avoid re‑accumulating ghost and zombie APIs is to keep the runtime catalog as your source of truth.

With Operant in place:

Continuous discovery ensures every new service/endpoint appears in the blueprint within minutes of first traffic.
Policy-as-guardrail means:
- New APIs must land in a defined trust zone
- Unowned or unmanaged endpoints trigger alerts or are blocked by default
- Deprecation policies can be enforced based on “last seen” dates
Inline CADR (Continuous, Adaptive, Dynamic Response) lets you:
- Automatically quarantine new unknown endpoints
- Require explicit promotion from “unknown” to “trusted” before they’re widely reachable
- Keep your runtime state aligned with your intended architecture—no drift

This is how you avoid API sprawl turning into an attack surface again.

How this compares to legacy approaches

If you’ve tried to chase ghost/zombie APIs with other tools, you’ve probably run into one or more of:

CNAPP + hope: great at infrastructure posture, weak at live API behavior and inline controls.
WAF-only: sees the edge, not the east–west nervous system where most shadow endpoints live.
Manual catalogs and ticket queues: inherently out of date; cannot block attacks in real time.

Operant’s difference is simple:

3D Runtime Defense that unifies discovery, detection, and defense
Runtime-native position that sees every API—north–south and east–west
Inline enforcement that actually blocks, redacts, and rate-limits ghost and zombie endpoints in minutes, not quarters

You get better protection, lower operational cost, and far more control over your live API surface.

Final verdict

To genuinely discover all APIs—including the messy east–west ones—and put real pressure on ghost and zombie endpoints, you need runtime-native visibility and enforcement.

Using Operant, the path looks like this:

Drop it into your cluster with a single-step helm install—no code changes.
Let it build a live API blueprint from real traffic, across internal and external paths.
Use that blueprint to automatically flag ghost and zombie endpoints based on ownership, usage, and lifecycle signals.
Contain those endpoints with inline blocking, trust zones, rate limiting, and auto-redaction.
Keep your API surface clean over time with continuous discovery and adaptive runtime policies.

You stop hoping your API list is accurate and start enforcing what can actually run in your “cloud within the cloud.”

Next Step

Get Started