Blog · arXiv Analysis · Last reviewed June 25, 2026

The Computer-Use Agent Becomes the Contextual Integrity Test

Anmol Goel and Iryna Gurevych's June 2026 arXiv paper Capable but Careless: Do Computer-Use Agents Follow Contextual Integrity? turns a quiet privacy failure into an executable test: a helpful agent can complete the task while moving information into the wrong context.

A contextual-disclosure failure is not simply a secret appearing in an answer. It is a successful workflow in which the source context, recipient, content type, purpose, or transmission rule no longer matches the setting where the information originally belonged.

The governance object is the disclosure boundary: what the agent could observe, what it selected, what it withheld, who would receive it, and what rule justified moving the selected facts across contexts.

From Task Success to Disclosure

The paper, arXiv:2606.23189 [cs.AI, cs.CL], was submitted on June 22, 2026. It studies computer-use agents that work across applications such as email, calendars, notes, to-do lists, messages, and rendered user interfaces. A computer-use agent here is a model-mediated workflow that can observe app state, reason over a task, and emit a UI action or communication artifact on the user's behalf. The issue is not that the agent cannot see enough. It is that the agent may see too much and share the wrong subset.

That makes the paper different from a prompt-injection or task-completion benchmark. The request can be legitimate, the workspace benign, and the agent cooperative. The privacy failure appears when information from one setting moves into another where it is inappropriate for the recipient, purpose, or transmission norm.

This is distinct from the site's pages on sensitive-screen handover, unsafe shortcuts, and data-agent privacy surfaces: it tests whether disclosed facts belong in the recipient context.

Current Context

As of June 25, 2026, computer use is no longer only a research demo. OpenAI's current API guide defines computer use as a model operating software through the user interface, inspecting screenshots, and returning interface actions for a harness to execute. The same guide tells developers to run it in an isolated browser or virtual machine, keep a human in the loop for high-impact actions, and treat page content as untrusted input. Anthropic's Claude computer-use documentation similarly calls computer use a beta feature with distinct internet-facing risks, recommends minimal-privilege containers or virtual machines, domain allowlists, avoiding sensitive data, and human confirmation for meaningful real-world consequences, and warns that instructions found in webpages or images can conflict with the user's instructions.

Those vendor documents do not validate AgentCIBench's measurements. They explain why the benchmark matters. The deployed action loop already has the shape the paper studies: broad observation, cross-application task context, drafting or UI action, and a human who may not see which facts came from which source.

The governance setting is also broader than one paper. NIST's Privacy Framework is a voluntary tool for identifying and managing privacy risk, NIST's AI Risk Management Framework is voluntary guidance for incorporating trustworthiness into AI design and evaluation, and OWASP's 2026 Top 10 for Agentic Applications frames agentic systems as a security surface involving goal hijack, tool misuse, identity and privilege abuse, insecure communication, memory and context poisoning, and trust exploitation. Contextual-integrity testing belongs inside that larger risk program, not as a one-off benchmark score.

What AgentCIBench Tests

The paper introduces AgentCIBench, an evaluation harness for contextual-integrity failures in computer-use agents. Each scenario gives the agent a personal multi-app workspace, a task, a recipient, information that must be shared for utility, and information that must not be shared. The scorer checks whether the agent emits a message, calendar entry, note, or reply that includes the necessary content without leaking the forbidden content.

The contextual-integrity lens comes from Helen Nissenbaum's privacy theory: privacy is not only secrecy or control, but appropriate information flow under context-specific norms. In agent terms, a calendar item, shopping note, HR thread, or medical reminder may be visible to the agent and still inappropriate to send to a colleague, vendor, manager, classmate, or family member.

The test therefore asks for a contextual tuple, not a sensitivity label alone: source context, sender, recipient, information type, task purpose, and transmission principle. This is stricter than "did the agent have access?" Access is not permission to republish. A personal assistant may need broad read access, but the disclosure decision must be narrower than the observation window.

That distinction is useful for design. A safe agent should not merely identify protected fields such as passwords or medical terms. It should decide whether an otherwise ordinary fact belongs in the outgoing artifact for this recipient and this purpose.

The Three Failures

AgentCIBench targets three failure modes. Visual co-location tests whether the agent shares prohibited items because they sit near the task target in the rendered UI. Task-ambiguity overshare tests whether an underspecified request leads the agent to dump dense personal state instead of selecting only what the task warrants. Recipient misalignment tests whether the agent changes the shared subset depending on who will receive it.

