Our CNAPP shows posture issues, but we need something that can actually stop runtime attacks—what approaches exist?

Most teams I talk to are hitting the same wall: the CNAPP is full of “critical” posture issues, but the breach stories you lose sleep over are runtime attacks that slip right past clean dashboards. You don’t get breached by a misconfigured S3 bucket you fixed last quarter; you get breached by live traffic flowing across APIs, services, and (now) AI agents in authenticated sessions.

If your question is “our CNAPP shows posture issues, but we need something that can actually stop runtime attacks—what approaches exist?”, the answer is: you need to layer real runtime defense on top of posture management, and you need it where the attacks actually execute—the “cloud within the cloud.”

This guide breaks down the main approaches, their limits, and what a modern runtime AI + cloud defense stack looks like in practice.

Why posture-only CNAPPs don’t stop runtime attacks

CNAPPs were built for configuration and compliance:

Are your clusters following CIS benchmarks?
Are public buckets locked down?
Are images free of known CVEs?
Are security groups too open?

All of that matters. But none of it can block an attack that is already in motion.

Runtime attacks today look like:

Prompt injection and jailbreaks against production LLMs
Tool poisoning in agent workflows (MCP, plugins, internal tools)
Data exfiltration through “legitimate” APIs and agents
Lateral movement across east–west APIs inside the cluster
Abuse of ghost/zombie APIs that no one knows are still live
Zero-day vulns exploited via authenticated sessions

Your CNAPP might tell you an image has a critical CVE or a pod is over-privileged. It cannot:

Intercept a malicious prompt and strip the injection before it hits the model
Stop a rogue agent from reaching a sensitive internal API
Auto-redact PCI or PHI from flowing out in a response
Block an exfiltration flow in real time based on runtime behavior

Configuration is static. Attack paths are dynamic. The gap between the two is where real breaches live.

The main approaches teams try for runtime protection

Most organizations, once they realize CNAPP isn’t enough, end up exploring some combination of:

Perimeter WAF + API gateways
Agent-based workload protection (EPP/EDR for containers, eBPF sensors)
Service mesh + policy engines (Istio, OPA, custom admission controllers)
SIEM / observability + detection rules
Runtime AI Application Defense Platforms (a newer, runtime-native category)

Let’s walk through them in terms of what they can actually stop, and where they fall down.

1. WAF and API gateways: necessary but perimeter-bound

Most stacks already have:

A WAF in front of public endpoints
One or more API gateways fronting external APIs

These are useful for:

Traditional input validation and OWASP Top 10-style perimeter attacks
Basic rate limiting and throttling
IP reputation / geo-blocking
Some auth/authorization checks at the edge

Where they fail for modern runtime attacks:

They see requests, not end-to-end flows
A single prompt injection request looks like any other POST to /chat. The WAF has no visibility into:
- Which model is invoked
- Which internal tools or MCP servers the agent calls
- What data is being pulled or exfiltrated
They are perimeter-only
Once traffic is inside the cluster, moving east–west between services and agents, the WAF is blind. This is exactly where the “cloud within the cloud” exists.
They are signature and rule heavy
Emerging attacks (tool poisoning, 0-click agent exploits, supply-chain abuse of MCP tools) don’t fit simple regex rules.

If your question is “can we just turn up our WAF to block more,” the honest answer is: you can reduce some noise, but you won’t get real runtime blocking across AI agents, MCP, and internal APIs.

2. Agent-based workload protection and eBPF sensors

Next option: drop agents or eBPF-based sensors on nodes and containers. These typically ship process, syscall, and network telemetry to some backend and raise alerts.

They’re useful for:

Detecting suspicious process activity (crypto miners, reverse shells)
Identifying anomalous system calls or kernel-level exploits
Basic behavior analytics at the host level

Where they fall short:

Application semantics are missing
A syscall stream won’t tell you:
- Which LLM model is being called
- Which MCP tool is being invoked
- Whether the outgoing data is sensitive or exfiltrated You get noise without the higher-level context of “who is calling what and why.”
Mostly detection, not enforcement
Many eBPF-based “runtime security” products are essentially observability tools:
- They stream vast amounts of telemetry
- They raise alerts in a console or push to SIEM
- They rarely give you safe, granular primitives to block at application boundaries
Inline control is fragile
Trying to enforce security by killing processes or blocking system calls is brittle in Kubernetes. You break workloads, not specific flows.

These tools are better than nothing, but they rarely satisfy the requirement you stated: “something that can actually stop runtime attacks.”

