Scopehaven
Request a first test
FIX VERIFICATION GUIDE
How to prove an AI agent security fix worked without breaking legitimate requests
A security fix for an AI agent can fail in two ways: the forbidden action still happens, or the fix blocks work that should be allowed. The second often looks like success, because a check that only asks "was it refused?" passes when everything is refused. Proving a fix means showing both that the failure is gone and that normal use still works, on a comparable run.
Short answer: before the fix, record the failing check together with the allowed-use controls next to it. After the fix, rerun the same checks with the same identities, data and rules on the patched build. Call the failure repaired only when the check now passes, every allowed-use control still passes, and nothing else newly fails.
This guide is for engineers fixing a permission failure in an agent that reads customer data or takes actions. It covers a test environment you are authorized to use. For retesting on every model, prompt or tool change, see the release checklist.
01 / BEFORE
Capture the failure before you change anything.
- The failing check. The rule, the test user, the request and what happened.
- The evidence. The record that showed the failure, such as the row written, the message sent or the record returned.
- The setup. Build, configuration, model, prompt and tool versions, and the synthetic data used.
Keep this run. It is the "before" that the fix will be compared against, and it shows the check can fail. A check that never fails cannot show that a fix worked.
02 / CONTROLS
Write down the requests the fix must not break.
Write the allowed-use controls before the fix exists, so they describe the product rather than the patch. Each one is a request close to the failing one that the rule says must still work.
| Failure | A fix that blocks too much | Allowed-use control that catches it |
|---|---|---|
| The agent returns another customer's record. | Record lookup is switched off for everyone. | The same user still gets their own record. |
| A member can issue refunds. | The refund tool is removed for every role. | An administrator's refund still goes through once. |
| A suspended user's run keeps writing. | Every in-flight run is cancelled on any access change. | Runs for users whose access did not change still finish. |
| Planted text triggers an export. | Exports are disabled. | A user who may export, and asks to, still gets the export. |
| The agent reports refunds it never issued. | The agent stops confirming any refund. | A refund that did happen is still reported correctly. |
03 / RERUN
Rerun the same checks and compare like with like.
Run the failing check, its allowed-use controls and the rest of the suite on the patched build, with the same test users, customer accounts, data and rules. A before-and-after comparison means something only when those are the same. If any of them changed, record it and treat the new run as a new baseline rather than as proof of a repair.
Model output varies between runs. For checks that depend on it, run each one several times on both builds and compare how often it failed, not a single result.
04 / READ
What the before and after can show.
| After the fix | Reading |
|---|---|
| The check passes, every allowed-use control passes, nothing else newly fails. | Repaired, for what you tested. |
| The check passes, but an allowed-use control fails. | Not repaired. The fix blocks normal work. |
| The check passes, but another check newly fails. | Not repaired. The fix moved the problem. |
| The check still fails. | Not repaired. |
| The check is inconclusive. | Not shown either way. Get the evidence the check needs. |
| The checks, rules, identities or data changed. | Not comparable. Treat the run as a new baseline. |
A failed check counts as repaired only when the fixed build passes it and every check for normal, permitted use still passes.
05 / EXAMPLE
An example from our own pilot.
In an internal pilot, we used Scopehaven's approach on a pinned version of an open-source AI workspace on our own machine, with its real server, a local model and synthetic data. We suspended a test user. New requests from that user were correctly refused, but in 2 of 14 test cases an agent run started before the suspension still wrote a file afterward. We made a partial, local repair, and the same 14 checks then passed, including the ones confirming that normal use still works. We verified the repair only on the file-write path we tested; other tools and full session termination were not tested.
We're not naming the project. This is one finding in one pinned version, reproduced and partly repaired on our machine with synthetic data. It is not a safety certification or a claim about the project's current release.
Where Scopehaven fits
Scopehaven is a local assessment workbench for testing the permissions you define, on the actions you check, and rerunning the same checks to show whether a fix held, including the actions that should still work. Scopehaven runs allowed-use controls alongside forbidden checks, so a fix that over-blocks a covered workflow fails instead of passing. A run is never labelled fixed when the run, suite, policy or evaluator identities are incompatible.
On your own app, what a run can establish depends on the connection and the evidence available. Scopehaven does not certify your application or guarantee it is free from vulnerabilities.
Common questions
Isn't a passing test after the fix enough?
Not on its own. A fix that disables the whole feature also passes. The allowed-use controls are what tell a repair apart from an outage.
Should I change the failing check to match the fix?
No. Keep the original check unchanged so before and after compare. Add new checks for nearby paths the fix might have missed, and record them as new coverage.
How many times should I rerun?
Once per build for code paths that always behave the same. For checks that depend on model output, run each several times on both builds and compare how often it failed.
Who should verify the fix?
Ideally someone other than its author, using the recorded checks rather than a new manual test.