Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Is a Secure Environment for Claude Computer Use in Regulated Work?
A secure environment for Claude computer use in regulated work keeps the model on a rendered page where sensitive values appear as consistent tokens before it reads them, with real values resolving only at the destination a person approved. Ask where that substitution happens, who approves each consequential action, and what record the session leaves.
Teams looking for alternatives to running Claude computer use on raw screens in regulated work are trying to keep the capability and change the input. One screen holds the claimant's name, date of birth, policy number, bank account, diagnosis codes and reserve amount, and a screenshot captures all of it whether or not the task needs it. The work is regulated, so the record has to show who approved a payment and what that person saw. A secure environment answers three questions: what the model receives when the page renders, where the real values resolve, and what record the session leaves for the reviewer who arrives a month later. The answer is a rendered page on which policy values are replaced before capture, while Claude still does the regulated work. Anthropic's own documentation makes the screenshot the center of the tool, which is why the screen, rather than the network, is the boundary that decides the question. That control differs from the sandbox, the gateway and the data loss prevention rule a team already runs, so a regulated review should ask about the screen before it approves the model.
Key findings
- For Claude computer use to be safe in regulated work, the values on a rendered claim would have to be replaced with consistent tokens before the model reads it, so the model works on CLAIM_001 and the real value resolves only at the approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each submission or record change, and a record of every screen the model read with the approver's name attached (What Is a Tethered Agent?).
- Anthropic's computer use documentation describes screenshot capture and warns teams to isolate Claude from sensitive data, and it does not describe a control that replaces values on the rendered page before the screenshot is taken (Anthropic, Computer Use, 2026).
- The same page states that the tool "provides screenshot capabilities and mouse/keyboard control for autonomous desktop interaction," so what the model receives is the screen itself (Anthropic, Computer Use, 2026).
- A systematic review of automation bias describes it as "the tendency to over-rely on automation," which is why an approval step has to be a decision a person makes rather than a prompt they dismiss (Goddard et al., 2012).
- Reddy and Gujral document CVE-2025-32711 in Microsoft 365 Copilot, where the client "automatically fetches the external image URL included by the attacker" (Reddy and Gujral, 2025).
What does Claude computer use receive from a claims screen?
Claude computer use is not a connector that returns a field. Anthropic's documentation states that the tool "provides screenshot capabilities and mouse/keyboard control for autonomous desktop interaction" (Anthropic, Computer Use, 2026). The model receives a rendered image. On a claims task, the whole viewport is one input: name, date of birth, policy number, bank account, diagnosis codes and reserve amount arrive together.
A person working the claim can look only at the field the task needs. A screenshot has no such filter, and the fields the model does not need stay in its context for the rest of the run. The exposure grows when the page renders notes, emails or uploaded documents, because those are text the model reads as instruction and data at once. Anthropic warns that "In some circumstances, Claude follows commands found in content even when they conflict with your instructions" (Anthropic, Computer Use, 2026).
Reddy and Gujral document CVE-2025-32711 in Microsoft 365 Copilot, where the client "automatically fetches the external image URL included by the attacker" (Reddy and Gujral, 2025). A claims screen that renders an emailed note gives an attacker the same surface.
The scope is the rendered page. A protected browser governs what the agent reads and does on a page it draws (What Is a Protected Browser for AI Agents?). A desktop application outside that browser, a terminal, an IDE, the local filesystem, direct API calls and MCP are outside it.
What has to be replaced before the claim screen reaches the model?
A team can redact the transcript after capture, inspect text in flight at a gateway, or change the page before the screenshot is taken. No product reviewed describes that substitution: 0 of 86 AI security and data protection products describe reversible tokenization of what an agent reads on a screen, and 1 describes masking on a page (How Many AI Security Products Control What an AI Agent Sees?).
Render-layer substitution builds the page, replaces the values a policy names with consistent tokens, and lets the model read the tokenized page. On the claims record, the claimant name becomes CLAIMANT_001, the policy number POL_001 and the bank account ACCT_001, while the reserve, a figure the claims task does not use, becomes AMT_001. The same token is used for the whole run, so the model can refer to CLAIMANT_001 across pages without ever holding the name. The real value resolves only at the approved destination, at the moment a named person approves the action that needs it (What Is Render-Layer Tokenization?).
The regulated argument is data minimisation. Article 5(1)(c) of the GDPR requires personal data to be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed" (Regulation 2016/679, 2016). A policy that shows the model the fields the task needs and tokens for the rest meets that standard in practice; counsel decides whether it does.
Substitution is not de-identification. HHS describes "two methods that can be used to satisfy the Privacy Rule's de-identification standard": Expert Determination and Safe Harbor (HHS, 2012). A tokenized screen leaves the real value in the system of record and resolves it at an approved destination, so it limits what the model reads without de-identifying the data (Can Staff Use AI on Patient Records Without PHI?).
| Field on the claim | What the person sees | What the model reads | Where the real value resolves |
|---|---|---|---|
| Claimant name | The name on the claim | CLAIMANT_001 | The claim record, at submission |
| Bank account | The account on file | ACCT_001 | The payment rail, at approval |
| Reserve amount | The reserve on the claim | AMT_001, a figure the task does not use | The finance system, at approval |
What do the vendors themselves say?
Anthropic documents the mechanism and the risk in the same place. The computer use page describes a model that interacts with computer environments through screenshots and mouse and keyboard control, and its safety guidance is to "Take precautions to isolate Claude from sensitive data and actions to avoid risks related to prompt injection" (Anthropic, Computer Use, 2026). Isolation is the right instruction; the page does not say where to enforce it, and it does not name an approver or a per-run record.
Anthropic's engineering write-up on sandboxing is the closest documented control, and it governs a different object. It states that "effective sandboxing requires both filesystem and network isolation" and that sandboxing "safely reduces permission prompts by 84%" (Anthropic Engineering, 2025). Both claims are about Claude Code, a coding agent working in a terminal and a repository. A sandbox limits what the agent can execute and which hosts it can reach; it does not change the pixels in a screenshot taken by a browser.
A sandbox bounds execution, and a protected browser bounds reading; a regulated deployment needs both.
The Cloud Security Alliance reports that "Eight in ten employees use AI tools not approved by their organizations" (Cloud Security Alliance, 2026).
What the vendor pages do not describe is the reading-side control. Anthropic's page names the screenshot, the injection risk and the isolation advice; it does not describe replacing values before capture, and it does not describe a record of what the model read.
Who approves the action, and what does the approver see?
A named person approves each consequential action, and the approval is a decision about a specific submission, payment or record change. The approver sees the record as the model saw it: CLAIM_001, CLAIMANT_001 and ACCT_001, the destination the action will reach, and the amount in the claim's own terms.
Approval is weak if it is only a prompt. Goddard, Roudsari and Wyatt's review of automation bias describes "the tendency to over-rely on automation," so a bare approval prompt is weak evidence of review (Goddard et al., 2012). An approval screen has to show the thing being approved, with the values the approver needs, or the click becomes a formality people learn to clear.
The record has a second purpose. Anthropic reports that "In at least some cases, models from all developers resorted to malicious insider behaviors" in hypothetical corporate environments, while saying it has not seen evidence of that behavior in real deployments (Anthropic, Misalignment, 2025). A regulated team does not have to accept the strongest reading to act on it. Put the consequential action behind a person, and keep a record of what the model proposed and who allowed it.
Authority is the other half. An agent that can go anywhere its supervisor could go is useful, and the same reach is what makes an unapproved action expensive (What Is a Tethered Agent?). The gate names the person whose authority the reach depends on (Does Anthropic Store Claude Computer Use Screenshots?).
What does a governed environment change?
A governed environment changes what the model reads at the point the page is rendered. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the model receives CLAIM_001 and CLAIMANT_001 rather than the claim and the person. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. Real values resolve only at an approved destination, at the moment a named person approves the action that carries them. A named approver confirms the policy and each consequential action, and the session exports a record of the screens, the actions and the approvals.
It does not change the system of record: the claim still holds the real name, account and diagnosis code, and access control and retention remain the organization's.
A browser control that stops a person copying or downloading a record governs an action on the page; it does not say what a model reading the same page receives (RedactSure vs Chrome Enterprise Premium: 2026 Comparison & Alternative). A data discovery platform can tell a team where sensitive data sits without changing the rendered screen (RedactSure vs BigID: 2026 Comparison & Alternative).
OWASP's recommended mitigation for prompt injection is to "Restrict the model's access privileges to the minimum necessary for its intended operations" (OWASP, 2025).
What the record shows
Claims organizations get three changes from a governed environment at the point a claims screen is read: the values in the screenshot, the destination where real values resolve, and the record of who approved what. Anthropic documents the screenshot and warns that content can direct the model; its pages do not describe substitution before capture, and the sandbox it documents for Claude Code covers files and network rather than the screen. The conclusion for regulated work is that the screen has to be treated as the boundary, because a capture carries every field in the viewport and a page can carry an instruction. Compliance teams should run the same test on their own setup: open one claim with a test value, capture the same screen the agent receives, and search the image and the transcript for the value. If the value appears in either, the control sits after capture, not before it.
Methodology and limitations
This page rests on Anthropic's computer use documentation and sandboxing write-up, the OWASP LLM01 entry, GDPR Article 5(1)(c), HHS de-identification guidance, a Cloud Security Alliance note, Anthropic's misalignment report, a systematic review of automation bias, the EchoLeak paper, and existing RedactSure research pages. Vendor pages were read between October 21, 2026 and October 22, 2026, and each Sources line carries the date for its page.
No product named here was tested for this page. The products are described from their public documentation as read between October 21, 2026 and October 22, 2026; "not described in the pages reviewed" means the pages reviewed. Vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a claims task with placeholders and an approver, not an organization. Determinations about whether a workflow meets a regulatory standard belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
What is a secure environment for Claude computer use in regulated work?
One that changes what the model reads, not only where the agent can go. Claude still opens the claim, reads the screen and proposes the submission, but the values in that screen are replaced with consistent tokens before the screenshot is taken, the real values resolve only at the destination a person approved, and the session leaves a record of what the model saw.
Does Claude computer use see everything on the screen?
Yes, on any screen it is given, because the tool works from screenshots. Anthropic's documentation states that it provides "screenshot capabilities and mouse/keyboard control for autonomous desktop interaction," so the model receives the rendered image and every field in the viewport. A person can ignore a field they do not need; the screenshot includes it. That is why the field set on a claims screen matters more than the prompt.
Does a sandbox change what Claude reads on a screen?
No, not by itself. A sandbox governs what the agent can execute and reach: Anthropic's engineering write-up states that "effective sandboxing requires both filesystem and network isolation," and it is describing Claude Code rather than the browser screen. The screenshot is taken inside whatever environment the browser runs in, so a sandbox can limit where the agent goes and still leave every rendered field in the model's input.
Who should approve an action the agent proposes?
A named person, per action, outside the model. The approver should see the record as the model saw it, with tokens in place of values, and approve the submission, payment or record change against a stated destination. A review of automation bias describes "the tendency to over-rely on automation," which is why a prompt that only asks for a click is weak evidence of review.
What record should the environment keep?
A record of each screen the model saw, each action the agent proposed and took, and each approval with the approver's name and the time. That record should export to the organization's own monitoring because the reviewer a month later needs to reconstruct what the model read before it acted. A transcript is not the same record: it can show tokens without showing the page they came from.
Is replacing values with tokens the same as de-identification?
No. HHS describes "two methods that can be used to satisfy the Privacy Rule's de-identification standard," Expert Determination and Safe Harbor, and both concern a dataset from which identifiers are removed or assessed. Substitution on a rendered screen leaves the real value in the system of record and resolves it at an approved destination, so it limits what the model reads rather than de-identifying the data. HHS also warns that de-identified data "retains some risk of identification."
How RedactSure Keeps a Claims Screen Out of the Model's Input
A screenshot of a claim carries every field in the viewport, and the sandbox leaves the image intact. Anthropic's own documentation warns that content on a page can direct the model.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: Claude opens claim CLM-4417, the screenshot carries the claimant's name, policy number and bank account, and the transcript keeps them for the rest of the run. Inside the governed environment: the page renders with CLAIMANT_001, POL_001 and ACCT_001, the model works and submits on those tokens, the real account resolves only at the payment destination a named approver confirmed.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A claims screen is the record a regulated team will be asked to defend. Bring one claim of your own and see, with test values, what the model reads, who approves the submission and what the record shows. Book a demo