AI that asks permission

The nightmare version of an AI assistant is the one that reads “go ahead and cancel that order” in some thread and simply does it. LinearPilot is built around a hard line that rules that version out: the assistant can propose a change to your data, but a person approves it before anything actually happens.

The way it decides what needs a yes is by risk level. Reading your data is low-stakes, so it just happens; asking a question shouldn't require ceremony. Creating something new is lighter-weight. Modifying or deleting records that already exist is the high-stakes tier, and that's the one that stops and asks for explicit approval before it proceeds. The rule tracks how much damage an action could do, not how impressive it looks.

Concretely, that means the assistant will look things up, summarize, and answer across your data without stopping to ask, because reading can't hurt you. Drafting a document or proposing a new record is treated gently as well, since a draft you didn't want is easy enough to throw away. It's the actions that overwrite or remove something real — changing a client's details, deleting a record, sending something outward — that get held back for a human yes. The friction is spent exactly where the risk is, and almost nowhere else.

In practice the approval is not a vague “the AI wants to do something” prompt. It shows you the specific change it intends to make and then waits. Nothing is written until you say yes. A useful side effect is that there's no frantic “undo what the AI just did,” because the default state is that it hasn't done anything yet. Approving before acting is a much calmer model than acting and hoping you can reverse it.

The clearest place to see this is the most powerful thing you can hand an assistant: running actual code over your data. Real analysis, as opposed to a plausible-sounding guess, usually requires executing code. LinearPilot allows that, and it wraps it in the strongest version of the same rule rather than making an exception for it.

Code execution runs in a sandbox with no network interface at all, so the code physically can't call home or reach out to the internet, and it runs only after you approve it. It is available on every plan and ships switched off: an administrator has to turn it on for the company before anyone can reach it. The capability is gated on every one of those fronts — by an explicit company opt-in, by your approval of the specific run, and by the credit meter which charges the AI work of a run against the same pool a chat turn draws from — because it's the feature with the largest blast radius. There is a longer post on how that sandbox is built if you want the mechanism rather than the summary.

Gating the most useful capability the most tightly isn't a contradiction. Power and blast radius are the same axis: the thing that can do the most for you is the thing that can do the most damage if it's wrong. The approval step is precisely what makes it reasonable to give the assistant real teeth instead of shipping a defanged version that can only ever talk.

It helps that the approval is legible. You aren't asked to authorize an abstraction; you see the concrete edit, the field and the value and the record it lands on, and you decide on that. An approval you can't actually understand isn't really consent, so the whole point is to show the change plainly enough that saying yes means something.

The trade-off is real and worth stating. Approvals add friction. If what you wanted was a fully autonomous agent that never pauses to check with you, this is deliberately not that. The bet underneath the whole design is that for anything touching real business records, “show me first” beats “sorry, it already sent the email” every single time.

So permission in LinearPilot isn't a compliance checkbox bolted onto a finished product. It's the shape of the thing. The assistant earns its usefulness by being allowed to act, and it earns your trust by asking first, and those two facts are meant to hold at the same time.