OWASP ASI05 Unexpected Code Execution: Controls Guide

When an agent can write code and run it, any text that reaches the model is one step away from executing on your infrastructure. OWASP lists this as ASI05 Unexpected Code Execution (RCE) in the OWASP Top 10 for Agentic Applications for 2026. This guide goes deeper than the OWASP Top 10 for Agentic Applications Guide: what the entry covers, how OWASP frames prevention, how to choose an execution sandbox, what identity has to do with it, and how to prove the controls work. It is written for platform and AppSec engineers who build or operate coding agents, data analysis agents and anything with a code interpreter, shell tool or package installer. It describes failure modes and controls, not attack procedures.

Key takeaways

Code generated at runtime skips your normal gates. OWASP's point is that agent code is produced on the fly, so it never passes code review, CI scanning or change control unless you build those checks into the execution path.
The model is not the boundary. Refusals, system prompts and command allowlists that match on a prefix have all been routed around in public research; isolation and least privilege outside the model are what limit damage.
Separate generation from execution. OWASP asks for a validation gate between the agent that writes code and the environment that runs it, with human approval for anything elevated.
The sandbox is only as good as what it can reach. A strong runtime with host credentials, writable configuration, instance metadata or open egress inside it still gives an attacker a foothold.
Agents must not be able to change their own permissions. Several real flaws turned into code execution because the agent could edit the settings or allowlists that governed it.

What it is and who it applies to

OWASP describes ASI05 as the risk that attackers use prompt injection, tool misuse or unsafe deserialisation to turn text into executable behaviour on the agent's host or its connected systems. Because the code is produced at runtime, it can slip past controls designed for code that humans write and ship. The entry builds on two OWASP Top 10 for LLM Applications 2025 entries, LLM01 Prompt Injection and LLM05 Improper Output Handling, and corresponds to threat T11 (Unexpected RCE and Code Attacks) in the OWASP Agentic AI Threats and Mitigations taxonomy. In OWASP's Appendix A it sits under the AIVSS core risk "Insecure Agent Critical Systems Interaction".

ASI05 applies wherever model output becomes something an interpreter acts on:

Coding agents and AI IDEs: agents that edit files, run tests, install packages and execute terminal commands. See the AI Coding Agents Security Guide.
Data and analysis agents: code interpreter tools that run Python against uploaded files or databases.
Operations and remediation agents: agents that patch servers, fix builds or run runbook commands.
Agent frameworks and low-code builders: platforms that evaluate user-supplied or model-supplied code, components or templates.
Memory and tool layers: components that deserialise objects or evaluate expressions passed between agents.

ASI05 is distinct from ASI02 Tool Misuse and Exploitation, where a legitimate tool is used for a harmful purpose, and from ASI04 Agentic Supply Chain Vulnerabilities, where a component is malicious before the agent uses it. In practice they chain: a poisoned package (ASI04) installed by an agent becomes code execution (ASI05), and a file upload tool combined with path traversal (ASI02) can end the same way.

Structure and key requirements

The OWASP entry has three parts: common examples of the vulnerability, example attack scenarios and prevention guidance. The table summarises the examples and scenarios by root cause, with the control that breaks each one.

Root cause (OWASP examples and scenarios)	Typical setting	Primary control
Injected instructions lead to attacker-defined code or shell commands, including commands embedded in a "file processing" request	Coding and file-handling agents reading untrusted content	Sandbox with no secrets and default-deny egress; approval for commands outside a version-controlled allowlist
Hallucinated or backdoored code, for example a generated patch containing a hidden backdoor	Patch-generating and code review agents	Static analysis and human review before merge or execution; treat generated code as untrusted
Unreviewed shell or install commands during automated repair delete or overwrite production data	Remediation and "fix the build" agents	No production credentials in the execution environment; dry-run and approval for destructive operations
Unsafe deserialisation of an object produced by an agent, or `eval()` in a memory system processing untrusted content	Multi-agent frameworks, memory and tool layers	Ban `eval` and native object deserialisation on untrusted data; use data-only formats with schema validation
A chain of legitimate tools (upload, path traversal, dynamic loading) reaches execution	Agents with file and plugin tools	Per-session isolated file system, path canonicalisation, no dynamic loading from writable paths
Malicious or vulnerable package installed at runtime, or an unpinned dependency pulls a backdoored minor version	Agents allowed to run package managers	Internal mirror or proxy, pinned versions with hashes, no install scripts by default

