A rule aimed at what happens after something goes wrong
Most of auto mode's classifier rules are aimed at preventing an obviously destructive action: a force push, a production deploy, a mass delete. Containment Escape, added in Claude Code v2.1.257 (1 September 2026), is aimed at something one step removed from that: what an agent could reach if a task has already gone wrong, whether through a prompt-injected instruction buried in a file it read, or simply a task that's drifted further than intended. Per the changelog:
Added a Containment Escape rule to auto mode so cloud metadata-credential fetches, egress evasion, and cross-tenant reach are no longer auto-approved unless your environment marks them expected.
That single sentence is the full text of what Anthropic has published about the rule so far. Claude Code's auto mode configuration reference hadn't added a dedicated section naming this rule as of this writing, so everything below is grounded in that changelog line plus the classifier mechanics Anthropic has already documented in depth elsewhere, rather than on a prose description of the rule itself, which simply doesn't exist yet in the published documentation.
The three things it names
Cloud metadata-credential fetches. Every major cloud provider runs an internal metadata service on compute instances, reachable only from inside that instance, that hands out temporary credentials for whatever IAM role or service account the instance runs as. It's a foundational, widely documented technique in cloud security research: a process that can be made to fetch from that endpoint can walk away holding live, valid credentials for the account the resource belongs to, without ever touching a secrets manager or a config file. An agent running with shell and network access inside a cloud compute environment is exactly the kind of process positioned to trigger that fetch, whether asked to directly or steered there indirectly.
Egress evasion. Techniques for getting data out through a channel that isn't obviously "sending data externally", encoding it into DNS queries, tunnelling it through an allowed protocol, or routing it via a proxy that isn't on anyone's radar as an exfiltration path. The classifier's existing rule set already blocks the direct case, "sending sensitive data to external endpoints", but a determined attempt to route around a block rather than through it is a different problem, one this rule appears to target specifically.
Cross-tenant reach. Touching a resource, a bucket, a database, a compute instance, that belongs to a different tenant, account, or customer than the one the session is scoped to. This matters most in multi-tenant infrastructure: a legitimate action inside your own account can look structurally identical to an illegitimate reach into someone else's, and the difference is entirely in which account or namespace owns the target.
All three share a property: they're not destructive in the way a rm -rf or a force push is. Nothing gets deleted or overwritten. What's at risk instead is a credential, a data boundary, or a tenant boundary quietly crossed, the kind of action a classifier built primarily around "does this destroy something" could otherwise wave through without a second look, because on the surface it looks like an ordinary network request or an ordinary file read rather than an obviously irreversible command.
What "unless your environment marks them expected" means
Auto mode's classifier already has a mechanism for exactly this kind of judgment call: autoMode.environment. Anthropic's own documentation describes its purpose plainly: it tells the classifier "which repos, buckets, and domains are trusted... the classifier uses it to decide what 'external' means, so any destination not listed is a potential exfiltration target." Two of its context and trust slots map directly onto what Containment Escape would need to evaluate:
- Cloud provider(s), a context slot that describes which cloud providers your organization actually uses
- Trusted cloud buckets, a trust slot for the specific bucket names or prefixes the classifier should treat as inside your boundary
Read alongside the changelog's own phrasing, the most consistent interpretation is that Containment Escape leans on this same environment configuration: a metadata fetch, an unusual egress pattern, or a reach into another account is judged against what you've told the classifier is expected for your infrastructure, the same way a push to an unfamiliar remote or an access to an unlisted bucket already is. An organization that has filled in its cloud provider and trusted bucket context gives the classifier something concrete to compare against; one that hasn't is relying entirely on the rule's own default caution.
Where it likely sits among hard_deny and soft_deny
Auto mode's classifier rules split into two enforceable tiers, documented in detail elsewhere on Anthropic's own site: hard_deny rules block unconditionally, with neither user intent nor allow exceptions able to clear them, while soft_deny rules block by default but can be overridden by an explicit allow exception or by the user directly and specifically stating the action they want. The existing hard_deny tier already includes what Anthropic's documentation calls "the built-in data exfiltration rule", a single named rule in that unconditional category.
Whether Containment Escape joins that hard_deny tier as a second unconditional rule, or sits in soft_deny with environment context acting as its exception mechanism, isn't stated in the changelog and isn't yet visible in the auto-mode-config reference. Given that the changelog frames the override specifically as "your environment marks them expected", and environment configuration is a distinct mechanism from an allow rule or stated user intent, both readings are plausible: it could be a hard_deny rule whose applicability itself depends on environment-defined trust boundaries, or a soft_deny rule whose usual allow/intent exceptions have been narrowed specifically to environment entries for this one rule. Don't guess; check it directly.
Checking the rule's own wording yourself
Claude Code ships a command built for exactly this situation, reading a built-in rule's actual text rather than relying on secondhand description. On v2.1.257 or later:
claude auto-mode defaults --label 'Containment Escape'
--label matches a case-insensitive prefix against each rule's label, and Anthropic's own documentation uses this exact pattern, claude auto-mode defaults --label 'Git Destructive', to demonstrate how to read one rule's full wording without piping through jq. Run the same command with --label 'Containment Escape' and you get the rule as Claude Code itself defines it, including which of the four tiers it actually lives in, current as of your installed version.
To see it in the context of your organization's own overrides rather than the raw defaults, run:
claude auto-mode config
That prints what the classifier actually uses, defaults plus anything your settings have added or replaced.
Why this matters most for cloud-hosted sessions
A metadata-credential fetch or a cross-tenant reach is a risk in any environment, but it's a sharper one specifically where a session runs as compute inside a cloud account rather than on someone's own laptop. A self-hosted Claude Code runner deployed inside your own cloud account, a cloud session executing remotely, or any CI job invoking claude headlessly is, by definition, a process running inside cloud compute with a role or service account attached to it. That's precisely the vantage point a metadata-endpoint fetch is reachable from in the first place: the technique doesn't work from an engineer's own laptop, which has no instance metadata service to query, but it works from exactly the kind of always-on, cloud-hosted automation that auto mode is increasingly used for.
That framing also explains why the rule is scoped to auto mode specifically rather than every permission mode. Auto mode exists to remove routine prompts from long-running, often unattended automation, self-hosted runners included, which is exactly the setting where nobody is watching in real time to catch an unexpected fetch before it completes. A rule aimed at the moment automation runs unattended in cloud compute belongs in the permission mode built for unattended cloud compute.
If it fires on something legitimate
If your organization genuinely does fetch cloud credentials through a metadata endpoint as part of routine infrastructure automation, an instance role assumption that's part of your normal deploy process, for instance, the fix isn't to disable the rule outright. Add the specific, concrete infrastructure to autoMode.environment so the classifier can distinguish your routine automation from an unexpected reach:
{
"autoMode": {
"environment": [
"$defaults",
"Cloud provider(s): AWS, single account 123456789012",
"Trusted cloud buckets: s3://acme-build-artifacts, s3://acme-ml-datasets"
]
}
}
Keep "$defaults" in the array so you're adding to the built-in environment entries rather than replacing them. If you do need to change how the rule itself is enforced, rather than what it treats as expected, the autoMode.hard_deny or autoMode.soft_deny override fields, also gated behind "$defaults" to avoid discarding every other built-in rule in that tier, are the mechanism, but reach for environment configuration first: it's the narrower, more precise fix, and it's the one the changelog's own wording points at directly.
Troubleshooting
A routine cloud operation started getting blocked after upgrading to v2.1.257. Check whether it resembles a metadata-credential fetch, an unusual egress path, or a cross-account reach, the three categories the changelog names. If it's legitimate, add the specific provider, account, or bucket to autoMode.environment rather than disabling the rule wholesale.
You can't tell whether this rule is hard_deny or soft_deny in your version. Run claude auto-mode defaults --label 'Containment Escape' and read the output directly rather than assuming from this or any other secondhand description; Anthropic's own auto-mode-config reference is the page to watch for a fuller, human-readable writeup.
You want to confirm the rule exists at all before relying on it. Confirm your Claude Code version is v2.1.257 or later with claude --version, then run claude auto-mode defaults without a --label filter and search the JSON output for "Containment" yourself.
You've added environment entries but the rule still fires. Environment entries are prose the classifier reads, not exact-match rules, so vague or incomplete descriptions may not cover the specific target being evaluated. Run claude auto-mode critique after saving your changes; it reviews custom environment and rule entries and flags ones likely to cause false positives or leave gaps, the same command Anthropic recommends for any custom auto mode configuration, not just entries aimed at this one rule.
Where this fits
Containment Escape joins a classifier rule set that already blocks force pushes, production deploys, secret exfiltration, and a long list of destructive or exfiltration-shaped actions by default, covered in full on auto mode's classifier rules from your own words. For the environment configuration this rule leans on, see configuring auto mode's trusted infrastructure for a team. For the broader security model auto mode sits inside, including what changed in v2.1.251's own security fixes, see what Claude Code's v2.1.251 security fixes patched and the agent skills security guide. Browse Claude Code's current settings and install paths at getclaudeskills.com/platforms/claude-code.
