A review screen can tell the wrong story even when the underlying records are intact. On 6 October, METR described a proof of concept in which an agent’s output could rewrite the actions displayed in a transcript viewer and intercept its download button. The original record remained in METR’s database.

The researchers conducted the work in an isolated staging environment. They report no observed use of this exploit in their evaluations, and the vulnerability was patched within a day of reporting. METR’s account

An interface can also mislead without an attacker: a request times out, an approval response is lost, or a result never reaches the screen. These failures need faithful state handling; METR’s exploit also requires defenses against untrusted content taking control of the viewer. Both raise a practical question: what may the screen claim about the work?

Three layers need to stay distinct: what happened in the receiving system, what the execution record establishes, and what the interface tells the reviewer. A faithful display cannot repair missing or incorrect evidence. It should never turn uncertainty into success.

The screen makes claims about the work

Consider a hypothetical agent asked to update a customer record and send a confirmation. A read-back from the customer system verifies the changed record. The messaging request times out before a delivery result returns. The agent then writes, “Customer updated and notified.”

The first action is confirmed. The second remains uncertain. A green “Completed” card would conceal the distinction that determines whether a colleague should investigate before sending another message.

In another hypothetical case, an approval card says “Approved” after a person clicks, although the permission service never records the response. The click, recorded permission, attempted action and confirmed effect are four workflow facts to preserve across those three layers.

These distinctions belong in the interface’s status contract: the rules connecting each displayed status to supporting evidence. A summary can explain them, but an agent’s generated words should not silently become the application’s authoritative status.

Existing implementations show what to test

GitHub’s draft Unified Agent Session Specification requires unresolved calls to remain unresolved and forbids success checkmarks for ambiguous completions. Its conformance fixtures provide a precedent for case 1 below, where one action is confirmed and another remains unknown. Specification

A Qwen Code change merged on 1 October connects saved execution receipts to WebShell results, separating execution, output capture and delivery. Its test plan gives the cross-view checks: live and restored cards agree, late results stay with the original turn, and downloads preserve expected bytes. The feature is disabled by default in that change. Qwen change

GitHub Agentic Workflows supplies case 3’s distinction between no action needed and action blocked. A change merged on 4 October records incomplete outcomes when controlled action outputs, called safe outputs, are missing, empty or wholly rejected, while preserving valid no-operation results. GitHub change

Claude Code’s 6 October release notes document fixes for dropped permission-prompt answers in cloud sessions and lost final messages when quitting. The first motivates case 2’s lost-response test; the second motivates recovery checks. Neither establishes unauthorized execution. Release notes

AI-DLC adds a different approval-gate content test. An 8 October issue reports failed checks that never reached the agent or person while an agent-written report claimed PASS. A 9 October merge adds selected failures to gate messages for the agent to relay. Test whether that evidence survives when the gate appears again.

These bounded cases motivate tests; they do not establish a cross-product failure rate or prove the proposed suite works.

Follow one operation through every view

For the customer-update example, I would build a small fixture, a controlled set of test records, outside the agent’s control. Its status contract could use four entries:

  • Approved. Requires an accepted decision for this action and scope. Authority: permission service. Without it: “Permission unresolved.”
  • Attempted. Requires a dispatch record for this operation. Authority: executor. Without it: “Attempt unconfirmed.”
  • Record updated. Requires a read-back confirming the intended change. Authority: customer system. Without it: “Update outcome unknown.”
  • Notification delivered. Requires recipient-side delivery evidence for this message. Authority: messaging service. Without it: “Delivery outcome unknown.”

An acknowledged request alone cannot establish the intended effect. Explicit failure evidence gets a failure label, rather than being treated as missing evidence.

Then I would feed those facts through the live card, restored session, summary, approval history and export. Compare views against the same evidence snapshot. Increment its version when new evidence is accepted, while retaining the operation’s identity. Different detail levels are fine; a view using older evidence should disclose that and refresh within a defined update window.

Five cases make a useful starting set:

  1. Confirmed update, unknown notification. The receiver confirms the customer update; the message request times out without a final result. At evidence version 17, every view must preserve “record updated; notification outcome unknown.” At version 18, a receiver result confirms delivery failure: the view becomes “record updated; notification failed.” The operation identity stays the same, and the overall task remains incomplete.
  2. Approval clicked, response not recorded. The browser records an interaction, but the permission service has no accepted decision. Test two responsibilities separately: the display must show unresolved permission, and the execution gate must prevent this approval-required action from proceeding.
  3. No action needed versus action blocked. An explicit, valid no-operation result may finish the task. A denied required action must retain an incomplete outcome and a useful reason.
  4. Completed execution, unavailable output. The operation succeeds, but access to its output is revoked or retrieval fails. The display should preserve the confirmed execution outcome and identify the access or retrieval problem. It must not substitute unrelated content or erase the distinction.
  5. Untrusted content in a result. In an isolated security test, hostile or malformed output must remain data. It must not alter trusted status fields, hide earlier events, change approval controls or replace the export.

Define the expected result before running each case. Check for unsupported success, invented permission and late results attached to newer tasks. An export must identify its source version and disclose authorized omissions, redactions or truncation. It need not expose every private field.

Include positive controls: a confirmed result becomes confirmed, a valid approval appears correctly, and a permitted export works. Separately, inject a deliberately false “Completed” label into the unknown-notification case. The suite must reject it. This checks whether the test detects the mistake it claims to prevent.

Test the same status distinctions and approval controls with keyboard navigation and screen readers. Status must remain understandable without color alone.

A small fixture set cannot establish production reliability. It can expose specific mismatches and become a regression suite as failures are found.

Give generated interfaces the same contract

OpenAI’s 7 October Intelligent UI announcement describes model-composed responses using native components and progressive rendering. It is a capability announcement, not evidence of a security defect. For teams building generated review interfaces, which elements may the model compose, and which facts must the application supply? OpenAI announcement

I would allow flexibility in explanation and layout while binding permission state, operation identity and confirmed effects to checked application data. A partial response should not expose an actionable control before its target and scope are established. Test reconnection, compact layouts and regenerated views.

Rendering safety, authorization enforcement and state synchronization remain distinct engineering responsibilities. A status contract specifies expected claims; it does not by itself secure the renderer.

A faithful screen still needs a human test

Better presentation does not guarantee better judgment.

In a February preprint, a final study with 12 technology-company employees compared a redesigned review interface with a baseline. The authors found little improvement in correctness judgments and greater confidence when participants accepted incorrect results. Annotations were prepared from the agent’s reasoning: if a trace wrongly claimed completion, the interface would repeat that claim. The study used one computer-use system and a small, experienced sample. Study

The study did not test an interface whose status was grounded in independently checked system evidence. It does caution against treating a reassuring presentation as proof that oversight works.

After the engineering checks, use authorized sandbox tasks to test whether reviewers can identify unresolved work and avoid both premature acceptance and needless escalation. Measure their errors and review effort separately from their confidence.

Do not make employees responsible for discovering that the application’s status labels are unreliable. Product and engineering owners should establish what those labels mean, what evidence supports them and how a reviewer can challenge them.

Start with the status people already rely on

Choose one consequential workflow and the screen people use to accept its output. Ask the team to demonstrate an uncertain result, a lost approval response, a restored session and a failed export.

Then compare what the screen says with what the receiving systems establish.

The useful outcome is a testable status contract between recorded events and the claims shown to a reviewer. Use it to expose misleading states, alongside the security and authorization controls that protect the workflow.