AWS AgentCore vs Daytona vs E2B (2026): Where Should Agent Code Run?

Quick verdict

When an AI agent writes code and runs it, that code is untrusted by definition. It was generated by a model that can be manipulated through prompt injection. The question "where should agent code run?" is really "how do I contain untrusted code that has access to my tools, data, and network?"

Short version:

Already on AWS, need IAM, VPC, CloudWatch, long sessions, plus memory, identity, and policy in one place: AWS Bedrock AgentCore.
You want the strongest off-the-shelf isolation for untrusted code, with a multi-cloud SDK: E2B, which runs on Firecracker microVMs.
You want persistent workspaces, Computer Use, fastest developer experience, and GPU sandboxes: Daytona.
You are building a coding agent that must reason and execute: commonly a hybrid, an AgentCore or framework-based reasoning runtime plus a dedicated execution sandbox (E2B, AgentCore Code Interpreter, or a Lambda microVM).
Data sovereignty for an AU or SG regulated business: prefer AgentCore inside your own VPC, or a bring-your-own-cloud sandbox, over a default multi-tenant SaaS sandbox.

The single most important clarification in this post: these three are not the same category. AgentCore is a broad agent operations platform. Daytona and E2B are focused code-execution sandboxes. Comparing them as equals is misleading. What we will do instead is compare the slice that genuinely overlaps, where model-generated code executes, and then be honest about everything AgentCore does that the pure-play sandboxes do not attempt.

This is written for technical founders, CTOs, platform leads, AI engineers, and in particular AU and SG teams with real data-residency and audit obligations.

AgentCore is broader than Daytona and E2B

Read this before the matrix, because it reframes everything.

AWS Bedrock AgentCore is not a sandbox product. It is a suite: a Runtime for hosting agents, plus Memory, Identity, Gateway (tool and API access), Browser (managed headless browsing), Code Interpreter (the actual sandbox slice), Policy, and Evaluation. It is an agent operations platform where code execution is one module among many.

Daytona is a sandbox for persistent agent and developer workspaces. Its job is to give an agent a place to live and work, quickly, with good developer experience.

E2B is a sandbox purpose-built for executing untrusted, model-generated code with strong isolation.

