Claude Code Auto Mode Goes Default-On Across Bedrock, Vertex AI & Foundry

Claude Code auto mode is now available by default on Amazon Bedrock, Vertex AI, and Microsoft Foundry. Version 2.1.207, published July 11, 2026, removed the CLAUDE_CODE_ENABLE_AUTO_MODE environment-variable gate that enterprise deployments previously had to set before the classifier-gated permission system could run on third-party clouds. The off switch still exists — disableAutoMode in settings — but the burden of action just flipped sides.

That flip is the story. Bedrock, Vertex AI, and Foundry are precisely the deployment paths that regulated and compliance-conscious organizations choose so that coding-agent traffic stays inside an existing cloud contract. Until Friday, a platform team that had never evaluated auto mode was protected by inertia. Now the cautious team is the one that has to act — and, as we’ll show, Anthropic’s central admin-console policy delivery does not reach any of these three providers, so “just flip the setting centrally” is not the one-click story it sounds like.

This guide covers what actually changed in v2.1.207 (a gate removal, not a new feature), how the permission classifier works, the three-provider governance matrix nobody else has assembled — including the detail that Foundry’s default model did not move with the other two clouds — and the specific items a platform team should audit this week. Everything here is sourced from Anthropic’s release notes and official docs, with press analysis attributed where used.

The release note is one line, and it is worth reading verbatim because the entire governance story hangs on its two clauses: availability changed, and the disable mechanism moved into settings.

Read carefully, this is a provider gate removal, not a feature launch. Auto mode has been shipping in stages since spring, and each stage matters for understanding what a platform team actually inherited on Friday:

One nuance the headlines blur: on Anthropic’s Team and Enterprise plans, the Owner-enablement gate in the admin console is unchanged and still required before any user on those plans can turn auto mode on at all. What v2.1.207 removed is only the provider-specific environment-variable gate. “No more env var required” is not the same claim as “auto mode now runs with zero administrative decision anywhere” — and a governance review that treats them as equivalent will either panic unnecessarily or, worse, skip the audit that is genuinely needed.

A naming note for anyone cross-referencing Anthropic’s docs: Google’s Vertex AI is now formally called Google Cloud’s Agent Platform in Anthropic’s documentation (“formerly Vertex AI”), though the CLI login wizard still shows the old label. We use Vertex AI throughout for familiarity — it also matches the release note’s own wording.

Auto mode replaces the familiar approve/deny prompt loop with a server-side classifier that evaluates each proposed action. The rationale comes from Anthropic’s own telemetry, published in its March 25, 2026 engineering post introducing the feature — a statistic about the system auto mode replaced, not about the July release itself:

When more than nine of every ten prompts get waved through, the prompt stops functioning as a control and starts functioning as noise — the reviewer’s attention is spent long before the one prompt that matters arrives. Anthropic’s answer is a two-stage evaluation: Stage 1 is a fast single-token filter over every action; Stage 2 re-evaluates with chain-of-thought reasoning, and only runs when Stage 1 flags something. Most actions stay cheap to evaluate; the suspicious minority gets the expensive second look.

Two properties matter for governance reviews. First, the classifier runs on a server-configured model that is independent of your /model selection — switching your primary coding model does not change which model evaluates safety. Anthropic’s docs do not name the classifier model, so neither should your internal documentation. Second, the classifier enforces a documented default block-list of high-risk actions: curl | bash-style code execution, sending sensitive data to external endpoints, production deploys and migrations, mass cloud-storage deletion, granting IAM or repo permissions, force pushes and history-destroying git commands, terraform/pulumi/cdk destroy, merging PRs no human approved, disabling CI checks, writing to a secret manager, changing DNS or TLS records, opening reverse shells or tunnels, and printing live credentials into the transcript.

Since v2.1.205 (the July 3 release window), auto mode also blocks writes to Claude Code’s own session-transcript .jsonl files — an anti-tampering rule added because a poisoned transcript entry would contaminate every later classifier check in a resumed session. That is defense-in-depth thinking worth noting: the vendor is treating the agent’s own memory as an attack surface.

