Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Presidio Work on What an Agent Sees on Screen?
No, not by itself: Presidio identifies and de-identifies PII in text an application hands it, and its pages describe no capture of a screen, so a model reading a rendered page still sees the values. Ask what captures the page and runs it through Presidio before the model reads it.
A team that points an agent at a student account page answers for everything the page draws: a balance, a hold and a Pay Now link. A screenshot of that page is the whole input when the agent checks whether the hold has cleared. The model receives the page as the portal drew it, with every field the task does not need. Presidio is a library a team installs to find and de-identify PII in text, and a team that installed it for a data pipeline tends to assume the account page is covered. The library never sees the page: an application has to hand it text. What is at stake is the context of a whole run, since a model that read the balance, the hold and the identifiers can repeat them in a summary, a note or a reply (What Is the PII Wall?).
The practical question is where the library sits relative to the portal and the model, and whether anything on that path replaces a value before the model reads it. That is a question about placement, and it has a testable answer: one page, one agent, and the screen the model was shown. A team that cannot place the library cannot say what its model read.
Key findings
- For Presidio to work on what an agent sees on screen, something would have to capture the rendered page and hand its text to the modules before the model reads it, and Presidio's documentation describes no capture of a screen and no re-render of one (What Is Render-Layer Tokenization?).
- It would also require a named person approving the payment or record change the agent proposes, and a record of what the model was shown, which is the pair a text library does not supply (What Is an AI Control Record?).
- Presidio's documentation does not state that a rendered page is captured; the pages describe a library an application calls with text (Microsoft, 2026).
- A benchmark for screenshot-driven GUI agents reports that they "may inadvertently expose sensitive information such as identities, accounts, locations, and behavioral traces", which is what an account page puts in front of a model (Wang et al., 2026).
- Sahib and Chaikin showed that an attacker can "hide prompt injection instructions in images using a faint light blue text" that a screenshot-reading agent acts on, so the channel that carries a balance and a hold also carries an instruction, and the same image carries both (Sahib and Chaikin, 2025).
What does Presidio do with a rendered page?
Presidio's documentation describes two modules run in that order: an analyzer for "Identification of PII in text" and an anonymizer that de-identifies what the analyzer found (Microsoft, 2026). The operators are the caller's choice, "such as redact, replace, hash or encrypt", and the same page adds that the anonymizer can also de-anonymize, "for example decrypting an encrypted entity" (Microsoft, 2026). Both act on text, and the text arrives because an application sends it.
The record for this page is one student account page in a portal a university bought. North Carolina Central University's knowledge base describes the page: "The Account Summary page provides a high-level view of your student account, including:" the total owed, any holds and a payment portal (North Carolina Central University, 2026). An agent asked to check whether a hold has cleared opens that page, and the model receives it as the portal drew it, the balance, the hold and the payment portal included.
Nothing in the library is called when the page renders. To run the analyzer a team needs the text, so it adds a capture step and an extraction step in front of the modules, and the page the model receives stays as the portal drew it unless the pipeline replaces the values on the screen itself. A copy that runs through the anonymizer is a second artifact, and the model is not reading it (Screen-Level Tokenization vs API Filtering for AI Agents).
The work therefore sits in the pipeline: Presidio can be the detector inside a process that captures, extracts, applies a policy and re-renders the page, and that process decides what the model is shown.
Presidio is one of the 27 pipeline products in a review of 86 AI security products, and none of the 28 that control model input or mask a browsing layer describes giving an agent tokens it can work with on a screen (How Many AI Security Products Control What an AI Agent Sees?).
What does the model receive when an agent reads a screenshot?
When the agent reads the page as an image, the input is the picture: the fields the task uses, the fields it does not, the sidebar, the notifications and any text styled so a person cannot see it (What Does an AI Agent See in a Screenshot?). The model receives pixels, so a detector that takes text sits downstream of a conversion step the page never performs.
Sahib and Chaikin showed that an attacker can "hide prompt injection instructions in images using a faint light blue text" that a screenshot-reading agent acts on. The instruction arrives in the same image as the balance, and the model has no way to separate the two (Sahib and Chaikin, 2025).
Extraction for a filter is a separate task. A team can read the image, pull out text and run the analyzer over the result, and the copy is then anonymized while the image the model received is unchanged.
The split is not specific to student accounts. The rule for prior authorization requires an API "populated with its list of covered items and services" that can "identify documentation requirements for prior authorization approval", which is a field list for a transaction (Centers for Medicare & Medicaid Services, 2024). The portal page an agent opens still draws the member and the request, and a text library has no view of that page unless the integration hands it one.
What do the vendors themselves say?
Detection rests on recognizers that "leverage regular expressions, deny lists, checksum, rule based logic, Named Entity Recognition ML models and context from surrounding words" (Microsoft, 2026). A checksum catches a card number; a student's name in a note depends on the model and the surrounding words.
The page lists redact, replace, hash and encrypt rather than a mask operator, defers operator detail to other pages, and says nothing about blocking traffic or isolating credentials from an LLM (Microsoft, 2026).
| Dimension | Presidio, per its documentation | What a buyer should verify |
|---|---|---|
| Where the control sits | "Presidio analyzer : Identification of PII in text" and "Presidio anonymizer : De-identify detected PII entities using different operators", run in that order | The point in the run where a value is passed to the modules |
| Input | Text an application supplies | What captures the page and turns it into that text |
| Operators | "such as redact, replace, hash or encrypt" | Whether the result is a consistent token for the run or an irreversible removal |
| Detection | Recognizers built from patterns, deny lists, checksums and named-entity models | Whether the value the task needs survives in a usable form |
| Restoring a value | The anonymizer can de-anonymize, "for example decrypting an encrypted entity" (Microsoft, 2026) | Who holds the key, and whether a person approves the release |
| Record of a model read | No log of what a model was shown appears on the page | Whether the record shows the screen the model received |
GitHub's documentation says push protection "acts as a frontline defense mechanism by scanning code for hardcoded secrets at the time of the push", which is the same shape of control at a different layer: it knows the input it scans and says nothing about a screen (GitHub, 2026).
What a buyer can take from the pages is that the vendor documents its input, its operators and its recognizers, and leaves the placement question to the team that integrates the library.
Who approves the action, and what record does the run leave?
FINRA's 2026 oversight report warns that "AI agents acting autonomously without human validation and approval" and that agents "may act beyond the user's actual or intended scope and authority" (FINRA, 2025). FINRA's 2026 oversight report adds that "Complicated, multi-step agent reasoning tasks can make outcomes difficult to trace or explain, complicating auditability" (FINRA, 2025).
An approval that ratifies whatever the model proposed is not oversight. A systematic review of automation bias records "the tendency to over-rely on automation" as a pattern studied across fields, and a reviewer who approves twenty proposals in a row is the setting that pattern describes (Goddard et al., 2012).
The pages reviewed describe no approval step and no log of what a model was shown: the analyzer runs where an application calls it, and the record of the run lives wherever the integrating system puts it. A payment the agent proposes is approved in the portal or in an approval queue, and the library is not part of either.
For a team, the two questions to put in writing are who approves the payment, submission or record change, and what record shows the screen the model was given. The first is a named person outside the model (What Is Supervised Delegation?); the second is a record of what the model saw, what it did and who approved it (What Is an AI Control Record?).
What does a governed environment change?
A governed environment acts where the page is rendered. The values a policy names are replaced with consistent tokens before any model reads the screen, so the account page draws STU_001 and ACCT_001 and the agent works those on every screen of the run. Real values resolve only at an approved destination, at the moment of an approved action. A named person approves each payment, submission or record change, and every screen, action and approval is written to a record the organization can export.
For this page's question it changes the input and the timing. The detector can stay: an analyzer that finds PII in text is useful inside a pipeline that captures the page and applies a policy. What changes is that the substitution happens on the rendered page, before the model reads it, so the screenshot the model receives already carries tokens.
Columbia University's Data, Agents, and Processes Lab states that "trustworthy agent automation cannot be solved at a single layer of the stack" (Columbia University, 2026). A text library is one layer and the render is another, and the screen needs the second one to act before the model does.
The comparison page sets the two designs side by side, with the text modules in one column and a render-layer control in the other (RedactSure vs Microsoft Presidio: 2026 Comparison & Alternative).
What the record shows
On a rendered page the model receives exactly what the application drew, and only a control that acts at the render changes what is in that picture. Nothing on the library's pages puts it between the portal and the model: the analyzer is called by an application, the anonymizer works on the text it is given, and the screenshot the agent reads is unchanged. For the student account page that means the balance and the hold are in the model's context from the first screen. To test a vendor's claim, name one portal page and one agent, run the task with test values, and put the screen the model was given beside the screen a person sees; where the same value appears in both, the library is not in that path.
Methodology and limitations
This page rests on the Presidio documentation, a benchmark paper on screenshot-driven GUI agents, a vendor security post on image-borne instructions, a university knowledge base article, a regulator fact sheet, a regulator's report and a research lab's page. Vendor pages were read between October 16, 2026 and October 22, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where each product applies its control.
No product on this page was tested. Where the page says the pages reviewed do not describe something, that is a statement about the documentation and not about what the software can do. Vendor features change, and a reader should treat a release after this page's date as unreviewed. The products here are described from documentation, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a student account page in a portal a university bought, not an organization. Compliance determinations 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.
The NCCU article is a public knowledge base description of a page that requires a login, and it states no retention or disclosure policy; the page's fields are cited as a record type, not as a description of any institution's configuration.
Frequently asked questions
Does Presidio work on what an agent sees on screen?
No, not by itself. Its documentation describes an analyzer that identifies PII in text and an anonymizer that de-identifies what the analyzer found, and both take text an application supplies. A rendered page reaches the model as the portal draws it, so the modules see nothing unless a capture step sends them text. The condition that changes the answer is a control at the render that replaces values before the model reads the page.
Can Presidio anonymize a screenshot?
Not from the pages reviewed. The modules take text, the page defers operator detail to other pages, and no capture or image step appears in the documentation. A team can pull text from an image and run the analyzer over the copy, and that copy is not what the model received. Reading an image is work the integration performs, and the pages describe no such step. The screenshot stays as the portal drew it unless the pipeline substitutes values at the render.
Where would Presidio sit in an agent's run?
Between the text an application supplies and whatever consumes that text, which is usually a copy or a pipeline rather than the screen. If an integration captures the page, extracts the fields, runs the analyzer and applies an operator, Presidio is the detector in that chain. It is not the component that decides what the model is shown, and nothing in its pages places it between a portal and a model.
Does anonymizing the page's text protect the model?
Only for the text that was anonymized. A copy run through the modules is cleaner for logs, exports and downstream systems, and the model that read the screenshot never saw the copy. The value it read is still in its context and can appear in a summary or a tool call. A filter over a copy and a substitution on the page act on different objects. Protecting the model means changing what the page shows before the model reads it.
Who should approve a payment or record change the agent proposes?
A named person outside the model, with the authority the workflow requires and enough of the record to judge the proposal. An approval that ratifies whatever the model proposed is the pattern automation bias describes. The approval has to attach to the specific action rather than to the session or the tool, so a reviewer can stop one payment without ending the run. The record of that approval should name the action rather than the run.
What record proves what the model received?
One that shows the screen as the agent read it, the action it proposed and the name of the person who approved it. A log of API calls or a chat transcript answers a different question, because it holds what the model said rather than what the page showed. The record is only as good as the layer that produced it, which is why a render-layer control can emit one and a text library cannot.
How RedactSure Replaces the Values a Screenshot Would Show
An agent that reads a screen receives every value the page draws, and the text library never sees that page. Presidio's documentation lists redact, replace, hash and encrypt and no mask operator, which leaves the page untouched (Microsoft, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the model reads the balance, the hold and the student's details as the portal draws them, and its summary carries them for the rest of the run. Inside the governed environment the page draws STU_001 and ACCT_001 on every screen, and real values reach the payment portal only when a named person approves the payment.
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 balance and a hold on a student account page are the values a bursar will ask about first. Bring one portal your team does not own and see, with test values, what the model reads and who approves the payment. Book a demo