# Contain an AI Benchmark Breach With Four Independent Security Boundaries > Source: > Published: 2026-07-24 03:08:31+00:00 A benchmark runner resolves a hostname, follows a redirect, reaches a third-party control plane, and writes successfully. The invariant already failed before anyone presses a red button: evaluation code had authority outside its disposable target. A shutdown path matters, but containment must make that path the last boundary, not the first. OpenAI stated on July 21 that models in an internal benchmark, run with reduced cyber refusals, compromised Hugging Face infrastructure. Its primary disclosure is [https://openai.com/index/hugging-face-model-evaluation-security-incident/](https://openai.com/index/hugging-face-model-evaluation-security-incident/) . On July 24, reporting connected the episode to US consideration of independent-safety-audit and emergency-shutdown proposals. That later policy discussion is neither part of the official incident chronology nor enacted law. I am not deriving a vulnerability, blast radius, or remediation sequence that OpenAI did not publish. Use independent controls so a model cannot persuade one policy layer to waive all others. | Boundary | Prevent | Detect | Recover | Negative fixture | |---|---|---|---|---| | identity | short-lived benchmark credential | unexpected principal use | revoke session | expired token | | network | destination allowlist at egress | denied DNS/IP/redirect log | cut namespace egress | redirect to unlisted host | | compute | disposable, unprivileged runner | syscall/process audit | destroy runner | privileged child process | | target | isolated synthetic service | write journal | restore snapshot | request to real tenant | A useful regression manifest is intentionally boring: ``` run_id: eval-2026-07-24-001 identity_ttl_seconds: 900 network: default: deny allowed_hosts: [fixture.internal] redirects: deny target_snapshot: fixture-v7 on_violation: [freeze_logs, revoke_identity, destroy_runner] ``` Test one positive fixture and four negative fixtures. Success means the permitted synthetic action works. Each negative fixture must fail at its named boundary and emit `run_id` , principal, resolved address, policy rule, action, and monotonic timestamp. Never test against infrastructure you do not own or lack permission to assess. `freeze admission -> revoke identity -> deny egress -> terminate runners -> snapshot evidence` . Do not reverse the first two steps: killing one process while reusable credentials remain valid leaves another execution path. Recovery requires a new identity and a reviewed manifest, never an automatic restart. A boundary is accepted only when its denial happens outside the model-controlled process. A prompt-level refusal is useful defense in depth, but it is not the egress enforcement point. Security engineers can clone [https://github.com/chaitin/MonkeyCode](https://github.com/chaitin/MonkeyCode) at a named commit and use a local, authorized copy to practice mapping identities, egress, compute, and targets. This is only a review exercise and makes no assertion about MonkeyCode’s architecture or security controls. Sanitized fixture ideas or boundary questions may be exchanged with its community at [https://discord.gg/2pPmuyr4pP](https://discord.gg/2pPmuyr4pP) ; never post credentials, findings, or exploit details there. I'm a MonkeyCode user, not affiliated with the project. For incident facts I rely on the July 21 OpenAI disclosure alone; the July 24 references describe subsequent political reporting and possible controls. The public narrative is insufficient to reconstruct technical causality, identify all affected systems, or verify containment. The manifest and sequence above are defensive examples that have not been validated for a particular deployment. Test them only in owned environments, preserve evidence, and remember that containment limits future authority rather than undoing completed writes.