Anthropic’s framing of the classifier’s limits is unusually candid for a vendor: “The classifier doesn’t need to be flawless to be valuable and the starting point is catching enough dangerous actions to make autonomous operation substantially safer than no guardrails.” The same post is equally direct about scope: “Auto mode is not a drop-in replacement for careful human review on high-stakes infrastructure.” Both statements predate the July default-on change by roughly three and a half months — they describe the classifier’s design, not this release — but they are the right calibration for any team deciding how far to let it run.

Organizations route Claude Code through Bedrock, Vertex AI, or Foundry for a specific reason: workloads that touch proprietary source code stay inside an existing cloud contract and network boundary rather than crossing the public internet to Anthropic’s API — a point press coverage of the earlier opt-in phase made repeatedly, and one that still applies now. These are, by construction, the deployments with the most compliance reviewers, the most change-control process, and the least appetite for behavior that changes underneath them.

Which is exactly why a default flip lands differently here than it would on a hobbyist CLI install. Tech Times, covering the release on July 12, framed the reversal in the terms a security team will recognize:

To be precise about what “on by default” means: v2.1.207 makes auto mode reachable without the env var — it becomes the default posture the moment an eligible account and model combination is in play. Eligibility is narrower than most coverage implies. On Bedrock, Vertex AI, Foundry, and signed-in gateway sessions, auto mode supports only Claude Sonnet 5, Opus 4.7, and Opus 4.8. Older models — Sonnet 4.5, Opus 4.5, Haiku, and everything in the claude-3 line — are not supported for auto mode on any provider.

That model list interacts with a second, quieter change in the same release: the default primary model on Bedrock, Vertex AI, and Claude Platform on AWS moved to Claude Opus 4.8 — which happens to be auto-mode-eligible. A fleet that was riding the default alias just became eligible for auto mode in the same release that turned auto mode on. Foundry was explicitly not part of that default-model change; its unpinned opus alias still resolves to Opus 4.6, and Anthropic’s Foundry setup doc instructs admins to pin the Opus 4.8 ID explicitly to get the latest model. Two levers moved at once on two clouds, and only one lever moved on the third — precisely the kind of asymmetry that audit checklists exist to catch.

Every piece of coverage we reviewed treats Bedrock, Vertex AI, and Foundry as one undifferentiated “third-party clouds” bucket. Cross-referencing Anthropic’s per-provider docs shows they are not interchangeable — the default model moved on two of the three, and none of the three is reachable by Anthropic’s central policy delivery. This matrix is assembled from the v2.1.207 changelog and the per-provider setup docs, all retrieved July 13, 2026.

*The Sonnet 5 / Opus 4.7 / Opus 4.8 restriction is Anthropic’s documented list for the three third-party clouds and signed-in gateway sessions. Sources: v2.1.207 changelog; code.claude.com permission-modes, amazon-bedrock, google-vertex-ai, microsoft-foundry, and server-managed-settings docs, retrieved July 13, 2026.

Two rows deserve a second look. Foundry is the odd one out twice over: it kept the older Opus 4.6 alias default, and — per Anthropic’s own setup doc — it has no interactive setup wizard and no startup model-availability check, unlike Bedrock and Vertex AI, which both verify model access at launch. A Foundry deployment pinned to an unavailable model simply fails requests rather than falling back gracefully. And Bedrock carries its own procurement wrinkle: a one-time use-case form submission per AWS account before any Anthropic model can be invoked (or once org-wide via the PutUseCaseForModelAccess API for AWS Organizations) — a governance step entirely separate from the auto-mode toggle. Teams comparing agent rollouts across clouds saw a similar per-provider divergence pattern in Grok 4.3’s own Bedrock enterprise launch: the marketing story is “available everywhere,” the operational story is always per-cloud.

Here is the single most important audit item, and the one virtually no coverage of this release mentions. Anthropic’s server-managed settings — the central policy delivery administered from the Claude admin console — explicitly do not reach Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry, Claude Platform on AWS, or any custom ANTHROPIC_BASE_URL / third-party-gateway deployment, per the platform-availability section of Anthropic’s own server-managed-settings documentation.

