Case · 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.

Scope

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.

At a glance

Mechanism and trust boundary

  1. 01

    Step

  2. 02

    Step

  3. 03

    Step

  4. 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

Link to claim
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

Link to claim
CLM-2026-DIB-DEPLOYMENT-TAMPER-2The tested tamper surfaces include model, instructions, tools, retrieval, dependencies and output postprocessing.supported

Basis: reported finding

Link to claim

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

  1. Oct 17, 2026 · Published version · first publication · revision 166
  2. Oct 17, 2026 · Canonical change recorded · material revision · revision 168Public fields changed: concepts, narrative