A Yes button is not a policy

By the fortieth prompt, nobody is reading it. "Allow this command?" turns into a reflex, and the person who runs an agent with write access, or one that can spend money, has quietly become the rubber stamp on their own machine.

A prompt is a good last gate. It is a bad place to keep the rules. This post is about moving the rules somewhere you can read, review and diff, and about the files that carry those rules, which rot faster than most people expect.

What a Yes button actually records

When the only control is "ask the user each time", three things go wrong.

• The rule exists only in the moment. There is no record of what the agent was allowed to do last Tuesday. There is only a run where someone clicked.
• Attention is the budget. The prompts that matter look like the forty that did not. A dialog that says "run this command" gives no hint that this one deletes.
• Nothing changes in a diff. If a teammate, or you, widen what the agent can do, no review sees it. A permission change that doesn't show up in a pull request is a permission change nobody approved.

A recent Medium post (Google Cloud Community, 22/10) argues the same direction in its title: stop clicking Yes, and ship the agent permission policy inside the repository. We take the shape of that argument, not a specific implementation, and apply it to what a Soot gives you today.

Policy is a statement about who, what and on what

The useful unit is not "may it run commands". It is a short sentence with three parts:

• who: which agent, in which job;
• what: which tool and which verb. Reading a balance is not sending a payment;
• on what: which path, host, account or payee, written down before the run starts.

Here is the shape, as an illustration. This is not a Soot file format, just the level of detail worth writing down:

# agent-policy.yaml (illustrative)
agent: release-notes
allow:
  - tool: read_file
    paths: ["docs/**", "CHANGELOG.md"]
  - tool: write_file
    paths: ["docs/release/**"]
ask_a_person:
  - tool: shell
  - tool: send_payment
deny:
  - tool: write_file
    paths: [".env*", "infra/**"]

Once it is a file in the repository, the properties you wanted come for free: a pull request shows who widened write_file, git blame says when, and a review can reject it. The "ask a person" list shrinks to the few calls that deserve a human, so when a prompt does appear, it means something.

What Soot gives you today, and what it does not

Soot is a preview, so we keep to what we can state today. A Soot is one mission plus the tools you explicitly grant. A tool can be declared as needing operator approval; when it is, the call waits in Nest until a person decides, instead of running and reporting afterwards. And soot check --show prints the grants that Soot currently has, so "what is this agent allowed to touch" is a command, not a memory. We covered the first steps in Production agents need a gate, not a free loop, including the fact that a default soot spawn comes with write and host-shell grants, and soot spawn --empty starts without them.

Be clear about the limit: we are not claiming Soot stores your policy as a file in your repository, or enforces a policy file you wrote. A habit that works with what exists is to run the check and keep the output next to your code:

soot check --show > soot-grants.txt   # without --secrets
git diff soot-grants.txt

That is a convention you keep, not a product feature. But it gives you the property that matters: if the grants change, the change is visible in a diff before the next run that touches a real file. Leave --secrets out of anything you commit or paste. The workspace is also not an OS sandbox; host tools run with the host's OS rights, so a policy is a statement of intent, and the grant is what actually refuses.

A related point from A valid signature is not permission: the reason shown to the person approving should name the thing being touched. A line that says *new payee, not on the list* gets read; "Allow once" does not.

The rule files rot too

The policy is half of it. The other half is the text the agent reads: an AGENTS.md or CLAUDE.md, skill files, and the descriptions an MCP server gives its tools. Those are instructions, and instructions behave like code that nobody tests.

Three recent posts point at the same problem from different sides:

• A dev.to post on agent memory (23/10) looks for lines in an agent's memory that are stale, redundant or contradictory, and helps the agent forget them. More notes are not better notes.
• A dev.to post about MCP servers points out that a server can change the sentence that describes one of its tools, and the agent's behaviour changes with it. Its tool diffs the exact words that changed between versions.
• A dev.to post about a rejected skill describes a maintainer's objection that rules in a skill can conflict with the process the harness already has. That is the instruction-file version of two policies that disagree.

None of these needs a new product to act on. It needs a review habit.

A small routine

1. Treat instruction files as reviewed code. AGENTS.md, CLAUDE.md, skill files and policy live in the repo, change through pull requests, and have an owner.
2. Read for contradictions. If one line says "never touch infra/" and another says "fix whatever fails", the agent will pick one, and not necessarily yours. Delete the older line.
3. Prune on a schedule. A line nobody can explain should go. A shorter file gets read; a long one gets skimmed.
4. Snapshot tool descriptions before an upgrade. Save what each MCP tool says about itself, upgrade, and diff. If a description changed in a way you didn't expect, that is a review item before the first run.
5. Re-run `soot check --show` after every change to tools or grants, and read the diff against the last one.
6. Keep prompts for the few things that need a person, and make each one say what it touches.

None of this makes the agent smarter. It makes the permissions boring: written down, reviewable, and changed only on purpose.

Next step

Pick the one tool in your setup that can write or spend. Write down who may use it, for what, and on what, in a file you review. Then run soot check --show and save the result next to it. The docs start at trysoot.com/docs.