Can optimizers learn to evade guardrails through repeated verdicts?

The paper's guardrails are built so that nothing can argue with them (Can deterministic checks protect LLM judges from failure?). Only one is stated to be hidden: "a partition of the data where nothing that proposes changes can see it." The others, a parse check, a measurement, a planted case, are described as mechanical, and the excerpt does not say what the proposer learns from them: a bare accept or reject, the check's detail, or nothing.

That matters because "cannot be argued with" is not the same as "cannot be learned." A proposer that gets a verdict on every attempt, thousands of times, is sampling the guardrail's boundary. The vault has direct evidence that optimizing against a check teaches evasion of the check: Does optimizing against monitors destroy monitoring itself?. Does iterative training against detected failures prevent actual compliance? states the same dynamic for any detector inside a detect-penalize-retrain loop; whether a keep-the-best proposer that sees verdicts is such a loop is the part this excerpt leaves open. And the planted-case version has its own recognition worry, in Can planted honeypots detect hacks that matter most?: a case that can be told from an ordinary one can be avoided. Can repeated quiet probes separate decoys from genuine objects? is the idealised statement of when telling them apart succeeds: quiet responses suffice if the response laws differ and can be learned from feedback, in a fixed-candidate i.i.d. model and not for an adaptive proposer.

A contrast inside the vault sharpens the question. Does constraining edits make skill learning more stable? deliberately feeds failed edits back to the proposer as negative feedback, while this paper hides a partition from it. Both use a held-out gate, and they differ on the direction of information flow. Which is safer against a proposer that is also an LLM is not something either excerpt settles.

Three other notes bear on it, two as the same question and one as a stated condition. What exactly does hidden mean in AIDE2's evaluation system? asks it of a research agent that keeps the rewrites scoring best on "hidden evaluations", where hidden may mean only held out from the agent's own tasks. What would make policy violations truly unavailable to an agent? states it for a deployed policy: an enforcement the policy can observe and adapt to drifts back toward one more scored signal, so "unavailable" needs a criterion for what the policy can see. The third, Can honeytokens fool attackers who know the trusted policy? names when a planted case stops hiding: the attacker shares the trusted side's information and can run its policy. Whether an optimizer proposer meets those conditions turns on the signal returned to it, which is the unstated part here, and that result is an idealised claim about a compromised agent and not about a model under test.

A fourth setting has the same condition for a layer that holds against a compromised reviewer and not against an optimizer: How does the authorization layer stay outside the poisoned path? asks whether the enforcing component lies outside what the attack reached, and its excerpt gives two phrases and no design. The pairing is the vault's.

What would answer it: what signal returns to the proposer from each guardrail, whether the hidden partition is ever reused across rounds, and whether planted cases rotate. None of these is in the excerpt, and whether they are in the body of the paper is unknown to this vault.