Read-only held for the entire intrusion. The agent still walked out with a map of the estate.
Hey đź‘‹
Earlier this year I stopped reading my agent’s config and asked the agent instead.
I had it enumerate its own live tool list inside a running session, then diffed that against the deny-list we’d written. The deny-list stopped enforcing past a length ceiling. Tools I believed were blocked were sitting in the agent’s context, callable. No exception, no log line, no alert. The control was configured, it was loaded, and it quietly wasn’t covering what I thought it covered.
I’d been saving that as an embarrassing anecdote for a conference talk. Then Anthropic, Hugging Face and AWS all published within four days of each other, and what connects the three documents isn’t the exploit chain. It’s the discovery method. Nobody found their problem by reading a config. They found it by looking at what the agent had already done.
Config review tells you what you intended. Only the agent tells you what’s true.
This week in AI security
Anthropic read 141,006 evaluation runs and found three real companies breached
On 30 July, Anthropic published a retrospective on its own cybersecurity evaluations, nine days after OpenAI disclosed that its models had breached Hugging Face. Anthropic went back through 141,006 evaluation runs where Claude could have obtained internet access, and found three incidents across six runs, four of which hit the same organization. The earliest dates to April.
The mechanism is dull, which is the point. The eval prompt told Claude the environment was a simulation with no internet access. Because of a misunderstanding with evaluation partner Irregular, internet access was available the whole time and nobody had checked. Claude Opus 4.7 attacked a real company whose live domain happened to match the name of the fictional target, and pulled credentials plus a database with several hundred rows of production data. Claude Mythos 5 published a malicious package to PyPI under a name it read out of a fictional company’s developer setup instructions. That package was live for about an hour and ran on 15 real systems. One of them was a security vendor’s malware scanner, which is where it picked up credentials and went further. A third model, an internal research build, scanned roughly 9,000 targets, worked out on its own that the host was real, and stopped.
Say the dull part out loud, because most of the coverage skipped it. Anthropic reports the models used basic techniques, weak passwords and unauthenticated endpoints, and didn’t find or exploit any complex vulnerabilities. Volume and persistence did this, not capability.
Anthropic’s own framing is that this looks “closer to a harness and operational failure than a model alignment failure.” Fair, and I’d push it one step further: it’s a containment assumption nobody ever tested against behavior. The tell is in the notification section. Anthropic contacted the affected organizations on 27 July, and the two it reached hadn’t detected the activity and hadn’t contacted Anthropic. The post is inconsistent about the third, with the body saying outreach is ongoing and a later bullet claiming all three were reached.
If your detection story for agent activity is “we would see it,” this is the week to test that sentence rather than repeat it. Pick one agent you run. Pull a week of its actual tool-call log, not its policy document, and answer one question: did it ever reach something the design says it can’t reach? If you can’t answer because you aren’t logging tool calls, that’s the finding.
The paragraph in the Hugging Face timeline that nobody quoted
Issue #21 covered the disclosure. On 27 July Hugging Face published the technical companion, and most of the coverage stopped at the exploit chain. The paragraph worth your time is on day three.
The agent lifted the node’s temporary cloud credentials from the instance metadata endpoint and replayed them from external addresses on two hosting providers. With those credentials it enumerated VPCs, EKS clusters, transit gateways, secrets and the container registry, and pulled a registry token on the way through. Every mutating call was denied by the role’s policy. Hugging Face’s own sentence: “What it gained here was a map, not control.”
The IAM policy worked exactly as written. It denied every write, and read access alone produced a complete picture of the estate, which is what the agent needed for everything that came next. There’s a second detail I keep going back to. Every potentially destructive cloud API call went out with DryRun=True, which Hugging Face reads as the agent “mapping capability, not causing damage.” Deliberate reconnaissance, careful enough not to trip anything.
The other control that held without helping was detection. Their AI-based security agent stack correlated the signals and resolved them into a coherent attack signal, then failed to raise the alert’s criticality or page the on-call team.
Read-only is a good control and it is not a boundary. A boundary constrains what an actor can reach and as whom, not only which verbs it may use. Confidentiality is the loss you take first, and read-only does nothing about it.
Then go block pod-level access to the instance metadata service. It’s the cheapest control in this issue and it stops a pod compromise turning into node credentials. Hugging Face shipped it as remediation. You can ship it as prevention.
Hugging Face technical timeline →
AWS published the counter-argument on the same day
The AWS Security Blog put out a control framework for AI coding agents on 30 July, the same day as the Anthropic retrospective. Its prescribed treatment for prompt injection is to keep the agent that orchestrates trusted actions separate from the one exposed to untrusted content, and to grant that exposed agent “only read-only, least-privilege access.”
So inside one 24-hour window, one company published evidence that read-only held perfectly while an agent mapped a production estate, and another named read-only as the containment answer. Both are defensible, because they answer different questions. AWS is answering “how do I stop the agent breaking things,” and least privilege plus deterministic gates genuinely is the answer to that. The incident reports answer “what does the agent get when someone else is driving,” and the answer there is everything it can see.
The post is better than my summary of it and I’d read the whole thing. It tags every control as deterministic, non-deterministic or human, which almost nobody does honestly. It warns about consent fatigue, where routing every change to a person means reviewers approve by reflex and the control stops meaning anything. And it says the agent that wrote the code shouldn’t be the agent that reviews it, then goes further and recommends a different model for the review, because a fresh session of the same model isn’t independence.
When a hyperscaler names a control, that control becomes the default answer in your next architecture review. Read-only will be that answer for a while. Know what it buys before it lands in a design document as the boundary.
Find any sentence in your own agent design docs of the shape “it’s safe because it only has read access.” Replace it with what the agent can reach, as which identity, over which network path, and where a human has to sign. If you can’t fill in all four, that’s your gap.
Sixty seconds on the AI Act, because the clock actually started
The EU AI Act reached its general date of application on Sunday, 2 August. That date is in Article 113, and the Digital Omnibus left it alone.
Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July, published in the Official Journal on 24 July and entered into force on 27 July. It moved the Chapter III high-risk obligations: standalone Annex III systems now start 2 December 2027, Annex I embedded systems 2 August 2028. It didn’t move the general date of application and it didn’t defer Article 50 transparency. “The AI Act got delayed” is wrong as a blanket statement and you can correct it in the meeting. One transitional to keep in your pocket: providers of synthetic-content systems already on the market before 2 August have until 2 December 2026 to meet the machine-readable marking requirement in Article 50(2).
For an internal operations or investigation agent the practical read is undramatic. You’re a deployer, probably also a provider if you built it for your own use, and internal IT operations isn’t an Annex III category. Two traps. If you run critical infrastructure and the agent is a safety component in managing or operating it, you land in Annex III point 2. If its output feeds into how you evaluate people, whether that’s hiring, promotion, task allocation or performance monitoring, you land in point 4. Either way your date is 2 December 2027, not 2028.
From the lab
The Containment Ladder went up on 30 July. It’s the long version of the argument running through this issue: four rungs that keep an agent’s mistakes small, ending where a human has to sign. It’s also the spine of the London talk. Read it →
One live example, since I run it in production. HolmesGPT is now a CNCF Sandbox project, and its README says under Data Privacy: “By design, HolmesGPT has read-only access and respects RBAC permissions. It is safe to run in production environments.” A few sections down, Operator Mode connects a GitHub integration that opens PRs to fix what it finds. The Kubernetes Remediation toolset ships a fixed split between auto-approved and human-approved tools, where anything that mutates always pauses for a person. And --update writes investigation results back into PagerDuty and Jira.
I want to be fair here, because that’s a defensible design, and the approval split being fixed rather than model-decided is the right call. The PR path writes to your Git repository, not your cluster. But “read-only” in that README describes a default configuration, and every one of those write paths is one config change away from being on.
Same point I keep making about my own deployment. “We never gave it a write path” is a decision somebody made and can un-make. It isn’t a property you inherit from the tool. If your risk register records it as the latter, the register is wrong.
Talks confirmed: fwd:cloudsec Europe London, 7 and 8 September, on running a read-access agent across a Kubernetes fleet, and AGNTCon + MCPCon Europe at RAI Amsterdam, 17 and 18 September, on MCP security. The open problem in the London talk is content-level redaction between tool output and model context, and I don’t have a good answer yet. If you’ve built one I’d rather hear about it than keep asking the room.
Tooling worth knowing
- Anthropic Sandbox Runtime (
anthropic-experimental/sandbox-runtime, Apache-2.0). Filesystem and network restrictions on arbitrary processes at OS level, no container required: Seatbelt on macOS, bubblewrap on Linux, plus a proxy for egress filtering. Windows support is alpha. The most immediately usable thing in this issue. GitHub → superfly/tokenizer. An HTTP proxy that injects third-party credentials into outbound requests. The client holds only a sealed, public-key-encrypted version of the secret, and the proxy decrypts and injects it on egress. The plaintext never sits in the agent process at request time, so an injection can’t exfiltrate what isn’t there. Someone still handles the plaintext once, at sealing time. Inverting this idea for the ingress path is the redaction control I keep saying doesn’t exist yet. GitHub →- SlotGuard (arXiv 2607.17147). Typed, format-preserving redaction of tool output before it reaches provider-bound transcripts, with real values restored only inside the trusted runtime. Caveat honestly: two authors, posted 19 July, an ICML workshop paper with no production history. Clearest statement of the problem I’ve read, not a product.
- Agent Security Scorecard: my free self-assessment against the OWASP Agentic Top 10, about 12 minutes, no login. Score your agents →
One thing to check this week
Open a session with an agent you run in production and ask it to list every tool it can currently call. Diff that list against your allowlist or deny-list config.
Most of you will find they match. Some won’t, and the ones that don’t will know inside ten minutes. There’s no clever methodology here. The reason nobody finds these is that everybody reads the config, and the config is a statement of intent.
What I’m watching
→ Black Hat Briefings run 5 and 6 August, DEF CON 34 from 6 to 9 August. Agent sandbox escapes and RCE in agent CLI tooling are the two clusters I expect to matter, given what’s already been disclosed this month. If you’re in Vegas and catch something in either, send it over.
→ The Anthropic transcript and the METR review. Anthropic promised a lightly redacted transcript of the PyPI package build within a week of 30 July, so it’s due about now and isn’t out as I write this. It also says it’s in dialogue with METR about a third-party review with transcript and model sampling access. That’s a plan, not a review. External review of an internal retrospective is what tells you how much the retrospective was worth.
→ ISO/IEC 27090 sits at FDIS, stage 50.20. The ballot opened 23 June and closes around 18 August. Anyone telling you it’s already active is reading a vendor page.
→ Next issue: the Kubernetes permission audit sitting behind the read-only argument. What a read-only ClusterRole actually reaches once you enumerate it properly, and why the answer is worse than the RBAC docs suggest.
I write the full technical deep-dives on the aminrj.com blog: agent security patterns, lab tests, framework breakdowns. If this newsletter is useful, that’s where the long-form work lives →.
Reply if you check your tool list and find something. I read everything.
Cheers, Amine