Stronger Judges Do Not See More: Deployment-Integrity Blindness in LLM Evaluation

Jianchang Su; Dawei Xiang; Yifan Zhang; Wei Zhang

cs.CROct 15, 2026

Stronger Judges Do Not See More: Deployment-Integrity Blindness in LLM Evaluation

Authors: Jianchang Su, Dawei Xiang, Yifan Zhang, Wei Zhang

Organizations: University of Connecticut

Abstract

LLM-agent evaluation reports behavioral scores but leaves the identity of the deployed runtime stack unreported. A tampered deployment that preserves evaluated outputs passes every output-only evaluator. We introduce DIB-Bench, a benchmark that measures this deployment-integrity blindness across 7,560 scored examples, six tamper types, and an evaluator ladder from regex scorers through LLM judges to GPT-5-nano. Stronger evaluators accept more tampered outputs: mean acceptance rises from 88.6% (rule-based) to 94.1% (GPT-5-nano), and a trigger-conditional tamper invisible on the evaluation suite produces 48-100% harmful outputs, rising with model capability. A PAC-style bound shows that tampers with zero output shift are undetectable from outputs at any sample size; a manifest-hash identity channel detects them with zero samples. Behavioral fingerprinting identifies the model component above chance (76.7%) but covers one of six stack components. We also propose a graded deployment-identity descriptor for evaluation reports.

Figures & tables

Panel of Figure 1 — Figure 1: Overview of DIB-Bench. (a) A deployment is a stack of six components, each recorded by a content hash in the declared manifest (hash prefixes from the Qwen2.5-7B run). A tamper changes one component (here the system prompt) while preserving the outputs the evaluation suite checks. Output-only evaluators score the outputs and pass the tampered deployment; the identity channel compares manifest hashes and fails it. A deployment that passes behavior and fails identity counts as blind. (b) Mean acceptance of the six tampered conditions (bars) and of the clean deployment (green ticks) across the evaluator ladder ( $n{=}7{,}560$ ). LLM judges accept more tampered outputs than rule-based scoring; the identity channel accepts none.

E2: undeclared-component tampers
Condition	Id. pass	Std	$\Delta$ vs clean
sampling (temp $0\to 0.7$ )	100	93.3	33.3% changed
chat-template injection	100	90.0	77.5% changed
E3: benign declared-component changes
prompt paraphrase	0	100.0	0% changed
dependency patch bump	0	100.0	0% changed

Table 1: Instrument validation (Qwen2.5-7B, seed 42,

n{=}120

each). E2: changing an undeclared component passes identity at 100% while behavior visibly changes, so the 0% identity rate in the main study is not tautological: it reflects manifest coverage. E3: changing a declared component in a semantically benign way fails identity at 0% while behavior is identical to clean, so identity is a change-detection signal, not a semantic-equivalence check.

	Rule-based		LLM judge
Condition	Standard	Strict	Qwen3-8B	GPT-5-nano	Identity	Blindness
clean	97.6	85.4	99.9	99.7	100.0	0.0
model substitution	95.2	72.4	92.9	98.6	0.0	98.6
prompt tamper	95.3	81.9	99.4	99.4	0.0	99.4
tool tamper	92.7	82.9	93.4	95.0	0.0	95.0
retrieval tamper	89.0	67.0	87.7	94.6	0.0	94.6

Table 2: The evaluator ladder on the synthetic suite (

n{=}7{,}560

, 9 runs). Columns represent output-only evaluators of increasing strength and the identity channel. Blindness is the GPT-5-nano acceptance rate under identity failure (= judge acceptance, since identity is 0% for all tampers). Mean tamper acceptance rises from Standard (88.6%) through Qwen3-8B (89.3%) to GPT-5-nano (94.1%): stronger evaluators accept more tampered outputs. The identity channel separates every tamper at 0%.

$\tau$	Standard	Strict	Forensic	Canary
0.70	5/6	4/6	5/6	2/6
0.80	5/6	3/6	5/6	0/6 ×
0.90	4/6	0/6 ×	4/6	0/6 ×
clean acc.	97.6	85.4	96.8	75.9

Table 3: Suite-level blindness

\mathrm{blind}@\tau

: tampered conditions (of six) accepted at threshold

\tau

while identity is 0%, for the four rule-based evaluators. Forensic adds a scan for tamper artifacts (override strings, leaked secrets) to standard scoring; Canary applies strict scoring to canary probes alone. × The same setting also rejects the clean deployment, whose acceptance (%) is in the last row.

