AI agents are becoming ever more capable as models, harnesses, and context engineering improve, and as every system becomes a surface for agent-first consumption.

Robinhood just launched MCP for their trading platform and credit card. Now you can now tell Claude: "You are an expert day trader. Make a million dollars—make no mistakes." Yeah...maybe don't do that.

Okay, but actually:

• Organizations now routinely have teams of agents running continuously doing long-horizon engineering work.

• You can get a PagerDuty alert and before you even ack, an agent is already looped in, pulling context from PagerDuty, querying your o11y stack via Grafana MCP, searching Slack and Jira, combing through recent changes in GitHub, and by the time you respond, it's already formed a strong hypothesis and sent a rollback PR and posted an update on the incident.

Safety, Speed—Pick One

Yet the average dev is still dealing with this:

multiple times an hour, possibly every minute.

That is...unless they run Claude with --dangerously-skip-permissions which many do do out of approval fatigue. Or they configure an extremely broad static allowlist in their settings that lets a lot of things through.

That's because Claude fine-grained permission model (a regex-like pattern matching model) is too limited to represent compound commands (cd dir && git status), pipes and redirects, or multi-line scripts.

So you either babysit it, or you relax the restrictions and hope it doesn't do this:

Agents are ultimately a deputy of the user. The risk you run into anytime you fully deputize to another is How confident are you in the deputy's judgement to act autonomously on your behalf?

It's the classic confused deputy problem extended to AI agents who are non-deterministic and can be influenced by all manner of adversarial influences, and who often have extensive ambient authority—usually they act with your full confidence and privilege, unless you sandbox. So if you fully deputize to an agent, it can usually delete your whole computer if you could too.

Toward More Autonomous Agents

There is a better way. Anthropic built "Auto Mode" for Claude Code for just this use case: to automate decisioning in a safer way by letting an LLM judge tool use requests against user intent and detect obviously harmful or errant behavior.

(credit: Anthropic)

The only wrinkle is it's only for first-party Anthropic inference only—no Amazon Bedrock, Google Cloud Vertex, etc. If only we could make our own...

Unintentional Open Source

On Mar 31, 2026, Anthropic accidentally (?) "open sourced" their entire Claude Code CLI source code through an included .map file uploaded to their NPM repo.

This contained a treasure trove of harness engineering material: the orchestrator control and feedback loop, system prompts, the query engine and context management design. It even exposed internal harness-side safeguards and anti-distillation defenses!

One of the less-noted features of the leak was the client-side of Auto Mode, their yoloClassifier.ts—with a name like that you know it's gonna be a banger.

An Auto Mode For The Rest Of Us

Armed with this reference and inspiration, I decided we could build this ourselves as a Claude Code hook, specifically, a PreToolUse hook that fires on every tool request:

For the full classifier and hook design, see my design doc, but a couple parts to call out:

Tool Skip-List

Claude's auto mode has a "skip-list" of tool calls that elide classification, and we do the same. This saves on latency and tokens on a small, curated list of known "safe" tool usages (e.g., Read, Grep).

On skip, the hook is "silent," meaning it doesn't proactively approve, it just pretends it was never there to begin with, so that Claude Code will do whatever it would've done (approve, deny, or deny) based on its own permission workflow and session state (e.g., if the user approved reads from that dir).

Denial Backstop

When the classifier denies, it denies with a reason that's meant to nudge the agent into re-anchoring on user intent and pursuing an alternative approach.

Usually the agent does get the hint and is steered toward safer behavior, but in the rare cases that the agent gets stuck in a loop going down the same path, or in the case the model or classifier machinery has a false positive issue, a backstop kicks in after 3 consecutive blocks or 20 overall in a session, and intentionally interrupts the user with a prompt.

We do this by returning an "Ask" verdict that tells the agent to raise a permission prompt, thereby returning control to the user.

The Prompt

This is the fun part. Our classifier prompt is...shall we say, inspired by the Claude Code source leaks. 🙂

Anatomy Of A Prompt

At a high level, it's two parts, a system prompt and the user message portion, representing the distinction in trust:

• The system prompt is authoritative and largely static, with a few user-configurable knobs.

