Design for the steered prompt: how Sudo's sandbox and approval hold up

Leon

• 2026-09-22

Say you are the security architect asked to sign off on an AI assistant that changes your production configuration. Endpoints, AI tools, agents, scheduled tasks, index settings, schemas. The vendor tells you the model is careful. That answers the wrong question. The question you have to answer is what the assistant can reach on the day someone else is steering it.

Sudo is the admin assistant in Curiosity Studio, and that question is the one we wrote our new technical paper around: Inside Sudo: a sandbox, a diff, a person. It is written for platform admins and security architects. It walks through the sandbox mount by mount, lists what is missing from it by construction, and spells out what an approval binds. Its thesis fits on two lines: no route to the host, and no route in except a diff a person approved.

Start from the assumption that the prompt is steered

Prompt injection still has no filter you can rely on. Simon Willison's lethal trifecta talk puts it bluntly: detection layers might catch 99% of attacks, and "in application security, 99% is a failing grade." A late 2025 study with authors from OpenAI, Anthropic and Google DeepMind, summarized in Willison's notes on the attacker moving second, ran adaptive attacks against 12 published defenses. Most fell to attack success rates above 90%.

So the useful design question is what a hijacked assistant can reach, not how to keep it from being hijacked. An admin assistant reads untrusted input all the time: a ticket, a field report, a file an admin attached. The paper's Table 3.1 answers the reach question directly.

At worst, a steered prompt changes the edits in Sudo's own copy. That copy cannot reach the host, cannot call out and cannot apply itself.

Absent beats refused

Sudo runs its scripts in an interpreter, and there is no shell behind it. Computerwelt, an open source .NET library, runs bash and Python in process over a virtual filesystem. There is no bash binary, no PATH lookup and no CPython. Nothing is forked or executed, and no container is started.

The paper's point is about the shape of the guarantee. A blocklist has to be kept complete forever. A capability the interpreter never implemented has nothing to refuse. Network commands are withheld by name as well, so a future library version that adds one does not hand it to the session.

An agent that can shell out is a deputy with the host's authority. An interpreter over nine mounts, two of them writable, has only what it was given. The Computerwelt series covers how the interpreter is built.

Where the person sits

Meta's Agents Rule of Two, also in Willison's post, says an agent should combine at most two of three properties in a session: it processes untrusted input, it can reach sensitive systems or private data, and it can change state or communicate externally. A task that needs all three should not run on its own.

Sudo needs all three to be useful, so the paper is precise about where the person goes. Sudo reads, edits and builds in its own copy, then commit stages the change set and stops. A person reads the diff and applies it. Four gates sit between a draft and your workspace:

The third row is the one I would ask any vendor about. Approval is bound to the commit id on the card. If Sudo staged a newer commit while the card was open, the card refuses to apply, because applying it would ship something nobody read. Approving a description of a change and approving its exact contents are different acts. Only the second is worth a signature.

The rubber stamp objection

A person in the loop who has no time approves everything, and the approval becomes the third property with extra steps. No design makes a tired reviewer careful. The paper's answer is to make each approval worth a person's attention: reads need no approval, a change arrives already compiled, and it arrives as a diff, the same shape as a code review. When a reviewer still misses something, every applied commit is one entry in the configuration history, attributed to the admin who approved it, and can be reversed. The approval cannot guarantee a careful reviewer. It does guarantee that the review covered the exact bytes.

Permissions bound it from below

Sudo's permissions are the chatting admin's, narrowed. It reads the graph with your permissions and skips node types that are never sent to clients. It writes none of your data; a migration runs only once approved. It can declare a secret and write code that reads one, but it never sees the value. Packages, backups, restarts and licensing are not Sudo's to do.

A read only admin gets a read only Sudo: the draft waits for someone who can hand it over.

What to take into your own review

The paper ends on three things to keep, and they make a decent checklist for any agent that touches production configuration, ours or not:

1. No route to the host or the network, enforced by what exists, not by what is refused.
2. No route in except an approved diff, bound to the exact commit shown.
3. Bounded by the approver's permissions, and recorded in the history you already audit.

The same sandbox is open to your own assistants; the last Computerwelt post shows how.

The full paper has the mount listing, the session limits, every button on the review card and what it keeps, and a glossary. Read it on the whitepaper's page, or download the PDF and hand it to whoever signs off on your agents.

Read the whitepaper (PDF)

Further reading

• My Lethal Trifecta talk at the Bay Area AI Security Meetup, Simon Willison. Why prompt begging and detection layers fail, and why removing one leg of the trifecta stops the attack.
• Design Patterns for Securing LLM Agents against Prompt Injections, Simon Willison's notes on the paper. Six patterns that trade agent freedom for resistance to injected instructions.
• New prompt injection papers: Agents Rule of Two and The Attacker Moves Second, Simon Willison. Meta's Rule of Two, and 12 defenses broken by adaptive attacks.
• The Confused Deputy, Norm Hardy. The case for handing a program capabilities instead of checking names, and still the clearest account of why rule lists grow without end.