The Security Agent's Compute Tax

Security is usually treated as overhead.

CPU. Memory. Network bandwidth. Storage. Telemetry processing. Kernel instrumentation. Log ingestion. Data retention. AI inference. Human investigation.

The individual cost may appear small. But security systems are rarely deployed once. They are deployed:

At scale, a small per-workload cost becomes infrastructure economics. This creates a question security teams rarely ask explicitly:

Security Is Computation

Every security system computes.

• An endpoint agent computes.
• An eBPF program computes.
• A network sensor computes.
• A SIEM computes.
• A detection engine computes.
• An AI security analyst computes.

Even an alert that is never investigated consumed resources to produce. The security stack therefore has its own infrastructure footprint.

Security is not outside the infrastructure economy. It is part of it.

The Invisible Tax

Imagine a cluster with 1,000 workloads. Suppose a security component consumes only a modest amount of additional CPU and memory per workload.

The same applies to telemetry, network traffic, storage, security analytics, log retention, and AI analysis. Security cost scales with deployment footprint.

The Security Compute Tax

This suggests a useful concept:

It should not be interpreted as a universal accounting metric. It is a design lens.

The objective is to compare Security Resource Consumption against Effective Security Coverage. The question becomes: How much security can one unit of compute buy?

CPU is Only One Cost

A naive security efficiency calculation might consider CPU. But runtime security has several resource dimensions.

A security system can be CPU-efficient while generating enormous telemetry. Another can reduce telemetry while consuming significant memory. Another can minimize local resources while pushing substantial computation into a centralized backend.

The real metric must therefore be multidimensional.

eBPF Makes the Cost Visible

Kernel-level observability is powerful. It also creates an engineering responsibility.

Datadog's engineering analysis of eBPF workload protection explicitly distinguishes:

1. CPU and memory consumed by the user-space security agent.
2. Performance impact from kernel instrumentation.
3. Workload-dependent memory consumption from eBPF maps and buffers.

It notes that excessive resource consumption can degrade critical services and, in severe cases, contribute to OOM conditions that create security monitoring gaps.

That is a critical insight. Security overhead is not merely an infrastructure bill. It can become a security problem itself.

The Security Paradox

Consider:

The security system has now created a reliability problem that can reduce security.

Always-On is Not Always Optimal

Traditional security often favors: Maximum telemetry + Maximum inspection + Maximum retention.

The assumption is intuitive: More visibility means more security.

But more visibility also means: More CPU + More memory + More events + More storage + More processing.

At sufficiently large scale, maximizing observation everywhere can become economically inefficient. The goal should instead be:

Security Efficiency

A useful conceptual metric is:

The exact formula should be empirically defined for a product benchmark. The important point is the optimization target.

Not All Workloads Need the Same Security Density

Consider a cluster containing: a static frontend, a database, an inference server, an AI agent, a build runner, a monitoring service, and a batch job.

Their security requirements are not identical.

• A public-facing inference endpoint may deserve high observation.
• A short-lived batch process may require different coverage.
• A highly privileged control-plane workload may require intensive monitoring.
• A low-risk internal process may not need maximum inspection continuously.

Adaptive Security Density

A conceptual model:

Instead of assigning the same security computation to every workload (Security Cost = Constant), the system aims for: Security Cost = Function(Risk). This is a fundamentally different resource allocation model.

The Casino Model Connection

This is where stochastic patrol becomes economically interesting.

Suppose N = number of workloads and K = number of deep inspection resources, where K << N.

Instead of permanently applying deep inspection to all workloads, the system can maintain broad lightweight coverage and allocate high-resolution observation dynamically.

The mathematical question becomes: How can limited security resources maximize useful coverage? That is a resource-allocation problem.

AI Makes the Economic Problem Harder

AI infrastructure is already resource-intensive.

Google Cloud's 2026 State of AI Infrastructure research found that 83% of organizations surveyed said they need infrastructure upgrades to support production-grade agentic AI. It also found that 62% reported significant "inference tax" from factors including data egress, storage bloat and idle specialized hardware, while 81% cited operational complexity as a hidden cost of scaling AI.

In this environment, security overhead competes with expensive workloads for infrastructure resources.

Security Competes With the Workload

Consider a GPU inference node. Its primary purpose is to run inference.

But the node also needs: OS, Container runtime, Kubernetes, Monitoring, Logging, Security, Networking, Storage.

Every additional security operation competes for CPU, memory, network, kernel resources, I/O, and operational attention. Security architecture therefore becomes part of capacity planning.

The Multiplicative Effect

Suppose a security agent consumes X CPU, Y MB memory, Z GB telemetry per workload.

At 10 workloads, the impact may be negligible. At 10,000 workloads, the economics change.

Now consider: CPU × workloads × clusters × regions × environments. The security footprint becomes a platform-level cost.

AI Security Can Also Create AI Cost

Modern security platforms increasingly use AI for alert triage, investigation, threat hunting, log analysis, incident summarization, detection engineering, and remediation recommendations.

That introduces another cost layer: Security telemetry → AI processing → Tokens / inference → Security decision.

The future security stack therefore needs to optimize both Runtime computation and Security intelligence computation.

Compute Should Follow Information Value

Not every event has equal security value.

• Normal process heartbeat may contain little incremental information.
• New credential access may contain significantly more.
• Known internal API call may be low-value.
• Previously unseen external destination may justify deeper inspection.

The system should spend more resources where additional observation can materially change a security decision.

Security Information Density

This introduces another conceptual metric: Security Information Density = Useful Security Information / Security Compute Consumed.

The goal is not to collect the maximum number of events. It is to maximize the amount of actionable security information produced per unit of infrastructure consumed.

Runtime Security as an Economic Optimization

The optimization problem can be expressed as:

This is much closer to an engineering optimization problem than a simple feature comparison.

The Security Resource War

This creates a strategic competition between security architectures.

The second architecture is not automatically superior. It has to prove that reduced resource consumption does not produce unacceptable coverage gaps. That is exactly what makes the benchmark important.

How to Measure It

A credible runtime-security benchmark should measure:

Opsonance's Thesis

Opsonance can frame the problem as:

That is the foundation of Adaptive Security Density. The architecture therefore attempts to turn security from a fixed tax into an adaptive resource allocation system.