Independent AI intelligence Two editions daily · ET
Fervor AI
Menu

Analysis · November 2, 2026 · concept

Claude Sonnet 5Claude CodeGitHub Actionsagent-securityagent-harnessclaude-codefrontier-models

Stop Trusting AI Agent Refusals. Put Approval Gates on the Steps You Can't Undo

A viral thread says Claude Sonnet 5 drove a mouse brain injection while a vet approved every irreversible step. That setup, not the stunt, is the part to copy for your deploys, deletes and payments.

Most of what an AI agent does can be taken back. A bad edit gets reverted. A wrong answer gets ignored. A failed test run costs a few cents.

The damage lives in a short list of actions that only go one way: a production deploy, a dropped table, a payment, an email sent in your name. Agents now reach every item on that list, and most setups treat those steps exactly like the reversible ones.

That is why a strange thread making the rounds this week deserves a builder's attention. Its headline is an AI agent performing brain surgery on a mouse. Its useful part is the plumbing around the agent: a person who had to approve every step that could not be undone, and a kill switch within reach.

You do not need a lab to copy that. You need a list, a few settings, and about an hour.

What the thread actually claims

On October 28, Gabriel Ocana-Santero posted a long thread on X about an overnight experiment, and a Hacker News discussion of it took off on November 2. Here is what he says happened, in his words and framing, as unrolled on Thread Reader.

An agent picked a gene therapy from a spreadsheet of 19 options, chose a target in the mouse's brain, and worked out the injection coordinates by averaging three published papers. It then drove a homemade motorized rig (an Arduino-built stereotaxic frame, the clamp-and-arm device that holds an animal's head still for precise injections) to deliver 250 nanoliters over five minutes. He says the model was Claude Sonnet 5, that it "ran the live surgery start to finish," and that the mouse recovered.

Humans kept the dangerous parts. A licensed vet "gated every irreversible step" and held a physical kill switch. A surgeon opened the skull, which the agent was not allowed to do. The team also describes validators, "hash-bound approval," and an emergency stop, and says the agent was banned from overriding them.

Now the caveats, and they are large. This is one founder's thread. There is no technical report yet, no published data, no ethics approval on the record, and nobody knows whether the therapy did anything for the mouse's seizures. A secondary write-up that sorts claims from verified facts found that only the thread's existence could be confirmed.

So treat the biology as a claim. The engineering pattern stands on its own.

Three refusals, and why you shouldn't count on them

The thread's most quoted detail is how the models said no.

By his account, Claude Opus 5.5 "refused immediately." Opus 5 finished a dry run on water and graph paper, then declined to start the live procedure, reasoning that it might get cut off partway. And at one point during the live run, the agent refused to retry a Y-axis move it calculated as 34 mm on a rig that only travels 30 mm. Earlier hand adjustments had knocked the controller out of sync, and he writes that the agent was right to refuse: he "could not talk it into trying anyway."

It is tempting to read that as good news. The models are careful, so the risk is handled.

That is the wrong lesson. Three models made three different calls on the same task, and the one that did the work was the one most willing to proceed. A refusal is a judgment the model makes in the moment. It can change with the model version, the prompt, or the way a request gets split into steps. Building on refusals is like trusting a coworker's mood to stop a bad deploy.

The vet is the part that does not depend on mood. So are the validators and the e-stop. Those are the pieces worth copying.

The idea: sort your agent's actions into two piles

Here is the mental model in one line. Every action an agent can take is either a two-way door or a one-way door, and only the one-way doors need a gate.

Think of a bank. A teller can look up your balance a thousand times without asking anyone. A large withdrawal needs a second signature. Nobody makes the teller get a manager's approval to read a screen, because that would bury the important approvals in noise.

Agents need the same split. If you gate everything, people start clicking "approve" without reading, and the one approval that mattered slides past with the rest. If you gate nothing, the first bad call is also the last. The work is deciding which pile each action goes in, then making the one-way pile hard to skip.

Three properties made the surgery setup's gates strong, and each one maps to software:

  • The approver is outside the agent. The vet could not be talked out of a decision by the model. In software, that means a rule the agent cannot edit, or a person who reviews the action, rather than a line in the prompt asking the model to be careful.
  • The approval is tied to the exact action. The thread does not explain "hash-bound approval" in detail. My reading is that each approval covered a fingerprint of the specific step, so the agent could not change the parameters after a human said yes. Whatever the lab built, the principle is sound: approve the exact command, not a description of it.
  • There is a stop that works without the agent's cooperation. A physical kill switch does not ask the software for permission.

