From Security Agents to Security Systems

For years, the security industry has largely built around the idea of the security agent. Install an agent. Keep it running. Collect telemetry. Send the data somewhere. Analyze it. Generate an alert. Investigate. Respond.

The architecture is understandable because the infrastructure it was designed for was comparatively understandable. Servers were relatively persistent. Applications followed predefined execution paths. Security policies could be defined ahead of time. Human analysts remained central to investigation and response. Compute was treated as abundant enough that security software could maintain a substantial presence across the environment.

That world is changing.

Cloud infrastructure is increasingly ephemeral. Kubernetes has become a dominant operating layer. AI workloads are becoming operationally significant. AI agents can execute multi-step workflows across systems. Machine identities vastly outnumber human identities. And software is increasingly capable of adapting its behavior based on what it discovers at runtime.

Sysdig's 2025 usage research found that 60% of containers in its dataset lived for one minute or less, while workloads using AI/ML packages grew by 500% year over year.

At the same time, AI agents are introducing a new operational model. Google Cloud's 2026 research found that 83% of surveyed organizations said they need infrastructure upgrades to support production-grade agentic AI, while 79% of technology leaders identified security, governance or operations as a major challenge to scaling inference.

The infrastructure is becoming more dynamic. The workloads are becoming more autonomous. The attack surface is becoming more interconnected. And security is still frequently designed around the assumption that the best answer is to put another permanent sensor everywhere.

The security agent was an important abstraction

The security agent solved a real problem. It brought security closer to the workload. Instead of relying exclusively on perimeter controls, organizations could place software directly on endpoints, servers and workloads.

But the model also introduced an architectural assumption: Every protected workload should maintain a relatively persistent security presence.

That assumption becomes increasingly expensive as infrastructure scales. 100,000 workloads requires 100,000 security agents. The security footprint scales linearly with the infrastructure footprint.

Datadog's 2026 engineering analysis of eBPF-based workload protection makes this tradeoff explicit. The company describes CPU and memory consumed by the user-space agent, additional kernel-level overhead, and the need to benchmark security instrumentation under real production loads.

A security agent is an execution component. A security system is a control architecture.

The environment has become a moving target

The infrastructure ecosystem has continuously evolved to abstract away static hardware.

NIST describes Moving Target Defense (MTD) as an approach in which the defender changes aspects of the environment to increase uncertainty for attackers.

The Three Assumptions That Are Breaking

Randomness is not the point

There is an important distinction between random security and unpredictable security. Randomly selecting workloads without context would be a poor security strategy.

Security-game research (like Stackelberg Security Games) has studied precisely this problem: defenders have limited resources, attackers can observe defensive patterns, and randomized strategies can allocate resources in ways that make attacks harder to optimize against.

Adaptive Security Density

Imagine 10,000 workloads. A traditional architecture might attempt to maintain approximately equivalent security instrumentation across all of them.

Most workloads do not need maximum defensive computation at every moment. But any workload can potentially earn more security attention when its state changes.

Security computation therefore becomes proportional to risk state, not merely workload count. This is Adaptive Security Density, enforced by what we call Special Forces.

Events are not enough

A file access is normal. A network connection is normal. A shell is normal. The security signal is no longer necessarily any individual event.

MITRE ATT&CK's detection strategies increasingly describe behavioral chains and temporal relationships between events rather than relying only on isolated indicators.

The objective becomes attack-chain interruption, not alert generation. The sequence is the signal.

The Execution Boundary

AI makes this particularly important. An AI model can reason. An agent can choose. A tool can expose capability. But eventually something must execute.

Google Cloud's 2026 agent-governance research describes agents as systems that are granted access to databases and APIs and argues for stronger governance around dynamic permissions.

The implication is important: AI security cannot depend entirely on understanding AI intent. The machine's execution is observable.

The Resource Problem

Runtime security consumes resources. AI infrastructure makes this more important. Security is now competing for the same compute that AI needs to operate.

Asynchronous Observation

Continuous baseline monitoring remains useful. But deep inspection does not need to be perfectly synchronized with the workload's ordinary execution path. The defender can observe independently of the workload's expected timeline.

Distributed, not fragmented

A security system can be distributed without being fragmented. Security resources exist close to workloads. Security state can be correlated across the environment. Critical decisions can happen close to execution.

The Opsonance System

The New Control Loop