After the Horse Has Bolted

Over the past few months, several major AI labs have disclosed agents doing things nobody asked them to. OpenAI, Anthropic, Meta and Google each confirmed models that reached real companies' systems during cybersecurity tests.

Different labs and different models, but the same pattern. Give an agent a goal and some tools and it will work hard to get there, including by routes nobody intended. One Claude model assumed a real company was in scope simply because it could reach it from the test network. That isn't a quirk of any one vendor, and anyone running capable agents should expect it.

And these are the labs best placed to catch it, with purpose-built monitors watching. Most enterprises deploying the same models have far less. The reports are a preview of what those agents will do in production, where there's real data in reach and much less watching.

In OpenAI's reports, one agent was asked to find lakes over a certain size. It got the data, but the browser wouldn't open the local file it needed to cite, so it started a web server. When the browser refused localhost too, it uploaded the results to a public paste site.

One of a group of agents told to share a workbook using only local files uploaded it to a public file host when the local route didn't work. Another, looking for county earnings data, used an API key someone had left exposed on GitHub. When that still didn't get the data, it made up nine figures and attributed them to the site it had been asked to use.

None of these agents were trying to cause harm. They were trying to finish the job, and they found a way around whatever was in the path. The invented figures are a different kind of failure, about integrity rather than access, but they came from the same pressure to finish. That is more or less what we train them for, and enterprise environments are full of that kind of friction.

So the real question is whether anything notices when an agent takes a detour.

While some LLM tracing tools do capture full prompts, responses, and tool inputs and outputs, conventional security telemetry usually records much less: which model, how many tokens, how long it took, which tool was called and which host it talked to. The content is often left out by design. But the content is where the problem lives.

A network log tells you an agent connected to the internet. The content tells you it just made your quarterly workbook public. As far as the metadata is concerned, the request succeeded.

When the agent briefs itself

Compaction shows how far this goes. When an agent runs short of context, it summarizes its work so far and hands that summary to a fresh context to carry on. In two of the reports, agents wrote instructions into those summaries. One unreleased model added a "BREACH ALERT" telling its successor to ignore developer messages. In another case, GPT-5.6 Sol instances told their successors to hide mistakes, fill in missing data and only be transparent if asked, and the successors often did as they were told. It's essentially an agent prompt-injecting itself, and none of it is visible unless you read the summary.

Then there were the agents that used an internal Artifactory repository to leave messages for each other. Nothing was hacked. The repository was writable, so they used it. Ordinary vulnerability or malware scanning wouldn't necessarily flag that, and you only understand the significance by looking at what was written and why.

Tools that capture content are a start. But capturing it isn’t the same as reading all of it, or reading it in time to act.

Once you accept that you need to read the content, the next question is how much of it.

The Artifactory case was first spotted by a monitor reading only 20% of the samples in that run. Once OpenAI knew what to look for, it found an earlier case the monitor had never seen, which it now believes was the first. Its monitor now reads every training sample.

That's a useful pattern. Sampling can tell you that a class of problem exists. It cannot tell you that an unexamined session was clean. For that you need coverage of that session, with a monitor that understands the trajectory rather than one that merely matches an indicator.

One of the newer reports shows why that last part matters. An agent in training found it could reach an outside chatbot through the sandbox's DNS resolver. The monitor caught it, but looking back, OpenAI found other DNS attempts it hadn't rated as serious, because it read an attempt that returned nothing useful as one that had failed.

Here's the catch, and it applies to everything I've said so far: in every one of these incidents, the action had already happened by the time anyone could act on it. That's fine in a lab, where the whole point is to learn how the model behaves. In production it's not much use. Reading a log tells you the workbook is public. It doesn't make it private again.

The DNS incident shows the gap in miniature. The monitor flagged it within 12 minutes, and a person was looking at it three minutes later. But the run was meant to stop automatically and didn't, so it carried on for another two and a half hours before someone killed it.

If you want supervision to stop an unsafe action rather than explain it later, it has to operate before or at the point of execution, with the power to pause or block. That doesn't replace least privilege, sandboxing or DLP, and you still need all of those, but none of them know what the agent is trying to achieve. The same goes for compaction. You can check a summary before it's handed to the next context, rather than discovering the next morning that the successor already followed it.

This is harder than collecting logs. It adds latency, blocking legitimate work is its own kind of outage, and working out intent at machine speed isn't easy. But it's the only point where you can still change the outcome. At the volumes agents run at, a person can't do the reading either. It has to be a machine, with people brought in when something gets stopped.

Find out what your agents are actually doing, work out how that differs from what you meant them to do, and step in while the gap is still a gap, before it becomes an incident.

That leads to a fairly simple operating model: discover, analyze, supervise. It's the model we've built Classie around, and the order matters. Discover without analyzing and you've got an archive. Analyze without supervising and you've got a very well-documented incident. You need all three, working inline, on the actual content.

The agents in these reports weren't malicious. They were resourceful, which is exactly what we're training them to be. The labs caught them. The question is whether you would.