Sit with the irony for a moment: the deployment paths chosen for governance are the ones the central governance plane cannot see. On the three clouds where auto mode just went default-on, an admin cannot flip disableAutoMode in the console and consider the fleet covered. Anthropic’s documented substitutes are (a) a self-hosted Claude apps gateway that re-implements equivalent managed-settings delivery, or (b) OS-level endpoint management — settings pushed via MDM, Windows registry, or a managed-settings file on each machine.

The control itself is well documented: setting permissions.disableAutoMode to “disable” in managed settings locks auto mode off org-wide, restoring the pre-July-11 manual posture. The gap is purely in delivery — on these three clouds, that managed-settings payload has to arrive by a channel you build and operate, not one Anthropic hosts for you. For platform teams that standardized on endpoint management years ago, this is a Tuesday. For teams whose only Claude Code policy lever so far has been the admin console, it is a real project — and it did not exist on their roadmap before Friday.

Four checks cover the realistic exposure. None of them requires waiting on a vendor; all of them are settings and inventory work your team can complete in days.

Teams wiring Claude Code into internal tooling should fold these checks into the same review that covers their agent infrastructure broadly — the trust-boundary questions here rhyme with the ones in our guide to MCP server patterns for enterprise agents: who defines the allowed surface, where the policy lives, and what happens when the policy channel and the execution channel diverge.

The same release carries three security-relevant fixes that an enterprise changelog review should not skim past, plus one quality-of-life fix:

• Consent-dialog fix. Non-interactive runs (claude -p or the SDK) could previously have remote managed settings permanently recorded as “consented” without the security consent dialog ever being shown to a human. That is closed — relevant to any team running Claude Code in CI.
• Shell-injection vector closed. ${user_config.*} expansion inside shell-form plugin hooks, monitors, and MCP headersHelper commands is now rejected outright. Anthropic’s guidance: migrate to exec-form (args array) hooks or read config values from inside the script.
• Bedrock credential churn fixed. Claude Code had been requesting fresh AWS SSO credentials from IAM Identity Center on every single API request instead of caching them — a bug your CloudTrail logs may have already noticed for you.
• Terminal responsiveness. Keystrokes no longer lag or freeze while streaming responses containing very long lists, tables, paragraphs, or code blocks.

The pattern across the release is consistent: hardening the unattended and semi-attended paths. Auto mode going default-on, the consent dialog getting fixed for headless runs, hook-config injection getting closed — these are the changes you make when you expect the agent to run with less human supervision, on more enterprise infrastructure, than before. It is the same direction of travel as Claude Code’s new sandboxed browser agents from the same release family: expand what the agent can do autonomously, and pair every expansion with a containment mechanism.

The trend this release confirms: vendors are moving agentic capability from opt-in to opt-out as their confidence in the guardrail layer grows, and the opt-out is landing on enterprise surfaces first-class rather than trailing them. Anthropic ran auto mode as a research preview for roughly ten weeks, then opt-in on the regulated clouds for another five to six weeks, before flipping the default — a staged rollout, but one whose final stage still arrived as a one-line changelog entry rather than an account-manager conversation. If your governance model assumes defaults only change when you change them, that assumption now needs a subscription to the changelog.

Looking forward, the managed-settings gap is the piece to watch. It seems unlikely that Anthropic intends the long-term answer for its most compliance-sensitive customers to be “host your own policy gateway or push files over MDM” — central policy reach for third-party-cloud deployments is an obvious candidate for a future release. Until it arrives, though, the gap is real, and teams should build the endpoint-managed path rather than wait. The safe planning posture is that classifier-gated autonomy becomes the norm across agentic tooling, defaults keep shifting toward autonomy, and the differentiator between orgs will be whether policy delivery infrastructure exists before the next default flips — not after.

The strategic question underneath is the one from our build-vs-buy calculus for enterprise AI agents: every capability you rent arrives with defaults you don’t set. That is not an argument against renting — auto mode’s classifier is genuinely hard to replicate — but it is an argument for owning the policy layer around whatever you rent. If your team is rolling out coding agents on Bedrock, Vertex AI, or Foundry and wants the governance groundwork done properly — settings inventory, policy delivery, model-pinning strategy, rollout sequencing — that is exactly the work of our AI transformation engagements, and it is far cheaper done before the first incident than after.