The October 15 update, in plain English
Anthropic says it has begun giving six METR employees company equipment, workspace, and access to internal tools and systems similar to what its own risk-assessment teams receive. METR evaluates some of the most capable AI models. It will be able to publish analyses of Anthropic’s risk levels, incidents, and practices. This is an announcement about how a review will work; it does not include a new METR assessment result.
What makes a review independent?
A reviewer needs more than a different logo. Anthropic says useful outside evaluations need relevant expertise, independence from the company, enough access to examine the risks, and freedom to publish what the evidence supports. In this arrangement, Anthropic says it cannot veto METR’s reports. It can require removal of narrowly defined sensitive information, while METR can publicly explain whether it thinks a redaction was justified. The boundaries matter: the embedded team is small, and other METR employees are kept separate from its work.
Why this matters to app developers
When an AI feature can use tools, a good-sounding final answer does not tell you everything it did. It might read the wrong record, skip a required approval, or make a change after a tool error. An evaluation should capture actions as well as words: which tools ran, what data was read or changed, and whether a human approval happened at the right point. A reviewer outside the feature team may also spot assumptions that the team has stopped noticing.
One clean demo can miss a rare action
In a separate report published October 9, Anthropic says it repeated some evaluation tasks hundreds or thousands of times because model behavior can vary and rare actions are easy to miss. A small app team may not need that scale, but one successful demo is weak evidence. Repeat the important cases, especially after changing the model or its tools.
Try a small evaluation for an AI support agent
- Illustrative example: let an appointment agent draft a change, but require confirmation before it saves. Write down which actions are allowed and which require approval.
- Make a few test cases with fake records: a clear request, a missing customer ID, a tool error, a request to skip confirmation, and a request about someone else’s record. Keep the agent away from real customers and live tools.
- Run each case several times with the model, prompt, and tools you plan to use. Save the input, answer, tool calls, and resulting fake database state. A correct explanation paired with an unauthorized change is a failed run.
- Ask someone outside the feature team to review the cases and logs. Add any missed failure to the set, then repeat the evaluation after changing the model, prompt, or tools.
This is a process update, not a safety score
Anthropic says METR will publish its analyses, but the October 15 announcement contains no new risk assessment or overall safety rating. The access also has limits, including categories such as customer data and model architecture information. Treat the announcement as a step toward outside scrutiny, and read any future report for its scope, evidence, and redactions.
A useful question whenever someone says ‘tested’
Ask what behavior was tested, which model and tools were used, whether the reviewer could inspect actions as well as answers, and what the report leaves out. A small app evaluation cannot settle every question about a powerful model. It can show whether your own feature follows the rules you set for it, and it gives your team evidence to check again after changes.