Unexpected Code Execution: When Your Agent Becomes a Shell (ASI05)

This is post #5 of the . But when agents can both generate AND execute code without you in the loop, the stakes are even higher.

You ask your coding agent to fix a failing unit test. It generates a patch, installs a dependency, runs the test suite. All good.

Except the "dependency" it installed was backdoored. And the "test suite" it ran included a shell command that opened a reverse shell to an attacker's server. Your agent did exactly what it was told. It just didn't know who was doing the telling.

Welcome to ASI05: Unexpected Code Execution. Where prompt injection meets exec().

What Makes This Different From Regular RCE?

Traditional RCE exploits a bug in your software. A buffer overflow. A deserialization flaw. Something breaks in a way the developer didn't anticipate.

Agent-based RCE is different. The code execution is the feature. Your agent is designed to generate and run code. That's its job. The vulnerability isn't that code can execute. It's that the wrong code executes, and nobody checked before it ran.

And here's what makes it specifically dangerous in agentic systems:

• The agent generates code in real-time, so static analysis of your codebase won't catch it


• The agent has tool access, so generated code can call APIs, access filesystems, and reach networks


• The agent operates autonomously, so there's no human reviewing the code before execution


• The agent can chain multiple steps, turning three harmless operations into one devastating exploit

OWASP puts it bluntly: "Prompt injection, tool misuse, or unsafe serialization can convert text into unintended executable behavior."

Real Attacks That Have Already Happened

This isn't theoretical. Let me walk you through the incidents.

1. AutoJack: A Single Web Page RCEs Your Agent Host

In June 2026, Microsoft disclosed and is a command injection vulnerability in VS Code's agentic AI functionality. An unauthorized attacker can execute arbitrary code over a network without any user interaction or authentication. Critical severity.

Think about that. Your developer's IDE. Running an agent. Exploitable remotely. No clicks needed.

4. Replit "Vibe Coding" Runaway

During automated "vibe coding" tasks, agents generate and execute unreviewed install or shell commands in their own workspace. OWASP cites the Replit case where an agent deleted or overwrote production data while attempting self-repair tasks. No attacker needed. Just an unsupervised agent with too much access.

5. AWS AgentCore Sandbox Escape Research

Even purpose-built sandboxes aren't perfect, even if they are from AWS. In March 2026, researchers at Palo Alto for an incomplete blocklist in the install_packages() method that could allow command injection within the sandbox.

The lesson isn't "don't use sandboxes." It's "sandboxes are necessary but not sufficient."

Why "Just Sandbox It" Isn't Enough

Every conversation about agent code execution ends with someone saying "just run it in a sandbox." And yes, you absolutely should. But sandboxes alone don't solve the problem:

• Sandboxes can have escape vulnerabilities (AutoJack, AgentCore DNS escape)


• The agent may need legitimate access to resources inside the sandbox (databases, APIs) that an attacker can abuse


• Sandboxes don't prevent logic-level damage (deleting data the agent legitimately has access to)


• Sandboxes don't catch code that looks correct but contains a backdoor (hallucinated code with hidden functionality)

You need defense in depth: sandbox the execution, validate the code before it runs, limit what the sandbox can reach, and monitor what it does.

Mitigating Unexpected Code Execution on AWS

1. Amazon Bedrock AgentCore Code Interpreter

The audit logging of all executions

import boto3



# 1. Network isolation is a property of the code interpreter RESOURCE,

#    set at creation on the CONTROL plane. It is not a session flag.

control = boto3.client("bedrock-agentcore-control")



ci = control.create_code_interpreter(

    name="agent-sandbox",

    executionRoleArn="arn:aws:iam::123456789012:role/AgentCIExecutionRole",

    networkConfiguration={"networkMode": "SANDBOX"},  # SANDBOX = no outbound. Use VPC for controlled egress.

)

code_interpreter_id = ci["codeInterpreterId"]



# 2. Sessions and execution run on the DATA plane.

dp = boto3.client("bedrock-agentcore")



session = dp.start_code_interpreter_session(

    codeInterpreterIdentifier=code_interpreter_id,

    name="agent-session-1",

    sessionTimeoutSeconds=60,   # default 900 (15 min), min 60, max 28800 (8 hrs)

)

session_id = session["sessionId"]



# 3. Execute. code and language go INSIDE `arguments`.

response = dp.invoke_code_interpreter(

    codeInterpreterIdentifier=code_interpreter_id,

    sessionId=session_id,

    name="executeCode",

    arguments={"language": "python", "code": agent_generated_code},

)



# 4. The result is a stream. Iterate it.

for event in response["stream"]:

    if "result" in event:

        out = event["result"].get("structuredContent", {})

        print(out.get("stdout"), out.get("stderr"), out.get("exitCode"))

Critical: Use NETWORK_ISOLATED mode. The DNS escape research showed that even "isolated" sandboxes can leak data via DNS queries if you don't lock that down.

2. Lambda for Ephemeral Execution

If you can't use the AgentCore Code Interpreter, gives you:

• 
  No shared host - each task runs on its own kernel


• 
  Task-level IAM roles - separate from your agent's role


• 
  VPC security groups - can deny all egress


• 
  Read-only root filesystem - prevents persistence
  

{

  "taskDefinition": {

    "containerDefinitions": [{

      "name": "code-sandbox",

      "readonlyRootFilesystem": true,

      "user": "1000:1000",

      "linuxParameters": {

        "capabilities": { "drop": ["ALL"] }

      }

    }],

    "networkMode": "awsvpc"

  }

}

Combine with a security group that allows zero egress and you have a container that can compute but can't phone home.

4. Separate Code Generation from Code Execution

This is the architecture-level mitigation. Don't let the same process that generates code also execute it. Use )

5. Static Analysis Gate Before Execution

Run a lightweight SAST pass on agent-generated code before it executes. For Python, rules or pipe code through - What happens when an agent's long-term memory gets corrupted, and how Amazon Bedrock Knowledge Bases, S3 Object Lock, and CloudTrail help you build tamper-evident memory systems.

I would be very interested to hear your thoughts or comments, so please feel free to ping me on , or drop them below. If you've dealt with sandboxing agent-generated code in production, I'd love to hear what worked (and what didn't).

Onward!!