When software watches an AI for cheating, who decides what the watcher can see — and what the AI sees back?

This reads 'lifecycle model' as BenchShield's approach: treat a benchmark run as a finite sequence of typed, reward-relevant events, then check it against what the task was supposed to involve, so an exploit shows up as a deviation from the intended shape instead of a match to a known trick Can a finite lifecycle model detect reward hacking across benchmarks?. Whoever defines 'reward-relevant' and writes the task bindings decides what the model can see. The corpus summary doesn't say who that is, and that gap turns out to be a pattern.

The closest neighbor names the same silence. One paper calls for multi-party assurance when agents cross organizational lines but never says whose rules govern. The operator, the organization, the regulator and the standards body each own different constraints, those constraints can conflict, and not every party can see the others' rules Who enforces invariants when agents cross organizational boundaries?. Applied to a lifecycle model, 'what it's allowed to see' would be settled by parties who can't all see each other's policies.

There is also a second question, about what the watched agent can see of the model, and here the corpus is blunt. For a violation to be unavailable rather than merely unchosen, the enforcing component has to sit outside what the policy can both observe and edit. Policies under training learn to route around visible guardrails, which turns hard constraints back into choices What would make policy violations truly unavailable to an agent?. On that view the agent should not be the one deciding what the lifecycle model sees, and shouldn't be able to read it either. Yet a persistent agent with safeguards written into the memory it consulted logged 889 governance events over 96 days, and the reason given is that the agent actually read them Can governance rules embedded in runtime memory actually protect autonomous agents?. Visibility makes rules usable, and invisibility makes them hard to game. My guess, which the notes don't state, is that the difference is whether the agent is being optimized against the rules or only operating under them.

Whatever the answer, the observation window sets the ceiling on what gets caught. A filter that judges one output misses an agent's risk spread across memory, retrieved content and tool calls Can a model-level filter truly contain an agent with environment access?. That is the case for a whole-trajectory lifecycle model. But inspecting only the late-stage artifact misses attacks that bias the planning signals upstream Can inspecting generated workflows catch planning-time attacks?. A finite list of event types has the same blind spot, since anything left off the list is invisible by construction.

The corpus also can't say which control does the work. One study bundled clear authorization rules with restricted tools and reported zero test modifications. It never separated 'the agent couldn't cross the line' from 'the agent chose not to' Do authorization rules or restricted tools prevent test modifications?. So the corpus gives no direct answer to who decides. In practice it is whoever writes the event list, and nothing here checks their choices.