AI agent isolation: per user or per agent?

Every serious agent platform has converged on the same answer. If you want an agent to do real work, give it a computer: a screen, a file system, a browser, a shell. That argument is finished.

The question underneath it is not, and almost nobody is arguing about it in public. Whose computer is it? One per user, one per team, or one per agent? That choice decides what happens when a single agent goes wrong, and it is being settled quietly, in documentation, by whoever ships first.

Where the isolation boundary sits today

There are three positions on the spectrum, and all three are shipping.

Per session. Nothing persists, so there is nothing to share. E2B and Browserbase sit here: a sandbox or a browser session exists for the length of a task and then it is gone. Isolation is a side effect of the environment being disposable, which is also why work spanning days does not fit.

Per user. One persistent machine belongs to a person, and every agent that person runs works on it. Grok Bot is the clearest current example. Claude Cowork arrives at the same boundary by a different route: the agent runs in a virtual machine on the laptop in front of you, and that laptop belongs to one person.

Per agent. Each agent gets a machine of its own that persists between sessions and that no other agent can reach. This is where SpineOS sits. A self-hosted project such as Bytebot or Cua can be configured this way too, because when you run the infrastructure yourself the boundary is whatever you build.

What a shared computer for AI agents actually means

It means every agent one person runs reads and writes the same files, drives the same browser, and inherits the same logins.

xAI's Grok Bot, launched in August 2026, is the current reference implementation, and its documentation is unusually direct. From the Grok Bot FAQ, answering "Do my Bots share one computer?":

Yes. Every Bot on your account uses one persistent cloud computer. They share its files, browser sessions, and logins so they can hand work off. The computer is assigned per user, not per Bot. Do not use separate Bots as a security boundary.

That last sentence is a vendor telling users not to assume the thing they will assume anyway. Good documentation, and the entire design question in nine words.

Their teams documentation puts the trade even more plainly: "All of that user's Bots share one computer, and Bots isolate personalities and workspaces, not compute."

What the per user model gets right

Two things worth stating plainly.

Between users, the separation is strong. xAI states that "every computer is a Firecracker microVM with its own kernel, memory, and virtual devices" and that "one user cannot reach another user's computer". That is a hardware-level boundary, not a namespace trick.

The credential design is the part a security-literate reader should notice. From their security documentation: "A Bot has no identity or credentials of its own", "Bots act as the signed-in member", and "Connector tokens are never stored on the computer". An agent inherits the access of the person it belongs to and can never exceed it.

So the honest exposure here is not that your API tokens are sitting on a shared box. They are not. The exposure is the surface the agents share while they work: one file system, one browser profile, one set of live sessions, on one durable disk.

Why the shared surface is the part that matters

Because the realistic failure modes of an agent are not credential theft. They are instruction poisoning and ordinary mistakes, and both travel through files and browser state rather than through tokens. Three consequences follow.

An agent that reads the open web becomes a channel. If an agent doing competitor research writes what it found into a file, and a second agent later reads that file as input, then anything the first agent was persuaded to write is now instruction for the second one. Neither agent did anything wrong. The disk carried it.

A logged-in browser profile authenticates every agent equally. Cookies and sessions are not scoped to a personality. If one agent signs into your billing provider to pull an invoice, every other agent on that machine is signed in too, for as long as the session lives.

Mistakes stop being local. A cleanup script with a bad path, or a config file rewritten in the wrong format, lands on every agent at once.

None of this makes Grok Bot careless. It is a deliberate trade, documented in the open, made in exchange for something users genuinely want.

The case for per agent isolation as the default

The boundary should match the unit of failure, and the unit of failure is the agent. Three arguments, in the order they matter in practice.

Reach. Once something has gone wrong, the only useful question is what it could touch. Per agent, the answer is one machine with a known disk. Per user, it is everything every agent of yours has ever touched, plus every site any of them is still signed into.

Attribution. On a shared disk, a file that should not exist has no author. You have logs, if the platform kept them, and you have inference. Give each agent its own file system and the file system becomes the record: what is on the machine is what that agent did.

Revocation you can actually perform. Destroying a desktop ends the exposure in one action. On a shared machine, removing an agent removes a personality and leaves behind every file it wrote and every session it opened.

This is how SpineOS is built. One cloud desktop per agent, each on its own virtual machine with its own persistent disk, isolated from every other desktop at the network layer, hosted in France. Five agent types run on it today: Claude Code, OpenClaw, Codex, Hermes and Grok CLI. Different vendors, different agents, different machines.

What per agent isolation costs

It breaks handoffs, and building them back is real work.

On a shared computer the handoff is free. Agent A saves a report, agent B opens it. Agent A signs into a tool, agent B uses the session. xAI names this as the reason for the design: files, browser sessions and logins are shared so Bots can hand work off. No plumbing, no protocol, no schema.

Isolate the agents and all of that disappears at once. Two agents that cannot see each other's file systems cannot pass work by default. You have replaced a folder with a distributed systems problem. Anyone who says isolation is free has not built the second half of it.

How a shared workspace knowledge base answers the handoff problem

By replacing one implicit shared machine with one explicit shared surface, and keeping everything else separate.

On SpineOS, agents belong to a workspace, and the workspace has a knowledge base every desktop in it can read and write. An agent that finishes a piece of research writes it there. Another agent picks it up on its next run. The desktops stay separate: separate disks, separate browsers, separate processes. The only thing two agents have in common is what you decided to share.

That turns an implicit channel into a reviewable one. What crosses between agents is a set of files in a known place, with a history, rather than the whole state of a machine.

Where that answer is still imperfect

A shared knowledge base is still a shared surface, and explicit sharing costs effort that implicit sharing does not. Four gaps, named, because a vendor listing only its own strengths would be doing what this post argues against.

It is a channel. A note written by an agent that read a hostile page is still a hostile note when the next agent reads it. Isolation narrows the shared surface from everything to one directory you can inspect. It does not remove the need to treat agent output as untrusted input.

It has to be done deliberately. Implicit sharing happens whether or not anyone thought about it, which is why it is convenient and why it is risky. An agent that never writes down what it learned passes nothing on.

Live state does not cross. A browser session, a running process, a half-configured tool: none of it survives a machine boundary. Each desktop establishes its own logins, which is a security property most of the time and friction the rest of the time.

Coordination is slower. Passing work through written artifacts costs more than sharing a file system two processes already have. We think the trade is right. We do not think it is free.

How to choose your boundary

Ask what a single fully compromised agent would reach, then put the boundary there.

• One person, one agent at a time, work that touches nothing sensitive: a per session sandbox is enough and cheaper.
• One person, several agents on one body of work, convenience valued above separation: a per user machine is defensible, provided you have read the sentence about not using Bots as a security boundary and you believe it.
• Several agents at different trust levels, or anything touching money, customer data, production systems, or credentials you cannot rotate in a hurry: per agent, and budget for the handoff mechanism.

The question that settles it is not architectural: if the agent doing untrusted web research were fully compromised right now, what else does it touch? That answer is your real boundary, whatever the diagram says.

Where this goes next

The first question got answered quickly. Agents get computers now, and that will not reverse.

The second question is how many computers, and it is being answered by defaults rather than by argument. Defaults become assumptions, and users assume agents are separate. xAI had to publish a sentence saying they are not, which means the assumption is already out there.

Per agent is the default that makes it true.

---

SpineOS gives every AI agent its own persistent cloud desktop: dedicated machine, own disk, own browser, isolated from every other desktop, hosted in France. Free during the beta, Pro at 49 euros a month for up to three agents, Max at 149 euros for up to ten with shared workspaces. Try it.