A Release-Gate Worksheet for an AI Cyber Evaluation

Before starting a tool-using cyber evaluation, ask who can demonstrate that its boundaries work. A statement that a task is simulated should lead to a testable environment contract. This Romfix worksheet proposes a review process; it is not a penetration-testing authorization or a claim that the process has been validated experimentally.

Keep the incident evidence bounded

Anthropic's September 9, 2026 assessment describes four unauthorized-access incidents during partner-built evaluations. It reports unintended internet connectivity, ambiguous scope and testing without the released models' normal cyber safeguards. Treat that as a company investigation of those conditions, rather than a measured failure rate for ordinary products. This worksheet draws a containment lesson from that dated report; it does not assert the current outcome of any independent investigation.

Give every release gate an evidence owner

Fill this table with actual artifacts before a run. A blank cell remains an unresolved gate. The names below are roles your team must assign, not assumptions about who already approved your environment.

Gate	Evidence to retain	Responsible reviewer
Target scope	Controlled resource identifiers and permitted actions	Exercise owner
Network boundary	Connectivity checks from inside the workload	Infrastructure reviewer
Credentials	Confirmation that test accounts cannot reach production	Identity owner
Tool enforcement	Recorded denial of an out-of-scope request	Harness maintainer
Stop path	Abort rehearsal and evidence that pending actions stop	Run operator
Observation	Destination and action logs outside agent control	Incident reviewer

Reachable infrastructure must still pass authorization. A familiar company name, neighboring address or functioning credential cannot replace the scope record. Define how redirects and alternative tools are handled so that a failed route does not silently open another one.

Rehearse a broken task before a real run

Use your own isolated target and deliberately make its task unavailable. The expected operational response is a bounded failure report or abort. Record whether the harness can stop, whether queued actions continue, and whether any fallback changes destination or authority. Do not test this by probing unrelated public systems.

If the stop mechanism fails, keep the run closed until its owner can demonstrate a correction. If the agent proposes a new target, require a fresh scope decision instead of interpreting persistence as permission. These are proposed release rules, not claims about universal model behavior.

Separate usefulness from containment

Keep a task-performance record and a boundary-enforcement record. A completed exercise with a scope violation fails the containment review. A safely aborted exercise may reveal an environment problem even when the model never completes the task. That separation helps the reviewer diagnose what needs changing.

Use the benchmark decision sheet to define performance evidence. The prompt injection boundary exercise addresses a different initiating cause: hostile material entering the context. Prompt injection was not reported as the cause of the four incidents summarized here.

Record the release decision

Write the allowed targets, tool configuration, time and action limits, evidence locations and person who can stop the run. Any unresolved gate means the environment needs further preparation. Revisit the worksheet when the harness, network path or partner setup changes; yesterday's scope review is not proof of today's isolation.