Name the thing you need to contain
An agent may read untrusted documents, invoke a trusted API or execute code written by a model. Those are different threats. A tool approval rule can stop an action before it starts; an operating-system sandbox limits what a process can reach after it starts. Neither rule validates the business meaning of a database update.
Make an inventory of files, credentials, network destinations, processes and external records the task can access. Then decide what must be blocked, what can be read and what needs review. The word ‘sandbox’ alone does not specify any of these boundaries.
References: OpenAI Docs — Agent approvals and security
Process sandbox, container and microVM
A process sandbox uses operating-system controls to limit file, network or system calls. A container packages a process with namespaces and other host-kernel controls; its practical isolation depends on configuration. A microVM runs a guest kernel under a hypervisor. Firecracker uses KVM for that boundary and targets short-lived workloads.
These layers can be combined. A microVM may contain the command runner while the application still decides which tool call is allowed and a network proxy controls outbound destinations. Choosing the strongest-sounding layer without a threat model can add operational cost while leaving an exposed API credential untouched.
References: Firecracker — microVM projectOpenAI Docs — Agent approvals and security
What the microVM does not decide
The guest can still use anything intentionally mounted into it. If a long-lived secret, host directory or unrestricted network route is available, isolation from the host does not make the downstream action safe. The application must still authorize the user, validate tool arguments and record which write succeeded.
MCP exposes tools and context between an application and server. It does not require the server to run in a microVM, and connecting a server does not prove that its actions are isolated. Treat protocol, permission policy and runtime as separate design choices.
References: Model Context Protocol — architecture overviewFirecracker — microVM project
A testable design for code execution
For untrusted generated code, use a disposable environment with a fresh filesystem, an explicit CPU and memory budget, scoped read-only inputs and no ambient production credentials. Deny network by default, then allow only destinations a task actually needs. Put external writes behind a separate trusted service with its own authorization checks.
Test escape and recovery scenarios in an authorized environment: can code read a blocked path, call an unapproved host, keep running after cancellation or leave data for the next task? Measure cold start and workload time for your own hardware and configuration. Do not reuse a vendor's boot-time figure as your production latency promise.