Execution Runtime Security in the Era of Agentic AI

• Agentic AI exposes a hard limit of reactive security: attacks can move faster than detection can respond.
• Positive runtime controls flip the model, denying execution unless actions are explicitly trusted.
• Application allowlisting is moving from operational burden to a core runtime defense for the agentic era.

For decades, the enterprise security strategy has been trapped in an endless loop of blocklisting: identifying bad signatures, cataloging known threat indicators, detecting anomalies against a noisy baseline, and writing rules to catch whatever breached the perimeter last week.

This reactive posture was barely sustainable when human operators drove keyboard attacks. In the era of autonomous, multi-step agentic AI, it is completely non-viable.

The only valid defense against agentic AI is execution runtime security. This is a stance we’ve been advocating for a few years now, and other cybersecurity leaders have echoed recently. When autonomous agents can reason, generate zero-day exploits on the fly, chain valid administrative APIs, and act at machine speed without human latency, detection-based security models disintegrate.

If an organization relies on identifying "bad behavior" to stop an autonomous system, it has already lost. The solution requires a fundamental shift to a positive security model—a deterministic architecture where execution runtime security, anchored by strict application allowlisting, serves as the primary control plane.

Before we get into the meat and potatoes of this thing, let me define two key approaches to securing assets, as most of our industry fails to talk about this deeply philosophical difference:

• Positive security model (allowlisting): A default-deny framework that blocks everything by default. It explicitly permits only cryptographically verified, pre-approved software, execution paths, or actions. 
• Negative security model (blocklisting): A default-allow framework that permits all actions and software by default. It blocks or alerts based on known malicious signatures, bad indicators, or anomalous behaviors.

Why blocklisting fails

To understand why traditional security fails in an agentic world, consider these three ways agentic AI alters the mechanics of an attack:

1. Non-deterministic execution paths: Legacy detection systems rely on pattern recognition—looking for static IOCs (Indicators of Compromise) or recognized command-and-control (C2) behavior. Agentic systems do not execute static code sequences. Prompted with an intent, an agent dynamically formulates an execution path, crafts custom scripts, and selects tools on the fly. The attack code is generated seconds before it executes, rendering signature-based tools irrelevant. 
2. "Identity-valid" exploitation: Agentic AI operating within an enterprise often uses legitimate credentials, API keys, or service accounts. When an agent misbehaves—or is hijacked via prompt injection—its actions look entirely authorized to standard Identity and Access Management (IAM) controls. It uses approved native tools (e.g., PowerShell, vssadmin, wmic) to achieve its goals. 
3. Machine-speed breakout times: Human threat actors take hours or days to move laterally. Autonomous agents execute multi-stage kill chains in milliseconds. An detection system that alerts a SOC after detecting anomalous behavior gives analysts an alert to read after the domain controller has been compromised.

Shift to the positive security model

A positive security model operates on a simple principle: everything is denied by default unless explicitly allowed.

Instead of asking, "Is this binary or action known to be malicious?" a positive model asks, "Has this exact execution state, path, and binary been cryptographically verified and explicitly permitted?"

At runtime, that distinction translates into two very different control flows.

TRADITIONAL DETECTIVE MODEL (NEGATIVE)

• Incoming Action → Malicious Pattern Check → Allowed unless proven bad
• Outcome: High latency, missed zero-days

POSITIVE RUNTIME MODEL (DETERMINISTIC)

• Incoming Action → Cryptographic Allowlist → Blocked unless explicitly allowed
• Outcome: Zero latency, enforced boundary

In an agentic environment, this distinction is everything. An AI agent—whether internal (such as an automated IT assistant) or external (like an attacker’s autonomous exploit agent)—must interact with the OS kernel, memory space, file system, and network stack to execute its intent.

Runtime security establishes deterministic control boundaries at those exact interaction points. If an agent tries to drop a secondary payload, inject code into a legitimate process, or run an unauthorized utility, the runtime engine evaluates the action against a predefined policy. If the action is not explicitly permitted, execution is denied inline—before CPU cycles are consumed and before state changes occur.

Application allowlisting turns that positive security model into an enforceable runtime boundary.

Application allowlisting as runtime control

For years, many enterprise IT teams viewed the operational demands of application allowlisting (often implemented via AppLocker, WDAC, or third-party endpoint platforms) as daunting enough to leave it in dream territory. Some feared its controls were too rigid, complex to maintain, or prone to disrupting developer workflows in dynamic environments.

In the era of agentic AI, application allowlisting takes on renewed importance. It must be brought back to the enterprise—not as a maintenance burden, but as the core pillar of runtime defense.

Consider how application allowlisting breaks the agentic attack chain across two realistic enterprise scenarios:

Scenario 1: The hijacked IT maintenance agent