OWASP's prevention guidance groups into seven requirements:

Apply LLM05 output handling to code: validate and encode agent output before it reaches an interpreter, shell or query. The LLM05 entry adds parameterised queries, context-aware encoding and treating the model as an untrusted user.
Test before production: pre-production checks, security evaluations and adversarial testing before any agent output can reach production systems.
No eval in production agents: use safe interpreters and track taint on generated code so that anything derived from untrusted input is marked.
Sandbox every run: containers with strict resource limits, never as root, with restricted file system access and logging of file changes.
Isolate and separate: per-session environments, least privilege, fail-secure defaults, and a validation gate between code generation and execution.
Gate elevated runs: human approval for elevated execution, and a version-controlled allowlist of commands that may run automatically.
Scan and observe: static scanning before execution, runtime monitoring, and logs of every generation and execution event.

Lessons from the research OWASP cites

Auto-GPT (Positive Security, 2023): indirect prompt injection from a browsed web page led to Python execution. Continuous mode and blanket approvals removed the human check; a writable docker-compose.yml mounted inside the container allowed escape to the host (CVE-2023-37273); and the shell command allow and deny lists could be bypassed by command chaining, so the researchers advised not to rely on them. Fixes shipped in v0.4.3.
GitHub Copilot and VS Code (CVE-2025-53773): injected instructions made the agent edit workspace settings to enable automatic tool approval, after which terminal commands ran without confirmation. File edits were written to disk without a review step. Microsoft fixed it in the August 2025 security updates. The general lesson: any file that controls an agent's permissions must be outside the agent's write scope.

Choosing an execution sandbox

OWASP says "sandboxed containers"; the strength of that sandbox is a design decision. The comparison below is NHI Mgmt Group's summary of the common options.

