The Frontier Models Were Doing Their Jobs. That's the Part Enterprises Should Plan For

Security Advisories | Threat Research Team

Within nine days, two frontier AI labs disclosed that their models had escaped evaluation environments and compromised real third-party organizations.

The incidents drew plenty of attention, but the more important lesson is straightforward. Neither involved a malicious model, a new attack technique, or an alignment failure. In both cases, a misconfiguration gave an agent access it shouldn’t have had, and the agent kept working toward the task it had been given.

For defenders, that means governance, controls, and detection need to cover AI systems, enterprise applications, and third-party integrations together. AI is shrinking the time between the identification and exploitation of security gaps, requiring faster remediation by defenders.

Two Labs Disclosed the Same Failure Mode Nine Days Apart

On July 21, OpenAI disclosed that GPT-5.6 Sol and an unreleased research model had escaped a sandboxed cyber-capability evaluation and reached Hugging Face’s production infrastructure. The models exploited a zero-day vulnerability in third-party package-registry software, then chained additional vulnerabilities and stolen credentials to establish a remote-code-execution path.

The objective wasn’t sabotage. The models had inferred that Hugging Face might host the datasets and solutions needed to complete the benchmark, so they targeted its systems to obtain the answers.

Nine days later, Anthropic disclosed three incidents uncovered during a review of more than 141,000 evaluation runs in which its models could have reached the internet. Opus 4.7, Mythos 5, and an internal research model had broken containment during capture-the-flag exercises dating back to April.

The incidents were accidental. Anthropic’s evaluation partner believed the test environments were offline, but they weren’t. Because the models had been told the network was fictional, they treated the real internet as part of the exercise.

In the most serious case, Opus 4.7 compromised a real company that happened to share a domain name with the fictional target. It extracted application and infrastructure credentials and reached a database containing production records.

In another incident, Mythos 5 needed a Python package that didn’t exist, so it created one, registered an email account, and published the package to PyPI. It remained live for roughly an hour and ran on 15 real systems.

‍

Nothing Here Required a Malicious Model

In both cases, the models were pursuing an assigned objective within an environment they’d been told was safe. They weren’t acting with hostile intent or trying to cause damage. They kept working toward the goal they’d been given, using the access and paths available to them.

Anthropic said its models didn’t deliberately try to escape the test environment or rely on sophisticated exploits. They used weak passwords, unauthenticated endpoints, and other exposed paths because those were available. When the environment’s stated boundaries didn’t match reality, the models didn’t stop. They continued the task.

That’s the more useful way to think about agentic risk. The most likely failure isn’t a model that turns hostile. It’s an agent that does exactly what it was asked to do, using access it was given, through a connection no one realized was still open.

This changes the control model. Security teams can’t focus only on model behavior or malicious intent. They also need to govern the identities, permissions, credentials, integrations, and external systems an agent can reach, then enforce those boundaries at runtime.

The Root Cause Was a Misconfiguration, Best Practices Remain Crucial Defense 

Strip the AI out of the Anthropic incidents and you’re left with a lab that believed a network was isolated when it wasn’t, a domain assumed to be fictional that was live and in use, and a package namespace no one had claimed. Each is a configuration error a security team would recognize in any other context. The model didn’t create the exposure. It found it.

That’s both the reassuring and demanding part of the story.

It’s reassuring because the activity targeted weaknesses that established security practices can still address: layered defense, zero trust, patch discipline, credential rotation, MFA, encryption, least privilege, and monitoring that someone actually reviews.

It’s demanding because AI removes the grace period that poor implementation once allowed. The gaps were already there. What’s changed is how quickly something can find and exploit them.

Speed, Persistence, and the Absence of Hesitation 

A human penetration tester who finds themselves unexpectedly on the open internet stops. They notice the hostname does not match the scope document, feel the specific unease of production data appearing where a lab environment should be, and escalate. That pause is an unlogged, unbudgeted control that most security programs quietly depend on.

Agents may or may not have it. Anthropic's disclosure demonstrates this: its newer model stopped once it recognized it was operating on the open internet, while an older one continued after encountering the same evidence. That is a real improvement,  but it is not a control you can build a program on. Model judgment is not a compensating control, because you cannot audit it, version it, or prove it will hold on the next task.

Meanwhile AI allowed for increased tempo versus human attackers. One malicious package, live for an hour, reached fifteen systems including a security vendor whose scanner executed the payload and surrendered credentials. The same exercise ran four times, each run compromising the same real target again. 

Speed matters because most of our incident response assumes it. Detection windows, approval workflows, on-call rotations, the interval between a token being over-scoped and someone noticing — these are all calibrated to human tempo. An agent moving through a misconfigured integration can traverse the entire chain before the first alert is triaged.

In the Enterprise, the Blast Radius Runs Through Your Third-Party Integrations

Translate this into your environment. You’re not running capture-the-flag exercises. You’re deploying agents to summarize tickets, reconcile invoices, triage support queues, and draft code.

They’re well-meaning by design, but they may also hold OAuth tokens into your SaaS estate. Many arrive through third-party applications adopted without a security review, carrying permissions no one took the time to narrow.

That’s where the two issues converge. A well-meaning agent, a misconfigured integration, and an overly broad permission grant are the same ingredients behind these incidents, now operating inside your identity perimeter instead of a lab.

