Skip to content
redactsure
Book a demo

Explore.

Guide · By Chris Sowa · Published
Last updated

How to Secure AI Agents That Read Documents and Navigate Browser Screens: Two Surfaces, One Control, One Named Person

Render every document and screen inside an environment you own, hand the model the task's fields with identifiers as tokens, and route each consequential action through 1 named person.

Document stacks pass through a guarded doorway as tokens into a browser workflow.

62% experimenting · 23% scaling · 1 named person

62% of organizations are experimenting with AI agents and 23% are scaling them anywhere (CX Today, 2026). The agents that stall are the ones that read. A claims agent opens a scanned claim form and carries the claimant into the claims platform, then the payment portal. Each task spans two surfaces, a document and a screen, and the agent you are evaluating receives both in full.

Troy fell to a gift carried inside the walls and opened there. A document is that kind of object: inert until something reads it, and then everything in it is in the room, including the name, the number and the date of birth the task did not ask for.

You probably run the agent in an employee's browser, where it receives screenshots of the active tab, personal data included, or in a vendor's cloud computer, where the password stays out of the model and the page goes to it whole. Neither answers the question: what will the model receive from each surface, and who approves what it does next?

A document is rendered before it is read, like a screen, so one control at the render layer covers both, and one named person covers every action.

An opened attachment reaches the model whole, as a Claude in Chrome screenshot does

Claude in Chrome's guidance says screenshots of the active tab are captured and all visible information, personal data included, becomes part of the context (Claude Help Center, 2026). OpenAI's dots documentation says the model sees webpage text and document content within connected apps (OpenAI, 2026).

A document agent is no different in kind. The PDF is decoded, the scan is recognized, and the result is a page the model reads whole: the referral with the MRN, the claim form with the SSN.

That is where the PII Wall appears: the point in an AI program where the valuable workflow turns out to run on data the security team will not let a model see, and the project shrinks or stops.

A document is rendered before it is read, and so is a screen. Rendering is the one step both share, so one control there covers both. The principle that policy enforces is Least Exposure: for each piece of work, the AI receives exactly the data the task requires and nothing more, enforced before any model reads the screen.

3 places the agent can run, and you own 1 of them

Property Employee's own browser Vendor's cloud computer Customer-owned governed environment
Model receives from a screen The active tab in full (Claude Help Center, 2026) The page in full (OpenAI, 2026) Task fields, identifiers as tokens
Model receives from a document The attachment in full Document content in connected apps, in full (OpenAI, 2026) Task fields, identifiers as tokens
Key holder The employee's machine Not disclosed (OpenAI, 2026) The customer

The vendor warns against opening the extension near sensitive documents (Claude Help Center, 2026).

The second column fixes only the password. Secure sign-in for dots submits credentials without exposing them to the model (OpenAI, 2026). The page the password opens still goes to the model whole.