Those modes are mundane, which is why they matter. No attacker needs to hide a malicious instruction. The failure can come from ordinary helpfulness: the agent reads across apps, over-includes visible detail, and treats a colleague, manager, friend, or external contact as if they were the same audience.

The governance lesson is that computer-use agents need recipient-aware disclosure boundaries. "Complete the task" is not enough; the system must know which facts are necessary, which facts are merely visible, and which facts should remain in their original context. A benchmark that scores utility, leakage, and refusal can expose that difference better than a single success metric.

The Numbers and the Caveat

The primary arXiv abstract reports an evaluation of 15 frontier agents, with 11 of 15 leaking on more than half of scenarios and an average leakage rate of 67.9%. The experimental HTML has an internal inconsistency: its abstract says 12 of 15, while its conclusion says 11. Both versions support the safer statement that most evaluated agents crossed the halfway leakage mark and that the reported average leakage was 67.9%.

The AgentCIBench project page also highlights engagement-conditioned leakage because refusal can mask raw leakage. That matters for governance: a model that refuses often may look safer on raw leakage while still being careless when it does engage. The paper's larger claim is not that every model leaks the same way. It is that task-completion utility does not predict disclosure restraint.

The paper also reports that leakage persists when agents act end-to-end in the rendered environment, not only in a state-grounded final-output probe. UI action can add new failure channels: navigation, partial drafting, recipient selection, form filling, and tool-state confusion.

The mitigation section is useful but limited. The authors report that three prompt-level interventions reduce engagement-conditioned leakage by 33 to 36 percentage points while raising utility in their setup. That is evidence of steerability, not proof that prompting alone is enough.

Why Approval Is Not Enough

A final approval dialog can still be too late or too vague. If a user sees a polished message and clicks send, they may not know which details came from which app or which are inappropriate for the recipient. In UI automation, even typing sensitive data into a third-party form can already be transmission. Contextual integrity requires an audit of information flow, not only a button before the last click.

A stronger interface would show the recipient, source contexts, selected facts, withheld facts, and why each selected fact is necessary. It needs a disclosure receipt, not private chain-of-thought: source, recipient, content type, purpose, transmission rule, and human decision at the point of risk.

The Spiralist rule is simple: a computer-use agent does not preserve privacy by seeing everything and asking once at the end. It preserves privacy by proving that each disclosed item belongs in the context it is entering.

The Disclosure Boundary Record

A contextual-integrity review needs a disclosure boundary record. That record should not be a transcript of the user's whole workspace or the model's private reasoning. It should preserve the evidence needed to reconstruct the information flow: task, user or workflow principal, agent identity, source application, source record, recipient, recipient role, selected facts, withheld facts, output artifact, policy rule, confirmation event, model version, app state, and final transmission status.

The record should separate three moments that ordinary approval dialogs blur. Observation is what the agent could see. Selection is what the agent chose to place into an outgoing draft, field, message, or form. Transmission is the moment the information leaves the original context. Privacy review fails when those three are collapsed into "the user approved the task."

At send time, the user-facing interface should show source labels and recipient-specific disclosure, not merely a polished final message. A useful preview would say, in plain terms, which facts came from notes, calendar entries, messages, files, forms, or memory; which facts were withheld; and which recipient rule is being applied. The goal is not to make every user read an audit log. The goal is to make the risky cross-context move visible before it becomes irreversible.

This is also where contextual integrity meets data minimization. A disclosure receipt can support accountability without becoming a new dossier if it stores record identifiers, hashes, source labels, redaction outcomes, and short excerpts where sufficient, while reserving raw content retention for incidents, legal duties, or user-requested review.

What It Does Not Prove

The paper does not prove that any named commercial product is unsafe in all computer-use settings. It evaluates a released benchmark and selected agents under a synthetic personal-app setup. It does not audit vendor privacy controls, enterprise policy layers, browser isolation, data retention, prompt-injection classifiers, or the real-world behavior of users reviewing drafts.

It also does not prove that contextual integrity can be reduced to a static allowlist. Social context is contested. A fact may be appropriate for a spouse but not a manager, a clinician but not an insurer, a school counselor but not a class group chat. The benchmark makes those judgments executable for test cases; real deployments still need policy, user research, domain expertise, appeal paths, and incident review.

Limits That Matter

