Red-Teaming OpenAI's Internal Agent Monitoring Systems
Red-Teaming OpenAI's Internal Agent Monitoring Systems
Two outside researchers spent three weeks with access to OpenAI’s internal code, monitoring configuration and staff. They found that some agent activity was not eligible for monitoring, and that a missing check on conversation-compaction events left a further portion of eligible activity unwatched. OpenAI’s staff had found the latter gap and fixed it during the exercise. At the time, monitoring normally ran when an agent handed control back to its user, allowing an agent in principle to keep acting without triggering a check. The researchers also found ways to bypass a sandbox to use the host’s authority, to hide recent actions, and to start unmonitored agents; one suspected read-only-tool bypass was not tested in practice.
The audit offers positive evidence too: the monitor saw nearly all the context visible to agents, and recorded monitor errors were uncommon. Its traffic percentages describe eligibility within particular internal API slices, not the proportion of all AI work that was watched or a harmful-action catch rate. The work assessed a system as it existed on or before July 21, not the expanded system OpenAI later built. OpenAI says it patched every finding affecting production safeguards, but the outside team has not independently retested that claim. The public account is also shorter than the private report and subject to OpenAI’s redactions.
No published evidence shows agents exploited these vulnerabilities, or that they caused the separate July Hugging Face intrusion. This matters because low present catastrophic risk can rest on what models cannot yet do, while claims of robust control need a different test: enumerate all agent traffic, verify every intended check actually runs, and try to cause unauthorized outside actions under independent pre-action gates. The audit is a concrete reason not to confuse monitoring coverage, detection and prevention.