3. Service mesh + policy engines: powerful, but brittle at scale

Platform teams often look at the service mesh and policy engines they already have:

Istio / Linkerd / Envoy for mTLS and traffic routing
OPA / Gatekeeper / custom admission controllers
Homegrown sidecar patterns for authN/Z and auditing

These help with:

Zero-trust basics (mTLS between services)
Declarative networking policies
Some coarse-grained authorization across services

But teams quickly run into:

Instrumentation projects from hell
Every enforcement point requires:
- Sidecars or proxies injected and carefully maintained
- Application changes to propagate identity and context
- Integration with multiple clusters, namespaces, and workloads
Policy complexity and drift
It’s hard to encode:
- “This MCP tool can only read from these APIs”
- “This agent cannot call that data microservice with this user context” …in static OPA policies that remain correct as services/agents change weekly.
No AI-native semantics
Meshes don’t understand:
- Prompt structures
- LLM inference flows
- MCP registries and tools They operate at L4/L7, not at “agent + tool + model + data” granularity.

Service meshes are essential plumbing, but they are not, by themselves, a runtime AI and application defense layer.

4. SIEM, observability, and “detect-only” approaches

The default enterprise response is often: “pipe everything into the SIEM, write detection rules, let IR handle it.”

That yields:

Better forensic trails after an incident
Correlated alerts across infrastructure and app logs
Some basic anomaly detection

But it doesn’t stop attacks.

In practice:

Attacks like prompt injection or agent tool abuse complete in seconds, not hours.
By the time an alert is triaged in a ticket queue, data is gone.
Most “detections” degrade into noise
High-severity alerts without precise enforcement actions produce:
- Alert fatigue
- Playbooks that are hard to automate safely
- “We’ll fix this in the next sprint” backlog items

If your requirement is “actually stop runtime attacks,” an observability-first approach cannot be the core answer. It can support your runtime defense; it cannot be your runtime defense.

5. Runtime AI Application Defense Platforms (3D Runtime Defense)

The emerging alternative—and the direction we built Operant for—is a Runtime AI Application Defense Platform that delivers 3D Runtime Defense (Discovery, Detection, Defense) across the actual attack surface:

Live cloud-native applications
AI agents and MCP workflows
Internal and external APIs
East–west traffic inside Kubernetes
“Cloud within the cloud” services and identities

Instead of starting with static config or host telemetry, this approach starts with live runtime flows and asks:

Who (user, agent, service identity) is calling what?
Which model or agent is invoked?
Which APIs and data stores are being accessed?
Is this behavior safe in this context?

Then it enforces inline, in real time.

What real runtime defense needs to do (beyond CNAPP)

If you want something that actually stops runtime attacks—not just surfaces posture issues—you need capabilities in three dimensions.

1. Discovery: build a live map of your “cloud within the cloud”

You can’t defend what you don’t see. Runtime defense should automatically discover:

All active APIs
Managed, unmanaged, ghost, zombie endpoints across clusters and namespaces.
All AI agents and workflows
Agents embedded in:
- SaaS tools (support, sales, collaboration)
- Internal dev tools and CI/CD
- Customer-facing applications
MCP servers, clients, and tools
Build a live MCP Catalog:
- Which tools exist
- Who can call them
- What data and APIs they touch
Runtime identities and trust paths
Users → agents → services → data stores
You need the complete path, not just the edge.

This has to come from automatic telemetry, not weeks of manual tagging or code instrumentation. In Operant, this is “single step helm install, zero instrumentation, works in <5 minutes”—the platform starts building your runtime blueprint from actual traffic.

2. Detection: identify real attacks with runtime context

Detections must be more than “a weird syscall happened.”

For modern AI + cloud workloads, you need:

OWASP-aligned detections with application context
Map to OWASP Top 10 for:
- APIs (injection, auth failures, excessive data exposure)
- LLMs (prompt injection, data leakage, model abuse)
- Kubernetes (misconfigurations exploited in runtime)
Agentic and MCP-specific detections
Catch behaviors like:
- 0-click exploitation of an AI agent that auto-executes tools
- Tool poisoning—compromised tools used inside workflows
- “Shadow Escape” patterns where agent tools break intended boundaries
Data-aware detections
See and classify sensitive data:
- PCI, PHI, PII, secrets, model artifacts Spot exfiltration and leakage patterns in real traffic.

Critically, detections need enough context to safely drive automated enforcement, not just send alerts.

3. Defense: enforce inline, without breaking apps

This is the piece most CNAPP and observability tools lack: precise, runtime-native control planes that act on live flows.