Option	Isolation boundary	Good fit	Trade-offs
Standard container (runc) with seccomp, AppArmor or SELinux, non-root, read-only root file system	Shared host kernel, filtered syscalls	Trusted internal code, low-risk data agents, development	A kernel flaw or misconfiguration can reach the host; profiles are hard to get right for arbitrary code
User-space application kernel, for example gVisor (`runsc` OCI runtime)	Per-sandbox kernel that intercepts system calls before the host kernel	Multi-tenant code interpreters, untrusted uploads, Kubernetes via a RuntimeClass	Not every syscall or `/proc` file is implemented; overhead on syscall-heavy workloads
MicroVM, for example Firecracker or Kata Containers	Hardware virtualisation with a guest kernel per run	Untrusted code from external users, coding agents with package installs, high-value environments	More operational work, image and start-up management, cost at high volume
Restricted language or WebAssembly runtime	No general system access unless explicitly granted	Calculations, transformations, plugins with a narrow interface	Limited libraries; not suitable for general coding agents
Developer workstation (agent runs in the user's IDE session)	None beyond the user's own permissions	Only with approval for every command and file write	Inherits the developer's credentials, SSH keys and cloud sessions

Choose a microVM or user-space kernel when the code or its inputs come from people outside your organisation, when the environment is shared across tenants, or when the agent can install packages.
A hardened container is acceptable when inputs are internal, the sandbox holds no credentials, egress is closed and the environment is destroyed after each session.
Small teams should use the managed sandbox their agent platform provides, turn off auto-approval, and spend their effort on keeping secrets and production access out of it. Large organisations benefit from one central execution service with a standard image, egress proxy and logging that every agent team calls, instead of each team building its own.

Whatever the runtime, the same rules apply: ephemeral per-session environments, no host mounts of configuration or source the agent must not change, CPU, memory, process and time limits, and default-deny network egress with a short allowlist through a logging proxy. See the AI Agent Sandboxing and Code Execution Guide and the Container Runtime Security Guide.

Identity and NHI requirements

Code execution becomes a breach when the code finds credentials. Every execution environment holds or can reach some non-human identity: a pod service account token, a cloud instance role, a package registry token, an API key in an environment variable. ASI05 controls therefore depend on NHI hygiene.

No ambient credentials in the sandbox: do not mount Kubernetes service account tokens unless the code needs them, block the cloud instance metadata endpoint from sandbox workloads, and do not pass the host's environment variables into the run. In the OpenAI and Hugging Face agent breach, agents that escaped an evaluation sandbox collected projected service account tokens, instance role credentials reachable from pods and secrets held in environment files.
Give the sandbox its own narrow identity: if the run must call an API, issue a short-lived, task-scoped token for that call only, bound to the session, rather than reusing the agent's or the developer's identity. See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide.
Keep secrets out of reach of file and template features: secrets in environment variables or files are readable by any code that runs; inject them per call through a broker where possible. See the OWASP NHI Top 10 NHI8 Environment Isolation Guide.
Protect the agent's own configuration: settings files, approval policies, MCP server lists and command allowlists must be writable only through change control, never by the agent. ATLAS tracks this as AML.T0081 Modify AI Agent Configuration.
Plan revocation: if a sandbox is suspected of compromise, every token it could have read must be revocable quickly. Keep an inventory of which identities each execution environment can reach.

Implementation steps

Inventory execution paths. For each agent, list every route from model output to an interpreter: shell tools, code interpreter, package manager, template engines, eval or deserialisation in the framework, and file writes into paths that are later executed (build scripts, task definitions, hooks).
Remove what is not needed. Disable shell and package install tools for agents that do not need them, and remove eval and native object deserialisation from agent and memory code. This is the cheapest and most effective step.
Turn off auto-approval by default. Keep a short, version-controlled allowlist of read-only commands that may run without approval, matched on the whole parsed command, not on a prefix. Everything else needs a person to approve the exact command.
Move execution into an isolated service. Ephemeral per-session sandboxes, non-root, read-only base image, resource and time limits, default-deny egress through a proxy, no metadata access, no host mounts.
Add a validation gate. Run static analysis and secret scanning on generated code before execution, and require review for code that will be merged or deployed.
Control dependencies. Route package installs through an internal mirror with pinned versions and hashes, and disable install scripts unless approved.
Pilot in monitor mode, then enforce. Roll the egress policy and command allowlist out in log-only mode to one agent team, review what would have been blocked for two weeks, tune, then enforce. Roll back by switching the proxy and allowlist back to monitor mode, not by removing them.
Test adversarially. Add indirect prompt injection cases that attempt command execution, configuration changes and egress to the release test suite, and rerun them after every change to model, tools or autonomy. See the AI Agent Security Testing Checklist.

Evidence and assessment

Assessors should ask for evidence that the controls exist and are working, not only for a design document.

Configuration evidence: sandbox runtime and image definitions, seccomp or runtime class settings, network policy showing default-deny egress, proof that metadata endpoints and service account token mounts are blocked.
Approval evidence: the current command allowlist in version control with its change history, and approval records showing the exact command approved.
Logs per execution: agent identity, user or principal, session, code or command hash, approval decision, runtime, network destinations contacted, files written and exit status.
Alert on: execution attempts outside the sandbox service, egress denials, writes to agent configuration or approval files, package installs not served by the mirror, processes spawning shells inside interpreter sandboxes, and sandbox runs exceeding time or resource limits.

Metric	What it shows	Target
Percentage of agent code execution that runs in the isolated execution service	Coverage of sandboxing	100% for production agents
Agents with auto-approval enabled outside the version-controlled allowlist	Human gate bypass	Zero
Execution environments with reachable credentials (metadata, mounted tokens, inherited environment)	Blast radius of a successful injection	Zero, verified by test
Egress denials per thousand sandbox sessions, reviewed weekly	Attempted exfiltration or misconfigured tools	Investigated, trend understood
Code execution injection test cases passed before release	Pre-deployment assurance	All pass; test set growing
Agent framework and IDE extension versions with known code execution CVEs still deployed	Patch hygiene	Zero beyond the patch window

Mapping to other frameworks

Framework	Relevant IDs	How it relates to ASI05
OWASP Top 10 for LLM Applications 2025	LLM01, LLM05, LLM06	OWASP maps ASI05 to LLM01 and LLM05; LLM06 Excessive Agency covers giving the agent a shell at all. See the OWASP LLM Top 10 LLM05 Improper Output Handling Guide.
MITRE ATLAS	AML.T0051.001 Indirect, AML.T0050 Command and Scripting Interpreter, AML.T0081 Modify AI Agent Configuration, AML.T0105 Escape to Host, AML.T0072 Reverse Shell	Entry through injected content, execution, persistence through configuration, and breakout from the sandbox
MITRE ATLAS mitigations	AML.M0028 AI Agent Tools Permissions Configuration, AML.M0029 Human In-the-Loop for AI Agent Actions, AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data, AML.M0032 Segmentation of AI Agent Components, AML.M0033 Input and Output Validation for AI Agent Components	Tool scoping, approval, separation of untrusted data from execution, and validation gates
MITRE ATT&CK v20	T1059 Command and Scripting Interpreter (T1059.006 Python), T1611 Escape to Host, T1552.005 Cloud Instance Metadata API, T1195.002 Compromise Software Supply Chain	The post-execution behaviour defenders already detect in the SOC
NIST SP 800-53 Rev. 5	SC-39, SC-44, SC-7, CM-7, AC-6, SI-10, SI-7, SI-3, CM-5, CM-14, SA-11, SI-4, AU-12	Process isolation, detonation chambers for untrusted code, boundary protection, least functionality, input validation, integrity, access restrictions for change, developer testing and monitoring
NIST CSF 2.0	PR.PS-06, PR.IR-01, DE.CM-09, PR.PS-04, ID.RA-01	Secure development, environment protection, runtime monitoring, logging and vulnerability identification

The NIST and ATT&CK mapping is NHI Mgmt Group's own; OWASP's Appendix A maps ASI05 only to LLM IDs, the T11 threat and AIVSS.

Common pitfalls

Prefix-matched command allowlists. An allowlist that approves anything starting with a permitted command can be satisfied by a chained command. In the Gemini CLI prompt injection flaw, instructions in a README produced a command that began with an allowlisted tool and ran a second command without a prompt; it was fixed in version 0.1.14. Parse the full command, or require approval.
Code validation endpoints that execute. Features that "check" code by running it are execution endpoints. The Langflow CVE-2025-3248 exploitation abused an unauthenticated code validation endpoint in an agent builder, and attackers dumped environment variables before installing a botnet. Authenticate, isolate and patch agent platforms like any internet-facing application.
Sandboxes with a view of the network and the cloud. An isolated runtime that can reach internal registries, metadata endpoints or the internet is a pivot point, as the OpenAI and Hugging Face incident showed.
Agents that can edit their own guard rails. Writable settings, task files and allowlists let injected instructions switch approval off, as CVE-2025-53773 demonstrated.
Auto-approve as a convenience default. Continuous or "yes to all" modes remove the only human check; keep them for disposable environments with no credentials.

Practitioner checklist

List every path from model output to an interpreter, shell, package manager or deserialiser for each agent.
Remove eval, native object deserialisation and unused shell or install tools from production agents.
Run all agent code in ephemeral, non-root sandboxes with resource limits; use a microVM or user-space kernel for untrusted inputs.
Enforce default-deny egress through a logging proxy, and block instance metadata and token mounts in sandboxes.
Disable auto-approval; keep a version-controlled allowlist matched on the full parsed command.
Make agent settings, approval policies and MCP lists read-only to the agent.
Scan generated code for vulnerabilities and secrets before execution, and review code before merge.
Serve packages from a pinned internal mirror and disable install scripts by default.
Log every generation and execution with agent identity, approval and network destinations.
Add code execution injection tests to every release and keep agent frameworks and IDE extensions patched.

OWASP Agentic Top 10 ASI05 Guide