The Fine Print Behind an AI Safety Pass

Key takeaways

• Passing a safety evaluation means meeting its criteria under the conditions tested.
• A refusal or wrong answer does not establish that a model lacks the underlying capability.
• Theoretical capability concealment does not prove that deployed models deliberately deceive evaluators.
• Evaluation results are most useful when their conditions match the work you plan to assign.

Before you give an AI permission to edit files or run code, “it passed the safety tests” sounds reassuring. But how much reassurance should that buy you? The answer depends on what the tests actually established—and how closely they resemble the job ahead.

A refusal tells you about behavior

Suppose an AI responds to a dangerous request with “I can’t help with that.” That is evidence that it refused the request. It leaves open whether the model could perform the task under different circumstances.

This is the distinction between capability and observed behavior. What a system can do and what it does in a particular interaction are separate questions.

The distinction works both ways. A wrong answer is no reason to jump straight to “it’s hiding something.” The model might have misunderstood the question, lacked necessary information, or simply been unable to solve the problem.

Evaluators therefore need to ask two questions: How did the model behave here? And what might it be capable of under other conditions?

A test result answers the first question directly. Answering the second takes further evidence.

Two models, identical answers, different possibilities

Consider a hypothetical evaluation with 100 questions. Two AI systems give exactly the same answers to every one.

The first system cannot perform a particular task outside the test. The second can perform it when given a specific input. That input never appears in the evaluation.

Looking only at those 100 responses, the evaluator cannot distinguish the systems. Their recorded behavior is identical, even though their capabilities differ.

This thought experiment does not establish that any real model is deceiving anyone. It illustrates a narrower point: a finite conversation record cannot settle every question about behavior beyond that record.

That is a limitation of black-box evaluation, where evaluators inspect a model through its inputs and outputs. Adding questions gives them more evidence. Behavior under untested conditions still requires inference.

A bigger test helps. It does not automatically become an exhaustive one.

“Can hide a capability” carries a lot of fine print

Claims about mathematical proofs of capability concealment need careful reading. The assumptions determine what a proof establishes.

Can the evaluator only send questions to the model? Can they inspect its internal structure? How much time and computing power do they have?

Change those conditions, and the scope of the claim may change too.

If a proof shows that a model with hidden capabilities can be constructed under certain assumptions, it establishes a possibility. Whether a deployed model behaves that way requires separate observation and testing. Calling that behavior deliberate deception requires evidence supporting the claim of intent.

There is another distinction to preserve: concealing a capability and acquiring one are different problems. A claim that a system can conceal an arbitrary capability does not mean it possesses every conceivable capability.

The useful question is whether a given evaluation method could distinguish systems with meaningfully different capabilities. That is a question about the limits of the method, before it becomes a claim about any particular product.

Read the test conditions before granting access

These limits do not make safety evaluations useless. Discovering dangerous behavior gives developers something concrete to address. Consistent results across multiple conditions can strengthen confidence in behavior under those conditions.

But “passed” compresses a lot of information into one word.

To interpret the result, you need to know what tasks were tested, which tools the model could use, and how long interactions continued. Those details help establish how relevant the evaluation is to your intended use.

A model tested only on written responses has not, through that test alone, demonstrated how it will behave with permission to modify files and execute programs. Those permissions change the conditions that matter.

Likewise, an unexpectedly low score does not establish concealment. Evaluators need to vary the questions and working conditions, examine how performance changes, and consider whether ordinary errors explain the difference.

A safety evaluation can give you a sound reason to trust a system within the conditions it examined. Before extending that trust, ask one practical question: Was the job I’m about to give this AI actually part of the test?