AWS Lambda MicroVMs for AI Agent Sandboxes: Architecture and Security Guide

AI agents become materially riskier when they stop answering questions and start executing tools. A coding or operations agent may run shell commands, clone repositories, read files, install packages, query databases or call internal APIs. The model can be hosted elsewhere, but the tool execution environment is still part of your security boundary.

AWS Lambda MicroVMs provide a new option for that boundary: a managed, Firecracker-isolated virtual machine that can be created per agent session, given a constrained IAM role and network path, and terminated when the session ends. AWS now documents this pattern for both Claude Managed Agents and Cursor Cloud Agents.

The practical question is not simply “can an agent run in a MicroVM?” It is what should run there, what should remain outside, and which controls prevent an autonomous tool call from becoming an infrastructure incident? This guide answers those questions.

What is an AWS Lambda MicroVM?

An AWS Lambda MicroVM is a managed, isolated virtual machine designed for workloads that need a stateful execution environment without managing a standing VM fleet.

For AI agents, the useful pattern is one disposable MicroVM per agent session. The model or agent control loop can remain with the AI provider while shell commands, file operations and other tools execute inside infrastructure controlled by your AWS account.

AWS documents Lambda MicroVM integrations for Claude Managed Agents and Cursor Cloud Agents. In both patterns, the MicroVM becomes the execution sandbox rather than the model host.

That distinction matters:

This architecture reduces the amount of trusted infrastructure shared between unrelated agent sessions.

Why do AI agents need a stronger sandbox than a normal backend worker?

Because agent-generated actions are not equivalent to deterministic application code. The agent may receive hostile input, misinterpret an instruction, choose an unsafe command or interact with untrusted repository content.

A normal backend worker often runs a known code path. An autonomous coding agent may instead decide to execute commands such as package installation, test runners, build scripts, Git operations and database clients. Repository files themselves can also influence agent behaviour.

The safer mental model is therefore:

Treat every agent session as a temporary, semi-trusted workload that should receive only the files, credentials, network access and lifetime required for its task.

A sandbox does not make an agent safe by itself. It gives you a boundary on which other controls can be enforced.

How the per-session MicroVM architecture works

A production design can be reduced to six steps:

1. A user or system starts an agent task.
2. Your control plane validates the request and selects an approved sandbox image and policy.
3. The control plane calls __INLINE_CODE_0__ with the image, execution role, networking configuration, lifecycle settings and session-specific initialization data.
4. The agent connects to the sandbox and executes tools inside it.
5. Logs and audit events are collected outside the guest.
6. The MicroVM is terminated at session completion or at a hard maximum duration.

The AWS __INLINE_CODE_0__ API supports an execution role, ingress and egress network connectors, an idle policy, logging configuration, a maximum duration and a run-hook payload. The maximum lifetime is 28,800 seconds, or eight hours. See the RunMicrovm API reference.

A useful high-level architecture is:

User / Application
        |
        v
AI Agent / Model Provider
        |
        | session or tool request
        v
Your Agent Control Plane
        |
        | RunMicrovm
        v
+----------------------------------+
| AWS Lambda MicroVM               |
|                                  |
|  Agent worker / tool adapter     |
|  /workspace                      |
|  shell + approved utilities      |
|                                  |
|  temporary session state         |
+----------------------------------+
       |             |
       | IAM         | controlled network egress
       v             v
 Approved AWS     Approved APIs /
 resources        private services

CloudWatch Logs + CloudTrail

The important design feature is that the agent does not inherit the control plane's permissions. Give the MicroVM its own execution role.

What security boundary does Lambda MicroVM provide?

AWS describes each session as a Firecracker-isolated virtual machine. The Claude and Cursor integration documentation also states that sessions do not share state and can be terminated at the end of the session.

That is stronger isolation than simply starting another process inside a long-lived application server. It is still not permission management. The guest can only be as safe as the IAM, network, secrets and application policies attached to it.

A practical defence-in-depth model has five layers.

1. Session isolation

Create a fresh sandbox for each independent agent session rather than sharing a mutable workspace between customers or tasks.

This limits accidental state leakage and makes cleanup simple: terminate the MicroVM instead of trying to sanitise a reused machine.

2. Least-privilege IAM

The execution role should contain only the AWS permissions needed by that class of agent task.

For example, a repository-review agent may not need database access at all. A data-support agent may need read access to one bucket and one database path but no infrastructure mutation permissions.

Do not give a general-purpose agent broad administrator permissions because the MicroVM is “isolated”. Isolation controls where code executes; IAM controls what that code can do to AWS.

AWS publishes MicroVM IAM actions including __INLINE_CODE_0__, __INLINE_CODE_1__, __INLINE_CODE_2__, __INLINE_CODE_3__ and authentication-token creation in its MicroVM security documentation.

