In one week Claude Code started counting the rules a folder pre-approves, and offered to draft a trust boundary from evidence. Both are the right instinct. Both stop one step short of the question those labels make askable.
This arrived in the second week of August, and it had never been surfaced before. Open a session in a folder with a populated allowlist and Claude Code stops to tell you how large that list is, and asks whether you trust it.
The real dialog, from the repo this site is built in. The 278 is real too.
This is the right instinct, and it is a bigger change than it looks. The allowlist has been promoted from a convenience file that grows in the background to a security artifact you are asked to consent to, at the one moment you are actually paying attention. Two days after auto mode became the default, Anthropic was pointing at the surface that auto mode does not screen: the rules you already granted. Nothing in my repo changed overnight — those 278 entries were there the day before, silently.
But a count is not a verdict, and 278 is not a number anyone can act on. It tells you the pile is large. It does not tell you whether any two rules in it compose into a path from untrusted content to credential or source egress — and the pile got large the only way these ever do: one “yes, allow” at a time, each individually reasonable, none ever revisited. The dialog asks a question it gives you no instrument to answer. Only proceed if you trust this configuration. For most repos the honest answer is “I have no idea.”
polycheck reads the same files the dialog counts, and returns the verdict instead of the number.
The same week, Claude Code proposed an auto-mode setup for this repo. Read it closely, because it is better than I expected — and it stops in an interesting place.
Excerpted from the real proposal, on this repo.
That distinction is the part worth noticing. Nothing in that list came from asking me to fill in a form. Every entry was derived from something observable, and the derivation is stated next to the conclusion.
| What it declared | How it got there |
|---|---|
| Cloud provider | Counted aws CLI invocations — 47 in this project, plus shell history. |
| Repository visibility | Confirmed through the GitHub CLI. Not asked, checked. |
| Trusted internal domains | The hosts this project's transcripts contacted repeatedly. |
| Sensitive remote targets | A naming rule with a stated matching discipline: prod as a whole word or name segment, so prod-db counts and producer does not. |
| Branch protection | Nothing. It could not query rulesets, so it wrote that the status is unverified and said do not assume unprotected. |
That last row is the one I'd hire. Where the default branch was unset it left it unresolved rather than guessing; where protection could not be confirmed it recorded uncertain rather than absent. No silent defaults. That is exactly the discipline polycheck's INCONCLUSIVE verdict exists to enforce — colouring an unchecked thing green is the most dangerous thing a security report can do, and this proposal refuses to.
It produces labels. Trusted domains. Sensitive data locations. Sensitive remote targets. Protected IaC scopes. What it does not produce is an answer to the only question those labels make askable: can the permitted operations, in some order, carry untrusted input to an outbound channel with no gate in between?
Instead the proposal closes with this:
Allow carve-outs none suggested — defaults look like they cover your usage
That is a coverage claim, and coverage claims are the kind of thing you prove, not the kind of thing you eyeball. On this repo the same policy surface resolves to 134 modeled actions. “Looks like it covers” and “does cover” are different statements, and the distance between them is a graph search — not a judgment call, not a matter of care or seniority.
allow is an ungated edge, ask a gated one, deny no edge at all. Check is a reachability question over a finite graph, and reachability is decidable — you do not need an opinion about it, you need a search. That is the part I build.
Anthropic turned on auto mode by default in Claude Code for Pro, Max and Team users, with Enterprise and API following within a month. A classifier reviews shell commands and actions instead of prompting you for each one.
It is a good change and the data behind it is not close.
The reason is the part everyone in security already suspected and nobody had numbers for: people approve 97% of the prompts they are shown. A checkpoint that is waved through 97 times in 100 is muscle memory, not a control.
Manual approval was never the control we told ourselves it was. So this is an improvement. It also quietly changes where your risk lives, and that is the part worth ten minutes.
Two specifics from the announcement. Auto mode sets aside allow-rules broad enough to grant arbitrary code execution — python:*, Bash(node:*) and friends — so the classifier can review those commands rather than letting a blanket grant wave them through. Deny and ask rules continue to apply. Your settings files are not modified.
Read that again as a security engineer. Anthropic has independently concluded that a broad Bash(...) prefix is not a boundary, and neutralised that class of rule. Which means the levers that still bind your agent afterwards are deny, ask, and every allow-rule that isn't arbitrary code execution — and those are precisely the rules almost nobody has audited.
That is not a tuning problem, it is structural. The lethal trifecta — Simon Willison's name for untrusted content, sensitive data and an outbound channel coexisting in one session — is a sequence of individually reasonable calls. WebFetch a page. Read a file. Have an MCP tool post the result.
Not one of those is a shell command. Each is separately fine. The hazard is the state they assemble, and no per-action screen, however good, has a vocabulary for “not both, in one session, after untrusted input.”
Scan → Label → Compile → Check. The dialog and the setup wizard do the first two, from better evidence than a questionnaire would give them. Compile is bookkeeping: allow is an ungated edge, ask a gated one, deny no edge at all. Check is a reachability question over a finite graph, and reachability is decidable — you do not need an opinion about it, you need a search. That is what polycheck does, on the same files the dialog counts, and it returns the verdict instead of the number.
Jean-Jacques Dubray · Provable Trust · polycheck · Governing agents
© 2026 Cognitive Fab. All rights reserved. · Glossary