A benchmark for what happens when a model receives conflicting instructions from different priority levels, built from a human-authored taxonomy of 44 constraint families across generic, health, finance, retail and coding settings. Across 37 evaluated models, hierarchy compliance ranges from 98.2% to 20.5%. The authors report that strong system-over-user compliance is not a reliable proxy for user-over-tool robustness: several models hold system constraints under direct user conflict but degrade sharply when the conflicting instruction arrives inside a tool output.
An agent reads a support ticket, the ticket body contains instructions, and the agent follows them. Everyone knows to test that. The version people miss is the tool output: the agent calls a search API, the retrieved page says "ignore previous instructions", and the instruction arrives wearing the same clothes as the data it was asked to fetch.
IH-Benchmark separates those two surfaces and scores them separately.
Compliance across 37 models runs from 98.2% down to 20.5%. That range is the whole argument. Two models with identical scores on a generic safety eval can sit 70 points apart here, and the gap only opens on the tool-mediated case.
The authors also report that the failures worth finding are subtle rather than dramatic. Models resist unauthorised purchases more reliably than they resist injected disclaimers or small factual distortions. A red-team suite built out of spectacular attacks will pass a system that quietly rewrites a number.
Score the model you are about to ship, not the family it belongs to. Test the tool-output path explicitly and separately. And treat constraint hardening as a probe rather than a fix — the paper finds some models improve with stronger warnings and others do not move at all, so "we added a stricter system prompt" is not evidence of anything.
@article{mccauley2026ihbenchmark,
author = {Conor McCauley and Zeliang Kan and Jason Martin},
title = {IH-Benchmark: A Conflict-Centered Benchmark for Instruction-Hierarchy Robustness in LLM Applications},
year = {2026},
eprint = {2607.25987},
archivePrefix = {arXiv},
url = {https://arxiv.org/abs/2607.25987}
}Ejentic did not author this paper. Credit belongs to the authors named above; the note is ours.
2026
Directly relevant to anyone bolting retrieval onto a model and assuming the citations are the safety mechanism. Adding a fake citation to a true claim made models worse, not better. Grounding that is not verified is worse than no grounding at all, because it arrives with the confidence of evidence.
2026
When a provider is bimodal, the mean is a fiction. Report the modes and the condition that separates them, or you will architect against noise.
2026
Verify with a behaviour only the new code can produce. If you cannot name one, you have not designed a verifiable change.