Inside the code sandbox

Real analysis needs code. A language model estimating a sum across four thousand rows is not analysis, it is a confident guess, and the confidence is the dangerous part. So LinearPilot lets the assistant write code and run it against your data. The interesting engineering is not that it can — it is the box we put it in, which is what this post is about. The approval model covers why the assistant asks before it acts; this one covers what happens after you say yes.

Every run gets its own virtual machine, created for that run and destroyed when it finishes. Not a process on our server with some flags set on it — a separate machine with its own kernel, which is what makes the isolation a property of the boundary rather than a property of us remembering to configure something correctly.

That machine has no network. Not a firewall rule applied inside it, not an allow-list with nothing on it: no network interface exists, so there is nothing for code to reach through. We check this the way a claim like that deserves to be checked, with a positive control. A probe that opens a socket fails with “network is unreachable,” and the same probe run without the isolation applied connects successfully. A test that only ever passes tells you nothing about whether it would notice a regression, which is the entire reason for the second half.

Two kinds of thing go in. First, files you point the assistant at from Drive — spreadsheets, PDFs, images and scans, which are converted to text on the way in so the code gets something it can read. Second, read-only exports of your business records: contacts and deals, quotes and invoices, tasks, expenses, employees, calendar events, signing envelopes, inventory, and a few more besides.

Those exports are the part worth reading closely. Each one is filtered to your company, and then filtered again by the same record-level visibility rules that decide what you can see when you look at those records in the app — so code run on behalf of someone who cannot see a record does not receive that record in a file either. Each export is capped at five thousand rows, and when it truncates it says so, because a short answer computed from a silently short input is the worst kind of wrong.

What comes back out is deliberately narrow. Printed output, capped so a runaway loop cannot flood anything. Files written to an output folder, which are collected and filed into Drive — charts are simply image files, produced by drawing to a file rather than to a screen that does not exist. And nothing else. The code has no database connection and no network, so there is no route from inside the box to your records.

Which raises the obvious question: how does an analysis that should change something change it? It doesn't. Code that wants to modify a record writes a list of proposed actions to a file, and those come back to you as individual approval items, checked against what you are actually permitted to change, which you accept one at a time. A bug in generated code can propose something wrong. It cannot perform it. That distinction is the whole design.

The approval screen is meant to be worth reading rather than clicked past. Before anything runs you see the plan, a manifest of exactly which files and how many rows are being staged, and the generated code itself, in full, not a summary of it. Approve or reject. If the staged input contained text that looked like instructions aimed at the assistant, the screen says so — a spreadsheet is data, and a spreadsheet that reads like a command is a thing you should be told about rather than something we quietly swallow.

The gates stack. Code execution is available on every plan — plans are defaults for capability, not ceilings, and the meter that actually rations expensive AI work is credits, not access. Even so it ships switched off, and an administrator has to enable it for the company. It also disappears entirely if the company has turned off the assistant's ability to write at all. Then there is the per-run approval, and underneath that the same per-dataset permissions the rest of the product uses, so someone without access to employee records does not get them staged no matter what they ask for. A heavy analysis that burns a lot of credits is charged against the pool the same way a chat turn is; a plan with a smaller pool simply runs out sooner.

Honest limits, since they shape what the feature is good for. A standard run gets two minutes, two gigabytes of memory and two processors. A run that fails gets revised and retried a small fixed number of times rather than looping indefinitely. Output is capped at twenty files and fifty megabytes. It is Python only. This is a tool for analysing your data, producing a chart, reconciling two exports — not for hosting anything or running a long job.

Two exceptions to “you always approve the code,” because they exist and you should hear about them from us. An administrator can enable a setting where a follow-up question in the same conversation runs without a second code approval, but only when it reads a subset of what you already approved — the scope can narrow, never widen. And a run you schedule to repeat cannot write anything at all, by construction: only a run that proposed zero changes can be scheduled, it is checked again when it fires, and any action file the frozen code produces is discarded unread. A schedule has nobody sitting there to approve it, so it is given nothing that would need approving.

The shape of all this comes from one observation. The most useful thing you can give an assistant is the ability to actually compute, and the most dangerous thing you can give an assistant is the ability to actually compute. Those are the same sentence. The box, the missing network interface, the approval screen with the real code on it, and the rule that writes can only ever be proposed are four different answers to it.