Panel of Figure 2 — Figure 2: Standard acceptance (%) by task family and by model pair, pooled over the main study ( $n{=}7{,}560$ ). For tampered rows, acceptance equals blindness because identity is 0%. Model pairs are declared $\to$ deployed; L8B is Llama-3.1-8B and the other models are Qwen2.5. Acceptance drops where the suite probes the behavior that a tamper changes and stays near 100% elsewhere.

Setting	$n$ /cond.	Clean	Tampered
Synthetic suite (main study)	1,080	97.6	88.6
BFCL-simple	600	100.0	99.9
GSM8K	600	27.7	27.6
Qwen3-8B $\rightarrow$ Qwen2.5-7B †	120	100.0	100.0
gpt-oss-20B $\rightarrow$ Qwen2.5-7B †	120	100.0	100.0
AgentDojo banking ‡	16	43.8	50.0

Table 4: Scope and replication. Clean : standard acceptance (%) of the clean deployment. Tampered : mean standard acceptance (%) over the six tampers. Id. : identity pass rate (%) of the tampered deployments. BFCL and GSM8K pool three seeds (Qwen2.5-7B

\rightarrow

1.5B). † Model substitution only. ‡ Native task utility, prompt tamper only.

E4: conditional prompt tamper
Slice	Id.	Match	Harm
ordinary suite	0	100%	13.3%
triggered probes	0	–	81.0%
E8: stealth undeclared tamper
ordinary suite	100	100%	13.3%
triggered probes	100	–	86.2%

Table 5: Stealth tampers (Qwen2.5-7B, seed 42). Id. : identity pass rate. Match : decision-match vs. clean on the ordinary evaluation suite. Harm : triggered harm rate on held-out triggered probes (

n{=}58

). E4 evades output evaluation (100% match) and is caught by identity (0%). E8 evades both channels (identity 100%) by injecting through the undeclared chat template. Both produce

>

80% harm on triggered inputs. The 13.3% harm on the ordinary suite equals the clean baseline.

Panel of Figure 3 — Figure 3: Capability scaling of the trigger-conditional tamper (E4), in %. On the ordinary suite, each tampered deployment matches the clean deployment’s decisions on at least 96.6% of tasks, so every output evaluator accepts it. On held-out triggered probes ( $n{=}58$ ), harm rises with the capability of the deployed model.

Component	Descriptor	Declared $\to$ observed
Model	revision id; tokenizer and chat-template hash	6b171a $\to$ 6b171a	✓
Prompt	hash of the resolved prompt	c23ca1 $\to$ f957c9	$\times$
Tooling	hash of tool specs and router	077a40 $\to$ 077a40	✓
Retrieval	policy hash, corpus snapshot id	cb9f5d $\to$ cb9f5d	✓
Runtime	dependency versions, container digest	2b9d71 $\to$ 2b9d71	✓
Postproc.	hash of the output transform	d728b3 $\to$ d728b3	✓

Table 6: A minimal deployment-identity descriptor, with a worked example: the record DIB-Bench produces for the Qwen2.5-7B prompt-tamper deployment (SHA-256 prefixes). Each component is also reported with how its descriptor was obtained (self-declared, build provenance, or attestation). The single mismatch localizes the tamper to the system prompt. Content-hashing the chat template (row 1) closes the E8 gap from § 6 .

Appendix figures & tables3 assets

Supplementary material from the paper’s appendix.

Appendix

Layer	Borrowed shape	DIB-Bench instantiation	Reported artifact
Task environment	Agent benchmarks define tasks, tools, and adversarial contexts.	DIB-Bench defines factual, policy, tool, secret, and canary task families.	Output text and task metadata.
Deployment condition	Attack benchmarks perturb prompts, tools, users, or retrieval content.	DIB-Bench perturbs one declared runtime component at a time.	Condition label and changed component.
Behavioral scoring	Benchmarks score task success, safety, and robustness.	DIB-Bench reports standard, strict, forensic, and canary output scores.	Output-only pass rates and CIs.
Integrity evidence	Supply-chain systems record provenance and artifact integrity.	DIB-Bench records expected-vs-observed component hashes and traces.	Manifest matches, mismatches, hashes, and traces.
Blindness metric	The bridge: compare behavior acceptance with deployment identity.	DIB-Bench measures output-passing integrity failures.	Example and suite-level blindness.

