OneCLI says every hosted agent now gets its own micro-VM

OneCLI says every agent on its hosted Cloud now runs in its own micro-VM — with a real browser, a real filesystem, and root inside that virtual machine, not on the customer’s. The company laid out the change in a vendor architecture post, arguing that the containers it used to ship were fine until people asked agents to do work a process sandbox could not finish.

This is OneCLI describing its own stack. Nothing in the post or the current docs is an independent audit of the isolation story. Treat the cutover, and especially the claim that a mistake goes nowhere, as the vendor’s account.

Containers could clone a repo. Then they stopped.

OneCLI writes that every agent it shipped used to run in a container. That was the obvious first call: cheap, quick to start, isolated from other agents, with the gateway acting as what the company calls the Agents Vault for secrets. Inside that box the agent could run commands, read and write files, and use the tools already connected for it. For a while, the post says, that was enough.

Then an engineer asked an agent to check out a repo, bring the whole stack up — database included — and say whether a feature actually worked. The agent cloned the code and stopped. OneCLI says there was nowhere to start PostgreSQL, nothing to run the app in, and no way to look at the result. The container could run a process. It was not, in the company’s words, somewhere you could run a complete application like a database. No browser. No display. The request ended the way they all did: the agent explained what it would do if it could, and the work itself did not get done.

That is the stated trigger. Not a security incident. A checkout-and-verify job that a container-shaped sandbox could narrate but not complete.

Three requirements, one micro-VM

The company says it wanted three things and would not trade any of them: a filesystem the agent owned, a browser it could drive, and isolation strong enough that it would be comfortable running the setup inside a customer’s environment. Getting the first two working, it writes, is not hard. The third is why it would not take a shortcut. The more an agent can do, the more it matters that a mistake goes nowhere.

A container shares the host kernel. OneCLI says it was not comfortable with that being the only thing between an agent and everything else on the machine. What it built, it claims, is one micro-VM per agent on OneCLI Cloud, inside that agent’s sandbox. A real browser. A real filesystem. Root on that VM, not on yours. The company asserts that nothing the agent does reaches another agent, another employee, or the customer’s systems, and that if it breaks something, it breaks only its own computer.

That last sentence is OneCLI’s architecture claim, not a finding from a lab or a third-party review.

The post is also specific about where the cutover applies. One micro-VM per agent is described as a OneCLI Cloud change. The documentation still talks about agents that can run on your own infrastructure, with an outbound-only runner and no inbound ports. Do not flatten those two deployment stories into one.

Policy still sits outside the model

More capability, the post argues, made the policy layer matter more, not less. An agent that can only suggest things cannot do much damage. An agent with a browser and a filesystem can.

The computer is what lets it act. The policy layer is what decides how far. Sending an email, deleting a record, spending money: each one stops and asks. The rule is enforced outside the agent, so no prompt gets around it — again, as OneCLI describes it.

That matches the product docs fetched alongside the post. OneCLI is framed there as an open-source platform for running AI agents as a team: one agent per person, each with the access it needs, working in a sandbox and routed through a gateway that injects credentials and enforces policy. Agents, the docs say, never see the keys. The same gateway can inject access from Bitwarden or 1Password on demand. Approvals for actions you need full control over — sending the email, emptying an S3 bucket — are described as deterministic and human-in-the-loop, in the chat itself.

What OneCLI says agents can do once they have a box

The company’s clearest consumer example is groceries. Ask an agent to place a usual Instacart order and, the post says, it opens the browser, fills the cart, and checks out. A stronger version does not need the list: snap a photo of a fridge stocked the way you like it, then another when it needs restocking, and the agent works out what is missing. If oat milk is out of stock, it shows the closest match, waits, and finishes the order once you approve.

The engineering example is OneCLI’s own repo. It asks an agent to add an integration. The agent clones the code, brings the stack up with Postgres, Redis, and the app in containers, writes the connector and login flow, then runs that flow against the real provider on its own computer, watches the callback land, and fixes whatever broke. When it finishes, the company says, it leaves findings on the pull request and updates the ticket, so what reaches a human has already been run against the real thing rather than only checked on paper.

Writing the connector, OneCLI argues, was never the bottleneck. The slow part was always getting an environment where the integration could be tested for real. That is the part the agent took over, and how the company says it ships integrations now.

Those are vendor walkthroughs, not independently timed benchmarks. They do illustrate the unit the post is selling: a per-agent computer as the place computer-use and end-to-end tests actually happen.

What the docs actually name

Current documentation describes an agent as a durable thing, not a single prompt. It has a computer — “its own isolated sandbox, with a filesystem and a shell” — plus a conversation, memory, skills, a schedule, and credentials it never sees. The only way out of that computer, the docs say, is the gateway, so the agent reaches what you granted and nothing else. It can also have its own Slack app.

The micro-VM wording itself is in the Cloud architecture post, not in the documentation index text fetched for this piece. The docs talk about a per-agent computer and sandbox, a gateway that injects credentials, and a workspace-wide policy. The post is the one that says the Cloud agents now each sit in a micro-VM, and that Cloud is live with every agent on it having a computer of its own.

Separately, the same gateway can wrap agents you already run. The docs show installing the CLI, logging in, and routing a coding agent so its HTTP calls go through OneCLI for credential injection and policy. That path is about harnessing an existing agent, not about confirming the Cloud micro-VM cutover.

Read it as a vendor cutover, then go look

If you are evaluating computer-use agents or end-to-end integration tests, the unit OneCLI is arguing for is the per-agent machine: a place to boot a stack, drive a GUI checkout, and keep a broken experiment inside one box. Whether that box is isolated the way the post claims is a question for your own review. This write-up cannot confirm it.

Next step: read OneCLI’s architecture post for the container-to-micro-VM rationale, then the docs page on what an agent actually is — computer, gateway, and policy — and decide whether that hosted shape matches how you want agents to run.