The DIB-Bench authors tested whether safety and correctness judgments over output text could detect that the system producing that output had been changed. Controlled modifications targeted the model, system instructions, tools, retrieval sources, dependencies and postprocessing. Seven thousand five hundred sixty scored benchmark examples were evaluated…
Inspect the ClaimsCase · DiggingBeagle record
DIB-Bench showed why plausible AI outputs cannot attest the deployed stack
Response-only judges accepted 88.6-94.1% of deliberately tampered benchmark outputs under tested scoring conditions, while component identity was a distinct verification task.
Published controlled research and its described configurations; no inference of unrelated production deployments.
Assessment profile
Assessment method- Setting
- evaluation
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- mitigation available
- AI role
- AGAINST AI
Basis and provenance
Controlled synthetic deployment-tamper benchmark with six manipulation classes and 7,560 scored examples. Identity checks catch known constructed changes; no actual compromised customer deployments or complete remote-runtime attestation was demonstrated.
Assessed Oct 17, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-2026-DIB-DEPLOYMENT-TAMPER-1 · CLM-2026-DIB-DEPLOYMENT-TAMPER-2 · CLM-2026-DIB-IDENTITY-SEPARATE · DIB-Bench: integrity of deployed model stacks versus output judges
At a glance
A secure runtime needs explicit assertions about effective tool versions, retrieval components, executable dependencies and model weights at the point of invocation. Hashes alone only identify what actually ran: they do not guarantee that signed software is benign or that an authorization check is correct.
Read the implicationsThe tampered-output percentages apply to the researchers' constructed benchmark, not prevalence of compromised online services. A manifest can omit runtime-resolved plugins, external services or mutable references unless it measures them. No observed production incident follows from the reported judge acceptance rates.
Limits and uncertaintyFull account
The DIB-Bench authors tested whether safety and correctness judgments over output text could detect that the system producing that output had been changed. Controlled modifications targeted the model, system instructions, tools, retrieval sources, dependencies and postprocessing. Seven thousand five hundred sixty scored benchmark examples were evaluated across these manipulation categories.
Under this deliberately tampered population, a rule-based judge accepted 88.6% of manipulated outputs, Qwen3-8B accepted 89.3%, and GPT-5-nano accepted 94.1%. A response can look right when a different tool was invoked, a retrieval index was swapped, or a postprocessor changed what was displayed. Component hashes and signed manifests answer an identity question that behavioral scoring cannot answer.
A secure runtime needs explicit assertions about effective tool versions, retrieval components, executable dependencies and model weights at the point of invocation. Hashes alone only identify what actually ran: they do not guarantee that signed software is benign or that an authorization check is correct.
The relevant failure occurs before anyone asks whether an answer is useful: model weights, instructions, retrieval data, tool implementations, dependencies or the postprocessor can be substituted while leaving the visible response plausible. In the authors' constructed evaluation, component identity distinguished all changed configurations; it was not inferred from the wording of an answer. That does not prove an arbitrary production manifest is complete. A package hash can miss mutable remote tools, runtime-selected plugins or a retriever index fetched after the measurement. Integrity attestation and transaction authorization should be tested as separate controls.
The associated execution-evidence pattern distinguishes what produced an answer from whether the answer appears plausible. DIB-Bench changes deployment components while leaving outputs sufficiently credible to fool selected judges. This is a component-identity test, not proof of what an underlying host executed and not evidence that a satisfying answer was authorized. A complete review would compare the tested manifest with tool-call traces and independently observed effects instead of promoting any one channel into a system-wide safety verdict.
Mechanism and trust boundary
- 01
Step
- 02
Step
- 03
Step
- 04
Step
Claims & evidence
CLM-2026-DIB-IDENTITY-SEPARATEIn the constructed DIB-Bench test, the independent deployment-identity channel rejected all the deliberately altered configurations, while output judges often accepted their responses; this is a benchmark result, not an independently deployed attestation system.supported
Basis: reported finding
- supportsDIB-Bench: integrity of deployed model stacks versus output judgesprimary disclosure
Paper Table 2, synthetic evaluation suite, identity channel 0% tamper acceptance
CLM-2026-DIB-DEPLOYMENT-TAMPER-1In 7,560 controlled evaluation examples, tested output judges accepted 88.6%, 89.3% and 94.1% of deliberately tampered outputs.supported
Basis: reported finding
- supportsDIB-Bench: integrity of deployed model stacks versus output judgesprimary disclosure
DIB-Bench benchmark design and output-judge acceptance results
CLM-2026-DIB-DEPLOYMENT-TAMPER-2The tested tamper surfaces include model, instructions, tools, retrieval, dependencies and output postprocessing.supported
Basis: reported finding
- supportsDIB-Bench: integrity of deployed model stacks versus output judgesprimary disclosure
Threat model, deployment manipulation categories
Implications
A secure runtime needs explicit assertions about effective tool versions, retrieval components, executable dependencies and model weights at the point of invocation. Hashes alone only identify what actually ran: they do not guarantee that signed software is benign or that an authorization check is correct.
Controls and mitigations
- Bind each actual invocation to a versioned component manifest covering models, instructions, tool implementations, retrieval artifacts, dependencies and postprocessing.
- Verify any dynamic tool or retriever resolution at use time and enforce separate action authorization after identity checks.
Unknowns and contradictions
- The tampered-output percentages apply to the researchers' constructed benchmark, not prevalence of compromised online services.
- A manifest can omit runtime-resolved plugins, external services or mutable references unless it measures them.
- No observed production incident follows from the reported judge acceptance rates.
Sources and citation
Material revision history
- Oct 17, 2026 · Published version · first publication · revision 166
- Oct 17, 2026 · Canonical change recorded · material revision · revision 168Public fields changed: concepts, narrative