From the Research Universities edition of October 16, 2026
DIB-Bench preprint: output-only evaluators, including stronger LLM judges, accept up to 94% of tampered agent deployments; component hashes catch declared changes
Jianchang Su, Dawei Xiang, Yifan Zhang and Wei Zhang (arXiv preprint; affiliations not recorded in this inspection) · Evaluation methodology and reproducibility for LLM agents · Not stated in inspected text; applies to any institution publishing or relying on agent evaluations
- Publisher
- arXiv
- Original publication
- arXiv preprint 2610.21135v1, submitted 15 October 2026
- Source retrieved
- 2026-10-17
What happened
DIB-Bench measures whether evaluators notice when a deployed LLM agent's runtime stack (model artifacts, tokenizer, system prompt, tool specifications, retrieval data, runtime software) differs from the evaluated one. Across 7,560 scored examples, six tamper types and an evaluator ladder from regex scorers through LLM judges to GPT-5-nano, stronger evaluators accepted more tampered outputs: mean acceptance rose from 88.6% (rule-based) to 94.1% (GPT-5-nano). A trigger-conditional tamper that is invisible on the evaluation suite produced 48-100% harmful outputs, rising with model capability. The authors give a PAC-style argument that tampers with zero output shift cannot be detected from outputs at any sample size, while a manifest-hash identity check detected declared component changes with zero samples. Behavioural fingerprinting identified the model component above chance (76.7%) but covers one of six components. They propose a graded deployment-identity descriptor for evaluation reports.
Why it matters
University labs increasingly publish agent benchmark results and research offices increasingly accept vendor evaluations. This preprint shows a score cannot tell you which system produced it: a changed prompt, tool or model can pass. For research reproducibility, evaluation reports need a record of the exact stack, the same way methods sections record software versions.
Evidence and measured results
Benchmark of 7,560 scored examples, six tamper types, evaluator ladder; acceptance rates 88.6% and 94.1%; trigger-conditional tamper 48-100% harmful outputs; fingerprinting 76.7%; formal bound plus manifest-hash comparison.
Limitations and uncertainty
Synthetic, single-component tampering; small to mid-size models; no hardware attestation; preprint.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-16; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Institutions rely on agent evaluation scores without any evidence that the evaluated system is the one deployed or described in a paper.
- Stakeholders
- Research integrity officer
- CIO or research computing director
- AI tool procurement lead
- Faculty publishing agent benchmarks
- Discovery questions
- Do current evaluation reports record exact model, prompt, tool and data versions?
- Do vendor contracts require notice when an AI tool's stack changes?
- Who checks that a deployed research agent matches its evaluated version?
- Value hypothesis
- Interpretation: recording stack manifests with evaluations may make agent-assisted results more reproducible and make silent changes detectable.
- Potential engagement
- A short review of evaluation and deployment records for research AI tools, with a manifest template and procurement language.
- Unsupported claims
- Protection against forged manifests or undeclared components
- Detection of multi-component attacks
- Results at frontier-model scale
- That a passing hash means the system is safe or correct
Pre-sales engineering
Role takeaway
- Fit
- Relevant wherever agents are evaluated and then deployed for research tasks.
- Architecture and integration
- Generate hashes for each stack component at evaluation; store with results; re-check at deployment and on updates; include a deployment-identity descriptor in reports.
- Prerequisites
- Inventory of agent stack components
- Artifact storage for manifests
- CI or deployment hooks
- Constraints
- Covers declared components only
- No hardware-rooted attestation
- Tested on synthetic tasks and 1.5B-20B models
- Security
- Protect manifests from tampering (signing, restricted write access) and alert on mismatches.
- Proof of value
- Inject a single-component change and confirm manifest check fails while output score passes
- Measure share of stack components covered
- Verify mismatch alerts reach owners
Delivery
Role takeaway
- Work
- Add manifest generation and checks to evaluation and deployment pipelines and publish a reporting template.
- Dependencies
- Research computing pipelines
- Vendor disclosure of stack components
- Research integrity policy
- Ownership
- Research computing owns tooling; research integrity office owns reporting requirements.
- Skills and adoption
- Train research software engineers and faculty on recording evaluation provenance.
- Governance checkpoints
- Template approved by research integrity office
- Procurement clause reviewed by legal
- Periodic audit of manifest coverage
- Acceptance criteria
- Proposal: manifests recorded for every published agent evaluation
- Proposal: injected test changes detected
- Proposal: vendor change notices received for contracted tools
- Risks
- Undeclared components escape checks
- Manifests forged
- False sense of safety from hash matches
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Agent deployments used in research should emit a manifest with hashes of model weights, tokenizer, prompts, tool specs, retrieval indexes and runtime packages, stored with evaluation results.
Governance
Who approves, reviews and stays accountable for outcomes?
Research offices and journals reviewing AI-assisted results could require a deployment-identity descriptor alongside scores, and procurement could require vendors to supply one.
Security and privacy
What data, permissions and controls need testing?
Shows trigger-conditional tampering can hide harmful behaviour from evaluations; manifest hashes help only for declared components and need protection against forgery.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Research software engineers need to treat evaluation provenance as part of reproducibility training.
Procurement
What should contracts, pricing and exit terms secure?
Contracts for AI research tools could require stack manifests and change notification so that a vendor update does not silently invalidate prior evaluation.
Operating model
Which teams own the service once it runs?
Evaluation becomes a continuing check tied to deployment identity, not a one-time score.
Publication history
- 2026-10-16Research Universities · Issue 385 resources
Stable resource ID: dib-bench-deployment-integrity-blindness-llm-evaluation-20261015