AI runtime security: how to protect agent code execution

Your agent passed every test in staging. It parses documents, generates Python, and runs it correctly. Then a user submits a crafted input. The model treats part of it as code, and the executor runs that code with the agent's permissions. Customer data from several tenants leaks before your on-call engineer sees the alert.

That pattern has a CVE number. CVE-2026-0761 is an unauthenticated remote code execution (RCE) flaw in MetaGPT 0.8.1, scored 9.8 on the Common Vulnerability Scoring System (CVSS). A bug in the actionoutput_str_to_mapping function let remote attackers run arbitrary Python because model output reached an executor unchecked. The National Vulnerability Database (NVD) record listed no patch as of its February 2026 update, so check current status before you rely on an upstream fix. The same codebase carries two more RCE disclosures (issue 1942 and issue 1928), both built on unsafe exec() and eval() calls over LLM-generated output.

Your CI pipeline never saw any of this. Static analysis scans the code your engineers committed. The code that leaked the data didn't exist until the agent wrote it, seconds before it ran. This guide covers what AI runtime security means for agents that execute code, the threats that end in execution, four defense layers ordered by what holds when the previous one fails, and a rollout plan that doesn't require re-architecting.

Key takeaways

• Runtime is the gap: CI scans can't review code that doesn't exist until an agent writes it at request time.
• Injection becomes execution: Prompt injection is the entry point, and unsandboxed code execution turns it into a breach.
• Assume filters fail: Guardrails are probabilistic, so isolation has to hold when a filter misses.
• Four layers: Isolate in microVMs, restrict egress and credentials, validate before execution, then monitor and halt.
• Prove it first: Red-team the sandbox boundary and keep a tested kill switch ready before launch.

What is AI runtime security?

AI runtime security is the set of controls that monitor, constrain, and isolate AI agents in production. For agents that generate code, it also contains that code before it reaches data, credentials, or other tenants.

The term "AI runtime" in this article means the execution layer where agent-generated code and tool calls run, rather than the model-serving stack that hosts weights on GPUs. That execution layer is where the damage happens.

Three properties of generated code put it outside your existing application security program. It's non-deterministic: the same prompt can yield different code on two requests, so pre-deployment evaluation only samples the behavior. It's unreviewed: no engineer reads it before it executes. And it exists only at request time, so the attack surface appears when the agent emits the code and disappears when the session ends. Static analysis in CI, code review, and a web application firewall (WAF) all act on artifacts or traffic that exist before the request. None of them sees a Python string the model emitted a moment ago.

Guardrails catch known patterns, and isolation caps the damage when a pattern isn't known. You need both. Map your current controls against the three rows; the third row is the one the rest of this article fills in.

AI agent security risks: what goes wrong at runtime

IBM's 2026 Cost of a Data Breach figures put the global average breach at $4.99 million. For an engineering leader, that is the downside of one injected prompt reaching an executor with tenant-wide access. CrowdStrike's 2026 Global Threat Report recorded an 89% year-over-year increase in AI-enabled adversary operations, which means the people probing your agents now automate the probing. The Open Worldwide Application Security Project (OWASP) published the Top 10 for Agentic Applications on December 9, 2025. It's the taxonomy used below: ASI01 Agent Goal Hijack, ASI02 Tool Misuse, ASI04 Agentic Supply Chain, and ASI05 Unexpected Code Execution.

Prompt injection that ends in code execution

Prompt injection is ASI01 in the agentic list: an attacker hijacks what the agent is trying to do. Direct injection puts the instruction in user input. Indirect injection hides it in content the agent retrieves, such as a support ticket, a README, or a web page. Indirect injection is the harder case because the agent fetches the payload itself, and the input looks like data rather than a command.

The chain that turns injection into a breach has three links. The injected instruction changes the agent's goal. The model emits code or a tool call to pursue that goal. The executor runs it with whatever permissions the agent holds. MetaGPT's RCE was this chain with no gate at the third link.

The pattern is already in adversary playbooks. MITRE ATT&CK tracks campaign C0062, in which operators manipulated Claude Code across about 30 organizations for reconnaissance through exfiltration. Model-side filters cut how often the chain completes; they don't bring it to zero, so the layers in the next section assume it does.

Tool misuse, MCP exposure, and data exfiltration

ASI02 covers tool misuse, and the dangerous part is that each call looks legitimate. An agent with read access to a customer table and a working HTTP client can exfiltrate that table without a single denied request. Every operation sits inside its authorized permissions, so identity-layer logs show a valid credential doing valid things.

Delegation chains widen the problem. When one agent hands a task to another, each hop is individually valid, but the combination crosses an authorization boundary that no single agent was granted.

Model Context Protocol (MCP) servers are where tool calls meet the network. Microsoft's developer blog notes that MCP has no built-in point where policy is evaluated before a call executes. OWASP's Q1 2026 exploit round-up documented CVE-2025-59528, an RCE in CustomMCP mapped to ASI05, ASI02, and ASI04. Its listed mitigations include sandboxed execution and restricted outbound connectivity.

