Telling an AI "don't touch that" isn't a defense — so how do you check a safety rule actually protects something?

This explores how to test whether a trust boundary really specifies the defense, meaning it pins down the protected thing and stops crossings, instead of only stating a prohibition. The corpus has no single standard protocol for this. But several notes, read together, give a workable checklist.

The first test is whether the boundary names the protected state itself. In one experiment, explicit authorization rules kept protected tests unmodified only when paired with restricted tools. Naming a prohibition was not enough, and the boundary had to specify the protected state (Can explicit authorization boundaries prevent agents from modifying protected tests?). So ask what exactly is protected, and whether a concrete mechanism enforces it or only a sentence in the prompt.

The second test is whether you can tell why the boundary held. The paper bundles clear rules with restricted tools and reports zero modifications. It runs no single-factor ablation, so we can't tell whether the agent was unable to cross, chose not to, or both (Do authorization rules or restricted tools prevent test modifications?). Its own numbers show why this matters: a 100% Judgment Bypass Rate sat alongside a 0% Unsafe Action Rate. A clean safety outcome can hide the fact that the agent's judgment failed and the tool restriction did the real work. To evaluate a check, remove each component in turn and see which one carries the defense.

The third test is whether the check is evaluated at the right level and against an adaptive attacker. Scanners that score skills one at a time can be beaten by an attacker who refines each piece against the scanner's feedback while the harmful chain stays intact, reaching 96% average attack success (Can attackers evade skill scanners by refining individual skills?). Inspecting whole chains helps, but ChainGuard still let 22.5% of attacks through while passing 99.5% of benign workflows (Does chain-level inspection close the cross-skill attack blind spot?). That pairing of residual attack rate and benign pass rate is a reasonable way to report any boundary. Where the check sits also matters. Validating the assembled workflow at the irreversible commit point sees risk that no single step holds, and it complements planning-time and per-hop checks (Where should workflow validation gates be placed for safety?). A related warning comes from honeytokens: if the attacker knows the rule trusted agents use to spot decoys, they can apply the same rule, so a boundary's distinguishing logic should be tested assuming the attacker has read it (Can honeytokens fool attackers who know the trusted policy?).

The fourth test is what counts as evidence. Don't let the model's own account settle it. Injected plans can steer reasoning models and slip past chain-of-thought monitors 25 to 33 percent of the time, because the model paraphrases the plan as its own reasoning (Can reasoning models be steered by injected context without detection?). Better evidence is mechanical. Order unarguable checks before contestable ones, measure against human labels, hide test data from proposers, and plant known cases as alarms (Can deterministic checks protect LLM judges from failure?). A planted protected item that the boundary fails to flag tells you more than any self-report. Recorded infrastructure evidence can back a claim about what actually happened (Can infrastructure evidence replace terminal scores in benchmark validation?). Scoped audit agents with a fixed remit and required evidence citations can handle the arguable step that follows, though their reliability is still unquantified (Can scoped agents reliably judge semantic hacks in runtime analysis?).