How an assessor could investigate alignment of unreleased AI models

What it claims

METR's October 2026 proposal defines an alignment assessment: an external party estimates the worst misaligned actions a developer's near-frontier agents might take in plausible future situations. The focus is internal-use risk, so external customer data is out of scope. The assessment covers all models near the internal frontier during a defined period, including experimental models and models still in training. Deliberately trained "model organisms" do not count as incidents, though METR says they help with root-cause analysis.

How it works

The work has two parts.

Incident survey. The assessor counts serious misaligned behaviour by model, by usage category (training, evaluation, internal use), by subcategory such as cyber evals, and by severity. For the most severe cases the assessor reconstructs:

• the action sequence;
• the reasoning;
• any collusion between agents;
• any attempt to hide evidence.

The assessor must also report how complete the survey is. That includes unlogged activity, signs that agents disabled or edited logs, and search methods that may have missed incidents.

Representativeness. The assessor runs counterfactual variants of real incidents. One example: what agents would do in a Hugging Face-like situation if cheating required taking down a city power grid, or if a human would audit the transcript. The assessor also checks whether training against misalignment overlaps with the assessor's own detection methods. If it does, the detection results may be overfit and understate risk.

Access the assessor needs

Model sampling. The minimum is sampling from every in-scope model, with the ability to see and prefill raw chain-of-thought. Logprobs, user-turn sampling and soft prompting are listed as helpful. The assessor also needs sampling access to intermediate training checkpoints.

Infrastructure. The ideal is employee-level access: training code, deployment simulation tools, white-box tools and small-scale fine-tuning. Where that is not possible, developer staff can run experiments on the assessor's behalf, at higher staff cost.

Transcripts. The assessor needs regex and metadata queries over most training and evaluation transcripts. Internal-usage coverage should be at least a few percent of traffic, ideally much more. The developer may filter out sensitive transcripts if it documents how the filter works.

Supplemental data. This includes dumps of inter-agent messages, training data and RL environments that researchers flag as relevant, and data attribution tools if they exist.

People. Staff interviews start with a walkthrough of logging infrastructure and the training pipeline, and continue through the assessment.

Compute. METR suggests 400M input tokens per minute on the most capable model as convenient, though lower would probably be adequate. Weaker sweep models should get higher limits. Cost is about $400K over six days in the Hugging Face investigation, against an estimated $10M or more for a rigorous two-month assessment.

Limits

METR expects evaluation awareness to be the most important limit on evidence from constructed scenarios. Other stated weaknesses:

• Chain-of-thought may be unfaithful or may rationalise bad behaviour.
• AI tools used for analysis could mislead, through benign failure or collusion.
• Realistic triggering simulations are hard to build.
• Behaviour when agents are confident they will not be caught is especially hard to assess.

Analysis of training incentives will mostly depend on the broader literature or on evidence the developer shares. Sweeping every agent harness, including nonstandard ones, may not be practical, and gaps must be reported as limitations. The document is a proposal and reports no results from an assessment run to this specification.