ADR: Running AI-Generated Code — Lambda MicroVMs vs. Isolated Containers

AI agent platforms that execute code — whether Python generated by the model for data analysis, financial simulation scripts, or custom tools invoked via function calling — face a security problem that cannot be solved by input sanitization. Code generated by an LLM is, by definition, not auditable in real time. The model can produce code that attempts to read environment variables, make unexpected syscalls, or — in multi-tenant scenarios — access shared memory structures if isolation is insufficient.

The relevant threat model has three primary vectors: (1) sandbox escape — malicious or malformed code that exits the execution context and reaches the host or other tenants; (2) lateral exfiltration — code that reads data from neighboring sessions via shared memory, temporary filesystem, or environment variables inherited from previous executions on the same worker; (3) unwanted persistence — code that leaves artifacts (processes, files, open connections) that affect subsequent executions.

In the financial context, the risk is even more concrete: imagine an agent generating and executing a Monte Carlo simulation with a client's proprietary portfolio data. If the sandbox does not adequately isolate, a subsequent execution by another tenant may inherit state, variables, or network connections from the previous session. This is not hypothetical — it is exactly the vector that motivated AWS's design of Firecracker for the original Lambda and for Fargate, and that now motivates Lambda MicroVMs as a first-class primitive for user-generated code.

Standard Lambda already uses Firecracker internally, but the execution model reuses sandboxes across invocations of the same tenant (warm start) and does not provide isolation guarantees between distinct agent sessions of the same tenant, let alone between different tenants. For a multi-tenant code interpreter, this is unacceptable.

There is a genuine tension across five axes that cannot all be resolved simultaneously:

Isolation vs. Latency. Strong isolation (VM per session) has initialization cost. The original Firecracker was a major advance in reducing VM cold start from seconds to ~125ms, but it is still orders of magnitude slower than an already-warm container. Lambda MicroVMs promises sub-second launch/resume with state preservation — which changes the calculus for multi-turn agents, where cold start cost amortizes across the session.

Control vs. Operational Burden. Operating your own EKS cluster with Kata Containers or Firecracker gives full control over kernel version, seccomp policies, cgroup limits, and per-pod networking. But that implies a dedicated platform team, patching cycles, capacity management, and an incident runbook that most product teams do not want to maintain. Lambda MicroVMs transfers that burden to AWS — with the trade-off of lock-in and reduced internal visibility.

State vs. Ephemerality. Multi-turn agents need state across steps: Python variables defined in turn 1 must be available in turn 3. Standard Lambda does not reliably preserve state across invocations (the execution environment may be recycled). ECS/EKS-based solutions can keep a container alive per session, but that implies managing that container's lifecycle, scaling, and termination. Lambda MicroVMs resolves this natively with resume semantics.

Cost vs. Security. Standard Lambda is cheaper per invocation. Lambda MicroVMs will (estimated) carry a cost overhead due to additional isolation — AWS did not publish specific pricing at launch, but the analogy with Fargate (which also uses Firecracker with stronger isolation) suggests a 20-40% premium over standard Lambda for equivalent workloads. Containers on ECS/EKS have more predictable compute cost, but human operational cost frequently exceeds the infrastructure delta.

Regional Coverage vs. Immediate Availability. At launch, Lambda MicroVMs is available in 5 regions. For platforms with data residency requirements in other regions (e.g., sa-east-1 for Brazilian customers under LGPD, ap-southeast-1 for Singapore), this is a real short-term blocker.

In financial systems, the isolation model is not just a technical decision — it is a regulatory requirement. Frameworks such as SOC 2 Type II, PCI DSS, and in Brazil, BCB Resolution 4.893/2021 (IT risk management for financial institutions) require that data from distinct clients be demonstrably isolated. A multi-tenant code interpreter without strong isolation does not pass a technical controls audit.

Consider the concrete use case: an AI agent that receives portfolio data from an institutional client, generates Python code to calculate VaR (Value at Risk) with Monte Carlo, and executes that code to produce a report. The code generated by the model accesses data that is, by definition, confidential and subject to non-disclosure agreements. If that code runs on a standard Lambda with warm start, there is real risk that global variables or files in /tmp from a previous execution (from another client) are accessible.

With Lambda MicroVMs, each client session receives an isolated VM. The agent's code runs inside that VM. Even if the code attempts to access /proc, host environment variables, or make unauthorized syscalls, the Firecracker hypervisor blocks the escape. The blast radius is the session — not the worker, not the neighboring tenant.

Furthermore, state preservation has direct value in multi-step financial workflows: an agent that first loads historical data (turn 1), then calibrates model parameters (turn 2), then runs the simulation (turn 3), and finally generates the report (turn 4) can do all of this within the same MicroVM, without re-serializing gigabytes of data between each step. With standard Lambda, each turn would be a new invocation potentially on a different execution environment, requiring the agent to reload full context — additional latency and cost.

The async payload expanded to 1 MB (also launched in June 2026) complements this scenario: larger input datasets can be passed directly to the MicroVM without needing an intermediate S3 stage for small-to-medium inputs.

Being honest about what an architecture decision does not solve is part of senior work. Lambda MicroVMs solves execution isolation — but it does not solve everything.

Prompt Injection is still a vector. If the model generates code that exfiltrates data via a legitimate channel (e.g., writes portfolio data to a file and uploads it to an attacker-controlled S3 bucket via an authorized API call), VM isolation does not help. The defense here is granular contextual authorization on tools: the MicroVM has permission to write only to the tenant's S3 prefix, not to arbitrary buckets. This requires Bedrock AgentCore to implement per-session permission scoping, not just per-Lambda-function.

Denial of Wallet is a real risk. One MicroVM per session with preserved state means long or zombie sessions accumulate cost. A misconfigured agent (or a malicious user forcing long sessions) can generate unexpected cost. Mitigation: hard session timeout (e.g., 30 minutes of inactivity), CloudWatch alarm on sessions exceeding expected P99 duration, and circuit breaker in AgentCore for sessions with anomalous token consumption.

Hypervisor visibility is limited. You do not have Firecracker-level access to inspect what happens inside the VM beyond the logs the code produces. In a security incident, forensics is limited to what CloudWatch and X-Ray capture. For platforms with detailed forensic audit requirements, this may be insufficient — in that case, Option 2 (EKS with Kata) provides more visibility via eBPF/Falco.

Regional coverage is a roadmap risk. AWS may expand Lambda MicroVMs to other regions quickly, or it may take quarters. Platforms with customers in uncovered regions need to keep the ECS/EKS fallback operational — meaning the operational burden reduction promised by Option 1 is partial until full regional expansion.

The pricing model is not yet published. All cost analysis here is an estimate. Before committing high-volume workloads to Lambda MicroVMs, it is necessary to validate actual pricing with AWS and build a cost model based on sessions/day, average duration, and compute per session.