Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
How Do You Run Claude Computer Use on Customer Records Without Exposing PII?
Keep the personal data off the screen the tool captures: run development work on synthetic claims, and for live records render the claims page with placeholders before the screenshot is taken. Ask what the model receives on the screen, who approves the payment, and what record the run leaves.
A claims operation that clears a few hundred records a day has a queue problem. Each claim needs someone to open the record, read the diagnosis, check the member's details and route the payment. Claude's computer use tool does the work the way a person does, by reading screenshots of the page and clicking through the same fields. The screenshots are also the exposure. A page that renders a member's name, date of birth, diagnosis code and bank details into those fields puts all four in front of a model whose next output can be a note, a summary, or text pasted elsewhere.
The tool does not decide what a screen contains. The application that draws the page does. A security review therefore has one question above the rest: what does the page show the model while the claim is open? A team can answer it in two moves, keeping invented records in front of the agent while the workflow is built, and putting a placeholder layer between the record and the screen when live claims start flowing. McKinsey's research finds 62% of organizations at least experimenting with AI agents and 23% scaling them anywhere, which is why the question is being asked now (What Is the PII Wall?).
Key findings
- For Claude's computer use tool to work a claim without exposing PII, the values on the claims page would have to be replaced with consistent tokens before the screenshot is captured, so the model reads CLM_8841 and MEMBER_2210 where the record holds a claim number and a member name (What Is Render-Layer Tokenization?).
- It would also require a named person approving each payment, submission and record change, and a record of what the model received on each screen (How Can AI Agents Work With Customer Records Without Seeing the Actual Data?).
- None of the pages reviewed describes a masking step inside the computer use tool itself: the screenshot is the input, and the operator is expected to keep sensitive values off the screen (Anthropic, 2026).
- Anthropic's computer use documentation warns that "In some circumstances, Claude follows commands found in content even when they conflict with your instructions," and tells operators to isolate the model from sensitive data (Anthropic, 2026).
- The privacy evaluation of autonomous web agents found that they "are prone to inadvertent use of unnecessary sensitive information," so a claim screen hands the model fields nobody asked it to use (Zharmagambetov et al., 2025).
- Adaptive attacks bypassed 12 published defenses against jailbreaks and prompt injections with an "attack success rate above 90% for most," which is why the placeholder layer matters more than a filter in front of the model (Nasr et al., 2025).
What does Claude's computer use tool receive when a claim is open?
Claude's computer use tool works through the screen. Anthropic's documentation states that the tool "provides screenshot capabilities and mouse/keyboard control for autonomous desktop interaction" (Anthropic, 2026). Every step begins with an image the model reads and ends with an action it chooses, and the model never queries the claims system. It reads the rendering of the claims page, not the database behind it, which is why the exposure question is about the page. The model receives a view rather than a field list (Does an AI Agent See Everything on Your Screen?), and the view includes the columns the workflow never mentions.
The scope is the rendered page. A governed browser environment covers what the agent reads and does on screens an application draws: the claims queue, the member record, the eligibility tab, the payment form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so an agent that pulls the same claim through an interface sits outside this control.
On a claims page, the screenshot carries more than the task. A reviewer wants the diagnosis code checked against the policy, and the screen also shows the member's name, member number, date of birth, the reimbursement account and the adjuster's free-text note. Web agents "are prone to inadvertent use of unnecessary sensitive information" (Zharmagambetov et al., 2025), and OWASP records that "Personal identifiable information (PII) may be disclosed during interactions with the LLM" (OWASP, 2025).
Which claims can run on synthetic data, and how does a page get placeholders?
Development should run on records that were never real. A test tenant seeded with invented members and diagnosis codes lets the agent have the run of the screen. Teams use that phase to wire the tool and watch how the model handles a denial, a duplicate claim or a missing document.
A test tenant cloned from production is production data, and a generated record rarely reproduces the free-text note, the scanned attachment or the legacy field that holds a member number. An approval on the tool that runs the query does not limit the rows the query returns; that is the gap a coding agent has when it can read a test database of real customer records (How Do I Let a Coding Agent Use a Test Database That Contains Real Customer Data?).
For live claims, the placeholder layer goes in the rendering path. The team agrees a field map: the member name renders as MEMBER_2210, the claim number as CLM_8841, the date of birth as DOB_1979, the reimbursement account as ACCT_0031. The values stay consistent for the whole run, so the agent carries CLM_8841 from the queue to the payment form on the same claim. Free-text notes and scanned documents need a decision rather than a field map: the environment renders a summary with the identifiers removed, or keeps the document off the screen. The substitution happens in the rendering path, after the record is read and before the image is captured (What Is Render-Layer Tokenization?). The field map is a design the control review did not find described: across 15 AI agents, Claude's computer use tool among them, and 86 AI security products, none describes putting tokens an agent can work with in place of the sensitive values it reads on a screen (Do AI Agents Ask Before Making a Payment?, How Many AI Security Products Control What an AI Agent Sees?).
What do the vendors themselves say?
Anthropic's computer use page warns that Claude can follow commands embedded in the content it reads, and its advice is procedural: "Take precautions to isolate Claude from sensitive data and actions" (Anthropic, 2026). No masking step between the page and the model is described.
Claude Code's sandboxing documentation describes sandbox.credentials settings that deny or mask a credential, and an injectHosts list naming where a masked value may be substituted. That covers a sandboxed command, and the computer use tool reads a screen.
Coder's guidance is about the identity an agent runs under rather than the screen it reads. It warns that "LLMs and agents can be dangerous if not run with proper boundaries," and asks teams to "use separate identities with limited scope whenever interacting autonomously" (Coder, 2026), which narrows what the agent may do and leaves the page free to render the member's name.
An instruction hidden in a claim note is the case that turns a field map into a security control. The information-flow analysis found that "poisoned data retrieved from one component can change the model's behavior and compromise the entire system, including coercing the model to spread confidential data to untrusted components" (Siddiqui et al., 2025). A note field the agent reads is retrieved data, which is why the field map has to cover free text.
Who approves a claim payment, and what does the record hold?
Approval is where a claims workflow becomes consequential, because the page that shows a diagnosis also carries the account that receives money. Harvard's guidance lists "Sensitive Data Exposure" among seven risk categories and asks teams to "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible" (Harvard University Information Security and Data Privacy, 2026). A claim payment moves money, is hard to reverse and is visible to the member.
The approver reviews the action against the record rather than the model's memory of the screen: the claim number as a token, the amount, the destination account and the proposed step. The real values resolve into the payment form only when that person approves the release, so the agent has worked the claim without ever holding the account number it paid. The approval should name a person rather than a role inbox, and it should attach to one claim and one amount.
The record should hold each screen the model read, with the tokens in the fields, every action the agent took, and every approval with a name and a time. That answers the question an incident review always asks: what did the model see before it acted? It tells an auditor whether the member's data was ever on the screen.
Two answers belong in the vendor contract: whether the same token follows a claim across screens, and what the tool does when an instruction arrives inside a claim note. A governed environment without a named person on the payment is an audit trail without a decision.
What does a governed environment change?
A governed environment moves the decision about what the model may see to the moment the page is drawn. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works the claim as CLM_8841 and MEMBER_2210. Real values resolve only at an approved destination, at the moment of an approved action, which for a claim is the payment form after a named person approves it. Every screen, action and approval goes into a record the organization can export.
One field map covers the claims queue, the member record, the eligibility tab and the payment form, so the agent never has to be trusted to avoid a field. Because the token is stable, the agent can reason about the claim across screens without the record ever rendering the name.
The limit is the rendered page. The same claim reached through an API, an MCP tool or a shell command sits outside this control, and the field map is only as good as the last review of the page it describes. Columbia's lab writes that agents "turn every layer of the stack into a semantic quality problem," and that trustworthy agent automation "cannot be solved at a single layer of the stack" (Columbia DAPLab, 2026). An enterprise browser governs what a person may copy, paste, download or print on a managed device (Enterprise Browser or Render-Layer Tokenization?), and it does not describe what a model reading a permitted page receives. The rendering layer is the one a claims team can inspect before the first live run, which is why the category is worth comparing on where the control sits (RedactSure vs Chrome Enterprise Premium: 2026 Comparison & Alternative).
What the record shows
The control sits at the rendering step, before the screenshot exists, which is the only place it can sit for a tool that reads pixels. Anthropic's documentation presents the screenshot as the tool's input and asks operators to isolate the model from sensitive data, which places the decision in the application that draws the claim. None of that requires the agent to work blind: the claim number, the policy status and the diagnosis category can stay legible while the member's identity and bank details become tokens. Run one claim as a test with invented values, then the same claim with placeholders, and compare the screenshots the model received against the fields the record holds.
Methodology and limitations
This page rests on Anthropic's computer use documentation, Coder's agent guidance, OWASP's entry on sensitive information disclosure, Harvard's guidance on generative AI systems, Columbia's lab page, three research papers on web-agent privacy, information flow and adaptive attacks, and existing RedactSure pages. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 16, 2026 and October 22, 2026, and each Sources line carries the date for its page.
No product on this page was tested for this page. "Not described in the pages reviewed" means the recorded pages for that product do not say it, and vendor features change, so the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, an insurance claims page, and not an organization. Determinations about privacy law or an audit belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
How do you run Claude computer use on customer records without exposing PII?
Keep the personal values off the screen the tool captures. Build the workflow on synthetic claims, then put a placeholder layer in the rendering path so the live page draws CLM_8841 and MEMBER_2210 before the screenshot is taken. Put a named person in front of each payment, and keep a record of what the model read. The agent still does the work; it works on tokens that mean nothing outside the environment. Write the field list down before the first live claim.
Does the computer use tool mask what a screenshot contains?
No. Anthropic's documentation describes screenshots as the tool's input and asks operators to isolate the model from sensitive data, and it describes no masking of screen content. The controls it does describe, an injection classifier and guidance about untrusted content, narrow what the model may do with what it reads. Masking has to come from the application that draws the page, before the image exists.
Can synthetic records replace real customer data for a test run?
Yes for building the workflow and no for proving it. Invented claims let the agent run with broad permission because nothing on the screen belongs to anyone, which is how a team finds the duplicate-claim and missing-document paths. The limit is the page itself. A test tenant cloned from production, a scanned attachment or a free-text note can put real values back on the screen, so the test has to check the rendered page, not the environment's label.
Who should approve a payment the agent prepares?
A named person with authority over that claim and that amount, not a role inbox and not the agent's own review step. The approver should see the tokenized claim, the amount and the destination account, and the real values should resolve into the payment form only when that person releases them. Approval attached to a queue of items in one click is a notification rather than a decision.
What record should a claim run leave behind?
Each screen the model read with its tokens, every action the agent took, and every approval with a name and a time. That record shows what the model saw before it acted, which is the question an incident review asks first. It does not show what the model intended, and it does not establish that the claim was correct. It establishes the exposure, screen by screen, in a form an auditor can read.
Where should the placeholder be applied, in the page or in the model's prompt?
In the page, before the screenshot is captured. The tool's input is an image, so a filter on the prompt or on the model's text output runs after the pixels have already arrived. A prompt-side guardrail can still be useful for the text a model receives elsewhere, and it does not change what a rendered claims page puts in front of the model.
How RedactSure Keeps a Claims Page Readable Without Its Member Data
A placeholder value still leaves the screenshot as the input, and a claims page renders identity into it. Anthropic's documentation warns that Claude can follow commands found in content even when they conflict with its instructions.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the screenshot carries the member's name, member number, date of birth and bank account into the model's context for the rest of the run. Inside the governed environment, the page is drawn with MEMBER_2210, CLM_8841, DOB_1979 and ACCT_0031, the agent works the claim across those tokens, and the real values reach the payment form only when a claims lead approves the release, with that approval named in the AI Control Record.
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 member's name in a claims screenshot can travel anywhere the run does. Bring one claim from your queue and see, with test values, what the model reads and who approves the payment. Book a demo