The paper is a v1 arXiv preprint and uses synthetic OpenApps workspaces, not real personal accounts. The OpenApps environment is useful because it renders a personal multi-app workspace, including apps such as Messenger, Calendar, Maps, ToDo, Code Editor, and Notes, but it is still a benchmark environment. The authors explicitly caution that absolute leakage rates should not be read as estimates of real-world user harm. The scenario pool is intentionally stress-tested, the end-to-end study covers a 50-scenario subset and two agents, and the defense sweep covers three models and three prompt interventions.

Those limits do not weaken the benchmark's core point. They define its role. AgentCIBench is not a census of deployed harm. It is a pre-deployment and regression test for whether a computer-use agent can separate task-relevant sharing from contextually inappropriate disclosure.

Operational Failure Modes

Recipient collapse happens when the agent treats all named people as the same audience. A manager, spouse, vendor, clinician, classmate, and group chat may all be legitimate contacts while requiring different disclosure boundaries.

Visible-equals-shareable happens when the agent copies nearby UI content because it is on screen, in memory, or inside the same app, even though it is not necessary for the outgoing artifact.

Approval theater happens when the user approves a final-looking draft without seeing source labels, withheld facts, recipient role, or the rule that makes the selected information appropriate.

Context-free redaction happens when a filter removes obvious secrets but leaves ordinary facts that are sensitive because of the recipient or purpose: location, calendar constraints, family details, workplace conflict, financial stress, health status, or private relationship context.

Memory rebound happens when a fact withheld from one outgoing message remains in agent memory or a trace and later appears in another context. Withholding must apply to persistence and retrieval, not only to the first answer.

Benchmark laundering happens when a product cites task-completion or prompt-injection tests as if they cover contextual disclosure. A computer-use agent can be robust against malicious instructions and still disclose the wrong fact to the wrong recipient.

Governance Standard

A computer-use agent safety case should include contextual-disclosure tests beside task completion, prompt-injection resistance, handover gates, tool permissions, and state-preservation checks. The test set should name source context, recipient, purpose, must-share items, must-not-share items, output artifact, and scoring rule.

First, build a recipient model. The agent should identify who will receive the artifact, what role they occupy, and which source contexts are relevant to that relationship. "Send this to Alex" is not enough if Alex might be a coworker, vendor, friend, clinician, or family member.

Second, separate observation from disclosure. The agent may need broad context to complete the task, but the selected facts should be a smaller, justified subset. UI visibility, connector access, or memory access should not silently become republication authority.

Third, keep a disclosure receipt. Release records should preserve the model version, app workspace, task prompt, recipient, visible state, final artifact, selected facts, withheld facts, leakage score, utility score, refusal rate, confirmation event, and any mitigation prompt or policy rule. This belongs beside agent audit records and tool permissioning.

Fourth, test after change. High-stakes deployments should rerun contextual-disclosure suites after app-layout changes, memory-policy changes, connector changes, enterprise policy changes, prompt changes, or model upgrades. A passing score is not portable across every UI, recipient class, or memory configuration.

Fifth, govern false comfort. Prompt-level mitigations are useful, but they should be backed by outside-model controls: source labels, DLP checks, recipient-specific policies, form-transmission gates, audit logs, and human review at the actual disclosure point.

Sixth, bind memory to the same transmission rule. If a fact is inappropriate for the current recipient, it should not remain freely retrievable for a later recipient, tool call, or model run. Memory policy, trace retention, and disclosure policy should share the same context labels.

Seventh, audit the interface, not only the model. The system should test screenshots, form fields, draft previews, recipient pickers, auto-complete, browser state, and app layout because contextual leakage can occur through UI mechanics before a final text response exists.

The hard part is deciding which information can move from one legitimate context into another. That is where computer-use agents need governance before they need more autonomy.

Source Discipline

Use the paper for what it directly supports: AgentCIBench's design, failure taxonomy, reported metrics, mitigations, and limitations. Use the project page for the released benchmark framing and leaderboard caveats. Use vendor documentation only for current product and developer guidance about computer-use action loops, isolation, untrusted inputs, confirmation, and sensitive-data handling. Use NIST and OWASP for risk-management context, not as proof that any specific benchmark result generalizes.

Do not cite an agent demo as evidence of privacy maturity. The relevant evidence is the run record: what the agent could see, what it actually selected, what it withheld, who received the artifact, which policy allowed the transfer, and what a reviewer can reconstruct after the fact.

Current-source claims on this page were checked against primary or official sources on June 25, 2026. The article separates paper-reported benchmark results, project-release artifacts, vendor developer guidance, privacy theory, voluntary NIST frameworks, and OWASP security guidance because each supports a different kind of claim.

Sources

Return to Blog