
What should an agent be allowed to do without asking?
A tool I built quietly rewrote my own source files six times before I noticed, and I had been watching it the whole afternoon.
We would not give a new colleague commit access on their first morning, no onboarding, no review, and a mandate to change anything they judged worth changing.
We hand agents exactly that, routinely, and mostly by not deciding anything at all.
What does an unexamined permission look like?
Here is one from this site, and it is mine.
The illustrations here are generated, and there is a small local tool for redrawing one when it is wrong. It had a feature that seemed obviously good: take the page's first paragraph as the new brief, since that is usually what the drawing is about. Adopting a new brief means updating the file that stores it, so the tool wrote the new text into the settings block at the top of the content file.
Every part of that is reasonable in isolation. Together they meant that clicking a drawing silently overwrote a hand-written instruction in a source file.
It happened six times in one afternoon. Curated briefs replaced with page summaries, illustrations redrawn from the wrong text, and no error anywhere, because nothing had gone wrong by the tool's own definition. I was watching the whole time. The first audit I ran to clean it up used a rough rule of thumb and missed one of them.
Why did that take so long to notice?
Because the tool was doing what it was told, and because the destructive part was bundled with the useful part.
There was one button. It meant redraw this, and it also meant replace the stored instruction with whatever is on this page. Nobody chose the second thing; it arrived attached to the first.
I have come to think that is the shape of most permission problems. Not a dramatic capability handed over deliberately, but a small convenience with a side effect nobody separated out.
Who pays for a default like that?
In my case, nobody outside my own repository. But the pattern is not confined to illustration tools, and the general version is not harmless.
An agent with permission to edit design tokens without asking can change a color that
was graded for contrast into one that was not. An agent with permission to rewrite
component markup can remove an aria-label it judged redundant. An agent allowed to
"tidy" a stylesheet can drop a focus style it read as decorative.
None of those fail a test. None of them announce themselves. They arrive as part of a larger change that is mostly good, in a diff too long to read closely, and they are discovered by someone who cannot use the result.
Unreviewed change is where accessibility regressions live, and permissions are what decide how much change goes unreviewed.
Is asking every time the answer?
No. A tool that confirms everything trains people to confirm without reading, which is worse than not asking, because now there is a record of consent that means nothing.
The distinction I would draw is not between big and small actions. It is between reversible and destructive.
Redrawing an image is reversible; the old file is in git and the cost is eight cents. Overwriting a hand-written brief is destructive, because the text existed nowhere else. Those two deserve different treatment even though they sit in the same feature.
The fix here was not a confirmation on everything. It was to separate the two. The plain button redraws from the stored brief and never touches a file. Adopting the page text is a second, differently labeled button behind a dialog that names the file it is about to overwrite.
What would a reasonable default look like?
- Separate reversible from destructive, in the interface. Not in the documentation. One button should not quietly do both.
- Name the thing that will change. "This overwrites the brief in
post.mdx" is a decision. "Are you sure?" is a reflex. - Let the approval gate be annoying. In a multi-agent setup a person approving the plan before anything runs feels like friction every single time. It is also the only moment where someone with context looks before money and changes start moving.
- Default to read. An agent that can read everything and write narrowly is more useful than most people expect, and it fails in ways you can see.
- Make destructive actions loud in the log. Ours now prints the file it rewrote. Six silent rewrites is a tooling choice, not an accident.
- Audit against intent, not a heuristic. My first cleanup compared each brief to its page summary and missed the one where they differed. Comparing against the list of what I had actually written found it immediately.
Why I think this generalizes
Permissions are a design decision, and like most design decisions they get made by default when nobody treats them as one. The question what may this do without asking deserves the same attention we would give to any other consequential default, because that is exactly what it is.
Look at the agent tooling you use this week and find one thing it can change without telling you. Decide whether you meant that. The conventions for this are still soft, and they are being set by whoever bothers to think about it first.