An AI Agent Cannot Sudo, and That Draws the Line for You

I handed an AI coding agent a real job: deep-clean a production server over SSH before it got wiped and shipped. The instinct is to be nervous about that. An agent running destructive commands on a live box is exactly the scenario people warn about. What actually happened is that the agent could not run the dangerous half of the work at all, because it cannot sudo. The permission model split the job into an agent-safe lane and a human-only lane without anyone designing that split.

What the agent tried, and where it stopped

The agent worked through the reclaimable clutter first. It ran container tooling to purge stopped containers, dead images, and build cache, then removed a stale checkout in the home directory. None of that needs elevation, and it added up fast:

About 39 GB gone, all from commands that run as the login user. Then it hit the service layer: disabling old systemd units, purging packages, switching the box to a headless boot target. Every one of those needs sudo, and there the agent stopped.

Why the agent cannot cross that line

Two things put a hard wall between the agent and root, and both are worth keeping.

First, the shell an agent runs commands through has no controlling terminal. sudo wants a TTY to prompt for a password, and without one it fails immediately with sudo: a terminal is required to read the password. This is not a policy the agent can talk its way around. The command simply cannot complete.

Second, and more important, feeding the password to the agent is off the table by design. An agent that can type your root password into a prompt is an agent that can be talked into doing it for the wrong reason. The rule that an agent never handles credentials directly is what makes the first limitation a feature instead of an annoyance.

The split the permission model drew

So the cleanup fell into two lanes on its own, with no policy document describing them:

The human ran the second lane in a separate terminal with ssh host -t sudo ..., where -t forces a real TTY so the password prompt works. The agent had already done the bulk cleanup and left a clean report of what remained, so the human's turn was a short, reviewed list of elevated commands rather than an open-ended session.

Why this is a good default, not a limitation to fix

It is tempting to hand the agent a passwordless sudo rule and let it finish the whole job. Resist that. The commands that need root are the ones you most want a human to read first: disabling services, purging packages, changing what the machine does on boot. The sudo boundary routes exactly those to a person, and leaves the reversible, low-blast-radius work to the agent.

You get this for free if you do not undo it. Keep credentials out of the agent's hands, do not add a blanket passwordless rule, and the split takes care of itself:

• The agent handles container cleanup, cache reclaim, and file removal under the login user, and reports what it could not touch.
• Anything needing root lands in a human lane by construction, run over an explicit ssh -t sudo session on a short list the agent already scoped.
• If you must grant temporary elevation, make it a narrow, time-boxed rule you remove before the box leaves your hands, not a standing grant.

The most reassuring thing about letting an agent near a production server was discovering how much it was structurally unable to do.