Judge an AI admin by its authority, not its model

Leon

• 2026-10-07

Ask a security lead whether an AI assistant may change a production system, and you hear three fears. It does something nobody reviewed. It reaches somewhere it should not. It sees data it should not.

Vendors usually answer with the model: it is better aligned, it follows instructions, it was tested. That answer misses the point. Each of those fears is about authority, not intelligence, and a smarter model answers none of them.

That is the argument of our new whitepaper, An AI admin you can approve. It is written for CIOs and security leads, the people who say yes or no to an AI admin. It explains how Sudo, the admin assistant in Curiosity Studio, changes your configuration without ever holding the authority to do harm. Its short version fits on one line: Sudo does the work, a person keeps the say.

The risk is what the assistant can reach

An assistant that shells out to a real shell has the host's authority. Whatever the service account can reach, the assistant can reach. A rule checked at run time is all that stands between them.

Security people have a name for this shape of problem. Norm Hardy wrote it up as The Confused Deputy: a compiler that held a license to write into its own system directory. A user handed it the name of the billing file as its debug output, and the compiler overwrote it. Hardy's diagnosis was that the program "runs with authority stemming from two sources" and "has no way to keep them apart." An AI assistant running as a service account on behalf of an administrator is the same deputy, with a language model choosing which file to name.

The usual fix is a policy layer: rules, filters, a classifier that catches bad instructions. Simon Willison, who coined the term prompt injection, is blunt about that in his post on the lethal trifecta. Guardrail products tend to claim they catch "95% of attacks", and "in web application security 95% is very much a failing grade." His later write-up of two papers covers a study in which adaptive attacks bypassed 12 published defenses, most with success rates above 90%.

So the paper asks different questions. What can the assistant reach? What can it change without you? What does it leave behind? Four mechanisms answer them: a sandbox, an approval, your permissions and a record.

Dangerous things are absent, not blocked

Sudo works the way a developer works: it reads files, runs commands and hands you a diff. The difference is where those commands run. Sudo's shell never leaves Studio's own process. It is Computerwelt, an open source .NET library with a bash and a Python written in managed C#, over one virtual filesystem. There is no bash binary and no Python runtime underneath.

So the dangerous parts are missing by construction. No path resolves to a file on the server. Nothing is forked or executed, and no container is started. Network commands are withheld rather than present and refusing, so if the library ever grows one, a session does not silently acquire it.

Sudo may write to two places only: its own copy of your configuration, and scratch space discarded with the session. Everything else is read only and read fresh from your live deployment on every command. Each chat gets its own sandbox, and every script runs inside fixed limits that raise an error when reached, so a search that stopped halfway is never reported as the whole.

This is where the difference from a general purpose sandbox shows. Senko Rašić's guide to sandboxing coding agents with bubblewrap is a careful setup for a developer laptop. He says plainly that "Bubblewrap and Docker are not hardened security isolation mechanisms," and that he accepts the risk of data from the current project leaking out. For a developer's own machine, that trade can be fine. For an assistant inside a production deployment, it is the wrong starting point. A container runs real binaries against a real kernel and walls them off. Sudo's commands are interpreted inside Studio's process, with nothing underneath to wall off.

Willison's trifecta is private data, untrusted content and a way to communicate out. An admin assistant needs the first and may meet the second in uploaded files and configuration. Sudo has no route out of its sandbox, which takes away the third. Code you approve can still call out once it runs, the paper notes, but that is the code's authority, and it exists only after a person approved it.

Nothing runs until a person approves

Here is the loop. You ask in plain language. Sudo edits its copy. Every changed file is compiled against your deployment, and one failure refuses the whole set. Sudo stages the change as one commit, then stops and waits. You read the diff, file by file, and approve or discard it.

A team at Meta proposed an Agents Rule of Two: an agent should have no more than two of untrusted input, access to sensitive systems, and the ability to change state. When a task needs all three, it "requires supervision," via human approval or another reliable check. An admin assistant needs all three by definition. Sudo's approval is that supervision, and the paper is specific about what makes it reliable:

An approval is bound to one staged commit. If Sudo stages a newer commit while your review is open, that review refuses to apply. Approving would apply something nobody read.
There is one way in. An approved commit is an ordinary import of the changed files, through the same code that imports an uploaded configuration export.
Silence is never a yes. Approving says so in the conversation, in your voice. Discarding keeps Sudo's edits and says nothing there.

The fair objection is approval fatigue. Rašić's post starts from it: his coding agent asks before it reads, writes or runs anything, which interrupts him often enough that he cannot do much in parallel. The way out on offer is a mode that skips the prompts entirely. The paper's answer is to put the approval somewhere else. Sudo does not ask before each command, because a command in the sandbox can only touch Sudo's own copy and its scratch space. It asks once, at the end, for the change set, and you review a diff instead of a stream of permission prompts.

Sudo sees what you see

Despite the name, Sudo never assumes elevated privileges. Every read runs under the permissions of the administrator in the chat, and none of your data is written. A migration that fills a new field runs only after you approve it. This is the same principle we argued for in permission-aware retrieval: the assistant works from the view the person asking already has.

Some things stay out of reach even for a reader. Sudo can declare a secret and write code that reads it, but never sees its value. Access group membership is yours to manage. It installs no packages, runs no backups, restarts nothing and touches no licenses. Your own account narrows it further: for an administrator who may only read, or for everyone while write protection is on, Sudo drafts the change and cannot stage it.

Every change is on the record

Each approved commit is one entry in your configuration history, attributed to the administrator who approved it, in the same audit log as a change made by hand. An endpoint changed through Sudo is reviewed and rolled back like one changed by hand. You need no second audit process for the assistant.

Sudo's manner is a skill in your deployment that you can read and edit. It tells Sudo to check intent, target and impact, and to ask first on anything destructive. The paper is careful here: the guarantees do not rest on that skill. They rest on the sandbox and the approval.

Seven questions to ask any AI admin

The paper ends with the part I would hand to a security lead before a pilot. Ask these of any vendor, us included. An answer from the middle column means the safety rests on the model behaving.

Ask the vendor	The answer to worry about	Sudo's answer
What can it reach on the host?	What the service account can	Nothing outside its sandbox
Can it reach the network?	Blocked by a rule	No route out
What runs without review?	Small changes, automatically	Nothing at all
What exactly do we approve?	A summary of the change	The diff, bound to its commit
Whose permissions does it use?	Its own service account	The admin in the chat
Can it read our secrets?	If it has access	Never a secret's value
Where is the record?	In the vendor's logs	Your audit log and history

Then ask to see it rather than hear it. Install the free developer version of Studio on a machine you control. Ask Sudo for one small change and read the staged diff. Discard it and check that your deployment did not move. Approve the next one and find it in the audit log. Sign in as an administrator who may only read and ask for the same change: Sudo drafts it but cannot stage it.

Where to go next

This paper stays at the level of the decision. Two companions go further. For the engineering underneath, the mounts, the build check and the commit binding, read Inside Sudo: a sandbox, a diff, a person. For the people who will use Sudo every day, Working with Sudo is the admin guide. Sudo: seventy-four tools, replaced by one shell is how the sandbox design came about.

The whitepaper is 21 pages, with the full table of fears and mechanisms and a glossary. Read it on its page or download the PDF.

Read the whitepaper (PDF)