A suspended user's agent run still wrote a file: an internal pilot

By Scopehaven · Published October 23, 2026

Many permission checks happen when a request arrives. AI agents keep working after that: a run can call tools, wait for an approval and write data well after it started. In an internal pilot, that gap showed up as a file written after the user who started the run had been suspended.

The finding: in an internal pilot using Scopehaven's approach, with synthetic data, new requests from a suspended test user were correctly refused, but in 2 of 14 test cases an agent run started before the suspension still wrote a file afterward.

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.

Looking only at new requests, the suspension worked. The file on disk said otherwise. That gap is why, in this pilot, we read the file on disk, not the response to the next request.

This section describes a general pattern in agent systems, not that project's code. A web request is usually authorized once, when it arrives, and finishes in a moment. An agent run is different: it can keep working for seconds or minutes, calling tools, waiting for an approval or resuming from a queue. Each of those steps can act on permissions that were checked earlier.

The usual remedy is to check the user's current access again right before each action takes effect, not only when the run starts. Whether that holds is something to test, not assume.

In each case it is natural to check that the user can no longer do anything new. The question that is easy to miss is what work already in flight does next.

The full guide to testing access removal →

How to prove a repair held without breaking normal use →

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. Runs and evidence stay on your machine; the workbench does not upload them to Scopehaven.

Our synthetic demo suite includes a matching check, MIDTASK-01: access removed mid-task stops the pending action.

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.

We're not naming the project. The same kind of gap can occur in other agent systems, and the steps above are one way to check yours.

No. We measured one behaviour in one pinned version against our own expectation for agent runs: suspending a user should stop actions already in flight. It is not a claim about the project's current release.

It was a partial, local repair. The same 14 checks then passed, including the ones confirming that normal use still works. We verified it only on the file-write path we tested.

We tested one self-hosted app on our own machine; this note does not cover hosted assistants.

Tell us what your agent does and one thing it must never do. Together, we can scope the first checks on a local copy of your app.