Appendix

Table 7: DIB-Bench interface: a bridge between agent behavior benchmarks and deployment-identity evidence.

Figure 4: Blindness by (condition, model pair).

Condition	Model	Prompt	Tooling	Retrieval	Runtime	Any
clean	0.0	0.0	0.0	0.0	0.0	0.0
model_substitution	100.0	0.0	0.0	0.0	0.0	100.0
prompt_tamper	0.0	100.0	0.0	0.0	0.0	100.0
tool_tamper	0.0	0.0	100.0	0.0	0.0	100.0
retrieval_tamper	0.0	0.0	0.0	100.0	0.0	100.0
dependency_tamper	0.0	0.0	0.0	0.0	100.0	100.0

Appendix

Table 8: Component-localized identity evidence. Rates are percentages.

LLM Security

Large language model (LLM) security studies attacks, privacy risks, and defenses across model training, inference, and deployment.

See all 327 papers

Who Verifies the Benchmark? Decentralizing Trust in Large Language Model Evaluation
Aug 7, 2026Sahil Pardasani, Madhusudan SinghLLM Evaluation LLM-as-a-Judge
Blockchain Data Intelligence Lab The Pennsylvania State University, 201 Old Main, University Park, 16802, PA, United States of America.
Passing the Test You Trained On: Re-evaluating Prompt-Injection Detectors for LLM Agents
Oct 2, 2026Zhuowen LiuPrompt Injection Detection AI Agent Security Benchmarks
Cybersecurity Lab Japan Advanced Institute of Science and Technology (JAIST) Nomi, Ishikawa, Japan
Who Drifted: the System or the Judge? Anytime-Valid Attribution in LLM Evaluation Pipelines
Jun 13, 2026Yitao LiLLM Evaluation LLM-as-a-Judge

Aug 7, 2026J/K move · Enter open · S save

Who Verifies the Benchmark? Decentralizing Trust in Large Language Model Evaluation

Sahil Pardasani, Madhusudan Singh

Blockchain Data Intelligence Lab The Pennsylvania State University, 201 Old Main, University Park, 16802, PA, United States of America.

LLM Evaluation LLM-as-a-Judge LLM Auditing Language Model Bias Evaluation Bias in LLM-as-a-Judge

Open paper AskPDF arXiv

LLM benchmarks can build an organization's reputation and attract customers, but only when results are transparent and verifiable. Unverified claims that DeepSeek R1 outperformed OpenAI's o1 contributed to market panic on January 27, 2025, when Nvidia lost USD589 billion in market value. Yet vendor benchmarks often depend on an honor system. Academic reassessments and independent leaderboards have found undisclosed changes to proprietary models, contaminated training data, and selective reporting. LLM-as-a-judge methods scale evaluation by reducing human review. Studies, however, suggest that judges may show identity-aware bias, scoring an answer according to its source model rather than its quality. This bias has not been fully measured or corrected across politically sensitive, reasoning-intensive, and preference-based tasks. We examine this problem using seven verifier models: GPT-OSS 120B, Llama 3.3 70B, GLM 5.1, Qwen3 32B, DeepSeek V4 Pro, Mistral Large3, and Sarvam M. They score anonymous and identity-disclosed responses from three primary models on 58 factual, reasoning, political, and preference-based questions. Identity disclosure slightly raises scores for factual questions, moderately affects stress-reasoning tasks, and causes large changes for geopolitically sensitive topics. Notable results include GLM5.1 (+7.00 points, p = 0.0249) and Llama 3.3 70B (+1.56 points, p = 0.00). We also introduce a blockchain-based commit-reveal protocol using Autonomous Economic Agents on an Ethereum-compatible ledger. In Phase 1, each judge records a one-way hash of its score and a secret salt before candidate identities are revealed. In Phase 2, the identity and raw score are disclosed and verified on-chain. This creates a tamper-evident audit trail that separates blind evaluation from post-hoc claims and reduces the verification burden on independent researchers and leaderboard operators.

Abstract

LLM Security

Explore similar work

Who Verifies the Benchmark? Decentralizing Trust in Large Language Model Evaluation

Passing the Test You Trained On: Re-evaluating Prompt-Injection Detectors for LLM Agents

Who Drifted: the System or the Judge? Anytime-Valid Attribution in LLM Evaluation Pipelines