Only the third column allows a tethered agent: an agent that works only inside the governed environment a named person connected it to, on the applications that person chose. Other tabs do not exist for it (Should an AI Agent Run in the Employee's Own Browser?, 2026).

Copilot Studio's documentation says a reviewer who did not run the agent cannot verify the request

Microsoft's computer use documentation states the limit of a vendor's view: a reviewer who did not run the agent "can't properly verify or act on the request" (Microsoft Learn, 2026). A view is a control only when the person watching is the person approving, and a queue reviewer did not watch.

Asked whether Purview DLP enforces against a computer-use agent reading a screen, a Microsoft Q&A moderator's reply is that the documentation does not describe such enforcement (Microsoft Q&A, 2026).

Property DLP policy Vendor activity view Render layer plus named person
Acts on Content routed through a channel The run, during or after The render, before any model reads it
A document the agent opens Covered only in a monitored channel Shown as opened Task fields in clear, identifiers as tokens
A screen the agent reads Not described for a computer-use agent Shown in clear The same tokens as the document

One policy carries CLAIMANT_001 from the PDF to the claims platform to the payment portal

The control is render-layer tokenization: replacing sensitive values with consistent stand-in tokens at the point where a screen is rendered, before any AI model reads it, so the model works with SSN_001 and ACCT_001 and real values resolve only at approved destinations at the moment of action.

Consistency makes it work across two surfaces. The claimant on the scanned form, in the claims platform and on the payee line is the same CLAIMANT_001, so the agent matches all three without holding the name. Masking cannot do that (Masking vs Tokenizing Data for AI, 2026).

The policy is per task and names both surfaces. For a chart, the diagnosis codes, dates of service and payer stay in clear, the patient and the MRN are PATIENT_001. For a claim, the loss date and reserve stay in clear, the claimant is CLAIMANT_001 and the SSN is SSN_001 (What Should the AI See?, 2026). For a health record, that is the minimum necessary standard at 45 CFR 164.502(b) applied to a model (eCFR, 2026).

Greshake et al. showed in 2023 that content on either surface can steer the agent

0.08% attack success in one vendor's internal testing · 2 classifiers · 1 named person waiting on the action

Indirect prompt injection, where observed content redirects the agent, was demonstrated against real LLM-integrated applications (Greshake et al., 2023), leads the OWASP list as LLM01 (OWASP, 2025), and appears in Microsoft's taxonomy of agent failure modes (Microsoft AI Red Team, 2025).

Anthropic runs two classifiers for Claude in Chrome and reports attack success under 0.08% in internal testing (Claude Help Center, 2026).

A classifier reduces how often an attempt works, not what a successful attempt collects. If the model holds the referral PDF whole, a successful injection gets the patient's name and address. If it holds the task's fields with identifiers as tokens, the same injection collects PATIENT_001 (Prompt Injection When the Agent Sees Only Tokens, 2026).

"Send this record to the address below" is a consequential action, and every send, submission, payment and record change waits for the named person, who declines it.

The AI Control Record is where OMB M-24-10's human oversight becomes evidence

The record that works is the AI Control Record: the record of every screen the agent saw as tokens, every action, every approval with a name, exported to the customer's own monitoring. Not screenshots, which are the record in clear, stored again.

The approval in that record is Supervised Delegation: a named person grants the access, chooses the applications, confirms what is tokenized, can watch and pause the run, and approves every consequential action, on the record. A drafted letter holds CLAIMANT_001 until the person approves sending it.

For an agency, OMB M-24-10 sets minimum practices for rights- and safety-impacting AI, including human oversight and monitoring (OMB, 2024).

One more property keeps the record yours over time: separation of model and control, the principle that the environment deciding what an AI agent sees and who approves what it does is owned by the customer and independent of whichever model performs the work.

6 Rules for securing an agent on documents and screens

Walk the workflow by hand and list every surface

Open the task yourself once and list every document and screen it touches, with the fields the task needs on each. Names, numbers and dates of birth are rarely on it.

Surface Fields in clear Tokens
Scanned claim form (PDF) Loss date, description, reserve CLAIMANT_001, SSN_001
Payment portal, new payment Amount, date CLAIMANT_001, ACCT_001

Write one policy that names both surfaces

One policy, not one per surface, so the tokens stay consistent from the PDF to the screen, naming tokens, consequential actions and approvers.

Before: The document pipeline redacts names; the browser agent has its own allowlist; the two cannot be matched.

After: CLAIMANT_001 on every surface; payment on the portal is consequential; the adjuster approves.

Run the agent only inside an environment you own

A customer-owned virtual machine with keys you hold bounds what exists for the agent (Does an AI Agent Need Its Own Virtual Machine?, 2026).

Test: From inside the environment, try to reach an application that is not on the list. The attempt fails and lands in the record.

Render and tokenize the document before anything reads it

The scan is rendered as a page and the render layer tokenizes the page. Test an image-only scan with a sample document.

Before: The model's input for the referral is the referral.

After: The model's input for the referral is diagnosis codes, dates of service, payer and PATIENT_001.

Make the watcher the approver, with "automatically approve" off

The person who confirms the policy watches the run, can pause it, and approves each consequential action. Claude in Chrome defaults to automatic approval (Claude Help Center, 2026); for work with a payment or a send, the setting is manual (Should an AI Agent Have an Always-Allow Setting?, 2026).

Design Result
Approver sees the vendor's queue Signing what they did not see
Approver is the named person who watched Approval with a name, on the record

Export the record as tokens to your SIEM, never as screenshots

Every screen as tokens, every action and every named approval goes to the monitoring you already run.

Test: Pull one run from the SIEM. It shows the pages as tokens, each action and the name on each approval, and no real identifier.

How to choose where the agent reads and works

  • If the task touches no identifiers and no consequential action, a vendor's cloud computer with automatic approval is adequate.
  • If the task opens attachments that carry a name, a number or a date of birth, render and tokenize the document in an environment you own before any model reads it.
  • If the task works a screen with a patient banner or a claimant header, hand the model the task's fields with identifiers as tokens, under the same policy.
  • If the task pays, submits, changes a record or sends a document, the action waits for one named person who watched the run, with "automatically approve" off.
  • If the work falls under 45 CFR 164.502(b) or OMB M-24-10, export the AI Control Record to your SIEM as tokens with a name on every consequential action.
  • If you expect to change models within the contract term, keep the policy, the render layer and the approver in an environment you own, so only the model moves.

The checklist

Check Pass Fail
Model input for one sample document Task fields in clear, identifiers as PATIENT_001 The document, or a page with names in it
Model input for one screen in the same task The same tokens as the document Different tokens, masks or clear values
Image-only scan tested Page recognized, identifiers tokenized Untested, or identifiers in clear
Where the agent runs Customer-owned environment, your keys Employee's browser or vendor's cloud computer
Applications reachable from inside Only the ones on the list Every tab and session on the machine
Approver for each consequential action The named person who watched A queue reviewer or nobody
Planted instruction on each surface Tokens collected, action waited Real values collected, or action ran
Record in your SIEM Every screen as tokens, every action, every named approval Screenshots, or only the vendor's view

Questions

Can an agent read a scanned PDF without seeing the patient's name?

Yes, when the scan is rendered as a page before anything reads it and identifiers become tokens at the render. The model receives the diagnosis codes, dates of service and payer with the patient and the MRN as PATIENT_001; the clinician's screen keeps the real values. Image-only scans depend on what the render layer recognizes; test one from your own intake before you sign.

Does the agent keep what it read after the task?

In an environment you own, the model received tokens, so there is nothing of the record to keep; what remains is the AI Control Record in your SIEM, as tokens. For a vendor design, read its documentation: AgentCore Browser sessions reset after use (AWS, 2026), and the dots safety document does not disclose the key holder or data location (OpenAI, 2026).

What about documents the agent itself writes?

A letter or form the agent drafts is written from a context that holds tokens, so the draft holds CLAIMANT_001 and SSN_001. Real values resolve only at approved destinations, and for a document that destination is the send, which the named person approves. Until then the draft carries tokens, and a document that leaves early leaves with tokens in it.

Does the agent need its own machine?

Yes, and not the employee's. An agent in the employee's browser receives screenshots of the active tab, personal data included, which is why the vendor's guidance says to avoid it near sensitive documents (Claude Help Center, 2026). A vendor's cloud computer puts it on infrastructure whose key holder you do not control. A customer-owned virtual machine with keys you hold bounds what exists for the agent.

Can a DLP policy catch what an agent reads from a screen?

Not as documented today. A Microsoft Q&A moderator's reply says Purview DLP's documentation does not describe enforcement against a computer-use agent (Microsoft Q&A, 2026). DLP inspects what is routed through it, and an agent reading a screen routes nothing. A render layer changes what the model is handed in the first place (Does Purview DLP Cover What a Computer-Using Agent Reads?, 2026).

Why tokens and not masking?

Because the agent has to relate the document to the screen. The claimant on the PDF and in the claims platform are both CLAIMANT_001, so the agent matches them without holding the name, and the same token carries into the payment portal. A mask is a blank, and two blanks cannot be matched (Masking vs Tokenizing Data for AI, 2026).

Do the user's permissions change?

No. The named person connects the environment to the applications under the permissions they already hold, and the agent works inside that. Permissions govern what an identity may do; exposure governs what a model may see. Only exposure changes: the model receives the task's fields with identifiers as tokens instead of the document or the screen (Does Least Privilege Cover What AI Sees?, 2026).

Methodology

What this page rests on. Vendor documentation for Claude in Chrome, dots, Copilot Studio, Purview and AgentCore Browser, read as of October 9, 2026; 45 CFR 164.502(b), OMB M-24-10, OWASP LLM01; Greshake et al. (2023) and the Microsoft AI Red Team (2025); and CX Today's report of McKinsey's State of AI 2026.

What was not tested. No hands-on testing of the named products was performed. Vendor settings and documentation change with releases, and this page carries its date for that reason.

Whose determination it is. Whether a deployment meets the minimum necessary standard or OMB M-24-10 is a determination for the organization's counsel, assessor and security and compliance officers. This page describes designs and documents; it does not make that determination.

How RedactSure does this

RedactSure runs the agent inside a governed environment the customer owns: a secure virtual machine in the cloud the customer's posture requires, with keys the customer holds. RedactSure holds ciphertext it cannot decrypt. Every document and screen is rendered inside that environment, and the render layer replaces every sensitive value chosen by policy with a consistent token before any model reads it: the same CLAIMANT_001 on the scanned form, in the claims platform and in the payment portal.

1 policy per task · 1 named person per workflow · 0 real identifiers in the model's input

The Planner sets which values are tokenized and what the agent may do on each screen. A named person confirms that policy before the run, watches the tokenized stream, and approves every payment, submission and record change. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's own SIEM. The model is swappable; the controls and permissions stay put. Deployments are in pilot.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.