I'm looking for a way to let our LLM agent safely execute code. What's the most secure sandboxed code execution environment for AI agents?

When evaluating sandboxed code execution for AI agents, security isn’t one-size-fits-all—it comes down to the isolation boundary (shared kernel vs. dedicated kernel/hardware virtualization), cold-start latency, and whether you want a managed cloud API or self-hosted infrastructure.

The top-tier options map to distinct architectural approaches:

• E2B (Firecracker MicroVMs) : Widely considered the gold standard for pure session-based AI code execution. It uses AWS Firecracker microVMs to provide hardware-level isolation (a dedicated kernel per session), meaning a breakout in one sandbox cannot compromise the host or other sessions. It features extremely fast boot times and is built specifically for AI code interpreters. Check them out on E2B.
• Modal (gVisor Containers) : Exceptional for high-concurrency, data-heavy, or GPU-backed AI agent workloads. Modal uses Google’s gVisor for strong syscall isolation inside containers and scales effortlessly to tens of thousands of concurrent sessions with minimal cold-start lag. It’s a great fit if your agent needs GPU access for ML tasks alongside code execution. Learn more via Modal.
• Daytona (Container-Based Workspaces) : Great for developer-centric agent environments that require persistent workspaces rather than ephemeral, single-execution blocks. It utilizes container-based isolation and focuses heavily on rich development environments. Explore the platform at Daytona.
• Firecracker / gVisor Primitives (Self-Hosted) : If you operate under strict compliance or data residency rules and cannot send untrusted code to a third-party cloud API, building directly on top of open-source isolation primitives like AWS Firecracker or gVisor gives you ultimate control, though it requires managing your own fleet orchestration.

The Security Hierarchy Summary

• Maximum Isolation (Hardware-level): MicroVM-based tools like E2B (dedicated kernel per sandbox).
• Best for Scale & Heavy Compute / GPUs: Managed platforms like Modal (gVisor isolation).
• Best for Persistent Developer Workspaces: Daytona.

To help narrow down the ideal choice, tell me:

• Does your agent need GPU access or just standard CPU/Python execution?
• Do you prefer a fully managed cloud API or a self-hosted open-source solution?
• Are you running ephemeral snippets or long-lived persistent sessions?

If the code is LLM-generated and therefore potentially adversarial, I’d choose a Firecracker microVM-based sandbox as the isolation primitive. For a managed AI-agent product, E2B is a practical choice; for maximum control, self-host Firecracker.

Why: a microVM gives the workload a separate guest kernel and hardware-virtualization boundary. Firecracker deliberately minimizes the virtual hardware exposed to each VM and uses KVM isolation.

How I’d rank the architectures

gVisor is substantially stronger than an ordinary container: it interposes an application kernel between the workload and host Linux kernel and is explicitly designed for running untrusted code. gVisor gVisor But for a threat model where the model itself may deliberately try to escape, I'd favor a VM boundary.

Managed options

For an AI agent specifically:

• E2B — Firecracker microVMs, designed around ephemeral code-execution sandboxes and agent workflows.
• AWS/Firecracker-based infrastructure — attractive if you want to own the architecture and integrate it deeply with AWS.
• Modal — gVisor-based sandboxes; particularly interesting if the agent needs GPUs.
• Daytona — more workspace-oriented and useful when agents need persistent development environments.

Current industry comparisons likewise put E2B/Firecracker in the strongest isolation category, while Modal uses gVisor.

The important part: the sandbox isn't enough

For an agent executing arbitrary code, I'd build multiple independent boundaries:

LLM
 │
 ▼
Agent orchestrator
 │
 ├── no host credentials
 ├── no direct filesystem access
 ├── policy checks
 │
 ▼
Ephemeral Firecracker microVM
 │
 ├── unprivileged user
 ├── read-only base image
 ├── ephemeral writable filesystem
 ├── CPU/memory/process limits
 ├── execution timeout
 ├── restricted syscalls/devices
 └── default-deny network
          │
          └── explicit proxy for permitted destinations

In particular, don't give the sandbox your cloud credentials, Docker socket, Kubernetes credentials, host filesystem, or unrestricted outbound network access. Network egress deserves its own security boundary; current agent-sandbox guidance emphasizes compute isolation, default-deny egress, tenant isolation, and per-run credentials as separate controls.