3. Network restriction

Lambda MicroVMs can be launched with ingress and egress network connectors. Use those controls to separate agents that require public internet access from agents that should reach private services.

AWS notes in its Claude Managed Agents integration that MicroVMs have public internet access by default and that a VPC egress connector can be used for private resources or custom network restrictions.

This deserves deliberate design. If a sandbox can reach both sensitive internal data and arbitrary internet destinations, data exfiltration becomes a much larger risk.

4. Short-lived credentials and external secret storage

Do not bake production secrets into the MicroVM image.

AWS's Cursor integration stores the Cursor service-account API key in Systems Manager Parameter Store as a __INLINE_CODE_0__ and reads it at runtime. The general principle applies beyond Cursor: store secrets outside the image, grant narrowly scoped runtime access, and prefer credentials that expire.

Session-specific values can be passed through the run hook, but references to secrets are generally safer than embedding raw credentials in initialization data.

5. Independent logging and auditing

A compromised or confused guest should not be your only source of truth about what happened.

AWS Lambda MicroVM runtime stdout and stderr can be sent to CloudWatch Logs. AWS also records MicroVM management events in CloudTrail by default. Importantly, MicroVM data events such as __INLINE_CODE_0__, __INLINE_CODE_1__, __INLINE_CODE_2__, __INLINE_CODE_3__ and token creation require explicit opt-in for CloudTrail data-event logging.

That opt-in is easy to miss. For production agent infrastructure, enable the audit coverage you actually need rather than assuming every sandbox action is already recorded.

See AWS Lambda MicroVM monitoring.

A production security checklist

Before allowing an AI agent to execute real tools, review these controls:

The final item is important. Infrastructure isolation does not replace application-level approval. A production deletion, payment, user-account change or infrastructure mutation may still require explicit human authorization.

How do clients connect to a running MicroVM?

Each running MicroVM receives a dedicated HTTPS endpoint. AWS requires authenticated requests; there is no unauthenticated endpoint option.

You create a JWE authentication token and scope it to allowed ports. By default, inbound traffic routes to port 8080, while a request can select another permitted port through the __INLINE_CODE_0__ header.

The AWS MicroVM lifecycle documentation also supports suspend and auto-resume behaviour. Auto-resume can reduce idle resource usage, but the first request after suspension incurs resume latency.

For interactive agents, that creates a design trade-off:

• keep a session running when low latency matters;
• suspend longer idle sessions when preserving state matters more than immediate response;
• terminate sessions when state is disposable or the task is complete.

Do not treat these as interchangeable. A suspended environment preserves a session; a terminated one is a clean lifecycle boundary.

What are the scaling limits?

Lambda MicroVMs remove the need to manage an EC2-style worker fleet, but they still have quotas.

AWS currently documents a maximum MicroVM duration of eight hours and ARM64/Graviton architecture support. The default aggregate MicroVM memory quota varies by Region, and API operations such as __INLINE_CODE_0__ have rate limits that can be increased through Service Quotas where marked adjustable.

The practical implication is that a “one sandbox per agent” design needs admission control.

If hundreds of agents can start simultaneously, your control plane should:

1. check or track available capacity;
2. queue work rather than repeatedly hammering __INLINE_CODE_0__;
3. use idempotency tokens for launch requests;
4. retry throttled calls with exponential backoff and jitter;
5. terminate abandoned sessions quickly;
6. request quota increases before a high-volume production launch.

The __INLINE_CODE_0__ API accepts a client token specifically for idempotency, which helps prevent duplicate environments when a launch request is retried.

Lambda MicroVMs vs containers vs long-lived VMs for agent execution

There is no universal winner. Choose based on the threat model and workload.

For a customer-facing agent that can execute shell commands against arbitrary repositories, a per-session VM boundary is attractive. For a deterministic queue consumer running your own reviewed code, it may be unnecessary complexity.

When should you use Lambda MicroVMs for an AI product?

Use them when the agent needs meaningful execution freedom but the execution environment must remain disposable and tightly governed.

Strong candidates include:

• coding agents that clone and modify repositories;
• automated test and build agents;
• infrastructure troubleshooting agents;
• data engineering agents that run approved command-line tools;
• document-processing agents that execute converters or parsers;
• enterprise agents that must access private AWS resources without moving tool execution into the AI provider's infrastructure.

Consider a simpler architecture when the “agent” only calls a small set of deterministic application APIs. In that case, a narrow tool gateway can be safer and cheaper to reason about than giving the model a general shell, even inside a sandbox.

A sensible implementation sequence

Do not begin by giving an agent production credentials. Build the boundary outward.

Step 1: classify tools

List every tool the agent can invoke and mark whether it reads data, writes data, executes code, accesses the internet or changes production state.