So the honest comparison is: AgentCore Code Interpreter (and to some degree AgentCore Runtime's per-session microVMs) versus Daytona versus E2B, on the axis of where LLM-generated code runs. On that axis they are genuinely comparable. On the broader axis of "run, secure, remember, and govern a fleet of agents," AgentCore is playing a different and larger game, and Daytona and E2B do not claim to compete there. We will not pretend otherwise.

Category clarity matrix

Figures are directional, drawn from third-party sources in mid-2026, and must be re-verified before publication.

Product	What it actually is	Isolation model	Session model
AWS Bedrock AgentCore	Runtime plus Memory, Identity, Gateway, Browser, Code Interpreter, Policy, Eval	Runtime: per-session microVM; Code Interpreter: containerized sandbox with IAM	Sessions up to ~8 hours; idle wait often not billed (active CPU)
Daytona	Persistent agent and developer workspaces	Docker containers (shared host kernel)	Persistent; snapshots and fork; reported ~90ms create
E2B	Untrusted code execution for agents	Firecracker microVMs (dedicated kernel)	Session-based, now with pause/resume and snapshots; reported ~150ms create

The isolation column is the heart of the security story. A shared-kernel container (Daytona's default model) has a larger attack surface for kernel-level escape than a microVM (E2B and AgentCore Runtime), which virtualizes the kernel per instance. That does not make Daytona insecure, but it is a real trade-off: Daytona optimizes for speed and developer experience, E2B optimizes for isolation of untrusted code, and AgentCore folds microVM isolation into a broader AWS-governed platform.

Threat model: from prompt to shell to exfiltration

Design the runtime around the attack chain, not the happy path:

Prompt injection. A malicious input convinces the agent to run attacker-chosen code.
Code execution. The agent runs that code inside your sandbox.
Privilege and access. The code tries to read secrets, environment variables, or the cloud instance metadata service.
Network exfiltration. The code attempts to send data out, often via DNS or an outbound HTTP call to an attacker endpoint.

Security research in 2026 highlighted DNS-based exfiltration and credential-access paths in code-interpreter style sandboxes. In at least one case, AWS treated the observed network behavior as intended and responded with hardening guidance rather than a patch (directional; include as a risk section and verify the specifics before publishing). The lesson is not "AWS is unsafe." The lesson is that every sandbox needs an explicit egress and secrets policy, because default network behavior is rarely locked down enough for untrusted code.

The strongest production pattern, demonstrated by teams like Browser Use migrating to AgentCore, is: the control plane holds all secrets, the sandboxes run with zero standing credentials, network egress is restricted to an allowlist, and each session gets ephemeral scratch space (Browser Use reported a 1 GB /mnt/workspace per session with a zero-credential microVM model). Reproduce that pattern regardless of which vendor you pick.

Deep dive: AWS Bedrock AgentCore

What it is. A managed agent operations platform, generally available since around October 2025 and expanding regions through 2026 (verify current APAC availability). The Code Interpreter runs Python, JavaScript, and TypeScript, integrates with CloudTrail for audit, and can access files in S3.

Strengths. For an AWS-committed team, AgentCore's advantage is integration and governance. Identity flows through IAM, network isolation through your VPC, audit through CloudTrail, and observability through CloudWatch and OpenTelemetry. Sessions can run long (up to roughly 8 hours), which suits agents that do sustained work, and idle time is often not billed because pricing is oriented around active CPU. Crucially, memory, identity, policy, and evaluation live in the same platform, so you are not stitching five vendors together.

Trade-offs. You are committing to AWS. Pricing has more moving parts than a single per-sandbox rate (see pricing section). And, as the threat model notes, the default network posture of the code interpreter needs deliberate hardening; treat AWS's guidance as a starting checklist, not a finished configuration.

Choose AgentCore if you are on AWS, need long sessions, and want isolation plus identity, memory, and policy governed by controls you already operate.

Deep dive: Daytona

What it is. A platform for persistent agent and developer workspaces, historically open source (AGPL), with reported traction around 72.5K GitHub stars, a $24M Series A, and a claimed $1M run rate in under three months (all directional). It offers GPU sandboxes (an H100 rate around $3.95/hr was cited) and Computer Use across Linux, Windows, macOS, and Android.

Strengths. Speed and developer experience. Reported sandbox creation around 90ms, snapshots and forking, and persistent workspaces make it excellent for interactive coding agents and for workflows where an environment should survive between steps. The Computer Use breadth is unusual.

Trade-offs. Two important ones. First, isolation: Daytona's default is Docker containers with a shared host kernel, which is a weaker boundary for untrusted code than a microVM. Second, and significant for 2026 planning: Daytona moved its production codebase closed-source around June 2026, the open-source repository is reported as unmaintained, and while runners can be deployed via Helm, the control plane is Daytona-hosted (verify current licensing and self-host reality). For a team that adopted Daytona partly for its open-source posture, that shift changes the ownership calculus.

Choose Daytona if you need fast, persistent workspaces, Computer Use, or GPU sandboxes, and your code-execution risk is moderate or you add your own isolation layer, and you are comfortable with the hosted control plane and current licensing.

Deep dive: E2B

What it is. A sandbox purpose-built for running untrusted, model-generated code, built on Firecracker microVMs (the same virtualization family behind AWS Lambda). Reported metrics include over 1 billion sandboxes started, a "94% of Fortune 100" usage claim, 3.5M+ monthly SDK downloads, roughly 12.5K stars, and around $32M total funding including a Series A led by Insight (all directional).

Strengths. Isolation is the headline. Firecracker gives each sandbox a dedicated virtualized kernel, which is the strongest off-the-shelf boundary in this comparison for untrusted code. Pause and resume preserves memory state, snapshots are available through the SDK, and the multi-cloud SDK means you are not locked to one hyperscaler. Reported creation time around 150ms is slightly slower than Daytona's containers but is the cost of stronger isolation.

Trade-offs. E2B is focused: it runs code well, but it is not an agent operations platform, so you bring your own memory, identity, and policy layers. Self-hosting and bring-your-own-cloud maturity should be verified; at least one source suggests BYOC is not fully self-serve. And as a SaaS by default, its multi-tenant model may not satisfy strict data-residency requirements without a BYOC or dedicated arrangement.

Choose E2B if untrusted-code isolation is your top priority, you want a multi-cloud SDK, and you will supply the surrounding memory, identity, and governance yourself.

Cost models compared

The three price on different units, which makes head-to-head numbers misleading unless you model your own concurrency.

AgentCore prices around active compute: a reported ~$0.0895/vCPU-hour plus ~$0.00945/GB-hour, per second, with idle time often free (re-verify on the AWS pricing page, especially by APAC region). This rewards bursty, long-but-idle agent sessions.
Daytona prices around workspace and GPU hours, which rewards persistent, actively used environments but can accumulate if workspaces are left running.
E2B prices around sandbox runtime, with the isolation of microVMs baked in.

Beware vendor cost tables. One comparison modeled 200 concurrent sandboxes and produced figures like ~$16.8k on a PaaS plan versus lower on BYOC (directional and vendor-biased). Do not treat any such table as gospel. The only reliable approach is to model your own steady-state and peak concurrency, session duration, and idle ratio against each pricing unit. Pricing in this category is genuinely opaque, so the actionable advice is: build a small spreadsheet with your real concurrency profile before committing.

Security hardening checklist

Apply these regardless of vendor:

Zero standing credentials in the sandbox. Keep secrets in the control plane; hand the sandbox only short-lived, scoped tokens when strictly needed.
Egress allowlist. Deny outbound by default. Permit only the specific destinations the workload needs. This is your main defense against DNS and HTTP exfiltration.
Block the instance metadata service. Prevent code from reaching the cloud metadata endpoint to steal instance credentials.
Ephemeral, per-session storage. Reset scratch space between sessions; do not let one run's artifacts leak into another.
Prefer microVM isolation for untrusted code. Use E2B or AgentCore Runtime microVMs over shared-kernel containers when the code is genuinely untrusted.
Audit everything. Route execution and network logs to an audit sink (CloudTrail and CloudWatch on AWS, or your SIEM elsewhere).
Data residency. Confirm where sandbox execution and logs physically live. For AU or SG obligations, pin execution to an in-region VPC or a BYOC arrangement.

Decision tree and hybrid architectures

Most serious builds are hybrids. A few patterns:

Reasoning runtime plus execution sandbox. A coding agent reasons in one layer (an agent framework or AgentCore Runtime) and executes generated code in a dedicated sandbox (E2B or AgentCore Code Interpreter). Keeping reasoning and execution separate limits blast radius and lets you harden the execution tier independently.
AWS-native stack. AgentCore Runtime for the agent, AgentCore Code Interpreter for execution, Memory and Identity for state and auth, all inside your VPC. This is the cleanest option for AWS-committed regulated teams because governance is uniform.
Multi-cloud with strong isolation. E2B for execution behind whatever reasoning framework you prefer (see our frameworks post on LangGraph, CrewAI, Mastra, and Strands), with your own memory and identity layers.
Interactive or GPU-heavy developer agents. Daytona for persistent workspaces and Computer Use, accepting the container isolation trade-off or layering additional controls, and factoring in its closed-source shift.

The organizing principle mirrors our frameworks guidance: standardize the runtime, sandbox, and observability layer as a deliberate platform decision, and do not let it be an accident of whichever demo shipped first.

FAQ

Is AgentCore a competitor to Daytona and E2B? Only on the narrow slice of running model-generated code. AgentCore is a full agent operations platform; Daytona and E2B are focused sandboxes. Compare them on execution isolation, then recognize AgentCore does much more around it.

Which is most secure for untrusted code? MicroVM isolation (E2B, and AgentCore Runtime microVMs) is a stronger boundary than shared-kernel containers (Daytona's default). But configuration matters more than the label: an unhardened microVM with open egress is worse than a carefully locked-down container.

Do I need a sandbox if I already use an agent framework? Almost always yes. Frameworks decide how the agent reasons; they do not safely contain untrusted code it generates. That containment is the sandbox's job.

What about Modal or Vercel Sandbox? Credible adjacent options worth a look, but outside this three-way comparison. Treat them as "also consider" based on your stack.

Is Daytona still open source? As of around June 2026, the production codebase reportedly went closed-source and the OSS repo is unmaintained, with the control plane Daytona-hosted (verify current status). If open-source ownership was your reason for choosing it, revisit that decision.

We have AU/SG data-residency rules. What is safest? Prefer AgentCore inside your own in-region VPC, or a bring-your-own-cloud sandbox arrangement, over default multi-tenant SaaS sandboxes. Confirm where both execution and logs reside.

Conclusion

"Where should agent code run?" is a security question first and a convenience question second. AgentCore wins when you are on AWS and want isolation, identity, memory, and policy governed together. E2B wins when isolating untrusted code is the priority and you want a multi-cloud SDK. Daytona wins for fast, persistent, interactive workspaces, provided you accept its container isolation trade-off and its 2026 shift toward a closed, hosted model. For most real coding agents, the answer is a hybrid: reason in one layer, execute in a hardened sandbox in another, with zero standing credentials and a strict egress policy in both.

For AU and SG regulated businesses, the safest default is execution pinned to a VPC and region you control, with audit wired in from day one. If you are deciding between a demo-grade sandbox and a production-grade isolation architecture, that gap is exactly where an engineering-led readiness review earns its cost.