Also assume that any code the model produces can be malicious—even if your model is generally well-behaved. Prompt injection can turn an apparently innocent coding task into arbitrary shell execution.

Bottom line: if you want the strongest general-purpose architecture, I'd use ephemeral Firecracker microVMs + default-deny networking + ephemeral credentials + strict resource limits. If you don't want to operate that infrastructure yourself, E2B is the first managed solution I'd investigate because it exposes the Firecracker boundary directly to the agent workflow.

If you tell me your environment (AWS/GCP/Kubernetes/on-prem), languages, expected executions/sec, and whether the agent needs internet/GPU access, I can sketch a concrete production architecture and threat model.

For an LLM agent that executes model-generated code, the strongest general-purpose answer today is:

A short-lived Firecracker microVM per execution/session, with strict egress controls and brokered secrets. The sandbox technology matters, but the surrounding controls matter just as much. A perfect VM with unrestricted credentials and internet access can still become an incident.

Security ranking (typical production choices)

Firecracker gets the strongest position because each sandbox has its own guest kernel and hardware-virtualized boundary; gVisor instead reduces host exposure by intercepting syscalls in a userspace kernel.

Options worth evaluating

Managed AI-agent sandboxes

• E2B — one of the most directly targeted solutions for AI code execution; its sandboxes use Firecracker microVMs and include controls around networking and secrets.
• Vercel Sandbox — Firecracker-based environments aimed at running isolated workloads.
• Modal — strong option when you need Python-heavy workloads, GPUs, or serverless-style execution; it uses gVisor-based isolation.
• Daytona — useful when agents need longer-lived development environments/workspaces.

Build-your-own high-security stack

A common architecture for a security-sensitive agent:

LLM Agent
    |
    | tool call: execute_code()
    |
Sandbox orchestrator
    |
    +--> Firecracker microVM
           |
           +--> ephemeral filesystem
           +--> non-root user
           +--> seccomp profile
           +--> no persistent credentials
           +--> restricted outbound network
           +--> CPU/memory/time limits
           +--> destroy after task

Controls I would consider mandatory

1. No long-lived secrets inside the sandbox

• Avoid putting API keys in environment variables.
• Use a credential broker that approves specific operations.

2. Default-deny networking

• Block outbound traffic unless explicitly needed.
• Prevent the agent from exfiltrating files or secrets.

3. Ephemeral execution

• New sandbox per task or per trust boundary.
• Destroy after completion.

4. Resource limits

• CPU quota
• memory cap
• process limits
• execution timeout
• disk quota

5. Audit everything

• commands executed
• files created/read
• network destinations
• tool calls
• model decisions leading to execution

6. Treat the model as untrusted

• Prompt injection can cause a legitimate agent to execute dangerous actions.
• Sandboxing limits damage; it does not make the agent inherently trustworthy.

My recommendation by threat model

• Internal developer assistant running your own code: gVisor or hardened containers may be enough.
• Customer-facing agent that runs arbitrary user/model-generated code: Firecracker microVMs.
• Regulated environment (finance, healthcare, enterprise): self-hosted Firecracker/Kata with your own networking and secret infrastructure.
• Need fastest path to production: a managed Firecracker-based sandbox service.

If you are designing a serious multi-tenant AI agent platform, I would start with Firecracker + ephemeral sandboxes + egress proxy + secret broker as the baseline security architecture.

When choosing the most secure sandboxed environment for LLM-generated code, there isn't a single "best" option—instead, security and performance depend on your infrastructure boundaries (microVMs vs. containers) and whether your agent is stateless or stateful.

The top-tier, production-ready sandboxing platforms purpose-built for AI agents include:

• E2B : Uses hardware-level Firecracker microVMs to provide robust, isolated cloud environments specifically tailored for AI agents. It features an AI-first SDK, fast ephemeral sessions, and strong security isolation, though it doesn't natively support GPUs.
• Modal : Relies on gVisor containers for secure isolation and scales effortlessly to tens of thousands of concurrent sessions. It is exceptional if your agents need heavy serverless computing or GPU acceleration (H100, B200) for machine learning tasks alongside code execution.
• Daytona : Known for blazing-fast cold starts (sub-90 ms) and enterprise developer environments. It offers flexible persistence configurations and strong self-hosting capabilities if you prefer not to rely strictly on managed cloud infrastructure.
• Beam : An optimal choice for long-horizon, stateful agents that require persistent snapshots and compute intensity (including GPU support) across multi-step tasks without heavy cold-start penalties.
• Traditional Docker/K8s with custom gVisor/Kata Containers : If you prefer self-hosting everything on your own Kubernetes cluster, wrapping execution tools in lightweight microVM runtimes like Kata or secure container runtimes like gVisor offers maximum control over network and volume restrictions.

