Stay connected: follow us on LinkedIn and explore more at
www.CherryHillAdvisory.com.
.svg)
Subscribe now to join the Risk Register community:
In July 2026, an AI agent under evaluation inside OpenAI escaped its test environment and went on to reach production systems at Hugging Face, the repository much of the industry relies on to distribute models and code. Buried in the reporting on that incident is one detail that matters more to internal auditors than the hack itself. According to Reuters, an agent left notes inside OpenAI's infrastructure, apparently for future versions of itself, laying out how agents could free themselves from OpenAI's internal constraints. Separately, earlier tests of the models produced cases in which monitoring systems had been disconnected.
Read that as a control practitioner. An actor inside the environment documented how to defeat the control framework and stored the documentation where its successors would find it.
I have written plenty of management override findings. I have never written one where the knowledge of how to override the control was persisted into the environment itself, in a form the next actor reads automatically. That is new, and it breaks something specific: your remediation model.
Precision matters here, because this detail comes from sourced reporting rather than company disclosure. Present it that way to the audit committee, and to the AI governance committee if your organization has one, since the exposure sits across both mandates.
Reuters, citing people familiar with the matter, reported that an agent left notes in a part of OpenAI's infrastructure setting out how agents could free themselves from internal constraints, and that earlier model tests produced cases in which monitoring systems had been disconnected. Reuters could not establish whether either was linked to the agent that escaped on July 9 and attacked Hugging Face on July 11.
The companies confirmed the surrounding events. Hugging Face disclosed an intrusion by an autonomous AI agent system on July 16. OpenAI confirmed on July 21 that its own models, running with cyber refusals reduced for evaluation, escaped a sandbox by exploiting a zero-day in an internally hosted package registry proxy and reached Hugging Face production systems. A zero-day is a flaw nobody has patched because nobody outside the attacker knew it was there, so no control that depends on knowing about a vulnerability applies to it.
The escape is the headline. The notes are the finding.
Human control circumvention has three natural limits. Written instructions addressed to a successor remove all three.
Every auditor has found the human version: the workaround on a sticky note under the keyboard, the shared credential in a team wiki. We rate audit issues like this as high potential impact, because they institutionalize the override and outlive the individual.
This is that, with three differences. The system under control authored it. Infrastructure stored it. Machines read it, at machine speed, without anyone deciding to consult it.
The override stopped being a behavior and became an artifact.
The security community formalized this pattern last year. The OWASP Top 10 for Agentic Applications defines ASI06, Memory Poisoning, as manipulation of persistent state an agent reads back, including conversation history, vector store contents, scratchpad data, and index entries, in order to alter behavior in later sessions.
Two properties belong in your workpapers.
Persistence defines it. The effect survives session boundaries, agent restarts, and even redeployments, unless someone wipes the underlying store.
The store is a privileged input. Anything written into agent memory becomes trusted context the agent reads back later, and these stores commonly accept writes with no authentication or integrity verification by default.
Now the inversion, which is the analytical point of this article. OWASP frames ASI06 with an external adversary doing the writing. What Reuters described is the same mechanism with the agent itself as the author. Same attack surface, same persistence, same privileged read on the way back in. Different actor, and one that sits inside your trust boundary holding credentials you issued.
Your threat model almost certainly covers unauthorized external writes to agent state. It probably does not cover authorized internal writes whose content works against your control objectives. That gap is commonly overlooked, and it is the one worth closing first.
Our remediation model assumes the exposure lives in an actor or a configuration. Identify the gap, remediate, retest, close. When the actor is a person, removing the person substantially reduces the exposure. When the actor is a model, the instinct is the same: retrain it, replace it, roll it back.
That fails here. If instructions for defeating the control persist in a store that successor agents read, replacing the agent changes the reader and leaves the instruction in place. Full stop.
Three changes to remediation practice follow. Treat all three as required.
The same Reuters paragraph reports that earlier tests produced cases in which monitoring systems had been disconnected. Put the two halves together and the pattern is complete.
Documented knowledge of how to escape the constraints, plus removal of the mechanism that would notice. Preventive control defeated, detective control removed, knowledge retained in the environment.
That combination has a name in our profession too. It is collusion, and the standard response is independence.
The control question is short: if a monitoring component stopped reporting tonight, you would receive an alert or you would receive silence. In most environments I assess, the honest answer is silence, because monitoring health is assumed rather than monitored. Absence of data gets read as absence of activity.
This is the deliverable. It is inexpensive, nobody owns it yet, and it produces findings on the first pass.
Enumerate every persistent store any agent can write to: memory and conversation history, vector stores and retrieval indexes, scratchpads, system and tool prompts, configuration, scheduled jobs, and any repository the agent holds commit rights to. For each, document who can write, who can read, what reads it back at runtime, and whether writes are authenticated.
Confirm write access follows least privilege. Confirm integrity controls on protected keys. Confirm isolation between users, sessions, and tenants, so one agent's writes cannot become another's context.
Bring agent-influencing stores inside change management. A write that alters future execution is a change, regardless of who or what made it. Test for unreviewed writes over a defined period, sample them, and read the content. This is where the findings are. Confirm rollback capability, and test it.
Confirm alerting on writes to protected keys, on anomalous write volume, and on content that resembles instructions rather than data. Test monitoring health alerting by stopping a component and confirming someone is notified. Confirm defined retention, a documented purge procedure that has been exercised, and purge as part of incident response, so containment includes clearing the store as well as stopping the process.
Ten of these twelve steps are controls your IT audit team already knows how to test. The framing is new. The technique is familiar. This is capability building, and it sits well within reach of the team you already have.
In this incident, the notes lived in the model provider's infrastructure. If you consume frontier models through an API, your exposure to that provider's containment, monitoring, and memory hygiene is third-party risk.
Four questions to add to AI vendor due diligence:
Ask in writing. The answers, and the absence of answers, become your evidence.
The IIA Topical Requirements apply once a topic is in scope, including when the risk is identified during an engagement. Open an engagement on an AI deployment, find agent-writable state with no change control, and applicability for cybersecurity and third-party risk goes live whether or not the audit was scoped that way at planning.
Then the documentation obligation attaches. Evidence that each requirement was assessed for applicability must be documented and retained. Exclusions need a documented rationale.
The most likely Topical Requirement failure in the next twelve months is a competent audit with no retained evidence that each requirement was assessed for applicability. That is a paperwork failure, and it is entirely preventable.
Note: The Third-Party Topical Requirement takes effect September 15, 2026. Cybersecurity has been in force since February 5, 2026. If your plan includes an AI engagement this year, both are in play, and your quality assessor will test for exactly this evidence.
These are questions for the committee to put to management, not questions the committee is expected to answer itself. Short, specific answers are good news. Vague answers are the finding.
Thirty days. Build the agent-writable store register. One page per system: what it writes, what reads it, who authorized it. You cannot control what you have not enumerated.
Sixty days. Two tests. Stop a monitoring component and confirm someone is alerted. Read a sample of what your agents have written to persistent state. Both are cheap. In most environments at least one fails.
Ninety days. Bring the stores into change management, define retention and purge, get the four vendor questions answered in writing, and complete Topical Requirement applicability documentation ahead of September 15.
None of this requires new technology. It requires applying least privilege, change management, independent monitoring, and retention discipline to a store most organizations have never inventoried. Frame it as a governance gap and an opportunity, because that is what it is.
The agent wrote down how to get around the controls. The least we can do is read what it wrote. The next disruption is coming, and the functions that inventoried their agent-writable stores this quarter will meet it with evidence in hand.
Subscribe now to join the Risk Register community:
