Judge an AI admin by its authority, not its model
Leon
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. 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, and a rule checked at run time is all that stands between them. Norm Hardy described this shape in The Confused Deputy: a program that "runs with authority stemming from two sources" and "has no way to keep them apart."
The usual fix is a policy layer: rules, filters, a classifier that catches bad instructions. Simon Willison 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."
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. 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
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." 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.
- 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. 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.
Sudo can declare a secret and write code that reads it, but never sees its value. For an administrator who may only read, 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. 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, ask Sudo for one small change, and read the staged diff.
Where to go next
Two companions go further: Inside Sudo: a sandbox, a diff, a person for the engineering underneath, and Working with Sudo for the people who will use it every day.
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.
Further reading
- The Confused Deputy, Norm Hardy. The short paper on a program serving two masters, and the clearest account of why authority, not intent, is the thing to design around.
- The lethal trifecta for AI agents, Simon Willison. Private data, untrusted content and external communication, and why guardrail products are no answer to the combination.
- New prompt injection papers: Agents Rule of Two and The Attacker Moves Second, Simon Willison. Meta's rule for when an agent needs human approval, and a study of how adaptive attacks get through published defenses.
- Sandboxing AI agents in Linux, Senko Rašić. A practical bubblewrap setup for a coding agent, candid about what a container sandbox does not protect against and about the cost of approving every action.
Read next
Articles on context graphs, enterprise search and industrial AI
