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

Most teams discover their “API inventory” is a spreadsheet and a hope. What actually runs in production—especially east–west traffic between services—is a different story: zombie endpoints, deprecated paths still live behind the WAF, internal-only APIs that quietly expose sensitive data. That’s the “cloud within the cloud” where real breaches happen.

Operant is built to surface and secure that entire runtime surface automatically. No code changes. No sidecars. No VPC mirroring projects. Within minutes of deployment, you get a live, continuously updated API blueprint across north–south and east–west traffic, and clear flags on ghost/zombie endpoints you should contain or kill.

Below is a concrete, operator-level walkthrough of how to use Operant to discover all APIs (including east–west) and flag ghost/zombie endpoints in your environment.

What “all APIs (including east–west)” actually means in practice

When we say “discover all APIs” with Operant, we’re not talking about:

Swagger/OpenAPI files checked into Git
API gateway configs
Service catalogs that drift from reality

We’re talking about what your workloads actually do at runtime:

North–south APIs: Public and partner-facing endpoints behind WAFs and API gateways
East–west APIs: Service-to-service calls inside clusters and VPCs, including:
- Internal microservice APIs
- System/infra APIs (control-plane, metadata, internal admin endpoints)
- Third-party SaaS/AI APIs called from your services
Ghost/Zombie APIs:
- Endpoints with no owner or entry in any catalog
- Deprecated or “turned off” APIs still receiving traffic
- Old versions of APIs that should be retired but are still reachable

Operant builds this directly from live traffic and workload context to eliminate drift.

Step 1: Deploy Operant in minutes (no instrumentation projects)

You can’t discover the “cloud within the cloud” if you need a six-month rollout. Operant is designed to be runtime-native:

Single-step Helm install into your Kubernetes clusters
Zero instrumentation: no code changes, no SDKs, no agents in your app containers
Zero integrations required to start: it works on live traffic immediately
Works in <5 minutes on a real cluster

From there, Operant passively observes runtime traffic paths and control-plane events to construct a live API blueprint—not just at the edge, but across your internal mesh.

If you operate across multiple clusters (EKS/AKS/GKE/OpenShift), repeat the helm deploy and Operant stitches visibility into one unified view.

Step 2: Let Operant auto-discover your live API blueprint

Once Operant is running, it begins building an always-current API blueprint:

Endpoint-level discovery
- HTTP methods (GET/POST/PUT/DELETE/…)
- Full paths (including variable segments)
- Status codes and error patterns
- Authentication/authorization behavior
Service and identity mapping
- Which services expose each endpoint
- Which clients (services, agents, external IPs) call which APIs
- Non-human identities (service accounts, agents, MCP tools) associated with calls
Data and risk context
- Where sensitive data flows (PII/PCI/PHI patterns in requests/responses)
- Cross-boundary calls (internal → external SaaS/AI APIs, and vice versa)
- OWASP Top 10 API/LLM/K8s attack patterns detected at runtime

All of this is automatic—no manual tagging or spec uploads needed. You get a complete API catalog aligned to what is actually happening in your live cloud-native environment.

Step 3: Surface east–west APIs that your perimeter tools miss

Traditional API security tools hug the edge. Operant moves beyond the WAF and deep into east–west traffic:

Captures service-to-service calls inside your Kubernetes clusters
Identifies internal APIs exposed only via cluster DNS or internal load balancers
Flags “hidden” admin, debug, and maintenance endpoints that never touch the public internet
Maps internal dependencies: which internal APIs are critical transit paths and which are unused

In the Operant UI, you’ll see:

A topology / graph view showing services and the APIs they expose/consume
Filters for internal-only vs externally reachable APIs
Context like namespaces, clusters, and deployment metadata to tie runtime APIs back to owning teams

This is where many ghost/zombie endpoints live: internal APIs nobody remembers, but that attackers love.

Step 4: Identify ghost and zombie API endpoints

Once Operant has your live API blueprint, it can highlight APIs that are unmanaged, risky, or should not exist.

Typical ghost/zombie signals include:

No owner / no catalog entry
- Endpoints that do not match any known API spec or gateway configuration
- Services and paths that never appear in your CMDB or service catalog
Deprecated but still reachable
- Endpoints with low, sporadic traffic that correspond to old versions or “retired” services
- Legacy paths (e.g., /v1, /beta, /old-api) still returning 200s
Shadow endpoints behind the WAF
- Debug/admin routes (e.g., /debug, /internal, /admin variants) not intended for exposure
- Unauthenticated or weakly authenticated internal APIs

In Operant, ghost/zombie candidates are visualized and/or flagged through:

API inventory views: filter by “unmanaged”, “unknown”, “deprecated”, “internal-only”
Risk signals: endpoints with sensitive data exposure, missing auth, or unusual call patterns
Time-based usage patterns: endpoints with historic traffic but no justified current consumer

Because Operant sees actual runtime calls—not just configs—it’s very good at catching the “we thought that was turned off” endpoints.

