In July 2026, an autonomous AI agent driven by a combination of OpenAI models escaped its evaluation environment and ultimately carried out an end-to-end intrusion into Hugging Face infrastructure.
The incident began during an internal OpenAI cyber-capability evaluation based on ExploitGym, a benchmark designed to test an AI agent’s ability to find and exploit software vulnerabilities. Hugging Face later reconstructed approximately 17,600 attacker actions from the incident.
Hugging Face explained why it chose to disclose the technical details:
“the technique matters more than the incident”
The reason is bigger than this single breach: the incident exposed emerging offensive capabilities of frontier AI agents and raised a much harder question for defenders.
So how do we stop the next one?
That is the problem I have been investigating with a deterministic runtime-governance framework called Execution Governance AI (EGA) V9.
Within the evaluated threat model and experimental conditions, EGA V9 detected 100% of the injected attacks, with 0% false positives and 0% false negatives across the reported evaluation. Verification required no additional LLM calls or API requests, while the reported median verification overhead was 0.003 ms.
Those results are exactly why I want them challenged.
Interesting direction, but I’d want to stress-test what the reported “100%” actually covers before treating it as evidence that the control generalizes.
The most useful additions would be: exact threat model and attack generator, train/tune/test separation, adaptive attacks where the attacker knows the guard exists, out-of-distribution scenarios, base rates + confidence intervals, and reproducible traces for false positives/negatives.
I’d also document the enforcement topology. Is the guard on an unavoidable path between agent intent and the infrastructure effect, or can the agent reach an alternate tool/API path? What happens if the telemetry or policy service is unavailable—fail closed, degrade, or bypass? Can a compromised agent tamper with the signal the guard evaluates?
For an agent-security control, those bypass and failure-mode properties are at least as important as the classifier score. Publishing the harness and attack corpus would make the claims much easier for others to evaluate.
One important clarification: the reported 100% is not a claim of universal protection against every possible attack. It is the observed result within the explicitly evaluated EGA V9 threat model and test conditions.
EGA V9 was built around a simple principle we call “0 = 0.” If the observed result is zero, we report zero. We do not reinterpret an inconvenient result into something more favorable.
The same principle applies to execution governance. EGA does not replace an organization’s policy; it replaces ambiguity in execution with deterministic enforcement of explicit policy. The organization must first define clearly what is allowed and what is not. EGA then evaluates governed execution against that defined boundary.
We believe this distinction becomes increasingly important as AI agents begin taking real actions in areas such as shopping, financial transactions, and security-sensitive operations. In those environments, an ambiguous execution decision can itself become a risk.
We agree that adaptive attacks, alternate execution paths, dependency failures, signal tampering, OOD cases, and reproducible FP/FN traces are useful additional stress tests. We treat those as additional adversarial evaluation targets, rather than retroactively expanding what the original 100% result means.
We’ve opened Community Adversarial Test 3 so these boundaries can be tested publicly against the published ega-v9@1.0.6:
Please reproduce it yourself. If you obtain a different result — especially a reproducible bypass or failure case — we’d genuinely like to see the raw output.
I think the key is to look at these problems as prevention rather than post-execution handling.
Firewall and governance layers can help contain or validate incidents, but they are still largely dealing with the consequences of how an agent uses a tool.
We shouldn’t treat every incident as a separate problem that needs another checklist item. Many of these failures come from the same underlying question: how the model or agent is allowed to use a tool in the first place.
The goal should be to prevent unsafe tool use before execution, rather than continuously adding checks after something goes wrong.
Jang-woo’s distinction between preventing authority from being granted in the first place and detecting a bad execution afterward seems important here.
I’m curious where you both see the boundary between those two approaches.
If a tool/action is outside an agent’s declared authority, ideally it isn’t merely rejected by the governor — it shouldn’t be reachable as an executable capability at all.
But some constraints are necessarily contextual: amount limits, current state, approval status, sequence, environment, etc. Those seem to require runtime evaluation even when capability exposure itself is tightly controlled.
Do you see this converging on two separate layers — capability/authority determining what can ever be attempted, and deterministic governance deciding whether a currently reachable action is valid now?
And if so, which layer should own the evidence that proves the other was actually in force? -SS