Isolating agent-generated code with MCP and Microsandbox

AI agents are moving beyond generating answers to executing code, calling tools, processing data, and coordinating multi-step workflows. As these systems become more capable, a fundamental infrastructure question emerges: how can an agent execute a task without receiving unrestricted access to the environment?

Addressing this requires an architecture that separates reasoning, tool access, execution, and resource control. Open protocols such as the Model Context Protocol (MCP) standardize how AI applications connect to external tools, while sandboxing technologies isolate the code those tools execute.

A practical example is connecting an AI coding agent to Microsandbox through MCP. In this architecture, the agent can request code execution through a standardized tool interface, while Microsandbox runs that code inside an isolated microvirtual machine (microVM). The model, tool interface, and execution runtime remain separate components, each with a distinct responsibility.

Agentic AI requires more than model inference

A model generates responses or reasons in response to a task. Application logic coordinates the workflow, retrieves context, calls tools, and manages state. Some agents also generate code, test solutions, or execute commands as part of completing a task.

These activities have different infrastructure requirements. GPUs can accelerate model inference, while CPUs handle orchestration, API calls, data processing, and the execution environments surrounding the model. Storage and networking connect these components, and isolation mechanisms help constrain what individual workloads can access.

A program produced by a model may be incorrect, consume excessive resources, or attempt operations beyond what the task requires. Even when the agent is authorized to perform a task, its generated code should not automatically inherit unrestricted access to the host.

Separate the tool interface from the execution environment

MCP provides a standardized way for AI applications to discover and invoke tools exposed by an MCP server. This can reduce the need to build a separate integration for every compatible client.

But a protocol for invoking tools does not, by itself, determine how those tools execute operations or what resources they can access.

Consider a coding agent tasked with writing and testing a Python script. The agent needs a way to request execution and receive the result. The system running that code needs to decide where the program executes, what resources it can consume, and whether it can access the network or files outside its working environment.

These responsibilities can be separated into three layers:

• Agent and model: Interpret the task, generate code, and decide which tools to invoke.
• Tool interface: Define the operations available to the agent and communicate requests and results.
• Execution environment: Run the requested code within configured isolation, resource, and network boundaries.

In the Microsandbox implementation, an MCP-compatible coding agent can invoke sandbox execution tools, while Microsandbox manages the underlying microVM. This separates the agent's tool interface from the environment executing its code.

This distinction is important when evaluating security. A tool interface can define available operations and support access controls, but the implementation must enforce those controls. Similarly, an isolated runtime cannot compensate for an interface that exposes excessive privileges or unnecessarily sensitive information.

Interoperability works best when each layer has a clear responsibility.

Choosing an isolation model for generated code

The execution environment is a key design decision for systems that run code generated by an agent.

Containers are commonly used to package applications and constrain their execution. Conventional containers share the host operating system kernel. That shared kernel is part of the threat model when running potentially untrusted code.

Microvirtual machines, or microVMs, provide another approach. A microVM runs its own guest kernel, creating a different isolation boundary from a conventional container.

Microsandbox is one example of technology designed to provide isolated execution environments for AI agents. On Linux, Microsandbox uses KVM and libkrun to launch microVMs for code execution.

A workflow using this approach can follow four steps:

1. An agent generates a program in response to a user request.
2. The agent invokes an execution tool through an interface such as MCP.
3. The execution service launches or uses an isolated environment to run the program within configured limits.
4. The execution result is returned to the agent for interpretation or further action.

The agent can then inspect the output, revise the program, and repeat the process as needed.

This design separates the execution of generated code from the host and provides a place to enforce resource and access policies. Other risks, including network and data access, still need separate controls.

The Microsandbox agent sandboxing guide demonstrates this architecture using KVM-backed microVMs and MCP integration with a coding agent. In one example, the agent uses the sandbox_run tool to execute a Python script that generates the first 10 Fibonacci numbers. The guide also shows how checking hostname and uname -a can help confirm that commands run inside the sandbox rather than directly on the host. This demonstrates how agents can execute generated code through a standardized tool interface while maintaining a separate execution environment.