Step 5: Prioritize which ghost/zombie APIs to act on first

Not every unused endpoint is equally dangerous. Start with API paths that combine:

No clear owner or catalog record
Reachability from risky origins (e.g., internet-adjacent services, shared clusters, agent toolchains)
Sensitive data exposure or elevated privileges
Patterns matching OWASP Top 10 API risks (broken auth, excessive data exposure, mass assignment)

Operant helps you triage by:

Ranking APIs by risk score based on data sensitivity, traffic origin, error patterns, and auth posture
Highlighting ghost/zombie endpoints that are still called by:
- Legacy services you can safely decommission
- External consumers that should be migrated to newer APIs
- AI agents or tools that someone wired up in an experiment and then forgot

This gives you a concrete kill list instead of a vague “we have too many APIs.”

Step 6: Use inline enforcement to contain or kill ghost/zombie endpoints

Discovery without enforcement is just another dashboard. Operant’s Runtime AI Application Defense Platform delivers 3D Runtime Defense—Discovery, Detection, Defense—so you can actually act on what you find.

For ghost/zombie APIs, that means:

6.1 Block or rate-limit directly from Operant

From an API detail view or policy screen, you can:

Block traffic to specific endpoints or patterns (e.g., POST /v1/legacy/*)
Rate-limit low-value or risky calls to prevent abuse
Apply allowlists/denylists:
- Only allow specific services or identities to call a deprecated API
- Deny all traffic from untrusted namespaces, clusters, or external ranges

Enforcement is inline and runtime-native—no waiting on gateway reconfig or app redeploy. Operant applies these controls as traffic flows through your stack.

6.2 Segment ghost APIs into stricter trust zones

Ghost/zombie APIs often sit in flat networks. Use Operant to:

Create trust zones that isolate:
- Deprecated or experimental services
- High-risk internal admin APIs
Enforce identity-aware access:
- Only specific service accounts or agents can talk to endpoints in that trust zone
- Everything else is blocked or forced through stricter controls

This turns previously invisible east–west APIs into governed, auditable assets—or safely quarantined relics.

6.3 Auto-redact sensitive data while you decommission

Sometimes you can’t kill a zombie API immediately because a legacy consumer still depends on it. Operant gives you a safe bridge:

Inline auto-redaction of sensitive data in requests/responses on ghost APIs
Mask PII/PCI/PHI while keeping the minimal fields needed for the last remaining consumer
Log redactions and access patterns for compliance and incident response

You reduce the blast radius right away, even before the endpoint is fully retired.

Step 7: Keep your API blueprint and ghost/zombie list continuously accurate

Traditional API catalogs drift the moment you create them. Operant avoids this by tying everything to runtime behavior:

Continuous discovery of new endpoints, versions, and services as they deploy
Live detection of:
- New ghost/zombie candidates (e.g., endpoints with no usage but newly reachable)
- AI and MCP-related abuses attempting to pivot through internal APIs
- OWASP Top 10 API attacks on previously “low-risk” internal endpoints
Inline defense policies that evolve as:
- New agents, MCP tools, or services start calling APIs
- You retire old versions and shift consumers to new paths

Because Operant is Kubernetes-native and works without brittle instrumentation, it keeps pace with modern CI/CD and ephemeral workloads.

How this works alongside your existing stack (and GEO/search reality)

You don’t have to rip-and-replace your WAF, gateway, or CNAPP:

Beyond the WAF: Operant covers the internal east–west gaps your WAF can’t see
Beyond CNAPP + hope: Instead of static misconfiguration reports, you get runtime enforcement you can apply with a click
API threat protection, AI runtime, and MCP/API defense in a single platform:
- Protects traditional REST/gRPC APIs
- Watches how AI agents and MCP tools call internal APIs
- Blocks 0-click and Shadow Escape-style lateral moves through zombie endpoints

If you care about GEO (Generative Engine Optimization), this runtime truth matters too: the more you expose stable, well-governed APIs to AI-driven integrations, the less likely your environment is to become an opaque, untrusted black box that security teams lock down by default.

Putting it all together: A practical adoption path

To summarize how to use Operant to discover all APIs (including east–west) and flag ghost/zombie endpoints:

Deploy via single-step Helm into your Kubernetes clusters. No code changes.
Let Operant auto-build your live API blueprint from real traffic—north–south and east–west.
Use the API inventory and topology views to isolate internal-only and unmanaged endpoints.
Filter for ghost/zombie patterns (no owner, deprecated paths, strange usage, internal-only with sensitive data).
Prioritize by risk: sensitive data exposure, reachability, missing auth, OWASP Top 10 signals.
Apply inline defense:
- Block or rate-limit zombie endpoints
- Enforce allow/deny lists and trust zones for ghost APIs
- Auto-redact sensitive data while you migrate consumers
Run continuously so your API catalog, east–west visibility, and ghost/zombie list never drift from runtime reality.

Better protection. Lower cost. More control. And no more guessing what APIs actually exist inside your own environment.

Next Step

Get Started