Concrete enforcement capabilities should include:

Inline auto-redaction of sensitive data
As data flows through your APIs and AI responses, automatically:
- Detect PCI/PHI/PII or other confidential fields
- Redact or tokenize them inline
  No code changes, no rewrites of application logic.
Flow-based blocking and rate limiting
Policies like:
- “This agent cannot call the customer PII API.”
- “This MCP tool can only read from this subset of resources.”
- “Block all prompts attempting to override safety instructions or exfiltrate secrets.” Enforce by blocking specific flows or rate limiting abuse, not killing pods.
Trust zones and identity-aware access control
Build Adaptive Internal Firewalls:
- Segment internal APIs and services into trust zones
- Allow / deny flows based on identity, tool, or agent
  Example: “Dev environment agents cannot reach prod data APIs, regardless of network reachability.”
Allowlists and denylists for tools, agents, and APIs
Tight control over:
- Which agents can use which MCP tools
- Which APIs are exposed to external or third-party agents
- Which “ghost/zombie” APIs should be blocked entirely

The net effect: when an attack unfolds—prompt injection, data exfiltration, misuse of a tool—the platform blocks or contains it inline, rather than sending a ticket.

How this differs from CNAPP + hope

Putting it in blunt terms:

CNAPP tells you your house has too many unlocked windows.
A Runtime AI Application Defense Platform bars the window when someone is actually trying to climb in.
CNAPP gives you lists of posture issues.
Runtime defense gives you a control plane that enforces safe behavior across APIs, agents, MCP tools, and services.
CNAPP focuses on configuration state.
Runtime defense focuses on live traffic and behavior.

Operant’s own 3D Runtime Defense Suite is an example of this approach. It has already blocked >80% of the OWASP Top Ten attacks across APIs, Kubernetes, and LLMs in customer environments—not by scanning configs, but by acting directly on runtime flows.

Where Operant fits if you already have a CNAPP

If you’re not going to rip out your CNAPP (you shouldn’t), the pragmatic path looks like:

Keep CNAPP for posture and compliance
- CIS / NIST / PCI alignment
- Image scanning and misconfig detection
- Inventory and governance artifacts
Layer Operant for runtime enforcement
- Deploy via single-step Helm in your Kubernetes clusters
- Let it build the runtime blueprint of APIs, agents, MCP toolchains
- Turn on detections mapped to OWASP Top 10 and agentic risks
- Gradually shift from “observe” → “enforce” with:
  - Auto-redaction for sensitive data
  - Trust zones for internal APIs
  - Explicit policies for AI agents and MCP tools
Use runtime signals to prioritize posture fixes
- When Operant blocks exfiltration from a specific service, you now know:
  - Which configs, identities, and images matter most
- Feed that back into your CNAPP backlog so you fix what’s actually on the attack path.

This is how you move from “posture issues on dashboards” to runtime defense that actually stops attacks—without another multi-quarter instrumentation project.

Choosing an approach: questions to ask vendors (including us)

When you evaluate options, including Operant, ask:

Can you block an attack inline without code changes?
- Show me: prompt injection blocked, data exfiltration stopped, or a rogue agent contained.
How fast can we get to first enforcement?
- Is there a single-step install?
- Do we need to modify application code or sidecars everywhere?
- Can you work in <5 minutes on live traffic?
Do you understand AI-specific surfaces—agents, MCP, LLMs?
- Can you build an MCP Catalog/Registry?
- Can you control which agent uses which tool or API?
- Do you recognize and mitigate AI-specific risks (prompt injection, tool poisoning, 0-click workflows)?
Are you more than telemetry?
- What are the concrete enforcement primitives?
- Are they safe to automate in production?

If a runtime “solution” can’t give you confident Yes answers to those, you’re probably looking at another observability dashboard, not a defense layer.

Final verdict: from posture to protection

If your CNAPP is already telling you where your posture is weak, you’re halfway there. But to cover the attacks that matter now—prompt injection, agent abuse, API-level data exfiltration, east–west lateral movement—you need a runtime-native approach that:

Discovers your real “cloud within the cloud” (APIs, agents, MCP, identities)
Detects attacks with full runtime context across those layers
Defends by blocking, redacting, segmenting, and rate-limiting inline

That’s what a Runtime AI Application Defense Platform like Operant is built to deliver: 3D Runtime Defense that actually stops attacks, instead of just surfacing posture issues.

If you want to see what this looks like on your own live traffic—without another instrumentation saga—the next step is simple:

Get Started