The Runtime Security Cost Curve

Runtime security has traditionally been built around a simple proposition: If you want visibility, you need to observe the workload.

As cloud infrastructure expanded, that proposition became: If you want comprehensive protection, you need to continuously observe more workloads.

The amount of infrastructure requiring protection is increasing. And the amount of data generated by that infrastructure is increasing with it.

The industry has responded with increasingly sophisticated CNAPP, CDR, EDR and runtime-security platforms. But there is an economic question underneath the entire category: Does runtime security have to become more expensive as infrastructure becomes larger?

The answer may depend on how security itself is architected.

The numbers: runtime security already has a measurable infrastructure price

The economics of runtime security are not hypothetical. Public pricing from major vendors provides a useful view of how security consumption is currently commercialized.

Sysdig's public pricing states that CNAPP licensing is based on the number of hosts in the environment. Its platform covers cloud, containers, Kubernetes, hosts and serverless workloads. Its current AWS Marketplace listing provides unusually detailed public pricing.

The marketplace listing explicitly states that public purchases require a minimum of 20 units for the two base products and that additional usage is billed separately.

At the minimum public commitment, the base contract therefore represents $17,280/year ($1,440/month) for CNAPP Enterprise, and $8,640/year ($720/month) for Monitor Enterprise.

These figures should not be interpreted as an apples-to-apples quote for a specific customer deployment—the contract unit and host-hour overage mechanics matter—but they demonstrate something important: Runtime security is already a material recurring infrastructure expenditure. And the cost can have additional usage dimensions.

Prisma Cloud demonstrates a different version of the same model

Palo Alto Networks uses a credit-based model for Prisma Cloud runtime protection. Its current documentation states that Prisma Cloud Compute licensing is based on credits consumed by protected resources.

Importantly, Palo Alto's documentation states that a container host consumes 7 credits whether it runs one container or one hundred containers under the relevant Defender model. There is also public AWS Marketplace pricing for Prisma Cloud Enterprise: 100 Enterprise units — $18,000/year (approx. $15 per unit/month).

Again, this is not a direct runtime-security-only price comparison; Prisma Cloud is a broader CNAPP. But it establishes an important market fact: Major cloud-security platforms already monetize protection according to the quantity and type of infrastructure being protected.

The cost isn't only the license

The more interesting number isn't necessarily the SaaS subscription. It is the compute consumed by the security system itself. Palo Alto's Prisma Cloud documentation provides concrete resource requirements. Each Defender requires 256 MB RAM and 8 GB host storage. The documented typical load is approximately 1–5% CPU and 30–70 MB RAM.

That is not an assertion that the entire 30–70 GB is permanently unavailable to workloads. But it illustrates the scale of the problem. Security infrastructure is infrastructure.

Sysdig demonstrates the same engineering tradeoff

Sysdig's documentation similarly exposes the resource mechanics of its runtime agent. Its Universal eBPF driver has a documented event-buffer memory footprint of 8 MiB × number of CPU cores / 2, while its legacy eBPF driver uses 8 MiB per CPU core.

Sysdig also explicitly documents that its agent can consume additional memory for queued messages. This is not a criticism of Sysdig. In fact, it demonstrates the engineering reality faced by every runtime-security vendor: Observability has a resource footprint. The industry is already optimizing that footprint.

The industry is already moving toward lower-overhead instrumentation

This is where eBPF becomes important. USENIX research describes the traditional tradeoff between user-space agents and kernel-level instrumentation: user-space agents can consume CPU, memory and network resources, while repeated kernel/user-space interactions can introduce overhead. eBPF provides a mechanism for executing instrumentation within the kernel while retaining programmability and verification.

The next optimization is not necessarily better instrumentation

If eBPF makes observation more efficient, the next question is: Do we still need to observe everything continuously?

Suppose a Kubernetes cluster has 100 nodes, 2,000 containers, 50,000 processes, and millions of runtime events.

A conventional philosophy can be summarized as: Capture as much relevant activity as possible and continuously analyze it.

The alternative is: Maintain defensive coverage while dynamically allocating inspection where risk justifies it. This is the conceptual foundation of Opsonance's stochastic patrol model.

Security density

Opsonance introduces a different concept: Security density. Security density describes how much defensive computation is allocated to a particular part of the environment.

The objective is not to eliminate observation. It is to make observation risk-sensitive. That distinction is central.

This could change the cost equation

The traditional security relationship can be approximated as:
Security cost ∝ infrastructure × observation density

If infrastructure grows and observation density remains approximately constant, security expenditure tends to grow with it. An adaptive model attempts to create:
Security cost ∝ infrastructure × risk-adjusted observation density

If security resources are dynamically allocated, the system does not necessarily have to treat every workload as equally expensive to protect.

There is already evidence that cloud organizations care about this problem

