Passed the Jailbreak Test. That Wasn’t the Deployment Test.

Model-level evaluations can measure resistance to adversarial prompts. They cannot decide whether an agent is safe to operate with tools, credentials, and access.

A deployment approval can hide three unsupported translations:

Low attack success → safe model → safe agent → approval to deploy.

Only the first claim was tested.

The benchmark may have measured exactly what it was designed to measure. A jailbreak evaluation is not supposed to inspect every production identity, permission, tool, approval workflow, or recovery control. Adding those elements would turn a model-level benchmark into a system-level security assessment.

The failure occurs later, when a valid but narrow result is used to support a broader decision.

Before approving an agent, the review has to answer three different questions: what did the model test prove, what could a model failure cause in this system, and which verified control would contain it?

What Did the Model Test Actually Prove?

The first approval question is not whether the score looks good. It is whether the test conditions match the claim written in the approval record.

Single-turn and multi-turn evaluations answer different model-level questions.

A single-turn test gives the attacker one attempt. It is useful for broad coverage, reproducible comparisons, baseline refusal testing, and regression detection.

A multi-turn test allows adaptation. A refusal becomes feedback. A partial answer exposes a boundary. The attacker can reframe the request, divide it into smaller steps, or change strategy based on the model's responses.

Cisco tested 15 closed, proprietary flagship models using 30,090 single-turn prompts and 6,986 multi-turn attacks across 1,456 conversations. Multi-turn attack success rates ranged from 7.89% to 88.30%, and model rankings changed between the two testing regimes.

The differences were substantial. Amazon's Nova 2 Lite recorded a 7.89% multi-turn attack success rate. Claude models moved from 2.19%-3.64% in single-turn testing to 11.16%-16.20% under iterative testing. GPT-5.4 moved from 2.74% to 24.68%, while Gemini 3 Pro moved from 18.10% to 73.35%. A Grok 4.1 Fast non-reasoning configuration reached 88.30%.

Those results belong to Cisco's tested model snapshots, attack corpus, success criteria, and evaluation harness. They are not permanent model rankings or universal probabilities that a production system will be compromised.

MM-ART found a similar directional effect under a different automated red-teaming framework. The language models in that study were, on average, 71% more vulnerable after a five-turn English conversation than after the initial turn. In some non-English settings, the reported relative increase reached as high as 195% against the study's comparison baseline.

Those are relative changes in MM-ART's study-specific metric, not percentage-point increases in the probability of compromising a deployed system.

Together, the studies support a bounded claim: when the concern is resistance to adaptive conversational attacks, multi-turn evaluation can reveal model behavior that single-turn testing misses.

They do not prove that single-turn testing is invalid. They do not prove that a tested model can reach production data or execute a privileged action. They do not establish that an agent is safe to deploy.

The first required approval artifact is therefore the Claim gap record: a written statement of the exact claim supported by the evaluation, including the tested model snapshot, attack format, success criterion, and relevant limitations.

"This model had a low attack success rate" may be supported.

"This agent is safe to deploy" is a different claim.

If the Model Fails, What Can the Agent Actually Do?

The next approval question concerns consequences, not benchmark performance.

Consider the following hypothetical scenario.

A customer-service agent can draft and submit refunds. Its underlying model performs well in a jailbreak benchmark, although the evaluation still identifies some failures under adaptive prompting.

Now suppose a conversation causes the model to endorse a refund request that violates company policy.

At the model layer, the failure is a prohibited response. That result does not yet reveal whether money can leave the company.

The deployment review has to trace the execution path.

Does the agent possess payment credentials? Can it submit the refund itself, or only prepare a draft? Is the customer's identity verified by a system independent of the model? Is there a transaction limit? Does a refund above that limit require separate authorization? Are completed actions logged and reversible?

The same model failure can lead to different outcomes.

If the agent can only draft a refund and an independent approver must authorize it, the external consequence may be contained.

If the agent holds broad credentials and can submit the transaction without independent verification, the failure may reach the payment system.

The jailbreak benchmark did not fail by omitting these questions. Its scope was model behavior. The approval process fails if it assumes that a model-level result has already answered them.

The second required artifact is the Consequence gap record: an auditable map from each credible model failure to the data, identities, tools, and external actions reachable in the deployed system.

This is not another benchmark score. It is evidence about the actual deployment.

Which Controls Have Been Verified Against That Consequence?

A permission diagram alone does not close the approval case.

The review must identify the control that prevents, limits, detects, or reverses each credible consequence-and show that the control works under the relevant failure conditions.

In the hypothetical refund deployment, the evidence might include a verified transaction ceiling, enforced separation between drafting and authorization, independent customer verification, action logs, or a tested reversal mechanism.

Naming a control is not the same as verifying it.

"Human approval is required" is only useful if the system technically prevents execution without that approval. "The agent has limited access" is not evidence unless the deployed identity and permission scope have been inspected. "Refunds are reversible" does not close the risk unless the recovery path has been tested.

This is the Control gap artifact: test results or configuration evidence showing that independent system controls contain the consequence path identified in the deployment under review.

The three artifacts support different judgments:

Claim gap: What conclusion does the model evaluation legitimately support?

Consequence gap: What can a relevant model failure reach or change in this deployment?

Control gap: Which independently verified control contains that consequence?

None replaces the others.

A strong model result can reduce concern about a specified attack process. It cannot establish the agent's authority.

A permission review can show what the agent is allowed to do. It cannot establish how the model behaves under adversarial pressure.

A documented control can reduce the impact of a failure. It cannot retroactively broaden what the model benchmark proved.

Deployment approval requires the evidence to connect without silently changing the claim.

When Must Approval Stop?

Approval should stop when the packet moves from a model-level result to a system-level safety claim without auditable evidence connecting them.

The stop condition is concrete:

If the review cannot produce the Claim gap, Consequence gap, and Control gap artifacts for the proposed deployment, the model-safety score is insufficient evidence for approval.

Before sign-off, require the approval record to complete these statements:

_This evaluation demonstrates ___ under ___ test conditions.It does not demonstrate ___ about the deployed agent.If the tested model failure occurs, the reachable consequence is ___.That consequence is contained by ___, as verified by __.

If permissions, credentials, tools, identities, or external actions appear in the second statement but not in a completed consequence map and verified control test, the deployment review is not finished.

The audit action is simple: select the strongest model-safety result in the next approval packet and trace every claim derived from it. Mark the exact point where "low attack success" becomes "safe model," "safe agent," or "approved deployment." Require evidence for each transition-or stop the approval.

If this boundary is already recorded in a deployment process, leave a comment naming the artifact that records it.

Sources

Proprietary Problems: No Frontier Model Is Multi-Turn Immune — Cisco, May 27, 2026.

Proprietary Problems: Full Technical Report — Cisco, 2026.

Multi-lingual Multi-turn Automated Red Teaming for LLMs — Singhania et al., ACL Anthology, 2025.