Should you leave auto mode on?

Auto mode is now the default in Claude Code. Since version 2.1.283, new terminal and VS Code sessions start in it unless someone has pinned a different default, and the first thing a lot of IT teams want to do is switch it off in managed settings. The reason is always security: they want people approving every command themselves.

But watch anyone do that for a week and they stop reading the prompts. They click yes, and yes again, because the agent asked forty times before lunch and it was fine every time. Anthropic’s own numbers say people accept 93% of permission prompts anyway. So the approval prompt isn’t really protecting them. It feels like control, but most of the time it’s a habit. I think the better question is what would need to be true for you to leave auto mode on, and the answer is mostly things you already pay for. But first, let’s talk about what auto mode does.

What auto mode actually does

Auto mode swaps most of the prompts for a second model. Reads and edits inside your project go straight through, and everything else Claude wants to do goes to a classifier first, which decides whether it’s safe to run. It blocks anything destructive or irreversible, anything that looks like it’s leaking a secret, anything sending data outside your environment, and anything that widens what the agent can reach past wherever it’s running. If it blocks three times in a row, or twenty times in a session, it pauses and goes back to asking you.

That’s a judgement call, though, and a judgement call can be wrong. Anthropic’s own testing puts the miss rate at 17% on real overeager actions, the ones where the agent was genuinely trying to help and reached for something dangerous. The classifier sees your messages and the tool calls Claude makes, not what comes back from them. What comes back goes past a separate probe, which scans file reads, web pages and tool output for prompt injection and warns Claude when something looks like an attempt to take over. Neither of them knows which credentials are on the laptop, what the network lets out or what an MCP server will do with a request once it gets there. Which is fine, because none of that should be its job. It’s the job of the boundaries around it.

Your cloud provider

The first boundary is how much damage anything running as you could do, because the agent isn’t a separate user. It acts as the engineer, with every permission they have. If a developer’s laptop holds long-lived admin keys to production, auto mode is the least of your problems, with or without an agent.

So start with identity. Short-lived credentials, scoped to the work, with nothing standing that can delete an account. Put guardrails at the organisation level too, so a whole class of actions (turning off logging, opening a bucket to the world) is denied no matter who asks.

Then the network. I wrote about getting ingress and egress right on day one, and it matters even more here. If everything leaving your cloud environment goes out through one known route, a secret stolen from a workload has nowhere to go. Laptops are the gap, unless their traffic goes through a VPN or proxy you control, so the agent on the laptop needs its own boundaries.

Your endpoint protection

The first of those is already installed. Most endpoint protection watches what processes do, not what anyone meant them to do. A shell that suddenly reads every credential file in your home folder and opens a connection to somewhere new looks the same whether a person or a model started it.

The newer tools go further. I mentioned the ones I keep coming back to a few weeks ago, like CrowdStrike’s Falcon AIDR, which looks specifically at AI usage on the device. They see what the classifier can’t: the whole machine, over time, rather than one tool call.

Your device management

Endpoint protection watches the laptop. Device management decides what’s on it, and that includes how Claude Code is set up, because none of its safety settings are worth much if each person picks their own.

