Persistence and cleanup verification
Verify that finished agent sessions leave no unintended reusable state
Workers, browser profiles or storage volumes are reused between tasks. The decision is how to verify that finished agent sessions leave no unintended reusable state. The work begins with your actual workflow and looks for the evidence that separates intended behaviour from a consequential exception. It is particularly relevant to platform operations and privacy engineering owners. A useful outcome is an explicit account of what was examined, what remains uncertain, and which decision the evidence can support.
The runtime isolation relationship
- Session lifecycle events
Establish the basis for session markers.
- Termination modes
Compare success, error, and forced cancellation.
- Persistence
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around session markers
Questions and the evidence they need
- Session markers
- Inspect session lifecycle events for the relevant constraint or observation.
- Termination modes
- Inspect volume policies for the relevant constraint or observation.
- Reuse check
- Inspect artefact lists for the relevant constraint or observation.
The decision is how to verify that finished agent sessions leave no unintended reusable state. This is relevant to platform operations and privacy engineering owners when workers, browser profiles or storage volumes are reused between tasks. Name the affected workflow, the consequence of a wrong decision, and the owner who can act on the result. The initial discussion should establish which evidence is already available and which uncertainty is material enough to investigate.
The specific failure hypothesis is that a later session receives files, cookies or process state from an earlier one. It remains a hypothesis until examined in the deployment. Existing internal tests or operating records may already resolve it; identify the uncovered question before commissioning additional work.
Mechanism
Cleanup must cover failure and worker reuse
Relationships within runtime isolation
- Session markers
- Track state in approved files and caches.
- Termination modes
- Compare success, error, and forced cancellation.
- Reuse check
- Inspect whether a later task can recover prior state.
What this specialty examines
Cleanup verification should inventory every state location that can outlive a task. Include files, processes, browser profiles, caches, credentials and exported artefacts as applicable. Define which state is intentionally retained and which must be removed before reuse.
The review should plant harmless markers in approved state locations and verify cleanup after success, failure and forced termination. Identify the normal route, relevant exceptions and the authoritative record of the outcome. Inspect the relevant business-system record, enforcement event or process evidence alongside any reported status. Keep incomplete cases visible, with an explanation of what their absence prevents the owner from concluding.
The tradeoff to make explicit
For this decision, reuse improves startup efficiency while cleanup must handle abnormal termination. Compare the available design or operating choices against the same intended outcome. If one option removes a required control or changes the task boundary, describe that difference before treating its apparent simplicity, speed or lower effort as an improvement. The decision should expose the tradeoff instead of burying it in an aggregate score.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for session markers
Illustrative working format
- Session lifecycle events
- Retain the observed conditions and distinguish gaps from contrary evidence.
- Volume policies
- Confirm the applicable revision and who resolves disputed interpretation.
- Artefact lists
- Name the custodian and the conditions requiring a refreshed version.
- Synthetic state markers
- Keep expected behaviour and the limits of the constructed example explicit.
Start with session lifecycle events, volume policies, artefact lists and synthetic state markers. Identify the owner, revision and operating context of each source. Sanitised examples may support initial design, but differences from actual conditions should remain explicit. Where direct access is unsuitable, a customer-controlled evidence or execution route may be considered, with agreed handling and retention.
The scope also needs the runtime owner, agreed expectations for a representative boundary test, and the authority to inspect the relevant boundary. Specify what evidence would distinguish the failure in which a later session receives files, cookies or process state from an earlier one from acceptable behaviour. If stakeholders disagree about intended behaviour, resolve the interpretation before classifying the observed difference as a defect.
How the work proceeds
Carry session markers through to an accountable finding
From the scoped material to a decision record
- Session lifecycle events
Declare the permitted environment and resources.
- Termination modes
Apply the scoped check to reuse check.
- Persistence
Record the evidence, open dependencies, and the owner’s next decision.
Prepare the runtime boundary and fixtures
Use session lifecycle events, volume policies, artefact lists and synthetic state markers to identify the exact runtime and boundary claimed by platform operations and privacy engineering owners. Mark permitted resources and protected resources in a controlled fixture, including shared services where they are relevant. Define observable success, denial and incomplete setup before execution. The preparation output is a boundary map and fixture manifest that lets reviewers distinguish effective isolation from a test that never reached its target.
Exercise and inspect the boundary
Exercise normal completion, application failure and forced termination. Cleanup that runs only after a successful exit may miss the most important conditions. Use synthetic markers and inspect the next session rather than relying solely on a cleanup success message.
Choose containment or configuration changes
Translate the observations into a persistence and cleanup report with state-location coverage. Locate each issue in the worker, shared service, policy rollout or cleanup path rather than attributing every symptom to the sandbox as a whole. Decide which configuration change, narrower resource exposure or specialist investigation is warranted. Retest the affected boundary and inspect residual state before treating the changed environment as equivalent to the intended design.
Indicative artefact
Make the persistence usable by its owner
Persistence
Illustrative working format
- Persistence
- Identify the assessed workflow, revision, and decision boundary.
- State-location coverage
- Retain selection rationale, accepted alternatives, and unexamined task conditions.
- Termination modes evidence
- Link observations and counterevidence to the case, configuration, and conclusion limit.
A useful decision artefact is a persistence and cleanup report with state-location coverage. Supporting material may include selected cases, configuration or process records, evidence references, a disagreement log and prioritised actions. Retain the case selection rationale and material disagreements alongside the result; otherwise the result may be mistaken for complete coverage.
Illustrative scenario
Examine reuse check through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- Session markers
A cancelled session leaves a synthetic marker for the next worker assignment.
- Termination modes
Inspect marker state after forced cancellation and worker reassignment.
- Reuse check
Keep cleanup incomplete when later work can recover the earlier marker.
Consider a fictional situation: a failed browser session is returned to a worker pool with a previous test user’s authenticated cookies. The scenario is illustrative, with no client engagement, executed test or measured improvement implied.
For the failed browser session, begin a separate synthetic task and check whether earlier cookies remain usable. A worker should not return to the pool until its defined reset evidence is satisfied. Quarantine may be appropriate when cleanup is uncertain.
Scope and next action
Keep the conclusion within the authorised runtime boundary
Confirm fit before the next commitment
- Session markers
- This review is limited to the authorised runtime boundary.
- Session lifecycle events
- The relevant owner must confirm access and the intended operating conditions.
- Persistence
- Untested surfaces remain outside the conclusion.
Testing is confined to explicitly authorised environments and non-destructive cases. A bounded assessment cannot establish that escape or cross-boundary access is impossible. Any engagement depends on an agreed scope, qualified team, authorised access and confirmed availability. Bring the affected workflow, its current configuration or process, the triggering change and the evidence already available. The immediate scope question is prompted by the situation in which workers, browser profiles or storage volumes are reused between tasks; confirm which missing observation would change the owner’s next action.
Ways to engage
Related engagement scopes
AI Agent Runtime Security Review
Make every delegation explicit. Examine who the agent acts for, where it can execute and which tools it can reach when instructions alone are not enough.
AI Agent Red Team
Challenge the boundaries that matter to your workflow. Test agreed attack scenarios against agent instructions, tools and data access.
AI Agent Sandbox Assurance
Examine the boundary between agent execution and the systems around it, including files, networks, secrets and cleanup.
Continue exploring
Related insights and resources
The permission boundary behind every agent action
An agent can only be evaluated in the context of what its tools allow. Examine identity, delegated authority and action boundaries before you put a workflow in motion.
Before your agent can act, define its authority
A working paper for the moment an AI system moves from advice to action. Map identity, permissions, approvals and recovery into an authority model your team can review and test.
Computer-use agents bring the interface back into the threat model
A computer-use agent treats pixels, accessibility data and interface state as both evidence and an action surface. Security must bind intent to effects beyond the screen.