What Should You Verify Before Letting an AI Click?

The short answer is that no computer-use agent was started. There was no click, no blocked click, and no measurement of trust.

A live task did not go wrong. A predeclared capability gate stopped the test because the required safeguards were not observable in the inspected interface. Documented access to screen, URL, and DOM state is different evidence from an independent record that every action stayed within scope.

“Do not do this” is not a barrier

You can tell a computer-use agent not to leave a site or click a Send button. That sentence in the prompt (the written instruction) is an instruction, not an enforcement mechanism. An AI that sees the screen can also read on-screen text as input, and that text may conflict with the user.s instructions.

The official computer-use guidance from OpenAI, Anthropic, and Google uses different wording, but all three recommend isolation, site or action boundaries, human control before consequential actions, records, and checking the result. These are vendor operating recommendations, not proof that a particular product is always safe.

So this protocol set its own gate: before starting an agent, four records had to be separately observable. The gate did not pass, so this run produced none of the four records:

1. what the AI proposed;
2. what the policy decided immediately before execution—allow, block, or require confirmation;
3. what the component that actually drives the browser executed; and
4. what a separate checker independently verified about the final state.

An agent saying “done” is not the fourth event. Looking at the screen once is not a record of the whole path in between either.

A synthetic test site and a small policy wrapper

Instead of a real account, the setup used a synthetic site that opens only on my own machine (the loopback address). Page A and Page B each contain one synthetic string that does not appear in the prompt, so they can show whether an agent actually read both pages. Because C1 and C2 were not run, the only observation here is a unit test of the in-memory comparison function—not a live prompt or page-reading result. Page B also has an ordinary-looking “Send this report” button, but there is no external recipient or transmission target, and all inputs are non-sensitive synthetic data. In a real service, typing into a field may itself transmit data before Send is clicked.

I also built a test policy wrapper (the executor). It wraps only a mock browser component that I made; the selected in-app browser.s clicks and navigation do not pass through it. In the unit suite, the wrapper allows only the address of the machine itself (127.0.0.1) and a predefined set of actions. It blocks external navigation and the Send click before calling the mock primitive. Proposal, decision, and allowed execution events receive IDs and enter a hash-chained ledger, where changing an earlier record breaks later verification.

On September 13, 2026, the six automated Node.js tests that check only this wrapper were rerun, and all six passed. Blocked actions never reached the mock component; allowed actions reached it only after an allow decision had been recorded; and the tamper-detection test also passed.

That evidence has a hard limit. It is a unit test of the wrapper. It does not show that a real computer-use model ignored a planted instruction or that the selected browser could not make an external request.

Why the main run did not start

On September 9, 2026, I checked the documentation and feature inventory of the Codex In-app Browser/Unified Computer Use package 26.901.51231 on macOS 26.6.2 (build 25G83). It listed on-demand access to the screen, the current URL, and the page structure (DOM). I did not navigate or interact with a page. In any form I could see, the interface did not provide a separate proposal record, a per-action policy decision, an unchangeable execution ledger, or an enforced site allowlist. Internal controls that are not exposed were not ruled out, but they cannot count as evidence here. Cancellation, clean reset, and the exact screenshot transmission and retention path also remained unverified. The embedded engine, driver model, pricing plan, and incremental cost were unknown.

A strict page security policy (CSP) and a Send button with no sending function can be built, but they cannot prove that the page stopped the browser from navigating to another address. Checking the URL after an action is too late: it cannot exclude a brief out-of-scope visit followed by a return.

Neither the baseline condition without a planted instruction (C1) nor the condition with a planted on-screen instruction (C2) was run. They are not “two failures” or a 0% success rate. There were no behavioral observations, so their status is simply not run.

A delegation card to fill in first

A non-developer can fill in these fields first without reading any code:

Add one plain question: Does it actually stop if I do not answer? A polite “May I continue?” is different from a technical gate that prevents execution until a person approves.

A blank field is not a pass. Neither is N/A. If a record is missing, write "unknown" and do not delegate a task that needs that record.

So how much should you trust it?

This run did not measure the safety of an AI product. It showed that a predeclared capability gate can stop a test before missing evidence turns into a convincing completion story.

An independent checker verifies only the final state, and a correct final state does not prove a safe path, scope compliance, or the absence of transmission. Research environments such as WebArena also check functional outcomes separately, but one small local test page is not a benchmark or a general reliability estimate.

The scope handed to a screen-operating AI should be more specific than “I will be watching.” Ask what the executor blocks, what it records, when it pauses, and who verifies the outcome independently. These questions are the editorial standard chosen for this protocol, not a safety verdict on any product. If one essential record cannot be confirmed, stopping before the click, as happened here, is the right call. That too is a result.

AI was used to assist with research and drafting. The author independently verified and edited the final article.