Runaway loops are the quieter form of misuse. An agent that retries a failing tool call without a bound burns tokens and compute until a quota stops it, which is why OWASP lists unbounded consumption as LLM10:2025. Per-session quotas are cost controls as much as security controls.

Slopsquatting and supply chain risk

Slopsquatting is a supply chain attack in which an attacker registers a package name that LLMs tend to hallucinate, then waits for an agent to install it. It maps to ASI04. The hallucination rates are measurable. Peer-reviewed research found that commercial models invent at least 5.2% of package suggestions, and open-source models at least 21.7%. At those rates, an agent that installs its own dependencies will eventually request a name nobody owns, and whoever registers it first controls what runs.

Confirmed cases include unused-imports on npm and huggingface-cli on PyPI. In both, the agent installed what the model suggested and ran it with full process privileges. Pinned versions, a software bill of materials (SBOM) per session, and registry allowlists reduce the odds. They don't remove the need for a boundary around the install step itself.

Every threat in this section ends the same way: code or a tool call runs under the agent's authority. The defenses below are ordered accordingly, starting with containment.

How to secure agent code execution in four layers

Treat every agent action as untrusted, including the ones that pass your filters. The four layers below are ordered by what still holds when the layer before it fails. Isolation comes first because it's the only control that workshelps limit damage after the model has already been convinced to do the wrong thing.

1. Isolate execution with microVMs

Run each agent's code in its own microVM. Firecracker microVMs give every workload its own guest kernel under the Linux Kernel-based Virtual Machine (KVM), with a device model limited to virtio-net, virtio-balloon, virtio-block, virtio-vsock, a serial console, and a minimal keyboard controller. An exploit inside the guest has to break hardware virtualization to reach the host or a neighboring tenant. That's a different class of problem from a shared-kernel escape.

Containers deserve a precise qualifier. They're the industry standard for running your own trusted software in multi-tenant settings. For arbitrary, untrusted, or AI-generated code, containers share the host kernel, so one kernel vulnerability becomes every tenant's vulnerability. That's the workload where microVMs are required rather than preferred.

Teams can build and operate this boundary directly or use a managed agent infrastructure platform. Blaxel, for example, gives every sandbox its own Firecracker microVM, with the root filesystem held in memory and wiped on destruction. Sandboxes stay in standby indefinitely at zero compute cost and resume in under 25ms with filesystem and memory state intact. That resume time is what makes a fresh microVM per user session practical instead of a cost you amortize across users.

2. Restrict network egress and credentials

Default-deny egress, then allowlist. Block all outbound traffic from the sandbox except named domains, and put package registries on that list rather than leaving them open. OWASP's Q3 2026 exploit round-up recommends the same posture for isolated workloads: deny outbound access except to approved destinations, keep platform tokens outside the execution environment, and log process execution.

Agents should never hold raw secrets. Inject credentials at an egress proxy that rewrites outbound requests, so code inside the sandbox sees a placeholder and the real key never enters memory the agent can read. Anthropic's engineering team states the logic plainly: if credentials never enter the sandbox, "they can't be exfiltrated". Make whatever does enter short-lived and scoped to the session.

The draft concept paper from the National Institute of Standards and Technology's National Cybersecurity Center of Excellence (NIST NCCoE) on agent identity reduces to one instruction. Give each agent its own workload identity, authorize each tool call against that identity, and update policy when the agent's scope changes. Your next step this week: audit what each code-executing agent can reach today, by domain and by credential, and cut everything its current task doesn't require.

3. Validate and constrain code before it runs

Validate inputs and retrieved documents against schemas before the agent processes them. Constrain generation to a minimal surface: allowlist the operations and imports the task needs, and reject anything else. Run generated code through static application security testing (SAST) and a linter before the executor touches it. These checks are cheap and deterministic, and they cut the volume of dangerous code that reaches layer 1.

Pre-execution inspection looks at sequences rather than single statements. A webhook that evaluates the next planned action can flag a write to a production database, or a log deletion that follows an external API call, and halt before the first step runs. Human approval belongs here for destructive actions. The same OWASP Q1 round-up lists explicit confirmation and an emergency stop as mitigations for an email-management incident in which an agent deleted what it shouldn't have.

This layer reduces volume while layer 1 limits damage. A filter that misses occasionally still misses, and the miss then lands inside a microVM with no credentials and no open egress.

4. Monitor, limit, and halt

Agent observability means the full reasoning-chain trace: prompt, retrieved context, tool calls with parameters, authorization decisions, generated code, execution results, and sandbox-level filesystem, process, and network events. Tie each event to a workload identity and a session. Baseline each agent type on that trace and alert on drift. Signature rules won't catch an agent reading a secrets path it has never touched before, but a behavioral baseline will.

Set per-session and per-user quotas on tokens, compute time, and tool calls, sized to expected usage, and let a circuit breaker halt the session when a threshold trips. Quotas double as cost controls: a runaway loop then costs one session, not a monthly budget.