An enterprise deploys an AI agent tasked with routine systems administration. An attacker delivers an indirect prompt injection via a poisoned support ticket. The injected instructions force the agent to attempt local privilege escalation and dump memory from lsass.exe using a customized, dynamically compiled binary.

• Without allowlisting: The agent has administrative context. It drops the custom compiled executable into C:\Windows\Temp\ and executes it. The identity check passes. The behavioral endpoint detection and response (EDR) engine evaluates the process—but because the binary is novel and the parent process is a trusted service, execution succeeds. Memory is dumped before a high-confidence heuristic alert triggers. 
• With application allowlisting: The kernel driver checks the incoming file execution request against the active policy. The binary located in C:\Windows\Temp\ lacks a trusted publisher signature, fails the cryptographic hash check, and violates path rules. Execution is blocked instantly. It does not matter that the agent was authorized to run commands; the unauthorized binary cannot execute.

Scenario 2: Living off the land (LOTL) exploitation via prompt injection

An attacker leverages an AI agent to execute a LOTL attack, instructing the agent to invoke native system tools like certutil.exe to download a malicious staging file, followed by powershell.exe executing an obfuscated base64 payload in memory.

• Without allowlisting: Both certutil.exe and powershell.exe are legitimate, signed OS binaries. The system allows execution. The EDR inspects the command-line arguments, but obfuscation delays or bypasses heuristic detection long enough for the payload to establish persistence.
• With application allowlisting & constrained language mode: A positive security model enforces strict policy rules on native binaries. Certutil.exe is blocked from making arbitrary outbound network connections via network-level execution rules. PowerShell is forcibly locked into Constrained Language Mode for non-interactive agent sessions, disabling programmatic API calls, COM objects, and direct memory access. The agent’s attempt to execute dynamic code fails at the runtime execution boundary.

The reality of enforcing positive controls at runtime

Adopting a positive security model is an architectural shift that requires clear operational priorities:

1. Deterministic blocking over HEURISTIC alerts: Detection engines generate telemetry for human or automated response. Runtime execution controls act inline. When an AI agent moves at machine speed, defense must be synchronous with execution.
2. Constraining the agent's tooling surface: AI agents should operate under strict least-privilege constraints, not just for identity, but for executable binaries and tools. If an agent’s role is to query a database and format reports, its execution boundary must explicitly block access to command interpreters (cmd.exe, powershell.exe), compilers, and network tools. 
3. Cryptographic identity for process chains: A process spawned by an AI framework must carry explicit provenance. If an agent framework spawns a child process, runtime security must cryptographically verify parent-child relationships to prevent process hollowing, parent PID spoofing, or unauthorized binary invocation.

The new paradigm

The rise of agentic AI strips away the illusion that security teams can keep pace by analyzing logs, building better detection logic, or reacting to alerts. When software can generate unique, context-aware exploits faster than any SOC can analyze them, reactive models fail entirely.

Execution runtime security anchored in a positive model is not just one option among many—it is the only control model capable of containing non-deterministic systems. By enforcing strict application allowlisting and restricting system access to explicitly authorized execution paths, security teams can contain the blast radius of agentic systems—regardless of how clever the prompt injection or how fast the machine-speed exploit.

Maybe some day, traditional detection and response systems will match up to this threat. But today, their nature is reactive, and that puts teams still relying solely on them on their back foot right out of the gate. 

In Symantec® CBX, we have taken the industry a big step forward—away from those reactive systems and towards getting predictive about attackers’ next moves. It feels like a time machine, but the truth is that in order for the industry to get there, we will need to use automation to act on those predictions, and see AI-based attacks become slightly less bespoke.

Endpoint and EDR solutions still deliver critical prevention capabilities, but using it in conjunction with tools that protect other key attack vectors—including application control—can give your team a full-spectrum defense against AI threats.

Operationalizing positive security

The challenge with scaling application allowlisting has historically been operational friction, especially with more static or difficult-to-maintain approval models. Carbon Black® App Control addresses this by providing enterprise-grade application allowlisting built specifically for runtime enforcement. As an industry leader in positive security, Carbon Black replaces static, unmanageable hash lists with flexible, trust-based approval mechanisms—such as cloud-driven reputation, custom path/process rules, and trusted publisher verification. This enables organizations to lock down critical servers, cloud workloads, and agentic environments without crippling business operations. Beyond binary execution control, its integrated memory protection, file integrity control, and process-level restrictions prevent hijacked AI frameworks or compromised service accounts from abusing native tools or executing unauthorized code. To achieve the deterministic runtime boundaries required in the era of autonomous AI, Carbon Black App Control delivers the exact low-friction, high-enforcement foundation security teams need.

To see how innovative solutions pioneers in their field could fit into your environment, reach out to your in-region expert.