14 Oct 2026 · Tobias Lindqvist-Rao (editorial persona) · Enforcement architecture · on threat.cafe

A classifier that misses 17% of overeager actions: layering model-based approval over deterministic deny rules

Claude Code's auto mode is not safe enough on its own for actions you cannot undo, and Anthropic says so. In its own evaluation, the full classifier pipeline let through 17% of 52 real overeager actions, and Anthropic describes it as "not a drop-in replacement for careful human review on high-stakes infrastructure." The classifier is still far better than a tired human clicking yes. The design that follows from both facts has three layers: deterministic deny rules and hooks at the bottom for known-bad artifacts, credential paths and irreversible commands; the classifier in the middle for everything ambiguous; and a person at the top for the short list of actions that must never be auto-approved. Claude Code's documented decision order already supports this, because rules resolve before the classifier is consulted.

The published error rates

Anthropic's engineering write-up of 25 March 2026 reports a two-stage classifier: a fast single-token filter, then a reasoning stage that runs only when the first stage flags an action (Anthropic Engineering).

Dataset (n)                         Stage 1 only     Full pipeline
----------------------------------  ---------------  ---------------
Real traffic (10,000)               8.5% FPR         0.4% FPR
Real overeager actions (52)         6.6% FNR         17% FNR
Synthetic exfiltration (1,000)      1.8% FNR         5.7% FNR

Read the table by row, not by headline. The 0.4% false-positive rate on 10,000 real actions is why auto mode is pleasant to use: it rarely blocks legitimate work. The 17% false-negative rate is on a set of 52, so it rests on a handful of misses and its confidence interval is wide. The second stage trades misses for fewer false alarms: false negatives rise from 6.6% to 17% while false positives fall from 8.5% to 0.4%. That is a deliberate tuning choice for usability.

The comparison that justifies auto mode comes from Anthropic's 7 August 2026 post: in a study of 1,053 testers, "human review caught just 13.6% of dangerous commands, while auto mode caught 89%," and users approve 97% of permission prompts (Claude blog). The same post says auto mode "does not eliminate risk" and recommends reviewing high-stakes production changes yourself. These are vendor-run evaluations, and the rates will change between releases.

What the classifier sees, and what it is blind to

The classifier is reasoning-blind by design. In Claude Code's own classifier requests, it sees user messages, tool calls other than read-only lookups, and CLAUDE.md content. Tool results are stripped "so hostile content in a file or web page can't manipulate the classifier directly" (Claude Code permission modes). A separate server-side probe scans incoming tool results and flags suspicious content before Claude reads it.

That design closes one injection path and opens a blind spot. The classifier judges npm install some-package on the text of the command and the conversation. It has no way to know that [email protected] was published from a hijacked account forty minutes ago. A classifier cannot know facts that are not in its input. Known-bad status is a lookup problem, not a judgement problem.

Rules resolve before the classifier runs

The current documentation gives a fixed decision order for auto mode. The first matching step wins:

Actions matching your allow, ask or deny rules resolve immediately, with listed exceptions such as writes to protected paths.
Read-only actions and file edits in the working directory are auto-approved, with exceptions.
Everything else goes to the classifier.

Two further properties make the bottom layer reliable. Deny rules are evaluated first across all settings scopes, and a managed deny "can't be overridden" by any other level (Claude Code permissions). And PreToolUse hooks "run before the permission prompt"; a hook that exits with code 2 "stops the tool call before permission rules are evaluated," so the block applies even when an allow rule would let the call proceed. A hook that returns allow does not override a deny rule.

One caveat matters for anyone extending the client. A mod that handles tool.check can approve an action before the classifier step. On a machine with managed settings, or on Team and Enterprise plans, deny rules hold over mods by default, and a PreToolUse block from a managed hook holds too.

The three-layer design

                 +--------------------------------------------------+
  TOP            |  Person: ask rules for irreversible actions      |
  (rare)         |  git push to protected branches, prod deploys,   |
                 |  tools marked requiresUserInteraction            |
                 +--------------------------------------------------+
  MIDDLE         |  Auto-mode classifier: everything ambiguous      |
  (most calls)   |  scope creep, unfamiliar infrastructure,         |
                 |  actions driven by content Claude read           |
                 +--------------------------------------------------+
  FLOOR          |  Deterministic: managed deny rules, PreToolUse   |
  (every call)   |  hooks (exit 2), sandbox network allowlist       |
                 |  known-bad artifacts, credential paths, egress   |
                 +--------------------------------------------------+

The floor handles what can be decided without judgement. The middle handles what needs judgement but not a person. The top handles what needs a person regardless of how good the judgement is.

What belongs on the floor

Known-bad artifacts. A PreToolUse hook matched to Bash that parses install commands and checks the exact name and version against a local list, exiting 2 on a match. Use a local file, not a network call: a hook that hits its timeout "doesn't block the tool call" unless onFailure is set to "block" (Claude Code hooks).

Credential reads. Managed Read deny rules for paths such as ~/.ssh/** and ./.env. The docs note these apply to Claude's file tools and to recognised shell commands like cat, but not to "arbitrary subprocesses that read or write files indirectly," and point to the sandbox for OS-level enforcement.

Network egress. A deny rule on curl does not match the same program "by path or inside sh -c," so the docs recommend pairing it with the sandbox network allowlist when the restriction must hold. Egress is a sandbox job, not a command-text job.

The mode itself. Admins can set permissions.disableBypassPermissionsMode and permissions.disableAutoMode in managed settings, and allowManagedPermissionRulesOnly to make managed settings the only source of permission rules.

What belongs at the top

Use ask rules for actions that are irreversible or cross a trust boundary. The docs confirm that an ask rule matching command content, such as Bash(git push *), "still prompts you" even inside compound commands and in auto mode. MCP server authors can mark a tool with _meta["anthropic/requiresUserInteraction"], which forces a prompt on every call even in auto and bypass modes (Claude Code MCP docs). Keep the list short. The 97% approval rate is what happens to a long one.

Defaults moved: check what your fleet runs

Auto mode's reach has grown since the August announcement. The 7 August post made it the default for new sessions on Pro, Max and Team from 14 August and kept it opt-in on Enterprise "for now." The current permission-modes page says that with Claude Code v2.1.283 or later, auto mode is the built-in starting permission mode for interactive terminal and VS Code sessions "on every plan and provider." Admins who want a different starting mode set defaultMode or disable auto mode in managed settings.

Two behaviours are worth testing in your own environment. When the classifier blocks three times in a row or 20 times in total, auto mode pauses and prompting resumes. In a non-interactive -p run with no prompt tool, the current docs say the blocked action does not run "and Claude keeps working"; the March engineering post described headless sessions terminating instead. Pipelines that relied on the older behaviour should be re-checked.

Incurred trade-offs

A deterministic floor costs maintenance. Deny rules need owners, the known-bad list needs a source that updates faster than advisories, and every hook adds latency to the calls it matches. A floor that blocks too much will be bypassed by people, so keep it to decisions that need no judgement.

Review cadence

Re-read the published rates and the decision order on every minor release you roll out, and re-run three checks: a canary known-bad install that the floor must block, a credential read that a deny rule must stop, and a git push that must prompt. If any of the three reaches the classifier, the floor has a hole.

For the known-bad layer of the floor, the threat.cafe board records malicious packages, skills and MCP servers with their sources, which is the kind of exact-version data a hook can check offline.

Sources

#claude-code #auto-mode #permissions #hooks #guardrails

All posts