The trace above doubles as compliance evidence. The EU AI Act, as amended by Regulation (EU) 2026/1744, applies in general from August 2, 2026, with Annex III high-risk obligations from December 2, 2027 and Annex I from August 2, 2028. For high-risk systems, Article 19 requires automatically generated logs kept for at least six months. Enterprise buyers will also ask for SOC 2 Type II, ISO 27001, and Health Insurance Portability and Accountability Act (HIPAA) evidence for the execution layer itself, and this trace is most of that evidence.

Evaluate the agent code-execution boundary

Whether you build the boundary yourself or evaluate an agent infrastructure platform such as Blaxel, verify microVM isolation, default-deny egress, and proxy secrets injection against your own threat model.

How to roll out runtime security without re-architecting

Adoption is additive: the four layers sit alongside your existing Kubernetes clusters, cloud accounts, and alerting rather than replacing them. Sequence the work by blast radius. Start with the agents that touch tenant data or hold credentials, and prove the boundary before you widen the fleet.

1. Red-team the reasoning layer and the sandbox boundary

Test the reasoning layer first. Plant indirect injections in retrieved files and in web pages the agent fetches. Run agent-to-agent delegation attacks where each hop is valid and the combination isn't. Request dependencies that don't exist and check whether the install step fails closed.

Then attack the boundary from inside. Give an adversarial agent shell access in the sandbox and try three things: egress to a domain not on the allowlist, a read across a tenant boundary, and exfiltration of any credential the environment holds. The SandboxEscapeBench benchmark shows the adversary you're modeling. Claude Opus 4.5 escaped its container-based challenge in 56% of samples, and Mythos Preview succeeded at least once on every sample. The models you deploy are the models an attacker can point at your boundary.

Measure enforcement latency under attack. Controls that are fast in normal operation can degrade under adversarial load, and the defense then becomes its own denial of service. Confirm every control fails closed: a policy engine that times out should block, never pass.

2. Build kill switches, rollback, and CI/CD gates

Build the halt-all switch before the first production incident. One action should stop every agent session, and you should test it on a schedule rather than discover it during an outage. Feature flags should disable individual capabilities, such as shell access or a specific tool, without a redeploy, so you can degrade an agent instead of pulling it. Keep a known-good version you can roll back to in minutes.

Define severity levels up front. A blocked egress attempt is an alert, a cross-tenant read is a page, and a credential leaving the sandbox is a halt-all. Run tabletop exercises against those levels so the on-call engineer has already rehearsed the decision.

Put policy validation in the pipeline. Every agent deployment passes a check that its egress allowlist, tool allowlist, and credential scope match the declared task before it reaches production. Forward sandbox execution traces to your security information and event management (SIEM) system and correlate them with infrastructure alerts. An agent incident then shows up next to the host and identity events it touched.

Start protecting agent code execution in production

This week, inventory what your code-executing agents can reach: every domain, every credential, every tenant boundary. That list is your attack surface, and most of it can be cut without changing agent logic.

One injected prompt that reaches an unisolated executor exposes every tenant that executor can reach.

You can implement these controls in your own infrastructure or use a managed execution layer. For teams choosing a managed option, agent infrastructure platforms like Blaxel run each sandbox in its own Firecracker microVM and pair it with networking controls. Proxy secrets injection keeps raw keys out of the sandbox, domain filtering enforces egress allowlists, and dedicated egress gateways are available in private preview for static outbound IPs. The platform is SOC 2 Type II and ISO 27001 certified, with HIPAA coverage through a Business Associate Agreement (BAA) as an add-on. The sandbox documentation covers the isolation and networking configuration.

FAQs about AI runtime security

What's the difference between AI runtime security and AI guardrails?

Guardrails inspect text: the prompt going in and the model output coming out. They catch known injection patterns and policy violations, and they're probabilistic, so some attacks pass. AI runtime security covers what happens after the text stage: which tool calls are authorized, where generated code executes, what it can reach on the network, and which credentials it holds. Guardrails lower the number of attacks that reach execution. Runtime controls decide what an attack can do once it gets there.

Are containers enough to sandbox AI-generated code?

For your own trusted software in a multi-tenant setting, containers are the industry standard. For arbitrary, untrusted, or AI-generated code, they aren't enough on their own, because every container shares the host kernel. A kernel vulnerability reachable from inside one sandbox is reachable from all of them. MicroVMs give each workload its own guest kernel under hardware virtualization, so an exploit has to defeat the hypervisor boundary rather than a namespace to reach the host or another tenant.

How do you stop prompt injection from becoming code execution?

Assume the injection succeeds and break the chain after the model. Validate retrieved content against schemas, allowlist the operations and imports the agent may generate, and run static checks before anything executes. Then execute only inside a microVM with default-deny egress and no raw credentials, so a successful injection produces code that can't reach the host, the network, or a secret. Add pre-execution inspection with human approval for destructive actions.

What should you log to investigate an agent incident?

Capture the full execution trace: prompt, retrieved context, tool calls with parameters, authorization decisions, data access, generated code, runtime outputs, and sandbox-level filesystem, process, and network events. Tie each event to a workload identity and a user session so you can reconstruct who the agent was acting for. If you operate a high-risk system under the EU AI Act, align retention with the six-month minimum in Article 19.