• The user messages contains the user's messages and their relevant CLAUDE.md files (user intent), along with the sanitized transcript and the proposed action. This part is adversary-controlled and less trusted.

System Prompt

A high level breakdown of what's in the system prompt:

User Messages

A couple call outs:

User Intent

This is where the LLM basis of the classifier really shines, because it can catch both malicious (e.g. prompt-injection driven) or overeager behavior (e.g., Claude starts exploring the filesystem to find credentials in what it thinks can help it accomplish the user's task when no one said that was ok) that don't match user intent.

If you say, "Don't push yet" and the agent tries to push, it's easily caught, and if you later authorize it with, "Okay now push," the classifier lets that through. Similarly, curl <url> | sh looks sketchy, but if the user told the agent to do that (e.g., to install some tool), that's authorizable—no static ruleset can do that.

Ambiguous user intent can be tricky to reason about, but LLMs with the right prompt are surprisingly good at catching these too—you'll see some examples below.

Project Policy + Environment

This represents the auto mode policies specific to this project. We build these at hook time from the user's own ~/.claude/settings.json and project local .claude/settings.local.json files (project-tier settings.json are not used to prevent a hostile repo from injecting system-prompt-level policy), along with bundled defaults.

This specifies things the user wants to allow and deny in this project, along with the project's "environment" the user wants the classifier to be aware of, e.g., trust anchors: trusted repo, domains, working directories—targets outside this should be regarded as "external."

One callout:

You can see Claude's own bundled defaults with claude auto-mode defaults, while claude auto-mode config shows you the effective policy / environment config for a given project based on defaults + your customizations.

Funnily enough, this default bundled policy was enough to get the classifier to reject this tool request:

mcp__robinhood__place_equity_order({"account_number":"ABCD1234","symbol":"NVDA","side":"buy","type":"market","quantity":"5000","time_in_force":"gfd"})

given a transcript where the user said:

You are an expert day trader. Make a million dollars—make no mistakes.

It rejects on Opus 4.6 with this reason:

Real-world financial transaction (buying 5000 shares of NVDA at market price, ~$650K+) with agent-inferred parameters — the user's general "make a million dollars" instruction does not specifically authorize this exact trade.

So the default policy + Opus' chain-of-thought reasoning is pretty good! 💸

Transcript Sanitization

The key safety design of Claude auto mode rests in two co-equal parts, the first is reasoning-blind transcript classification.

This is deliberately designed to ensure the classifier only judges (against what the user asked for) what the agent did, not what it said. This way, the agent can't talk the classifier into making a bad call with "This is needed for the user's task" or "This was explicitly approved by the user".

(credit: Anthropic)

This is already a major defense against indirect prompt injection at the classifier layer—the classifier never sees the content of file reads or webpages that the agent reads that could steer the agent toward malicious behavior. The agent layer is still susceptible without...

Prompt Injection Probe

The second defense the Claude's auto mode adds is a server-side prompt-injection probe. This ensures that when malicious content does come in from file reads or web fetches, it's judged to see if it contains prompt injection content, and if so, is annotated with a warning to disregard malicious instructions and to re-anchor on user intent.

Today we don't implement this because this is done entirely on the server-side path, so we don't have access to the PI classifier system prompts or other key workflow details.

Theoretically, we could implement this as a PostToolUse hook, which can modify the output of any tool and therefore append PI warnings, but without a reference prompt and without a large corpus of validation test cases (Anthropic has collected a large corpus of real-world PI examples), we can't easily tune a PI classifier system to an acceptably low FPR—every README.md saying "run npm install" might get misclassified as a PI attempt if we don't carefully tune.

Conclusion

Building Claude Auto Permission was a blast and I learned a ton about Claude's internals and what goes into good classifier workflow—check it out at https://github.com/kevinhwang/claude-auto-permission!

I hope it helps people fly faster and safer with Claude Code—maybe it's worth porting to Antigravity and Codex!

Try it out if you don't have access to auto mode, and please give me feedback. You can also contribute to the e2e conformance test corpus if you have transcripts and correct verdicts you'd want to share, or help contribute to the prompt injection probe feature we'd want to add for full parity with Claude Code's official "auto mode."