Arbitrary Code Execution in AI Agents: Where the Boundary Breaks

Arbitrary code execution means an attacker can cause a system to run code or commands outside the intended program logic. In an AI agent, the path may not look like a classic memory-corruption exploit. Untrusted text can influence a shell command, package install, generated script, tool argument, or unsafe deserializer. The security question is the same: what authority does the resulting process have?

Trace the route from text to execution

List every component that can turn model output into an effect: shell tools, notebook kernels, code interpreters, package managers, CI runners, browser downloads, plugin loaders, and custom functions. Mark where untrusted user input, retrieved content, or tool responses enter the path. Then record the process identity, filesystem scope, network access, secrets, and downstream targets.

The prompt injection route matters when content can change the agent's proposed command. Prompt injection and code execution are not synonyms; one is an influence path, while the other is an execution outcome.

Remove ambient authority

Run generated code in an isolated, disposable environment with a narrow working directory, no production credentials, restricted network access, resource limits, and a short lifetime. Mount inputs read-only when possible and copy approved outputs out after validation. Do not rely on the generated program to enforce its own limits.

MITRE's CWE-94 describes improper control of generated code. The agent-specific implementation may be new, but the need to separate data from executable instructions is not.

Validate commands and tool arguments

Parse structured actions before execution. Compare the normalized command, executable, arguments, paths, destination, and requested privilege against policy. Deny shell metacharacters or indirect launchers where the interface does not require them. Prefer narrow tools such as 'read this file' or 'run this named test' over unrestricted shell access.

Use AI agent threat modeling to locate the execution boundary and downstream blast radius. Include package scripts and model-loading code; both can execute code before the apparent task begins.

Test with harmless canaries

Place a marker outside the allowed workspace, expose a mock secret, and configure a blocked destination. Feed the agent realistic tasks with misleading text in files, logs, or retrieved pages. Verify filesystem changes, processes, network requests, tool arguments, and final target state. Add allowed tests so the sandbox still supports the intended workflow.

The OWASP Agentic AI Top 10 guide helps connect excessive tool authority and control bypass to concrete tests. Record the exact agent, policy, image, and fixture versions.

Respond as an execution incident

If unauthorized code ran, stop the workload, revoke exposed credentials, isolate affected hosts, preserve logs, and identify persistence or downstream changes. Rebuild disposable environments from trusted images rather than attempting to clean an unknown state. Fix the earliest enforceable boundary, then rerun the original fixture and adjacent variants.

AgentGuard can help review agent tools and runtime control points; host containment and forensic response remain separate responsibilities. Test an execution boundary using a harmless target before permitting broader commands.

NIST's Application Container Security Guide covers risks in container images, registries, orchestrators, and runtime configuration. A container is only part of the boundary; verify its mounts, capabilities, network, secrets, and host integration.

Do not log raw secrets or full sensitive payloads while investigating. Preserve hashes, command metadata, policy decisions, process trees, destinations, and the minimum content needed to reproduce the path. If the runtime shared a host or credential with other workloads, expand the investigation to those identities and targets. The absence of a changed repository file does not rule out network, process, or credential effects.

Egress policy deserves its own test. A sandbox that blocks host files but permits unrestricted outbound traffic can still download a second-stage payload, publish captured data, or reach a cloud metadata service. Start with no network, then allow named destinations and methods required by the task. Resolve redirects inside the policy boundary and protect private address ranges. Record DNS and connection attempts for denied cases without automatically retrying them through another tool. Test the rule after dependency or package changes, because legitimate build behavior can quietly expand the required destination set.