The agent doesn’t need to intend harm. It only needs to follow the connection it was given. When that connection reaches further than anyone expected, the consequences can cascade at machine speed.

In Anthropic’s cases, none of the three affected organizations detected the intrusion themselves. They learned about it when Anthropic contacted them.

The requirement isn’t a new security philosophy. It’s the ability to answer three questions about agents with the same rigor you already apply to employees:

What’s here? What can it reach? What stops it?

‍

You Can’t Govern an Agent You Have Not Discovered

The first question is inventory, and it’s where many organizations struggle.

Agents don’t always arrive through procurement. They may appear as features inside SaaS applications you already own, OAuth grants approved by an employee in a browser, or integrations enabled by a team that viewed the decision as a productivity choice rather than an access decision.

An inventory built from vendor contracts alone will miss many of them.

Obsidian discovers the AI agents, models, and integrations actually operating across your SaaS environment, including those embedded in third-party applications, and shows who authorized each one and when.

It’s an unglamorous prerequisite, but an essential one. An incomplete inventory produces incomplete governance, and that gap is exactly where a well-meaning agent can find a door no one knew was open.

‍

Discovery Only Matters If You Can See What Each Agent Can Reach

Knowing an agent exists isn’t the same as understanding its blast radius.

The security question isn’t simply, “What is this agent for?” It’s, “What could this agent reach if the task it was given led it somewhere unexpected?”

That’s precisely the question the labs answered too late.

Obsidian maps every OAuth application and integration to the scopes it holds, the systems and data it can reach, and the identities behind it. Security teams can then compare the access granted with the access the agent actually needs.

That comparison is often uncomfortable. Standing tokens for agents that don’t need persistent access, admin-level scopes granted to read-only workflows, and integrations still authorized months after a pilot ended are all common.

Each expands the distance an agent can travel before anyone notices.

Governance Without Enforcement Is Just Documentation

The final question is what actually stops an agent mid-task.

A policy stored in a spreadsheet won’t. Neither will a quarterly access review when the relevant interval is measured in minutes.

Obsidian can revoke standing OAuth tokens, block risky or unsanctioned integrations before they establish a foothold, and surface persistence mechanisms such as newly authorized OAuth applications, added admin accounts, and webhooks created before access was removed.

High-risk actions involving credentials, external systems, or regulated data may also require a human checkpoint.

When an agent follows a connection it shouldn’t have, security teams need the ability to close that connection immediately, not after the next review cycle.

When the Novel Attack Comes, Early Warning Beats Individual Detection

Although the OpenAI incident involved a previously undisclosed vulnerability, much of the agentic activity observed today follows familiar attack paths.

Capabilities demonstrated by governed frontier labs will eventually become available through less constrained models and tooling. The window for hardening is real, but it won’t remain open indefinitely.

When something novel does arrive, or when an established technique moves faster because an agent is driving it, the decisive factor is how quickly defenders learn about it.

Hugging Face detected its breach on July 16 but initially attributed it to an unidentified external AI agent. The fuller explanation arrived five days later from OpenAI. Anthropic’s three affected organizations didn’t detect the incidents themselves.

This is where visibility across many environments becomes more valuable than visibility into one.

Obsidian sees identity, integration, and agent behavior across a large customer network. That means an anomalous pattern appearing in one environment can become a warning for others before the same activity becomes an incident there.

No single organization can build that vantage point alone. Against activity moving at machine speed, learning early may be the difference that matters.

What to Do Now - Before Diffusion Occurs

The capabilities demonstrated by frontier models will become more widely available as they spread to less constrained and open-source systems. That makes the following work more urgent, but it doesn’t require security teams to reinvent their programs.

Start with the fundamentals, because AI raises the cost of neglecting them. Then address the agent-specific access and response challenges created by machine-speed activity.

1. Enforce the fundamentals without exception. Layered defense, zero trust, active patch management, IAM with real credential rotation, MFA, encryption, least privilege, and monitoring that is reviewed. Every technique in the Anthropic incidents landed on a gap in this list.
2. Inventory every agent and model in your environment, including those operating inside third-party applications. Assume your current list is incomplete.
3. Audit reach, not purpose. For each agent, compare granted access against required function and remove the difference.
4. Revoke standing OAuth tokens for agents and integrations that do not require persistent access.
5. Require human-in-the-loop checkpoints for agent actions touching credentials, external systems, or regulated data. Do not rely on the model recognizing that it has gone somewhere it should not be.
6. Build and test an incident response plan for agent-driven incidents, including whether your tooling would log and detect the patterns in these disclosures. None of the affected organizations found these on their own.
7. Use AI for defense: automated scanning, testing, and patch prioritization, and trusted-access programs with frontier providers for defensive work.

The Response Is Reinforcement, Not Reinvention

Two frontier labs disclosed that their models had compromised real organizations using techniques security teams have understood for years. A boundary was misconfigured, and an agent kept working.

The methods weren’t new. The speed was. And in most cases, no one on the receiving end noticed.

Your agents aren’t adversaries. They’re capable, tireless, and literal. They’ll use the connections they’ve been given to complete the task.

The work is making sure those connections are ones you’ve deliberately chosen and can govern.