If you administer a Studio deployment, you have a backlog of small changes. A field on the ticket schema. An endpoint that returns open tickets grouped by product. A scheduled task that nobody owns any more. None of them is hard. Each one costs you an hour of finding the right file, the right scope and the right moment.

An assistant with write access should take that backlog off you. The fear is that it takes more than that. In April a post titled "An AI agent deleted our production database" reached Hacker News, and the thread under it ran past a thousand comments. The replies near the top mostly said one thing: an agent's actions are the responsibility of whoever gave it the access. I agree with them. So the useful question is what access you give, and what you get to see before anything happens.

Sudo is the admin assistant in Curiosity Studio, and we wrote a guide for the people who use it every day: Working with Sudo. Two companion papers cover the case for a CIO and the sandbox in technical depth. This one is practical. Its argument fits in two sentences: ask for the outcome, approve the diff. Here is what that looks like in use, and where outside practice backs it up.

Questions cost nothing

Start by asking. Which endpoints are public? What can the triage agent call? Which node types have no index? Are scheduled tasks failing, and what broke after the last deploy? Each of these is a read. Sudo greps code/endpoints/, opens one file in code/agents/, or reads /proc/exceptions and /proc/audit.

Two details matter for trust. Despite the name, the assistant never takes elevated privileges, and its graph queries run under your own permissions. And /proc is regenerated on every read, so the answer describes the system as it is now, not as it was when the chat started. A session that only read leaves nothing behind, so ask as much as you like.

The sandbox has nine mounts, and only two take writes. Your configuration sits in /workspace, as the definitions export writes it. Scratch files go to /tmp and vanish with the session. Everything else (reference examples, docs, the C# SDK, live runtime state, your uploads) is read-only.

Say the outcome, not the surface

When you want a change, describe what users should be able to do. "Users should be able to filter tickets by product" beats "add a facet". The answer might be a facet, an index setting or a schema field, and Sudo can look before it decides.

The paper's main example takes that sentence one step further: filter tickets by product, and show the product on the ticket card. That one request touches four surfaces. A field on the Ticket schema, a migration task to backfill it, index settings, and a renderer for the card. Sudo edits all four, compiles the schema and the code that uses it together, and stages one commit. If anything fails to build, the whole set is refused. Then it stops. Nothing has run, and the backfill starts only after you approve.

Reviewing is reading the diff

The pending changes panel opens the staged commit. You can read it file by file, side by side, or as one page with a comment box under each file. You can edit the right-hand side yourself, or comment and ask for changes. Then you press one of three buttons:

Button	What it does	Sudo's edits
Approve	Applies every file, as one commit	Applied, attributed to you
Discard	Throws the commit away	Kept, for another try
Reset	Returns Sudo's shell to live	Thrown away

There is a fourth case. If Sudo staged a newer commit while an older card was still open, the old card refuses to apply, because approving it would apply something nobody read. And Discard says nothing in the chat, so silence is never taken as approval.

The habit the paper keeps returning to is one commit per idea. Google's public guide for change authors makes the same case. It says the right size for a change is "one self-contained change", reviewed faster and more thoroughly than a large one. It calls 100 lines usually reasonable and 1,000 usually too large. It also notes that a 200-line change spread across 50 files is usually too large.

The same guide carves out an exception: a large change generated by an automatic refactoring tool "that you trust completely" can be bigger, because the reviewer only confirms they want it. An assistant's commit does not qualify. You are reading it precisely because you do not trust it completely yet. So the guide's main rule applies, and the paper's exception matches the guide's own: work that only makes sense together, like a schema and the migration that fills it, goes in one commit. Google says the same of a new API and its first caller.

What the sandbox cannot do

Simon Willison's lethal trifecta is a clear framing for agent risk: private data, exposure to untrusted content, and a way to communicate externally. Combine all three and an attacker can instruct the agent to send your data out. Remove any one leg and that attack fails.

Sudo cannot remove the first two. It reads your configuration, which is private, and it reads files you attach, which may contain text written by someone else. So the sandbox removes the third leg. There is no network, no host filesystem and no process spawning. curl, ssh and git are absent from the sandbox, which is stronger than refusing them. Caps are hard too: 120 seconds of wall clock and 100,000 commands per script, 4 MB of captured output, and a session that ends after 30 idle minutes. A cap that is reached raises an error instead of returning half an answer.

The paper names the limit of this. Code you approve can call out once it runs. That is the code's authority, not Sudo's, and it is the main reason to read every line of a diff that adds an endpoint or a connector. Willison makes a related point: instructions that beg a model to behave are not a security control, because "in application security, 99% is a failing grade." Sudo's rules live in a skill you can read, and they shape how it works. The boundary is elsewhere: the missing network, and the commit that waits for a person.

Running things is a request too

Starting a task, a migration or a reindex is a shell command, and each run gets a folder under /proc/runs/<id>/ with its status, log and output. "Run the nightly refresh and tell me if it worked" becomes run task, then reads of the status and the log. Small settings, like turning on the copy disclaimer and keeping chats for 30 days, become two values in one config file, in a small diff. Deleting an old task commits the deletion. Sudo refuses to delete a built-in.

Every applied commit is one entry in the configuration history, attributed to whoever approved it. You can read it under Manage, Access, Audit log, or from the sandbox at /proc/audit. Code surfaces keep their own history, so a change made through the assistant rolls back like one made by hand.

Teach it once, with a skill

Sudo's voice and boundaries are a skill in your configuration, sudo-persona. It says to verify intent, target and impact first, to go ahead with small reversible work, to ask before anything destructive, security sensitive, externally visible or ambiguous, to touch only the lines needed, and never to report success it has not confirmed. Read it before your first real change.

Your own conventions belong in a skill too. How your team names endpoints, where agents live, who signs off on a schema. The paper's rule of thumb: if you say it at the start of every session, it belongs in a skill. Ask Sudo for a draft and review it like any other change.

The paper closes with five habits. I would start with two. Ask for the diff early: "show me what that would change" catches a misunderstanding while it is still one file. And hand over the file instead of describing it. Attach the spreadsheet, the PDF or the zip, and a CSV becomes columns and null counts before it becomes a schema.

Read the guide

Working with Sudo is 22 pages, with the mounts, the review screen, the run commands and a glossary. Read it before you hand Sudo its first real change, then open the admin dock and start with something small.

Read the whitepaper (PDF)

Further reading

• Small CLs, Google engineering practices. Why one self-contained change at a time gets a better review, and the narrow cases where a large change is fine.
• How to do a code review, Google engineering practices. The reviewer's side of the same process, discussed at length on Hacker News.
• My Lethal Trifecta talk at the Bay Area AI Security Meetup, Simon Willison. Private data, untrusted content and external communication, and why removing one leg is the defense that holds.
• Design Patterns for Securing LLM Agents against Prompt Injections, Simon Willison's notes on an 11-author paper that trades agent generality for constraints you can reason about.
• An AI agent deleted our production database, Hacker News. The discussion, more than the incident, is the point: most replies place the responsibility with whoever granted the access.