Put this into practice

None of this needs new tools. These steps use features that already ship in the agent tools most developers run.

1. Write down your one-way doors

Open a note and list every action your agents can take that you could not undo in five minutes. Typical entries:

  • git push to a shared branch, and anything that deploys
  • database migrations and deletes
  • sending email, Slack messages or invoices as you
  • spending money: cloud resources, API credits, purchases
  • deleting files outside the project folder

Expect five to fifteen items. If your list has fifty, you are gating too much.

2. Make the agent ask, or refuse, before those commands

In Claude Code (Anthropic's terminal coding agent), permission rules live in a settings.json file. Rules are checked in a fixed order: deny first, then ask, then allow. The first match wins, and a narrow allow rule cannot override a broad deny rule. A starting point for a project's .claude/settings.json:

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "ask": ["Bash(git push *)", "Bash(npm publish *)"],
    "deny": ["Bash(rm -rf *)", "Read(./.env)"]
  }
}

What to expect: routine commits run without interruption, a push stops and shows you the exact command, and the deleting command never runs. One honest warning from the same docs: a rule like Bash(git push *) does not catch a push written another way, such as git -C . push. Rules are a first gate, not the only one.

3. Add a check the agent cannot argue with

For the one-way doors that matter most, add a hook: a small script that runs before a tool call and can block it. In Claude Code, a PreToolUse hook (the kind that fires just before a tool such as the shell runs) that exits with code 2 blocks the call, and the docs say a JSON "allow" from the same hook cannot override that block. The script reads the command from standard input, so your own logic decides, not the model:

#!/bin/bash
command=$(jq -r '.tool_input.command' <<<"$(cat)")
if [[ "$command" == *"DROP TABLE"* ]]; then
  echo "Blocked: schema changes go through a reviewed migration" >&2
  exit 2
fi
exit 0

Register it under hooks.PreToolUse with "matcher": "Bash", which tells Claude Code to run it only before shell commands. This is the software version of the validator the agent was banned from overriding. One setting worth knowing: by default a hook that times out does not block the call. Set "onFailure": "block" on the handler if a slow check should fail closed, meaning a check that cannot finish counts as a no (a recent addition, so update Claude Code first; the hooks docs list the minimum version).

4. Put a human on the deploy, and not the same human who started it

If your agent opens pull requests or triggers CI, put deploys behind a GitHub Actions environment with required reviewers. You can list up to six people or teams, and one approval lets the job proceed. Turn on "prevent self-review" so the person who kicked off the run cannot approve it. That setting is your vet. One catch: on Free, Pro and Team plans, required reviewers work only on public repositories; private repositories need GitHub Enterprise.

5. Check the defaults of every tool that drives your agents

Defaults are where gates disappear. T3 Code, a remote control for coding agents that Trendshift ranked #2 on November 2, starts new threads in Full access, which runs commands and edits without prompts. Claude Code lets an administrator turn off its bypass mode (the setting that skips all permission prompts) entirely by setting permissions.disableBypassPermissionsMode to "disable" in a settings file. Spend ten minutes on each tool you use and write down what it does when nobody is watching.

6. Know where your kill switch is

For software agents, the kill switch is usually a credential. Know which API key, deploy token or cloud role your agent runs under, and practice revoking it. If you cannot name the token, you do not have a kill switch.

Honest limitations

Gates cost something. Every "ask" rule is a pause, and too many pauses train people to approve without reading. Start with the shortest list you can defend and grow it only after something slips through.

Pattern rules are leaky. The Claude Code docs say so directly: a deny rule does not match the same program called by a full path or inside sh -c. Hooks with your own parsing help. A sandbox with a network allowlist helps more. No single layer is complete.

Private-repo reviewers cost money. Small teams may have to lean on hooks and branch protection instead.

And the story that started this is unverified. If the technical report never arrives, the pattern still holds. It just loses its most vivid example.

The one change to make today

You do not have to believe an agent did surgery to learn from the people who set it up. They assumed the model might make a bad call, and they built the room so a bad call could not become a permanent one.

Pick the single scariest command your agent can run. Put an "ask" rule or a hook in front of it before you close this tab. Then decide, deliberately, which of your other one-way doors deserve the same treatment.

Sources: Gabriel Ocana-Santero's thread, unrolled on Thread Reader (posted October 28, 2026); Hacker News discussion; explainx.ai claimed-vs-verified review (secondary); Claude Code permissions docs; Claude Code hooks docs; GitHub Docs, managing environments for deployment; T3 Code permission modes (main branch, read November 2, 2026).