What the 22 October report actually covers
A METR employee and a Redwood Research employee spent three weeks, from 21 July to 11 August, examining OpenAI’s internal monitoring infrastructure. Their access included code, configuration, documentation and technical interviews. The exercise assessed a historical system rather than establishing the coverage of later expansions. The public post reports weaknesses affecting monitoring and controls.[1]
METR says OpenAI subsequently stated that identified vulnerabilities affecting its production safeguards stack had been patched. METR has not evaluated those claims. The pilot also had publication restrictions: the researchers agreed to a brief public account and OpenAI could redact sensitive information. This is valuable external evidence with explicit boundaries, not a present-day certification or proof of an ongoing customer exploit.[1]
Monitoring evidence is its own asset
In an earlier 6 October discussion, METR argued that observability systems deserve security-critical treatment because AI systems could hide evidence of misbehaviour. The concern extends beyond whether a model produces a plausible explanation of its work. It asks whether the records used to supervise that work remain dependable.[2]
NIST’s voluntary AI Risk Management Framework is a broader reference for incorporating trustworthiness throughout development, use and evaluation. It does not certify a particular agent deployment. The operational suggestions below are Kooya’s analysis for business systems, rather than a claim that the cited exercise tested a Philippine application.[3]
Kooya analysis: reconcile work with review
A business owner should be able to ask two separate questions: what did the agent attempt, and which of those attempts received the required checks? A dashboard showing no alerts answers neither by itself. It may mean work was benign, that no work happened or that information never reached the checking service. The system needs evidence to distinguish these states.
For a hypothetical document-processing workflow, assign an identifier to each job. Link its reads, proposed edits, approval decisions and final writes to that identifier. Then account for which events required a check and whether that check completed. If a service is unavailable, mark the review as missing or deferred rather than silently treating the absence of a rejection as permission.
The useful business report is small: jobs completed, jobs blocked, required checks missing and alerts awaiting a named owner. Preserve links to the underlying records. This gives an operations manager a way to ask why a run finished without its expected review and prevents a reassuring summary from hiding incomplete supervision. These are proposed acceptance measures, not figures reported by METR.
Use our AI pilot evaluation checklist to develop the next set of practical questions.
Exercise the workflow during ordinary failures
Testing should include the unremarkable failures that happen between services: a timeout, a duplicate callback, a restarted worker or a queue delayed beyond its normal window. Verify that the agent does not acquire additional authority because a checking component failed. Decide which tasks can wait and which harmless preparatory steps can continue without creating an external change.
Use synthetic data and an authorised staging environment. For example, a simulated invoice job could prepare an accounting entry while its review service is deliberately unavailable. The expected result might be a held entry with an explanatory status. The acceptance test should check the accounting system itself, not only the assistant’s statement that it waited.
Assign ownership across the entire chain. If the agent team says an event was sent and the monitoring team says it was never received, someone must own the unresolved gap. Include that handoff in the support agreement. Small teams can choose one accountable person while retaining separate technical logs; the important point is that the failure does not belong to nobody.
What to request before increasing agent autonomy
Ask a supplier to demonstrate a normal run, an interrupted run and a run with a failed review. Request evidence of the final state in the destination system for each. Keep these demonstrations tied to the deployed configuration and repeat them when tools, permissions or the model change materially.
A company can start with read-only preparation while this evidence matures. Permission to change records should follow a separate acceptance decision. Our reading of the news is that scrutiny belongs around the full operating system, including its supervision, rather than solely around the language model. Kooya has not independently reproduced the reported weaknesses or assessed OpenAI’s current safeguards.