Resource limits and network access are separate controls

Isolation is only one part of a secure execution model. A workload can be isolated from the host and still consume excessive resources or communicate with systems it should not reach.

Resource limits help constrain the impact of an individual execution. CPU and memory allocations, for example, can prevent a runaway program from consuming all the resources available to other workloads. The appropriate limits depend on the task, expected runtime, and available infrastructure.

Network access requires separate consideration. A sandbox may be isolated from other execution environments while still having outbound connectivity. Developers should determine whether a task needs network access at all and configure the environment accordingly.

For example, the documented Microsandbox configuration isolates execution environments from one another while allowing outbound connectivity. Developers therefore need to evaluate network access separately from execution isolation.

File access presents a similar challenge. Agents often need to read input files or return generated artifacts, but broad access to host files can expose unrelated data. Explicitly defining what enters and leaves the sandbox helps maintain a clearer boundary.

These controls should be considered together:

• Execution isolation: Determine the boundary between generated code and the host.
• Resource allocation: Limit CPU, memory, and other resources available to an execution.
• Network policy: Define which external services, if any, the workload can reach.
• Data access: Restrict the files, credentials, and other information available to the agent and its execution environment.
• Tool permissions: Expose only the operations needed for the task and enforce authorization independently of the agent’s instructions.

No single mechanism provides complete security. A microVM does not automatically prevent data exposure, and an MCP server does not automatically establish a secure execution boundary. The overall design must account for how these controls interact.

Designing the boundary between agents and infrastructure

As agents take on more operational responsibilities, their permissions become an important part of infrastructure design.

An agent might need to execute a script without needing access to cloud account credentials. It might need to retrieve a particular dataset without being allowed to browse an entire filesystem. It might need to call an internal service without receiving unrestricted network access.

These are authorization and policy questions, not simply model-quality questions.

A useful design starts by defining the actions an agent needs to perform and then determining the minimum permissions and resources required for each action. Tool interfaces should expose specific capabilities rather than unnecessarily broad operations. Execution environments should enforce their own restrictions instead of relying on the model to follow instructions.

The same principles apply when an agent can modify infrastructure or invoke other services. The system should distinguish between requesting an action, authorizing it, executing it, and recording what happened.

This separation also supports clearer troubleshooting. When an operation fails, developers can investigate whether the problem occurred in the agent’s reasoning, the tool interface, an authorization check, or the execution environment.

For production systems, the objective is to make these boundaries explicit, testable, and appropriate to the workload’s risk.

Why interoperability matters for secure agent execution

The MCP and Microsandbox example demonstrates how technologies from different open source projects can work together while maintaining clear execution boundaries. MCP standardizes tool interactions, while Microsandbox isolates code execution. This modular approach reflects the open-source community’s focus on interoperability, allowing developers to combine technologies without relying on a single, tightly integrated stack.

During an Agent(X) conversation at AGNTCon + MCPCon Europe, Chris Aniszczyk, CTO of the Cloud Native Computing Foundation, emphasized how open source gives enterprises greater choice and flexibility across their infrastructure.

Manik Surtani, CTO of the Agentic AI Foundation described some of the questions its working groups are addressing:

“How do we solve identity, how do we do security and privacy, how do we deal with governance?”

These concerns become particularly important when agents execute generated code. Interoperability must be paired with isolation and access controls. MCP provides a standardized tool interface, Microsandbox isolates execution, and infrastructure policies define what resources and systems the code can access.

From agent capability to controlled execution

The evolution of AI agents is changing the demands placed on application infrastructure. Systems that once generated text now execute code, invoke services, and coordinate actions across multiple components.

Supporting these workflows means treating execution as a distinct part of the architecture. Developers need to decide how tools are exposed, where generated code runs, what resources it can consume, and which systems it can reach.

Open protocols can make the connections between these components more consistent. Sandboxing and explicit authorization policies provide separate mechanisms for controlling what happens when an agent acts.

The result is an architectural approach in which interoperability does not depend on giving every component unrestricted access to the others. Agents can use common interfaces while execution environments and infrastructure enforce the boundaries appropriate to each workload.