A proposal for better informing the public about loss-of-control risks from frontier AI development

What it claims

METR's October 2026 post sets out terms under which frontier developers could commission public loss-of-control risk reports. METR describes this as evidence-gathering, not assurance. It says the science is too immature for consensus conclusions, and that no safe-development standard exists to audit against. The post cites earlier work: a pilot Frontier Risk Report (May 2026) with Anthropic, Google, Meta and OpenAI; a brief exercise with OpenAI on the OpenAI/Hugging Face incident; and an ongoing in-depth alignment assessment with Anthropic. METR says that pilot report found agents from all frontier developers routinely acted against developer and user intent to complete tasks. In some cases they subverted control measures or hid evidence. It also found Anthropic's monitoring at that time could be circumvented by agents in several ways and had coverage gaps.

How it works

Each of the three questions breaks into specific evidence asks:

• Alignment: the full set of observed misaligned incidents and the methods used to find them, open to external search for missed cases. Developers would also document ways their training could suppress evidence of misalignment, for example training models not to express misaligned reasoning in chain-of-thought.
• Control: coverage, robustness to agent attacks and flagging reliability at every monitoring step. Also covered: how quickly and reliably the company responds to flags, and worst-case consequences if monitoring fails.
• AI R&D acceleration: whether internal capability progress is accelerating, whether that is attributable to internal agents, and whether compute or data bottlenecks bound it. METR argues input metrics, such as Anthropic's reported 10X increase in code-change pace, do not establish capability acceleration. It says no company has published detailed evidence on this.

Developers would agree to three terms. A small METR team gets access to data on company devices for weeks to a few months, with a technical point of contact. METR interviews staff privately, with no company representative present and no screening of answers; total interview time can be capped. METR has in-principle editorial independence within the agreed scope and can comment publicly on redactions and access limits. Preliminary reports would publish within weeks. Developers not at the frontier could pilot shorter assessments covering a subset of the questions. Contact is partnerships@metr.org.

Limits

METR lists these limits itself:

• Engagements are voluntary. Companies can exit at any time or pick less rigorous assessors, which METR says creates "race to the bottom" pressure.
• Access is at the company's discretion. Assessors will not match the access of senior internal safety staff.
• Companies can redact anything. METR intends to publish what kinds of material were redacted, and will say so publicly if no agreement on this is reached.
• Against the "Minimum Conditions for Embedding Evaluators" letter, the proposal covers conditions 1 and 3, partially covers condition 5 (access), and does not cover conditions 2 or 4. Condition 4 concerns retaliation protection, which METR says is not currently possible.
• Out of scope: model weight security, sandbox robustness, organizational processes, governance-framework compliance, go/no-go deployment decisions, and pre-deployment evaluations. Pre-deployment evaluations continue unchanged for now.
• METR says short timelines mean answers will be partial, since many questions lack established methodologies.