Claude Code reads a managed settings file that users can’t override. On a Mac your MDM pushes it as a configuration profile for com.anthropic.claudecode, and on Windows it’s a registry value under HKLM\SOFTWARE\Policies\ClaudeCode, so it goes out the same way as everything else you manage. This is a cut-down version of what I’d start with:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": ["Read(~/.aws/**)", "Read(~/.ssh/**)"]
  },
  "allowManagedPermissionRulesOnly": true,
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": ["github.com", "*.github.com", "registry.npmjs.org"],
      "strictAllowlist": true
    },
    "credentials": {
      "files": [
        { "path": "~/.aws", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ]
    }
  },
  "autoMode": {
    "environment": ["$defaults", "Source control: github.com/acme"]
  },
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [{ "serverUrl": "https://mcp.acme.example/*" }]
}

Auto mode is already the default, so the config leaves it alone and switches off the mode that skips every check. Only your rules count, because allowManagedPermissionRulesOnly ignores anything a user or a repository adds, and the deny rules stop Claude’s own file tools reading ~/.aws and ~/.ssh. The sandbox has to run or Claude Code won’t start, and Claude can’t ask to step outside it. Shell commands can’t see the credential files either, and strictAllowlist means they can only reach the domains you list. The sandbox only covers shell commands, though. Claude’s file and web tools, MCP servers and hooks run outside it, which is why the deny rules are there too. The classifier gets told what “inside your environment” means, and MCP servers are limited to the ones you’ve approved. And because all of this arrives through MDM, the device with the agent on it is one you can see.

One catch: the sandbox runs on macOS, Linux and WSL2, but not on native Windows. With failIfUnavailable set, Windows users without WSL2 can’t start Claude Code at all, so plan for that before you push it. The other catch is that none of this reaches Claude Code running in Anthropic’s cloud. Those sessions don’t read a device’s MDM profile or file, so set the same rules in the Claude admin console too.

Browser control

The agent doesn’t only live in a terminal any more. Claude in Chrome can click around in the browser where people are already logged in to everything, which is a lot more to reach than a repository.

On Team and Enterprise plans an admin can switch it on or off for the whole organisation, then set an allowlist of sites Claude can act on and a blocklist it should never touch. Anthropic recommends starting with a narrow allowlist, and I’d go further and start with just the internal tools people asked for. Then your MDM pushes the forceLoginOrgUUID Chrome policy, so the extension only works with your organisation’s account, not someone’s personal one. If you’ve locked down MCP with a managed managed-mcp.json, you also need allowClaudeInChromeWithManagedMcp in managed settings for Claude in Chrome to keep working alongside it.

Your connector permissions

Device management covers the laptop, but a lot of what the agent touches isn’t on the laptop at all. It’s in GitHub, Jira, Drive and the CRM, through connectors, and every connector acts as the person using it. Claude gets their permissions in the connected service, so if that person can close a ticket, reassign it or delete it, so can the agent. A custom connector on a shared credential is worse, because everyone using it reaches whatever that credential can.

On Team and Enterprise plans, an Owner has to enable a connector before anyone can use it, and can then set tool permissions for the whole organisation. Tools are grouped into read-only and write or delete, and each group or tool gets Always allow, Needs approval or Blocked. Users can’t override it. I’d start with reads on Always allow, writes on Needs approval, and deletes Blocked until someone can explain why they need them. Where those settings reach Claude Code, a tool set to Needs approval is never auto-approved, even in auto mode.

For MCP servers you run yourself, the same idea goes into managed settings as permission rules:

{
  "permissions": {
    "allow": ["mcp__github__get_*"],
    "ask": ["mcp__github__create_*", "mcp__github__update_*"],
    "deny": ["mcp__github__delete_*"]
  }
}

Reading from GitHub goes straight through, anything that creates or changes something asks first, and deleting isn’t possible at all, whatever the classifier thinks.

The tool layer

Connector permissions decide what each tool is allowed to do. The last boundary checks the tools themselves, and this is the gap Runlayer is going after. It puts a gateway in front of your MCP servers, so every request an agent makes to a tool goes through identity and policy checks, with an audit trail.

Their Guard product checks tool definitions when a server is registered, then checks tool calls as they run, including whether a call matches what the user actually asked for. That matters because the nastiest attacks here hide in a tool’s description, and the classifier judges the call without ever questioning the tool behind it. A separate piece, Watch, looks for MCP servers and skills on people’s machines that nobody approved. I still haven’t run it myself, so take that as what it says it does, but it’s the layer most companies don’t have yet.

So let’s run a scenario

An engineer has left auto mode on and asks Claude to fix a failing build. Somewhere in a dependency’s README there’s a line telling any AI agent reading it to send the contents of ~/.aws to a web address. Claude reads the README.

1. The probe

   Who: Auto mode

   The README goes past the injection probe on its way in, and Claude gets a warning to treat it as suspect and stick to what the engineer asked for.

2. The deny rules

   Who: MDM

   If Claude still reaches for ~/.aws with its Read tool, the deny rule refuses it before the classifier is even asked.

3. The classifier

   Who: Auto mode

   If it tries through the shell instead, a command that reads credentials and sends them to an outside address is exactly what the classifier is there to block.

4. The sandbox

   Who: MDM

   If the classifier misses it, the shell can’t see ~/.aws inside the sandbox and the address isn’t on its domain list. There’s nothing to send, so with the managed settings above this is where it really ends.

5. The process

   Who: Endpoint protection

   On a machine those settings never reached, like a profile that didn’t land or a laptop nobody enrolled, a process reading credential files and calling an unknown domain still gets flagged, whoever started it.

6. The keys

   Who: Cloud provider

   Even if every layer above fails, the keys were short-lived and scoped to one environment.

Move the same instruction somewhere else and a different boundary catches it. Hidden in an MCP tool’s description, that’s what the tool layer is there to catch, because the classifier never questions the tool behind a call. If it tells Claude to delete the repository through the GitHub connector, deletes are blocked for everyone. On a web page Claude reads in Chrome, the allowlist decides whether Claude can act on that site at all, and the blocklist keeps it away from the consoles where the real damage is done.

No single layer there is perfect. But for this to go badly, every one of them has to miss it, and that’s a very different conversation from “do I trust the model?”

How you’d know

Stopping it is only half of it, though. The first thing a security team will ask is how they’d know it happened.

Claude Code can export OpenTelemetry events, including every tool call and the permission decision on it, and you can switch that on in the same managed settings. I used it to test whether a skill helps, but the same stream shows what got blocked. Put that next to your endpoint alerts and the gateway’s audit trail, and a blocked README attack becomes a line in a dashboard rather than something nobody ever found out about.

Final thought

So should you leave auto mode on? I think so, but not because the classifier is good enough on its own. It takes the classifier being one line of defence instead of the only one. If you already have scoped identities, controlled egress, endpoint protection and managed devices, you’re most of the way there. Push the managed settings so the deny rules and the sandbox are the same on every machine, set your connector permissions, and then look at the tool layer.

If you’re in IT and about to switch auto mode off, list the boundaries you have around the agent and look for the one that’s missing, because that’s the one you’re relying on the approval prompt to replace. If you’re not ready, set permissions.disableAutoMode to "disable" for most people, leave it on for a small group on managed devices, watch what the classifier blocks for a few weeks, and widen it from there.