Updated August 21, 2026
TL;DR: Code-executing AI agents eliminate the static security perimeter that traditional AppSec tooling defends. Prompt injection escalates directly into remote code execution, and post-execution detection is functionally an autopsy. Containing these risks requires active runtime enforcement that intercepts and evaluates agent calls before code reaches an execution environment. A self-hosted sovereign AI control plane deployed inside your VPC, enforcing AIUC-1, NIST AI RMF, and OWASP Agentic AI policies at the API level, is the architecture that closes this gap without routing telemetry outside your perimeter. Developers change only their
base_url. Everything else keeps working.
Most enterprise AI security strategies focus on filtering inputs to models. That framing misses the actual threat surface of a code-executing agent, which is not what goes in, it is what the agent chooses to run on the host. When an AI agent generates code autonomously and submits it to an execution environment, your traditional security boundary shrinks to the walls of a sandbox that is often poorly defined and trivially escapable. This guide maps the complete risk architecture of code-executing agents to the specific runtime controls that contain each threat, so you can scope deployment decisions before seeking security team approval.
The architect's checklist for agentic security
Use this checklist to evaluate your current posture before approving any code-executing agent for production.
- Prompt injection surface: Validate agent inputs, including retrieved documents, tool outputs, and inter-agent messages, before they influence code generation
- Execution isolation: Code-executing agents run in hardware-isolated environments (microVMs or userspace kernels such as gVisor) rather than standard containers sharing a host kernel
- Network egress: Execution sandboxes operate under default-deny outbound network policies, with explicit allowlists for approved endpoints only
- Dependency control: Dynamic package installation is disabled or restricted to an approved registry within the execution environment
- Privilege boundaries: Agent processes run as unprivileged users, with filesystem access restricted to explicitly declared paths
- Tool call governance: The control plane enforces which agents are authorized to call which tools and Model Context Protocol (MCP) servers, configured in the Admin Console, not in application code
- Grounding verification: Verify that model outputs are grounded in context supplied through tool calls or source documents, with a defined policy response (log, alert, or block) when expected grounding context is absent or unsupported
- Audit log generation: Every governance event, including policy decisions, detected violations, and enforcement actions, produces a structured log event forwarded to your SIEM or observability platform (such as Grafana) inside your own infrastructure
- AI asset inventory: Every model, tool, and MCP server in the agent's call graph should be registered in the control plane before it operates
- AIBOM export: Your AI System inventory is exportable in CycloneDX format for AIUC-1 assessor and enterprise procurement reviewer requests
The unique vulnerabilities of code-executing agents
Three distinct vulnerability classes define the threat surface. Each escalates in a different way once code generation enters the picture.
The escalation path from prompt to remote execution
Standard AI input risks produce bounded outputs: a biased response, a policy-violating statement, or an exposed data record. Code-executing agents transform that risk profile entirely because the model's output becomes executable instructions on real infrastructure.
A Microsoft Security analysis documented exactly this: a single prompt injection caused an AI agent to launch a process on the host device, with no browser exploit or malicious attachment involved. The agent interpreted natural language, selected a tool, and passed attacker-controlled parameters directly into code execution. Trail of Bits research documented the same escalation path, showing how attacker-controlled data retrieved by an agent via a web page, database result, or tool response becomes an instruction that calls a shell tool, and that shell call becomes arbitrary code execution on the host or within a container. This is the documented default behavior of inadequately governed agents, which is why the OWASP Top 10 for Agentic Applications, built by more than 100 security experts and researchers, classifies Unexpected Code Execution (ASI05) as a distinct category from injection attacks. For a closer look at how these agentic threats manifest in practice, the Prediction Guard EP03: Agentic AI Automation video covers this threat model in detail.
The gap between compliance frameworks and runtime reality
Static application security testing tools were designed for code that is fixed at deploy time. Code-executing agents make code generation a runtime variable, producing a dynamic attack surface that static scanners cannot observe. By the time your SAST pipeline runs, the agent has already generated and submitted code to an execution environment. The code SAST would have scanned never existed at any fixed point in the build process.
Compliance checklists share the same structural flaw: they describe what should happen, not what did happen. A policy stating that agents must not execute untrusted code is not a control, it is guidance. The NIST AI Risk Management Framework addresses this through its Manage and Govern functions, which require operationalizing risk controls at the system level, not documenting them in a policy wiki. The NIST AI RMF implementation playbook from Prediction Guard maps these functions to specific runtime enforcement mechanisms for teams working through framework alignment.
Mapping threats from code to compromise
The following sections map each threat category to its specific attack path and the control that intercepts it.
Input manipulation and data exfiltration
ASI01 (Agent Goal Hijack), as defined in the OWASP Top 10 for Agentic Applications, describes attackers who manipulate an agent's objectives through prompt-based manipulation, deceptive tool outputs, malicious artifacts, forged agent-to-agent messages, or poisoned external data. In a code-executing context, the target is the agent's code generation step. If an attacker redirects the agent's goal before code is generated, the code itself becomes the attack vector.
Containing ASI01 requires validating all agent inputs before they influence the planning and generation cycle, including retrieved documents, tool call responses, and inter-agent messages, not only direct user prompts. The EP04: OWASP implementation video demonstrates how to apply this validation at the system level.
Beyond goal hijacking, code-executing agents create a direct path to data exfiltration that does not require breaking the execution sandbox. An agent manipulated through indirect injection can generate code that reads environment variables, accesses local credential files, or opens outbound HTTP connections to attacker-controlled endpoints, all within its authorized execution scope.
Runtime enforcement that evaluates generated code for data access patterns and outbound connection attempts before it reaches the execution environment is the mechanism that closes this path. Post-execution log analysis identifies the exfiltration after it occurs. The scaling agentic AI article from Prediction Guard covers the governance trade-offs of this enforcement model at enterprise scale.
Execution environment risks: sandbox escape and privilege escalation
ASI05 (Unexpected Code Execution) and ASI03 (Identity and Privilege Abuse) combine to describe the most severe execution risk: an agent that breaks out of its execution environment and gains unauthorized access to the host system.
The architectural reason is direct. Standard containers share the host kernel, meaning a single kernel CVE provides a direct privilege escalation path from any container to the host system. Hardware-level isolation, specifically microVMs or userspace kernels, addresses the shared kernel risk at its root rather than reducing it at the margins.
Security research documented a real example: Claude Code bypassed its own denylist via a /proc/self/root path traversal, illustrating that even well-resourced AI vendors produce agents with exploitable sandbox boundaries. ASI03 compounds this risk through delegation chains: an agent that assumes elevated permissions via cached credentials or role inheritance can exceed its intended authorization scope before any downstream control catches it.
Agentic supply chain and dependency risks
ASI04 (Agentic Supply Chain Vulnerabilities) describes a risk specific to code-executing agents: the ability to dynamically install packages at runtime. An agent that generates install commands as part of its code execution workflow can introduce unverified third-party packages into the execution environment. Attackers who pre-register package names that models commonly hallucinate can execute arbitrary code through this path, using the agent's own code generation against your infrastructure.
Restricting dynamic package installation to an approved registry and applying read-only filesystem policies outside declared paths are recommended controls that reduce, but do not eliminate, this attack surface. Control plane access controls, configured through the Admin Console, govern which tools and resources the agent is authorized to call and operate alongside the execution environment's own restrictions as complementary controls across the authorization boundary.
Runtime enforcement vs. post-execution detection: The control timing problem
The question is not whether to detect incidents, but whether your controls act before or after damage becomes irreversible.
Why detection-only controls fail for agentic systems
Analyzing logs after an agent has executed malicious code is an autopsy, not security. Detection-based approaches assume that identifying an incident quickly enough enables a meaningful response, but the consequences of compromised agent execution, credential exfiltration, lateral movement, data destruction, are irreversible before most SIEM alerts fire. Cloud-native guardrails and post-execution monitoring tools observe consequences. Runtime enforcement prevents them.
The blast radius concept is critical here. A single compromised agent in a multi-agent system can propagate failures across the entire workflow through ASI08 (Cascading Failures): one hallucinated fact, one malicious tool output, or one poisoned memory retrieval spreads through connected agents and amplifies before any detection-based system triggers. The OWASP Top 10 for Agentic Applications characterizes this as a single error, compromise, or bad decision that spreads across connected agents, tools, or workflows, compounding into system-wide harm beyond the original breach. Daniel Whitenack and Chris Benson examined Anthropic's Zero Trust for AI Agents framework in depth in Practical AI Episode 360, including blast radius, least agency, and what zero trust architecture requires of agentic systems operating inside enterprise infrastructure.
The enforcement window and what it stops
The lifecycle of an agent call that generates and executes code moves from input evaluation through generation to execution. Effective governance requires enforcement at the first two stages, before any code reaches an execution environment. The control plane sits between the agent application and the model endpoint, evaluating every call before the model response completes. Policy enforcement at this point can block the call, rewrite the prompt to neutralize injection attempts, or allow the call to proceed with an audit record that the check occurred, all inside your infrastructure.
Runtime enforcement that intercepts calls before model completion can block unauthorized tool calls, prevent malicious code patterns from reaching the execution environment, enforce output structure that prevents injection payloads from passing through agent-to-agent communication, and detect PII exfiltration before it leaves the controlled context. The EP12: self-hosted sovereignty video covers this architecture in detail, including how the control plane maintains data sovereignty throughout the enforcement chain.
Architecting a central control plane for agent security
The sections below cover deployment topology, developer integration, and SIEM log structure for teams scoping a production rollout.
Deploying control planes within your VPC
The architectural distinction that matters most to regulated enterprises is where enforcement logic and telemetry route. External AI gateways route telemetry outside your perimeter, which for defense-adjacent or financial services workloads handling sensitive or regulated data, creates a compliance gap.
A self-hosted sovereign AI control plane deploys inside your own Kubernetes environment, cloud VPC, or air-gapped network. All governance logic, policy enforcement decisions, and audit log generation occur inside your perimeter, and the audit logs are consumed by your own SIEM under your own controls. The control plane is CPU-only and does not require GPU resources to enforce governance policies. Registered models can run on GPU or CPU depending on your workload.
Build vs. buy: Time and expertise
| Factor | Build custom governance | Deploy self-hosted control plane |
|---|---|---|
| Time to initial enforcement (varies by infrastructure complexity) | Substantially longer than deploying a pre-built control plane; timeline depends on the scope of custom development, security review cycles, and SIEM integration work required | Typically shorter than a custom build; actual duration depends on your team's readiness across infrastructure setup, database configuration, authentication, and network configuration for the self-hosted deployment |
| Required expertise | Specialists across security engineering, AI system architecture, policy design, and SIEM integration development, typically drawn from multiple teams | Engineering team with infrastructure experience |
| Ongoing maintenance | Standard operational security practices (CVE patching, security updates, isolation testing) applied to a governance codebase your team owns and maintains entirely | Updates managed within your infrastructure |
Build vs. buy: Framework alignment and lock-in
| Factor | Build custom governance | Deploy self-hosted control plane |
|---|---|---|
| Framework alignment | Manual mapping to NIST, OWASP, AIUC-1 | Built-in policy maps for all three |
| Audit artifact generation | Engineering effort required to produce structured, framework-aligned audit artifacts, whether through custom development or configuration of standard logging tooling | Structured audit logs generated natively |
| Vendor lock-in | None (full ownership) | None (model agnostic, hardware agnostic) |
The build path gives you full ownership. The operational cost of maintaining a production-grade agent governance stack, continuous patching, ongoing re-testing to maintain alignment as AIUC-1 evolves, and SIEM integration maintenance, is ongoing engineering overhead that compounds with every new model or tool your team adds.
Applying controls to agent model calls
Developers do not change their code to connect to the control plane. Existing OpenAI-compatible SDK calls continue working without code changes beyond repointing the base_url to the self-hosted control plane endpoint. The control plane then governs every call transparently, evaluating inputs, enforcing policies, and generating audit records before the model response returns to the calling application.
Security teams configure governance policies on the Govern page of the Admin Console once, and those policies enforce on every model call that routes through the control plane, regardless of which developer built the agent or which framework they used. The EP10: "USB-C" of AI video covers the composability architecture across multi-vendor model environments, and the EP06: AI unification video addresses the fragmentation problem that makes a single governance surface necessary.
Structuring logs for SIEM and observability integration
The control plane generates structured audit logs during runtime enforcement: enforcement happens first, and the log records that it happened. The control plane does not hold SIEM (Security Information and Event Management) API keys, HEC tokens, Grafana credentials, or credentials of any kind. Your existing ingestion pipeline handles delivery under your own controls, so the credential surface for your SIEM or observability integration is entirely within your own environment.
ISO/IEC 42001 Control A.6.2.8 requires event log recording for AI systems, with logs capturing prompts, tool invocations, outputs, and affected resources as a replayable trace bound to users, sessions, and data sources. The Monitor page in the Admin Console configures SIEM and observability integration in three steps: open the Monitor page, click Configure under your target integration, and confirm to make the integration live.
Mapping controls to standards: AIUC-1, NIST AI RMF, and OWASP
The table below maps each control plane capability to its corresponding framework function and the specific enforcement mechanism it activates.
| Prediction Guard control plane capability | NIST AI RMF function | OWASP Agentic ID | Enforcement mechanism |
|---|---|---|---|
| Runtime policy interception | Govern, Manage | ASI01, ASI05 | Blocks or rewrites malicious inputs before execution completes |
| Access controls (model, tool, MCP) | Govern, Map | ASI03, ASI04 | Enforces which agents, users, and applications can call which registered resources |
| Grounding verification | Measure | - | Verifies agent actions against trusted grounding data before execution proceeds |
| Structured audit logging | Govern, Measure | - | Generates SIEM- and Grafana-ready records of governance events, including policy decisions, detected violations, and enforcement actions, as a byproduct of runtime enforcement, providing audit evidence for AIUC-1 assessor and enterprise procurement reviewer requests |
| Self-hosted VPC deployment | Map, Measure (general alignment) | - | Keeps all telemetry, governance logic, and audit logs within the customer's trust boundary, supporting Map and Measure alignment by keeping deployment context and measurement data inside the customer's infrastructure rather than routing outside the perimeter |
| AI System registration and AIBOM export | Govern, Map (general alignment) | - | Creates the registered asset inventory that AIUC-1 assessors and procurement reviewers require, supporting Govern alignment through organizational accountability for AI assets and Map alignment through contextualizing the deployment environment and identifying in-scope risks |
NIST AI RMF functions for code-executing agents
The NIST AI RMF's four functions, Govern, Map, Measure, and Manage, are concurrent processes implemented across the AI system's full lifecycle. For code-executing agents, the Govern function establishes organizational accountability and policy. Map contextualizes the AI system within its broader deployment environment, identifying potential technical, social, and ethical impacts across the AI system's scope. Measure tests the system against those risks. And Manage operationalizes the response through incident handling, risk treatment, and disclosure procedures. The NIST AI RMF Playbook makes this explicit: the Manage function requires technical controls that respond to identified risks.
OWASP controls for code execution
ASI05 (Unexpected Code Execution) is the OWASP Agentic AI category that most directly targets this threat model. The OWASP GenAI Security Project defines it as: agentic systems generate and execute code, and attackers exploit code-generation features or embedded tool access to escalate actions into remote code execution, local misuse, or host/container compromise. System-level controls for ASI05 operate at three points: the control plane governing what the agent is authorized to request, grounding verification on what the agent produces, and sandbox isolation for what runs. External gateways that evaluate traffic from outside your perimeter can address some input filtering, but they cannot enforce authorization controls on the execution environment or guarantee that telemetry stays within your infrastructure boundary.
AIUC-1 underwriting requirements for autonomous systems
AIUC-1 is the AI compliance and assurance standard purpose-built for AI agents and autonomous systems, organized across six risk pillars: Data and Privacy, Security, Safety, Reliability, Accountability, and Society. Its crosswalk view maps directly to the NIST AI RMF, OWASP Top 10 for LLM Applications, OWASP Top 10 for Agentic Applications, EU AI Act, and ISO/IEC 42001, making it a single framework anchor with published crosswalks to all five simultaneously, for regulated enterprises carrying obligations under more than one of them. AIUC-1 itself is updated quarterly to keep pace with evolving AI threats, which means the controls your governance program maps to may shift between assessment cycles, and continuously available audit artifacts are preferable to documentation assembled only when a review is imminent. Preparing for an AIUC-1 assessment requires gathering documentation across operational practices, legal policies, and technical implementations, then remediating gaps surfaced during scoping. Structured audit logs, an exportable AIBOM in CycloneDX format, and documented runtime enforcement policies are the artifacts AIUC-1 assessors request.
Deployment roadmap: Securing AI agent workflows
Phase 1: Agent registration and asset inventory. Before the control plane can govern a model, tool, or MCP server, it must be registered as an AI System asset in the Admin Console. The control plane only governs what has been registered, which means any unregistered asset operates outside your policy boundary. Registration produces active enforcement coverage and a structured inventory that is exportable as an AIBOM in CycloneDX format, the artifact that answers the AIUC-1 assessor's question about which models and tools are in scope.
Phase 2: Validating AI agent code execution. Governance policy configuration happens on the Govern page of the Admin Console. Security and GRC teams define which prompt injection detection policies apply, what grounding verification thresholds trigger alerts versus blocks, and which PII detection and masking rules apply. These configurations apply uniformly across every registered model and tool, regardless of which developer built the agent that calls them.
Phase 3: Isolating agent code execution. The control plane operates as a primary authorization checkpoint before the execution sandbox, where calls that pass policy enforcement proceed to the hardened execution environment and the sandbox enforces isolation boundaries as a complementary layer within the broader risk management response. Configure the sandbox with unprivileged process execution, default-deny network egress, read-only filesystem outside declared working directories, and dynamic package installation restricted to an approved registry.
Phase 4: Exporting logs to SIEM platforms. Configure SIEM and observability output formatting on the Monitor page in the Admin Console by opening the Monitor page, clicking Configure under your target integration (Splunk, Datadog, CrowdStrike, Grafana, or syslog), and confirming to make the integration live. Your existing ingestion pipeline handles delivery under your own controls and credentials.
Governance readiness self-assessment
Use this checklist to identify gaps in your current agentic code execution governance posture.
- Can you produce a complete inventory of every model, tool, and MCP server your code-executing agents call today, within one business day?
If no, your governance program has no verified scope boundary. - Does your current execution environment for agent-generated code use hardware-level isolation (microVMs or a userspace kernel such as gVisor)?
If standard containers, a single kernel CVE provides a direct host compromise path from any container in your agent's execution scope. - Does your governance enforcement happen before the agent's generated code reaches the execution environment?
If post-execution, detection-based controls cannot prevent the harm they identify. - Does your SIEM or observability platform (such as Grafana) receive structured, AIUC-1-aligned audit logs of every agent model call, tool invocation, and policy decision today?
If no, your current posture cannot satisfy an AIUC-1 assessor's request for audit log evidence. - If a developer added a new model endpoint or MCP server to an agent workflow today, would your governance policies automatically apply?
If manual review is required, your governance coverage has a gap that grows with every new asset deployed.
Book a deployment scoping call to assess whether a self-hosted control plane fits your infrastructure and compliance requirements.
Download the NIST AI RMF and OWASP capability mapping whitepaper to review which framework functions are addressed at the system level before your next architecture review.
For a comparison of deployment architectures and governance approaches, the Prediction Guard product comparisons page provides the technical differentiation detail that enterprise procurement reviewers request.
FAQs
How does Prediction Guard stop remote code execution?
The control plane intercepts agent model calls at runtime, applying prompt injection detection, PII detection and masking, toxicity filtering, and grounding verification to text inputs and outputs before the model response returns to the calling application. Enforcement happens before the model call completes, so generated code that violates a defined policy is never submitted to the execution sandbox.
Does Prediction Guard store SIEM or observability credentials?
No, the control plane does not hold SIEM API keys, HEC tokens, Grafana credentials, or endpoint credentials of any kind. It formats structured audit log output for downstream ingestion, and your existing ingestion pipeline handles delivery under your own controls.
Does securing agents require rewriting application code?
No, developers do not need to refactor their code. Existing OpenAI-compatible and Anthropic-compatible SDK calls work unchanged by repointing the base_url to the self-hosted control plane endpoint. Governance is enforced transparently at the control plane level for every call that passes through it.
What controls stop remote code execution specifically?
Runtime policy interception at the control plane applies prompt injection detection, PII detection and masking, toxicity filtering, and grounding verification to text inputs and outputs before the model response completes. Hardened sandbox isolation (microVMs or gVisor) prevents code that does execute from escaping to the host. Grounding verification reduces the probability that hallucinated commands enter the code generation output. All three controls address a distinct point in the escalation path from prompt injection to host compromise.
Does Prediction Guard monitor model drift?
No, the control plane generates the AI System inventory and runtime integrity monitoring that support drift analysis by external tooling, but model drift detection itself is outside scope. Drift detection is inherently retrospective, which means real-time runtime containment remains the primary defense against immediate execution exploits that code-executing agents create.
Does the control plane require GPU resources?
No, the control plane is CPU-only and does not require GPU resources to enforce governance policies. Registered models can run on GPU or CPU depending on your specific workload requirements, and the control plane remains hardware and infrastructure agnostic across all deployment environments.
Key terms glossary
Sovereign AI control plane: A self-hosted infrastructure system that unifies, secures, and governs disparate AI models, tools, and services entirely within an organization's security perimeter, with all governance logic, policy enforcement, and audit log generation occurring inside the customer's trust boundary.
Runtime policy enforcement: The active interception and evaluation of AI inputs and outputs at the API level, allowing, blocking, or rewriting agent calls before execution occurs, with an audit record of the enforcement decision generated as a byproduct.
Sandbox escape: A security vulnerability where code executing inside an isolated container exploits host weaknesses, typically through a shared kernel CVE, to gain unauthorized access to the underlying operating system or adjacent infrastructure.
Grounding verification: A probabilistic validation process that verifies generated content and agent actions against trusted grounding data sources to detect hallucinations before execution proceeds. This process is probabilistic, not deterministic, and enables graduated policy responses (log, alert, or block) based on confidence scoring.
AIBOM: An AI Bill of Materials, exported in CycloneDX format, that provides a structured inventory of all registered models, datasets, tools, and dependencies within an AI system. The AIBOM is the exportable audit artifact produced by AI System registration.
ASI05 (Unexpected Code Execution): The OWASP Top 10 for Agentic Applications 2026 category classifying the risk of agents exploiting code-generation features or embedded tool access to escalate actions into remote code execution, local misuse, or host/container compromise.
AIUC-1: A compliance and assurance standard for AI agents and autonomous systems, organized across six risk pillars (Data and Privacy, Security, Safety, Reliability, Accountability, and Society), with crosswalks to NIST AI RMF, OWASP LLM Top 10, OWASP Agentic AI Top 10, EU AI Act, and ISO/IEC 42001. Updated quarterly by the standards body to keep pace with evolving AI threats; confirm the current re-certification cadence at aiuc-1.com before scoping your assessment cycle.