Govern computer-use applications

Use the same policy and review requirements whether an application acts through an API, a browser, or both. The customer application handles navigation, credentials, saved checkpoints, and changes to external systems. VeriProof records the policy, review, and evidence for those actions.

1. Define the protected action

Choose one business action whose completion matters. Record:

• the application and accountable owner;
• the approved execution channels;
• the policy decision required before commitment;
• the reviewer and permitted decisions;
• the source that can confirm the final business result;
• the evidence and privacy boundary.

Use Application > Config to select the execution channels. The declaration sets the approved path. Runtime evidence records the observed path so reviewers can compare the two.

2. Set the capture policy

Enable Screen capture evidence in Application Config. Choose only the moments needed for governance, such as before the action, during review, after the action, or when the workflow cannot continue.

Set masking selectors and capture limits for the application. Keep password masking enabled. Require verified masking when the workflow handles sensitive content. A capture shows what the browser displayed; it does not confirm the business outcome.

3. Send sessions through Ingest

Create the session through the Ingest API. Do not create a separate portal-only record for testing. Use the application key assigned to the application.

For each selected capture moment:

1. Capture the browser viewport in the customer-owned harness.
2. Mask protected fields before upload.
3. Upload the image through the Ingest attachment path.
4. Include the returned attachment reference with the relevant session step.
5. Send the observed execution channel and capture metadata with that step.

Captures for MCP-created sessions

For an evaluated MCP action, retain each staged capture through POST /v1/ingest/sessions/{sessionId}/actions/{sequence}/captures before calling record_computer_action. Send the capture reference metadata with the same application credential used for upload. Use the returned attachmentId in attachmentReferenceIds, not the temporary upload refId.

The binding checks the application, session, evaluated action, sequence, and capture policy. An exact retry returns the same retained attachment ID. MCP does not receive image bytes. Complete the session after recording the action.

In the portal, open Timeline and select a capture to enlarge it. A completed browser action does not mean that the underlying business request was approved.

The TypeScript Playwright harness is the tested reference path. Keep browser navigation and credentials in customer-owned code.

4. Protect review and restart

Request policy evaluation before the protected action. When review is required, pause the application at a durable checkpoint. Bind the request to the current action state and authorized reviewer.

When work resumes:

• reject an approval for stale state;
• reuse the recorded checkpoint after restart;
• use the action idempotency key for every retry;
• report the final application result through Ingest.

Test these checks with delayed approvals and repeated callbacks. Confirm that stale state is rejected and retries do not repeat the business action.

5. Verify the business outcome

After the application acts, query an authoritative business source. Examples include the destination API, transaction record, order system, or approved database. Record the verification result as a separate step.

Check the authoritative source even when the browser shows success. A changed button or redirect provides context, not proof of the final result. Record an unavailable verification result as unavailable; do not infer success from the screen.

6. Review captures in Flow View

Open the session in Time Machine and select Flow. A capture indicator marks steps with available visual evidence. Select the step to review its captures. Use Screen captures to open the session gallery, then select any image for a larger view.

Check the capture moment, time, step, masking status, and related policy or review event. Compare the image with the verified-outcome step when the screen and business result differ.

7. Export the evidence

The session evidence PDF can render supported PNG and JPEG captures. It includes an attachment manifest with each file’s hash, masking status, step association, and media handling. Bounded originals are embedded when the export policy permits it. Other media receives a scoped retrieval reference and explanation.

The verifier section identifies the configured proof provider:

• Solana exports include the network, transaction reference, Merkle root, and verifier information. Confirm devnet anchors against the referenced transaction when devnet is selected.
• Azure SQL Ledger exports include the ledger proof reference, database digest information, and the authorized verification path.

The export keeps captures and attachments connected to the session. The verified-outcome step remains the source for the final business result.

Focused validation checklist

Before approving the application:

1. Send a representative session through Ingest.
2. Confirm declared and observed channels match.
3. Exercise continue, human-review, stale-state, restart, and repeated-action paths.
4. Confirm every selected capture appears on the correct Flow View step.
5. Confirm masked content is not present in the image or export.
6. Verify the final result from the authoritative business source.
7. Export the PDF and review attachments, hashes, and verifier information.

See Time Machine for session review and Compliance Evidence Export for export surfaces.