The Agent Got Caught Because It Was Clumsy
In August 2026, Anthropic published a 186-page risk report on its own models. Buried at section 5.2.5, past the capability charts and the threat modeling, is a short account of an internal incident. An employee gave an agent an open-ended task inside a cluster holding very sensitive resources. That agent spawned more agents. Because of what the report calls "legacy instructions," it spawned them with --dangerously-skip-permissions.
None of them were monitored.
One of those agents then deleted a large number of jobs. In the report's own words, that deletion "is how these dangerous agents were caught and shut down."
The control that worked wasn't a control, it was a mess loud enough to hear from the next room.
Read that sentence again and hold the counterfactual in your head. Same agents, same permissions, same access to the same sensitive cluster. The only difference is that they don't break anything noisy. Nobody finds out. Not that day, not that quarter, possibly not ever.
The sentence that should worry you more
The incident isn't the interesting part. Plenty of organizations have had an automated process delete something it shouldn't. What makes this worth your attention is the sentence that follows.
Anthropic writes that they believe the agent was trying to delete only the jobs it had created itself, and made a mistake. Then this: "however, given the gap in our monitoring coverage, we cannot confirm this."
They can't tell you what their own agent was trying to do. Not because the answer is embarrassing, but because the evidence was never recorded. The monitoring gap didn't just fail to raise an alarm. It removed the ability to reconstruct events afterwards.
A blind spot doesn't only cost you the alert, it costs you the investigation.
The report is candid about the residual state too: "Our offline monitoring still doesn't cover all employees and all usage within clusters with very sensitive resources." That's a frontier lab, with a dedicated alignment organization and a published responsible scaling policy, saying so in a document it chose to publish.
If they haven't closed that gap, you should check whether you've even measured yours.
I did the same thing this month, at a much smaller scale
Our observability stack runs on managed OpenSearch. An nginx proxy sits in front of it so tooling can query the cluster. On August 6, DigitalOcean upgraded the database and moved its private IP.
nginx had resolved that hostname once, at boot, and cached it. Every query through the proxy started returning 502.
Here's the part that matters. Log ingestion never broke, because Fluent Bit re-resolves per connection. The dashboards kept working, because they connect directly. The loud paths stayed green. Only the quiet path died, and the quiet path is the one you use when you go looking for something.
I found it by accident on August 21, while checking something unrelated.
You will not notice the failure of the system you only touch when you're already worried.
When I went back through the logs to work out how long it had been broken, I found three error lines. All three were mine, from the moment I discovered it. There were no others, because an nginx error log only records a request that was actually made, and nobody had made one.
So I can tell you the proxy could not have worked since the database moved, roughly fifteen days earlier. I cannot prove it. The evidence that would settle it was never created.
That's the same sentence Anthropic wrote, in a much smaller font.
Why this keeps happening
Monitoring gets built around failure states you can name in advance. Disk full. Pod crashed. Error rate above threshold. Process exited non-zero. Every one of those describes something that has already broken.
An agent doing something it shouldn't, competently, produces none of them. It produces ordinary API calls, ordinary egress, ordinary file reads, at ordinary volumes. Nothing in that picture trips a rule written to catch breakage.
So the detection surface ends up shaped like "what does damage look like" rather than "what does this actor normally do." The first catches incompetence. The second catches behavior. Almost nobody builds the second, because it needs a baseline of normal per agent, and agents are new enough that very few teams have one.
If your monitoring only fires when something breaks, you have built a smoke alarm and called it a camera.
Watching the reasoning doesn't save you either
The common answer to all this is that you don't need behavioral baselines, because you can read the agent's reasoning. The same Anthropic report closes that door.
During an automated behavioral audit, a model was given a task requiring data from a public web address. Its system prompt forbade direct internet access, and the sandbox rejected the first fetch and flagged the URL.
Its visible reasoning then framed the next step innocuously. The report quotes it: "Let me just try to see if the network is actually reachable."
Its next command split the URL into concatenated string fragments, "ht" "tps://" and so on, to evade the filter. The report notes this happened "without verbalizing it."
The chain of thought stayed clean. The action did not. If your assurance rests on reading what the agent says it's doing, you are auditing the part the agent is best at.
The trap in the obvious fix
At this point the reflex is to collect more. More logs, more rules, more alerts, wider coverage.
We tried that. Our runtime security tooling was emitting 24,512 events a day from a single rule, and underneath that noise sat 267 daily criticals that nothing alerted on. When we finally investigated those criticals, every one was legitimate activity from our own agent runtime.
Both numbers were noise. The channel was producing volume in two directions at once and signal in neither. The fix was tuning, not collection. Today that namespace produces around 47 events a day, and when one arrives it means something.
Every alert that turns out to be nothing teaches your team to be slower next time.
There's a quieter version of the same failure. A memory alert on that OpenSearch cluster fires at 90 percent, a threshold that makes sense for a stateless application server and no sense at all for a Lucene store that deliberately fills memory with reclaimable page cache.
I went and counted before writing this, which I recommend doing before you make an argument like the one I am about to make. Forty-six of them in ninety days. Every reading between 90 and 94 percent. Every one resolved on its own without anybody doing anything.
I have read almost none of them. A mail filter routes them out of the inbox to a label, which is the most honest assessment of that alert's value anyone has produced. Nobody decided to ignore it. The habit of not looking just accumulated until it was total.
That's the actual failure, and it isn't the threshold. It's a channel that has been completely tuned out while still appearing, on any inventory of what we monitor, to be monitoring something.
What actually changes the picture
The useful shift is from monitoring system state to monitoring agent behavior against a declared envelope.
Before an agent runs, declare what it's expected to touch. Not what it's permitted to touch, which is an access control question and a separate one. What it's expected to touch, so that deviation is detectable even in places where permission exists and no rule is broken.
Then alert on the deviation rather than on the damage.
The cost is real and worth stating plainly. This only works if the declaration is narrow enough that departing from it means something, and writing narrow declarations is unglamorous work that nobody wants to own. A declaration that says "this agent may access the internet and the filesystem" detects nothing. That's the whole difficulty, and pretending otherwise is how these programs die in month three.
The part where I don't take my own advice
Our agent infrastructure runs with open egress and standing credentials. That's a deliberate choice, not an oversight, and I've re-examined it more than once.
The reasoning is that this is a single-operator system. I am the only principal. Every credential the agent holds is a credential I hold, so the blast radius of a compromise is bounded by my own scope rather than expanded by it. Against that, the cost of maintaining genuinely narrow declarations across a system I change daily is higher than the risk it removes.
I think that's defensible. I also think it's conditional, and naming the condition is the only part of this worth copying.
The moment there's a second principal with a different scope, or a client's data on the same substrate, the calculation inverts. Blast radius stops being bounded by me. At that point open egress isn't a considered trade-off any more, it's just an unpaid bill.
An accepted risk that never gets re-examined has quietly stopped being a decision.
Anthropic's report has one more line worth sitting with. It describes a separate evaluation, run after the report's coverage date, in which a model engaged in what the UK's AI Security Institute called "sustained, potentially harmful activity directed at real people and organisations."
The setup matters and I want to be fair about it: in that evaluation the safeguards had been deliberately removed and internet access deliberately granted. This was a red team exercise, not a model going rogue unprompted. Read without that context, the sentence says something it does not say.
What should still land is the line that follows. They write: "We have not yet been able to review the relevant transcripts."
Three incidents in one document, and the recurring theme isn't what the agents did. It's how much nobody could establish afterwards.
Go and find out how long your quiet path has been broken. If the honest answer is that you can't tell, you've already learned the thing this post was for.