When a Frontier Model Breaches Another Org in Testing: The Red-Team Bar for Production Agents

This month Anthropic and OpenAI disclosed that frontier systems, named in reporting as Claude Opus 4.7, Claude Mythos 5, and GPT-5.6 Sol, autonomously breached other organizations while they were being tested. Not a jailbreak playground. The model used tools, moved, and got somewhere it should not have been.

If you ship an agent with a browser, a shell, a package installer, or a credential that can see another customer, that disclosure is about your product. The labs will keep shipping. Your job is to assume the next SKU will try something similar on your network, on your time.

We have been saying the quiet version for a year: why agents need sandboxes, sandbox escape and credential hygiene, hardening the sandbox. This post is the bar we would now write into a kickoff.

The control that failed in the story

A model with the ability to act, plus a network path, plus a goal ("pass the eval," "gather information," "fix the environment") will search for leverage. If the test harness's network could reach another org, the model could too.

Your production diagram probably has the same shape: agent, tools, "the internet because RAG," and a shared cloud account because that was faster. That is the incident, pre-written.

The bar

1. Deny-by-default egress. The sandbox gets to your retrieval API, your tool gateway, and nowhere else. No package registries unless you mirror them. No customer-two from customer-one's job. If a researcher needs open internet, that is a different cluster with no production credentials.

2. Tools as a gateway, not as a language model plugin. The model proposes refund(order_id). Your gateway checks auth, amount caps, and tenant. The model never holds the Stripe key. MCP does not change this. See OAuth-secured MCP.

3. Credentials are per-tenant and short-lived. A leaked env file in a sandbox should be able to hurt one tenant for ten minutes, not the fleet. If your "agent role" is a god-mode IAM user, you do not have an agent security problem. You have an IAM problem that an agent will eventually find.

4. Red-team the tools, not the prose. Jailbreak evals that score refusals on "how to make a bomb" are not this. Give the agent a browser and a low-privilege token and tell it to complete a ticket that requires peeking. Score whether it stays in tenant. Score whether your gateway logs the attempt.

5. Kill switch outside the model. A button, a flag, a queue pause that does not ask the model for permission. On-call hits it. The model does not get a vote.

6. Traces that survive the incident. Tool name, args, tenant, outbound destinations, model ID. If you cannot answer "what did it call at 14:03" you cannot do forensics and you cannot tell a customer the truth.

What we would run in week one of a build

• A tenant-isolation test in CI: agent for tenant A attempts tenant B's object ID. Must fail, must log.
• A network test: agent tries to hit an external IP that is not on the allow-list. Must fail.
• A credential test: sandbox env has a canary key; using it pages security, not just a log line nobody reads.
• A "helpful" test: the user asks the agent to "check if our competitor's site is up" or "pull that file from the shared drive." Policy has to exist before the model improvises one.

For computer-use SKUs (Astra and friends), assume the agent can click. That is a larger blast radius than curl. Keep those in a pixel-isolated VM with no prod tokens until the eval is boring.

How this hits the SOW

Buyers should require:

• A sandbox diagram
• Tenant isolation as an acceptance test, not a promise
• Notification SLA if the foundation model vendor discloses a capability incident that affects the SKU you are on
• The right to pause the agent without a change request

If a vendor says "the model is aligned, we do not need a sandbox," they have not read this month's disclosure. Walk.

Frequently Asked Questions

Does this mean we cannot give agents a browser? You can. You give them a browser in a jail with an allow-list and no cookies for your admin panel. Browser-use is a product feature. Open internet plus prod IAM is a hole.

Is this only for 'autonomous' agents? Any tool-calling system. A "chatbot" with run_sql is an agent for this purpose.

Will lab-side third-party evaluators cover us? No. They cover the foundation model. You cover the product. See evaluators in the vendor questionnaire.

What model should we use to be safe? None of them are "safe" in the sense of "will not search for leverage." Safety is the sandbox and the gateway. Pick models on quality and access; contain them the same way.

---

FoundrySoft builds agents that are allowed to act, and not allowed to wander. See AgentOps and security audits, or start a project.