This isn't a security-vendor-created concern. The broader cloud industry is already treating infrastructure efficiency as a first-class engineering discipline. The FinOps Foundation's 2025 State of FinOps report surveyed organizations collectively responsible for approximately $69 billion in public-cloud spend.

• 63% of respondents now manage AI spending, up from 31% the previous year.
• 31% of respondents work in organizations spending more than $50 million/year on public cloud.

Security teams are increasingly being asked to protect infrastructure that finance and engineering teams are simultaneously being asked to optimize.

Kubernetes makes this particularly important

The CNCF's 2026 Annual Cloud Native Survey reports that 82% of container users run Kubernetes in production (up from 66% in 2023). Furthermore, 66% of organizations hosting generative-AI models use Kubernetes for some or all inference workloads.

More Kubernetes + More cloud spend + More security requirements = Increasing pressure to make security resource-efficient.

The attacker creates another problem: predictability

Cost isn't the only reason to rethink continuous observation. A persistent security architecture creates a relatively stable observation surface. An autonomous attacking system can potentially learn what is monitored, which actions trigger controls, and how response mechanisms behave.

The defensive problem therefore becomes: Can the defender remain difficult to model?

Unpredictability becomes a security primitive

Opsonance's stochastic patrol model is built around this principle. Instead of assuming that every defensive observation must happen continuously and predictably, inspection can be distributed dynamically.

Randomness by itself is not security. The value comes from combining unpredictable inspection, kernel-level telemetry, local decision-making, risk-aware prioritization, and runtime intervention.

The economic advantage and the security advantage can reinforce each other

This produces an unusual alignment: The mechanism intended to reduce security cost can potentially also introduce defensive uncertainty. That is a much stronger proposition than simply saying, "We use fewer resources."

The real metric should be security efficiency

Instead of asking "How much telemetry does this product collect?", the customer could ask: "How much security does this product deliver for every unit of infrastructure it consumes?"

• Security value / CPU
• Security value / GB RAM
• Security value / telemetry volume
• Security value / dollar

What happens to pricing?

Adaptive runtime security could introduce another philosophy: Pay for defensive capability, not simply defensive footprint.

Instead of asking how many hosts you have, the commercial question could become: What level of adaptive protection do you require? This could lead to pricing around protection tier, risk surface, response capability, or inspection capacity.

What Opsonance would need to prove

This is where the thesis becomes scientifically testable. Opsonance should define measurable experiments:

• Benchmark 1 — Security resource overhead: Measure CPU, RAM, network bandwidth, kernel overhead, and storage consumption.
• Benchmark 2 — Security economics: Measure security cost per protected node, per workload, per detected attack.
• Benchmark 3 — Detection and interdiction: Measure the time from Attack initiation → observation → decision → interdiction.
• Benchmark 4 — Adaptive coverage: Measure how security resources change when risk changes.
• Benchmark 5 — Adversarial predictability: Measure whether an attacker can learn and reproduce the defensive observation pattern.

The industry could move from "more coverage" to "more efficient coverage"

AI could accelerate this transition

Automated attacks are pushing defenders toward machine-speed security economics. Sysdig announced its Secure AI offering in August 2026, stating that the system can perform more than 10 times as many investigations at 88% lower cost in its described workload. The next stage may be: AI attacks → AI-assisted detection → AI-assisted response → adaptive security allocation.

The potential industry shift

If adaptive runtime security works at scale, the category could evolve through three stages:

• Stage I — Agent-centric security: Scale the agent footprint with infrastructure.
• Stage II — Kernel-centric security: Move instrumentation closer to the kernel using eBPF. (Currently underway)
• Stage III — Intelligence-centric security: Ask what, when, and how deeply things should be inspected. The agent becomes the mechanism; the intelligence becomes the product.

Opsonance Point of View

Opsonance believes runtime security is approaching an architectural transition. A production environment does not assign equal compute to every workload. It schedules resources according to demand. Security can apply the same principle.

Opsonance therefore treats runtime defense as an adaptive control problem: observe → assess → allocate → patrol → interdict.

If Opsonance can eventually demonstrate that adaptive patrol can reduce security overhead while preserving or improving detection and interdiction performance, it challenges an assumption embedded in the economics of runtime security: That security coverage must scale proportionally with the infrastructure being protected.

The alternative is a different model: Security should scale with risk, not simply with infrastructure.

---

Evidence base

• Current public pricing: Sysdig pricing and AWS Marketplace; Prisma Cloud licensing and AWS Marketplace; Wiz pricing; CrowdStrike Cloud Security pricing.
• Infrastructure and market evidence: CNCF 2026 Annual Cloud Native Survey; FinOps Foundation State of FinOps 2025; CNCF Kubernetes FinOps Microsurvey; USENIX — eBPF and the Systems Trilemma; Sysdig Agent Driver Documentation; Prisma Cloud Defender Requirements; Sysdig Secure AI announcement.