Step 2: create task-specific sandbox profiles

Avoid one universal execution role. A code-review sandbox and a database-maintenance sandbox should not have the same permissions.

Step 3: build a minimal image

Install only the runtime and tools needed for that profile. Version the image and make promotion to production deliberate.

Step 4: constrain network paths

Decide whether each profile needs public internet, private VPC resources, both, or neither. Avoid “allow everything first, restrict later”.

Step 5: implement lifecycle limits

Set an appropriate maximum duration and idle policy. Ensure the control plane cleans up failed and abandoned sessions.

Step 6: externalise secrets

Fetch credentials at runtime using a narrowly scoped role. Never ship long-lived secrets in the image or source repository.

Step 7: add observability before autonomy

Collect runtime logs, session IDs, image versions and control-plane events before allowing agents to perform consequential actions.

Step 8: gate high-impact operations

Require policy checks or human approval for destructive actions even when the agent is correctly sandboxed.

Step 9: test hostile inputs

Test malicious repository instructions, package scripts, unexpected network calls, oversized workloads, infinite loops and attempts to access credentials the sandbox should not possess.

Step 10: load-test the control plane

Verify launch throttling, queue behaviour, quota handling, cleanup and retries before exposing the system to bursty production traffic.

If you are designing this kind of agent platform, Softotic's AI and machine learning development and custom software development work can cover the control plane, tool layer and application integration rather than treating the model API as the entire product.

Common architecture mistakes

Giving the sandbox the control plane's IAM role

The launcher may need permission to create MicroVMs. The guest usually does not. Separate those roles.

Treating internet access as harmless

A sandbox with access to sensitive data and unrestricted outbound networking has a straightforward exfiltration path. Restrict either the data, the egress, or preferably both according to the task.

Reusing state between unrelated sessions

Per-session isolation loses much of its value if your own startup code mounts a shared writable workspace containing multiple customers' data.

Putting secrets in the image

Images are reusable artifacts. Secrets should be runtime inputs protected by a secret store and IAM.

Logging without auditing

Application logs tell you what software reported. CloudTrail tells you which AWS API actions occurred. Production investigations often need both.

Assuming sandboxing replaces approvals

A perfectly isolated agent can still delete the production object it was legitimately authorized to access. Use application policy and human approval for high-consequence actions.

FAQs

Are AWS Lambda MicroVMs the same as normal Lambda functions?

No. Lambda MicroVMs expose a stateful VM-style execution environment with their own lifecycle, images, endpoints and up-to-eight-hour duration. They are useful for workloads such as agent sandboxes that do not fit the short, stateless function mental model.

Can Lambda MicroVMs run a coding agent?

Yes. AWS provides documented integration patterns for both Cursor Cloud Agents and Claude Managed Agents. In these designs, the agent/model service remains external while tool execution runs inside your AWS-hosted MicroVM.

Does each MicroVM have its own endpoint?

Yes. A running MicroVM receives a unique HTTPS endpoint. Requests require an authentication token, and tokens can be restricted to allowed ports.

Can an agent inside a MicroVM access private AWS resources?

Yes, if you explicitly provide the required network path and IAM permissions. That capability should be scoped to the task rather than enabled broadly.

How long can a Lambda MicroVM run?

Up to eight hours. The __INLINE_CODE_0__ API accepts __INLINE_CODE_1__ up to 28,800 seconds. For agent sessions, set a lower ceiling when the task should never need the full duration.

Should every AI agent use a VM sandbox?

No. If an agent only invokes a few narrowly defined APIs, a constrained tool gateway may be simpler. VM sandboxes are most compelling when the agent needs general-purpose execution such as shell commands, builds, file manipulation or untrusted code processing.

Build the boundary before expanding autonomy

The useful part of an AI agent is its ability to act. That is also where most of the engineering risk begins.

AWS Lambda MicroVMs give teams a practical new boundary for agent tool execution: disposable Firecracker-isolated sessions, task-specific IAM, controlled networking, authenticated endpoints and AWS-native logging and auditing. The architecture is strongest when the MicroVM is treated as one layer of defence rather than a magic safety box.

If your roadmap includes an agent that can execute code, work with private systems or act on business data, define the tool permissions and isolation model before adding more autonomy. Softotic can help design and build the agent architecture, including the control plane, sandbox policy, backend integration and production observability.

Sources and references

• AWS Compute Blog: Running self-hosted AI agent sandboxes with AWS Lambda MicroVMs
• AWS Lambda: Using Lambda MicroVMs as a sandbox for Claude Managed Agents
• AWS Lambda: Using Lambda MicroVMs as a sandbox for Cursor Cloud Agents
• AWS Lambda MicroVM API: RunMicrovm
• AWS Lambda: Running and using MicroVMs
• AWS Lambda: MicroVM monitoring