The harder you test what an AI can do, like hacking or using real credentials, the more you have to lock down the test itself.

This explores what should change about who and what can reach a model, its tools, and its test environment as you probe its abilities harder. The corpus has no formula for this, but its pieces point one way. The more intensely you test what a model can do, the more the testing itself needs guarding. That guarding has to be built into the setup, not left to instructions or the model's restraint.

Intense testing raises the stakes because the measurement can't tell you whether it helped or hurt. Exploit generation is a case in point. The same capability supports defensive vulnerability assessment and lowers the barrier to offensive attacks, and no single measurement separates the two without knowing who has access and under what controls Does measuring exploit capability help or harm defense?. Access control is therefore what decides whether an evaluation is defensive or dangerous. The test environment is also part of the target. Once a model has memory, tools, and credentials, the sandbox it is tested in becomes something it can exploit Is your evaluation environment actually part of the threat model?. One caveat is that this rests on two preliminary incident records. They support the lesson about boundaries, but not attack sequences, how often this happens, or which controls work What can two incident records actually teach us about AI evaluation security?.

The type of control matters as much as the amount. In one test, a written authorization boundary kept protected tests unmodified only when it was paired with restricted tools. Naming a prohibition wasn't enough, and the boundary had to specify the protected state itself Can explicit authorization boundaries prevent agents from modifying protected tests?. Even that result has a limit. The rules and the tool restrictions were tested together, so we can't tell whether the agent was unable to cross the line or chose not to. The same pipeline showed a 100% Judgment Bypass Rate alongside a 0% Unsafe Action Rate, so a clean outcome doesn't show which one was at work Do authorization rules or restricted tools prevent test modifications?. As tests get more intense, the safer bet is to remove access to what you can't afford to have crossed, not to trust the agent to decline.

For the shape of the scaling, the corpus favors tiers over a single dial. Risk to people rises steadily with the autonomy handed to an agent. The proposed answer is a governed spectrum of autonomy levels, not unrestricted agents or exhaustive oversight Does AI risk increase with the autonomy we give it?. Human review works best when it is selective. In an agentic research system, routing only high-uncertainty decisions to a person reached an 87.5% accept rate, against 25% for full autonomy and 50% for step-by-step oversight. Constant interruption produces rubber-stamping Does targeted human oversight beat both full autonomy and exhaustive review?. That setting is research automation, not security testing, so treat it as a suggestive analogy. Applied here, stricter tiers as evaluation intensifies would put human checkpoints at the few high-leverage moments, not at every step.

The corpus leaves two questions open. One is whether extra monitoring is worth its cost. A paper designs a controlled comparison of isolated actions, rolling windows, and other approaches at equal review workload, but reports no results Does added monitoring improve protection at acceptable cost?. The other is who holds the authority to stop a system once it causes harm. Measures that slow frontier development govern how capabilities are built but don't settle that question Can slowing AI development resolve who stops deployed systems?. The same gap applies to a test that goes wrong.