{"slug": "agents-need-their-own-computer-that-s-half-the-problem", "title": "Agents Need Their Own Computer. That's Half the Problem.", "summary": "LangChain published a post arguing that agents need their own computer, and that a sandbox does not stop prompt injection but does contain the execution blast radius. In response, the AI startup (which runs agents) admitted its own command runner ignored its security policy and now fails closed, refusing to run commands unless a sandbox is present or the user explicitly opts out. The company distinguishes isolation (where an agent can reach) from governance (what an agent may do), arguing both are needed and neither implies the other.", "body_md": "# Agents Need Their Own Computer. That's Half the Problem.\n\nLangChain published a post this week called\n[ Agents Need Their Own Computer](https://www.langchain.com/blog/agents-need-their-own-computer).\nIt’s right, and if you run agents against anything you care about, you should read it. The\ncore line is the one worth remembering: a sandbox doesn’t stop prompt injection, but it does\n\n*“contain the execution blast radius.”*Give the agent a real machine to work on — and keep that machine away from your laptop, from production, and from every other agent.\n\nWe agree so completely that we spent this week on the *other* half of the same problem. And\non being honest about the half we haven’t built.\n\n## Two jobs hide inside “keep the agent safe”\n\nThere are two different jobs here, and they get folded into one word so often that people buy one and think they got both.\n\n**Isolation**—*where*the agent can reach. Can it leave this folder? Touch`~/.ssh`\n\n? Open a socket to the internet? This is the sandbox. It’s what LangChain’s microVM gives you, and it’s what “blast radius” means: if something goes wrong, how far does the damage spread.**Governance**—*what*the agent may do, and*whether the thing driving it can be trusted*. Is this an action it’s allowed to take at all? Did the instruction come from you, or from a web page it just read? This is what our kernel does.\n\nA microVM is a room with a strong lock on the door. Governance is the rules for what you’re\nallowed to do while you’re in the room. You need both — and, this is the part people skip,\n**neither one implies the other.**\n\n## Why one isn’t the other\n\nA perfect microVM will not stop an agent that’s been talked into deleting the files inside\nits *own* workspace. It won’t stop one from reading a secret it legitimately has access to\nand mailing it out the front door. Those actions are all “inside the room” — the sandbox has\nno opinion about them. Deciding whether they should happen, and whether the thing that asked\nfor them is trustworthy, is governance’s job. (A poisoned document turning your agent into a\ncourier is [a threat we’ve written about before](/blog/the-zombieagent-threat/); the sandbox\nis not what stops it.)\n\nAnd governance won’t stop a plain bug — the agent’s own code scribbling on `/etc`\n\nbecause of\nan off-by-one, no injection required. That’s the room’s job.\n\nDifferent tools. The mistake isn’t picking one; it’s picking one and believing you have\nboth. We made exactly that mistake ourselves, and\n[wrote it down when we caught it](/blog/governed-is-not-confined/).\n\n## The honest part: what we shipped this week\n\nHere’s where it stops being theory, because we just lived it.\n\nWe were reviewing our own execution layer — the piece that actually runs a shell command an\nagent asked for — and found something uncomfortable. On every call, that runner is handed a\npolicy: no network, writes only inside these folders. **And it ignored it.** It shelled out\nand let the subprocess do anything the host user could do. Open a socket. Write anywhere on\ndisk. The policy was a decoration.\n\nThe *right* fix is the room — the OS-level sandbox LangChain is describing. You cannot fence\na subprocess with a few lines of Rust; it needs the operating system’s help (namespaces, a\nmicroVM, that class of thing). We don’t have that yet. It’s real work — and, agreeing with\nthe article once more, it should be a real isolation boundary, not a clever hack we talk\nourselves into trusting.\n\nSo we had a choice. Keep running commands and quietly pretend the policy meant something. Or stop pretending.\n\nWe stopped pretending. The command runner now **fails closed**: with no sandbox present to\nenforce the policy it was handed, it refuses to run the command at all — unless you\n*explicitly* tell it, in code, “I know this runs unconfined.” No silent gap. The refusal\nstates exactly why. A dry run (which touches nothing) still works; a real run does not, until\neither a sandbox is there to back the policy or someone has signed the waiver out loud.\n\n## Why “not yet — and we’ll say so” beats a half-built jail\n\nIt would have been easy to ship a *partial* sandbox instead: fence the filesystem, leave the\nnetwork wide open, call it done. That is worse than shipping nothing, because it **reads**\nlike a jail. The first person who tests it finds the hole — and now every other safety claim\nyou’ve made is suspect too. A tool that overstates its own protection fails at the exact\nmoment someone checks it.\n\nSo the rule we hold to is small and boring: enforce what you can, refuse what you can’t, and\nnever let the label outrun the mechanism. *“We can’t confine this yet, so we won’t run it and\ncall it safe”* is a sentence we can stand behind. A half-lit sandbox with the label “secure”\nis not.\n\n## Where the room will come from\n\nWhen we do build the isolation layer, it won’t be bespoke. It’ll be a slot that the real\nthing plugs into — a namespace backend, gVisor, a Firecracker-class microVM, quite possibly a\nhosted one exactly like the article’s. And the refusal we shipped this week *is that slot*:\nit’s the point where a sandbox will announce itself and flip the command from “refused” to\n“allowed.” We built the seam first, on purpose. The engine drops in behind it — and nothing\nin front of it has to change.\n\n## The takeaway\n\nGive your agent its own computer. LangChain is right about that. Just don’t mistake the\ncomputer for the whole answer. The machine decides *where* the agent can go. Something else\nhas to decide *what it may do once it’s there* — and whether to trust whatever is doing the\nasking. A room and a rulebook. Most “agent security” I run into is one of the two, quietly\nhoping it counts as both.\n\nWe spent this week on the rulebook — and on refusing to pretend we’d already built the room.\nWhen we build the room, you’ll hear about it, because we’ll finally get to use the word we\ncouldn’t this week: *confined.*", "url": "https://wpnews.pro/news/agents-need-their-own-computer-that-s-half-the-problem", "canonical_source": "https://ai2rules.dev/blog/a-computer-is-half-the-problem/", "published_at": "2026-07-24 00:00:00+00:00", "updated_at": "2026-08-15 07:42:27.530933+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-policy"], "entities": ["LangChain", "AI startup"], "alternates": {"html": "https://wpnews.pro/news/agents-need-their-own-computer-that-s-half-the-problem", "markdown": "https://wpnews.pro/news/agents-need-their-own-computer-that-s-half-the-problem.md", "text": "https://wpnews.pro/news/agents-need-their-own-computer-that-s-half-the-problem.txt", "jsonld": "https://wpnews.pro/news/agents-need-their-own-computer-that-s-half-the-problem.jsonld"}}