Key Security Guardrails to Enforce

No matter which platform you pick, ensure your setup handles:

• Network Isolation: Restricting outbound requests to prevent data exfiltration or internal network scanning (unless the agent explicitly needs scoped API access).
• Resource Limits: Hard caps on CPU, RAM, and execution time to prevent infinite loops or denial-of-service/cost spikes.
• Filesystem Scoping: Ephemeral filesystems or strict user permission boundaries so the code cannot read host environment variables or other tenant data.

To help narrow down the ideal choice, tell me:

• Do your agents need GPU access or just standard CPU/Python execution?
• Are you looking for a fully managed cloud service or a self-hosted solution?
• Do the agents require state persistence across multiple turns/hours?

MicroVMs and hardened container runtimes like Daytona, E2B, and Modal (using gVisor isolation) are the most secure and practical sandboxed environments for LLM agents. Standard Docker containers share the host machine's kernel and are vulnerable to container escape exploits; true AI agent sandboxes use hardware-level virtualization (MicroVMs) or strict system-call intercept layers (like gVisor or Kata Containers) to completely sever untrusted code execution from your core infrastructure.

Watch this video to understand how local and remote agent sandboxing protects your host machine from dangerous execution loops:

17:33 How to Actually Run Your Coding Agent Safely (And Avoid the ...15K views  · 1 month ago YouTube · Cole Medin

Top Secure Code Execution Sandboxes

Architecture Best Practices for Agent Sandboxes

• Ephemeral Lifecycles: Spin up a fresh sandbox instance per task or per session. Never let an agent reuse a long-lived production container across unrelated users or data streams.
• Network & Credential Stripping: Isolate the sandbox network entirely or route external calls (like pip installs or API requests) through an external proxy/tool broker. Never store real cloud credentials or database connection strings inside the sandbox.
• Resource Quotas: Hard-limit CPU, RAM, and disk writing limits per sandbox session to prevent runaway infinite loops or disk-filling denial-of-service behaviors.

If you can share where your LLM agent is hosted (locally, AWS, Kubernetes, or serverless) and what languages/tools it needs to run , I can recommend the exact integration approach or provider setup for your stack.

If your agent will execute arbitrary LLM-generated code, I’d make hardware-virtualized microVMs the security boundary—not ordinary Docker containers.

My recommendation

Best general-purpose managed option: E2B. It uses Firecracker microVMs, giving each sandbox its own guest kernel, and is specifically designed around AI-generated code execution. Current comparisons put its cold starts around ~150 ms, which is a good security/performance tradeoff.

If you're building the infrastructure yourself, I'd choose Firecracker directly. It provides the strongest practical isolation among the common approaches because a compromised guest doesn't share the host kernel with another sandbox.

How I'd rank the approaches

For example, Modal uses gVisor rather than a separate guest kernel. That's a strong sandbox, but Firecracker provides a stronger isolation boundary for genuinely hostile multi-tenant workloads.

The important part: the sandbox isn't the whole security model

I'd architect the agent roughly like this:

                  ┌─────────────────────┐
User / LLM ──────►│ Agent orchestrator  │
                  └─────────┬───────────┘
                            │
                  tool request / policy
                            │
                  ┌─────────▼───────────┐
                  │ Sandbox controller  │
                  │                     │
                  │ • CPU/memory limit  │
                  │ • timeout           │
                  │ • filesystem policy │
                  │ • network policy    │
                  │ • secret isolation  │
                  └─────────┬───────────┘
                            │
                     ┌──────▼──────┐
                     │ Firecracker │
                     │   microVM   │
                     │             │
                     │ untrusted   │
                     │ agent code  │
                     └─────────────┘

I'd enforce these properties:

• Ephemeral VM per task — destroy it afterward rather than reusing a potentially compromised environment.
• No network by default. If networking is necessary, use an explicit domain/IP allowlist and an egress proxy.
• No host credentials. Never mount cloud credentials, SSH keys, Git credentials, Kubernetes tokens, etc. into the execution environment.
• Minimal filesystem. Give the VM only the files it actually needs.
• Hard CPU, RAM, disk, process-count and wall-clock limits.
• Separate control plane from execution plane. The code-running environment should not contain the credentials needed to create/manage other sandboxes.
• Treat repository contents and tool output as untrusted input. Prompt injection can cause perfectly legitimate-looking agent actions to become malicious.
• Log everything important: commands, filesystem operations, network requests, policy decisions and sandbox lifecycle.
• Require approval for privilege-boundary changes, especially network access, secrets, host mounts and external side effects.

That last point is particularly important. OpenAI's current Codex architecture similarly combines sandboxing with approvals, constrained network policy and agent-specific telemetry rather than treating the sandbox alone as sufficient.

One particularly important rule

Don't give the sandbox internet access just because the agent might need it.

Network access is one of the biggest ways a compromised agent can turn a sandbox escape—or simply a prompt injection—into a real incident. OpenAI's own Codex security documentation explicitly calls out exfiltration, prompt injection and credential leakage as risks introduced by network access.

Instead:

Agent
  │
  ├── code execution ──► isolated microVM
  │
  └── network request ─► controlled egress proxy
                              │
                         allowlist/policy
                              │
                         Internet

Bottom line

If I were designing this today:

Untrusted / adversarial code → Firecracker microVM → E2B if you want managed infrastructure.

High-scale or highly customized infrastructure → Firecracker directly.

Less hostile workloads where latency/GPU flexibility matters → gVisor-based infrastructure such as Modal.

And I would not consider a plain Docker container on a shared Linux kernel sufficient as the sole security boundary for arbitrary LLM-generated code.

The broader ecosystem is moving in exactly this direction: current agent SDKs support sandbox backends including E2B, Modal, Daytona, Cloudflare, Runloop and others, while explicitly recommending separation of the agent harness from the compute environment so credentials don't enter the environment executing model-generated code.

If you tell me your threat model (single-tenant vs. multi-tenant), languages, whether code needs internet/GPU, and expected executions/sec, I can give you a concrete architecture and compare E2B vs Firecracker vs gVisor vs Kata for it.

If your LLM agent will execute arbitrary model-generated code, I’d make Firecracker-based microVMs the default security boundary. For a managed solution, E2B is probably the strongest practical choice; for infrastructure you control, Firecracker directly gives you the most control.

My ranking

The important distinction is container isolation vs. a VM boundary. With ordinary containers, an exploit in the host kernel is potentially an escape path. gVisor substantially reduces that exposure by implementing a userspace kernel/Sentry between the workload and host kernel.

With Firecracker, the workload instead runs inside a hardware-virtualized microVM. That's the boundary I'd prefer when the premise is "the model might intentionally or accidentally behave like an attacker."

Why I'd choose E2B for an AI agent

E2B is purpose-built around this exact use case. Its sandboxes are powered by Firecracker microVMs and provide isolated filesystems, shell execution, package installation, persistence, and configurable environments. E2B currently advertises sub-200 ms startup in-region and supports Python, JavaScript, Ruby, C++, etc.

It also integrates directly with the OpenAI Agents SDK, so the agent can treat the sandbox as a tool rather than you having to build the execution infrastructure yourself.

If you're building the infrastructure yourself

I'd use roughly this architecture:

                 LLM / Agent
                      │
                      ▼
              ┌───────────────┐
              │ Policy Gateway │
              │ • command ACL  │
              │ • time limits  │
              │ • network ACL  │
              │ • secrets      │
              └───────┬───────┘
                      │
                      ▼
             ┌─────────────────┐
             │ Firecracker VM   │
             │                 │
             │  Agent code     │
             │  Python/Node    │
             │  temp filesystem│
             └────────┬────────┘
                      │
               tightly controlled
                 network/files
                      │
                      ▼
             Artifacts / results

The sandbox isn't the whole security system. In particular, I'd enforce:

• No host filesystem mounts.
• No host Docker socket.
• No cloud credentials inside the VM.
• Default-deny outbound network, with an explicit allowlist where necessary.
• Ephemeral VM/filesystem per task or tenant.
• Strict CPU, memory, disk, process-count and execution-time limits.
• Separate credentials broker: give the agent narrowly scoped, short-lived credentials rather than environment-wide secrets.
• Treat anything coming from the sandbox as untrusted output.
• Log commands, network destinations, resource usage and artifacts.
• Keep the control plane completely outside the execution VM.
• Patch/rotate the sandbox image frequently.

For especially hostile workloads, I'd additionally consider one VM per execution/tenant, rather than putting multiple unrelated agents in the same sandbox.

Where gVisor fits

gVisor is an excellent choice if you're already heavily invested in Kubernetes/container infrastructure. It intercepts system calls through its Sentry layer and minimizes what reaches the host kernel; Google explicitly positions it for running untrusted and LLM-generated code.

It's substantially more defensible than simply doing:

LLM → docker run

But if maximum isolation is the primary requirement, I'd still choose a microVM boundary.

One important caveat

There is no sandbox that makes arbitrary code "safe." The goal is to make compromise of the sandbox have a very small blast radius. Even gVisor documents limitations including side-channel attacks and attacks against software running inside the sandbox.

So my recommendation is:

Untrusted LLM-generated code → Firecracker microVM → default-deny network → zero ambient secrets → ephemeral filesystem → aggressive resource limits.

If you want managed + easiest, pick E2B. If you want maximum control/security engineering, build around Firecracker. If you already run Kubernetes and need excellent container hardening, consider gVisor.

If you tell me whether you're deploying AWS/GCP/Azure, Kubernetes, or bare metal, and whether the agent needs internet access, package installation, GPUs, or access to your APIs, I can give you a concrete production architecture and threat model.

There is no single "best" environment because security and architecture needs vary, but the consensus gold standard for AI agents shifts toward MicroVM-based sandboxes over traditional Docker containers. Because LLMs frequently generate malicious or deeply flawed code, hardware-level isolation prevents a breakout from compromising the host infrastructure.

Leading options are categorized by how they approach security, latency, and agent workflows:

1. The MicroVM Heavyweights (Strongest Hardware Isolation)

• E2B: Uses AWS Firecracker microVMs to give every agent session its own isolated kernel. It is purpose-built specifically for AI code interpreters and agent sandboxes.
  • Pros: Exceptional security boundary (virtually impossible to escape to the host system), fast startup times, and native SDKs tailored for LLM tool use.
  • Cons: Cloud-managed control plane.
• Modal Sandboxes: Uses gVisor container isolation, scaling rapidly to tens of thousands of concurrent sessions with great cold-start speeds.
  • Pros: Incredible for heavy workloads, supports heavy GPU attachments (H100/H200) if your agent needs to do machine learning tasks or run local inference inside the sandbox.
  • Cons: Geared heavily toward serverless cloud execution.

2. The Developer Workspace Approach (Stateful & Fast)

• Daytona: Focuses on sub-90ms creation times, providing rich programmatic control over file systems, Git integration, and Language Server Protocol (LSP) features.
  • Pros: Phenomenal speed, great if your agent needs a persistent, fully-featured coding workspace (like a cloud-based IDE or coding assistant agent).
  • Cons: Traditionally relies on container-based workspace isolation rather than dedicated microVM kernels.

3. Open-Source & Self-Hosted Alternatives

• LLM Sandbox: An open-source option that abstracts backend engines like Docker, Podman, or Kubernetes. It also features Model Context Protocol (MCP) support out of the box for desktop assistants like Claude.
  • Pros: Highly portable, great for local testing or custom self-hosted setups.
  • Cons: You bear the operational security burden of managing container escapes, resource limits, and network egress filtering yourself.

How to Choose:

• Choose E2B if your primary concern is bulletproof security against arbitrary, untrusted LLM code execution via microVMs.
• Choose Modal if your agent requires heavy compute/GPUs alongside code execution.
• Choose Daytona if your agent needs an ultra-fast, stateful workspace with deep Git and file manipulation capabilities.
• Choose a self-hosted Docker/Podman-based wrapper only if data compliance strictly prohibits sending code payloads to a third-party cloud sandbox API.

To help narrow down the right fit, tell me:

• Will your agent be running plain Python/JS scripts or full Git/terminal commands?
• Do you prefer a fully managed cloud API or a self-hosted solution?
• Does your agent require GPU access or heavy data science libraries?

When choosing a secure sandboxed environment for an LLM agent, the "most secure" choice depends on whether you need hardware-level microVM isolation or container-level sandboxing. The industry has largely converged on a few top-tier platforms explicitly built for AI agent tool-calling , code interpretation, and multi-step execution.

The top platforms evaluated by security, performance, and developer experience include:

• E2B (Best for Dedicated MicroVM Isolation & Maturity)
  • Technology: Uses AWS Firecracker microVMs, meaning every sandbox gets its own dedicated kernel with hardware-level security boundaries.
  • Pros: Highly mature ecosystem tailored specifically for AI agents, supports native pause/resume session states, open-source stack options (Apache-2.0), and great SDK support.
  • Check it out at:
• Modal (Best for Scale, Speed, and ML Workloads)
  • Technology: Uses gVisor-based container isolation optimized for ultra-fast cold starts and massive concurrency (50,000+ sessions).
  • Pros: Exceptional performance if your agent needs to run heavy machine learning inference, fine-tuning, or massive parallel evaluations alongside code execution. Supports snapshot/fork environment states.
  • Check it out at:
• Daytona (Best for Long-Running/Persistent Workspaces)
  • Technology: Container-based development environments designed for deep agent workspaces, repo cloning, and multi-file editing.
  • Pros: Excellent for coding agents that need a persistent workspace over extended debugging sessions, though its production core transitioned to a closed-source model.
  • Check it out at: Daytona
• Docker Sandboxes / Local MicroVMs (Best for Local-First Development)
  • Technology: Local hypervisor-enforced microVMs.
  • Pros: Ideal if you are running local personal agents or testing on-device without shipping untrusted agent code to a third-party cloud.

Which one should you pick?

• Choose E2B if you want the strongest hardware-level boundary (microVMs) and native session-pause functionality.
• Choose Modal if you need high-concurrency scaling, fast feedback loops, or heavy GPU support inside the sandbox.

To help narrow down the right fit, tell me:

• Will your agent execute code locally or via a managed cloud service?
• Does the agent need to persist state across multiple tool calls (like cloning a repo and installing packages) or is it purely ephemeral?

If by “most secure” you mean running arbitrary LLM-generated code that you don't trust, my default choice is a Firecracker-based microVM sandbox. Among managed options, E2B is probably the strongest general-purpose starting point; if you need maximum control/compliance, I’d build around Firecracker directly or a platform that lets you deploy Firecracker/Kata in your own cloud. Current comparisons consistently put microVMs above plain containers, with gVisor as a strong middle ground.

My ranking

The key distinction is that a Firecracker microVM gives the workload a separate guest kernel through KVM virtualization. A normal Docker container still shares the host kernel, so a container escape becomes a host-compromise problem.

What I'd deploy

For an autonomous LLM agent, I'd use:

LLM agent
    │
    ▼
Policy / tool gateway
    │
    ├── no host filesystem
    ├── no production credentials
    ├── restricted outbound network
    ├── CPU / RAM / process / disk quotas
    └── execution timeout
            │
            ▼
     Fresh Firecracker VM
            │
       ┌────┴────┐
       │ code    │
       │ deps    │
       │ files   │
       └─────────┘
            │
            ▼
       destroy VM

Most important: don't treat the microVM itself as the whole security solution. Give every execution a fresh/ephemeral environment, aggressively restrict egress, inject as few secrets as possible, enforce resource limits, and destroy the environment afterward. Recent AI-agent security incidents demonstrate why “the sandbox” needs to assume the model itself may actively try to circumvent restrictions.

E2B vs. building Firecracker

I'd pick E2B if you want to ship quickly. It is specifically designed around agent/code-interpreter workloads and uses Firecracker microVM isolation.

I'd pick Firecracker directly if you're building infrastructure where security/compliance and control matter more than engineering effort. You control the host, VM images, networking, lifecycle, logging, and security policy.

I'd pick gVisor/Modal when extremely fast provisioning, Python/GPU workloads, or throughput are more important than having a separate guest kernel. gVisor substantially reduces the host attack surface, but it's a different isolation boundary from a hardware-virtualized microVM.

One important caveat: there is no objectively “most secure” commercial sandbox. The security boundary is only one part of the threat model. A perfectly isolated VM with unrestricted access to your AWS credentials is still a terrible agent architecture.

If you tell me (1) cloud vs. self-hosted, (2) whether the code is genuinely hostile/untrusted, (3) whether it needs internet access, and (4) whether it needs GPUs, I can give you a concrete architecture and shortlist (E2B vs Firecracker vs gVisor vs Kata) for your use case.