Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is Microsoft Presidio Enough to Protect PII From AI Agents?
No, Presidio's documentation describes two modules that identify and de-identify PII "in text" an application sends them, so an agent that opens a support ticket in a console never calls them and the model reads every field the page draws. Ask what the model received on the screen and who approved the change.
A support ticket holds a customer's name, email address, order number, shipping address and date of birth, and Presidio is the library many teams run over text like that. Its documentation describes an analyzer that identifies PII and an anonymizer that removes it "using specific operators (such as redact, replace, hash or encrypt)", a control over text an application supplies (Microsoft, Presidio, 2026). An agent working the ticket does not call it: it opens the helpdesk console, and the console draws the page with every field in place.
A team that installed Presidio for a data pipeline can assume the ticket is covered, and the assumption holds for the pipeline and fails for the screen. What is at stake is the context of a whole run: a model that read a customer's name, address and date of birth can repeat them in a reply, a summary or a note it writes back, and a run over two hundred tickets holds the queue in its transcript. Detection makes a copy safer and does not decide what a screen shows (What Is the PII Wall?).
Key findings
- For Presidio to protect PII from an agent on a ticket, the values on the rendered page would have to be replaced with consistent tokens before the model reads it, so the agent works CUST_014 and SSN_014 and the real values stay out of the run (What Is Render-Layer Tokenization?).
- It would also require a named person approving the reply, refund or password reset the agent proposes, and a record of what the model read on each screen (What Is an AI Control Record?).
- Presidio's published documentation does not state that values on a page are replaced before the model reads them; its pages describe two modules an application calls with text, run in that order (Microsoft, Presidio, 2026).
- The analyzer identifies "PII in text" and the anonymizer de-identifies what it found "using specific operators (such as redact, replace, hash or encrypt)", and detection relies on recognizers built from patterns, lists, checksums and named-entity models (Microsoft, Presidio, 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 a console 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 a ticket attachment is an input channel into the same model (Sahib and Chaikin, 2025).
What does Presidio anonymize, and what does an agent read from a support ticket?
The record is one support ticket in a helpdesk console the organization bought: a subject line, the customer's name, email address, order number, shipping address, date of birth, and the free-text note. An integration copies that text for a warehouse, and the copy is where Presidio runs: the analyzer labels the entities, the anonymizer replaces them, and the stored copy carries the replacements. The other path is the page the console draws when an agent opens the ticket.
On that path the model receives the page as the console rendered it, the list row, the detail fields and the note, plus a screenshot when the agent reads the page as an image (What Does an AI Agent See in a Screenshot?). No component calls the analyzer at render time, because it is not attached to the page. Zendesk's role documentation shows what a console does govern: "you can define your own agent roles and assign agents to those roles" (Zendesk, 2026). A role decides which tickets an agent opens, not which fields the page draws.
The ticket that causes the most trouble includes a sign-in problem, so the agent resets the password. Microsoft's procedure requires "at least the Password Administrator role", the admin page autogenerates the password, and "The temporary password never expires" (Microsoft Learn, 2026). A model that read that page holds a working password for the customer until someone changes it, and the anonymizer never sees it unless the helpdesk application sends that field.
Why is detection accuracy the wrong test for an agent reading a screen?
A buyer usually asks how accurate the detection is, and the page reviewed publishes no rate for a support ticket: it is a conceptual overview of two modules for text. The accuracy question assumes the detector sits where the value passes, and in a support desk a value passes twice: as text an integration copies, and as a page the console draws.
Detection libraries sit in a wider field with the same boundary: 28 of the 86 AI security and data protection products reviewed control model input or mask a browsing layer, and none of the 28 describes giving an agent tokens it can work with on a screen (How Many AI Security Products Control What an AI Agent Sees?).
What detection rests on is public: recognizers that "leverage regular expressions, deny lists, checksum, rule based logic, Named Entity Recognition ML models and context from surrounding words" (Microsoft, Presidio, 2026). A checksum catches a card number; a customer's name in a note depends on the model and its context. A review of AI refusal makes the point about judgment calls: "because the mechanisms of refusal are probabilistic, they're never likely to be all that reliable" (MIT Technology Review, 2026).
Lower layers do not close the gap: every established layer of the security stack finishes its work before a page renders (Enterprise Browser or Render-Layer Tokenization?). Masking the page need not break the work: consistent pseudonyms restored after the model's work reduce semantic utility errors by a factor of five (Does Masking Data on Screen Break Browser Agents?).
What do the vendors themselves say?
Presidio is documented as two modules an application runs in order, and the documentation is explicit that they work on text. The analyzer identifies "PII in text"; the anonymizer de-identifies the entities it found "using specific operators (such as redact, replace, hash or encrypt)" (Microsoft, Presidio, 2026). The page lists redact, replace, hash and encrypt rather than a mask operator, defers operator detail to other pages, and adds that the anonymizer can de-anonymize, for example decrypting an encrypted entity, so the calling application holds the key and can reverse the operation.
The page is a conceptual overview, and it names no approval step and no log of what a model read. A control over what an agent reads on a console screen is not described in the pages reviewed, and the page's own scope is text an application supplies. That distinction decides the ticket: a console draws its page whether or not a library is installed, and the page is what the model receives.
| Dimension | Microsoft Presidio, per its documentation | What a buyer should verify |
|---|---|---|
| Where the control runs | Two modules an application calls, analyzer then anonymizer | Which of the agent's applications make that call |
| What it receives | Text the application supplies, described as "PII in text" | Whether the console's page ever becomes that text |
| Detection | Recognizers built from patterns, lists, checksums and named-entity models | Which recognizers are enabled for the fields a ticket holds |
| Operators | Redact, replace, hash or encrypt, with de-anonymization available | Who holds the key, and who can reverse the value |
| Approval and record | No approval step and no record of a model's input on the page reviewed | What the record shows of the screen, and whose name it carries |
Who approves the password reset, and what record shows what the model read?
The consequential action in the ticket is the reset, the refund or the status change, and the regulator's concern is that an agent takes it alone. FINRA's 2026 oversight report records the flag that "AI agents acting autonomously without human validation and approval" and adds that "Agents may act beyond the user's actual or intended scope and authority" (FINRA, 2025).
An approval that carries weight names a person and shows them what they approve: the reply, the refund, the reset. A systematic review of automation bias names the failure mode, "the tendency to over-rely on automation" (Goddard et al., 2012), which is what an approval queue becomes at two hundred tickets a morning. Presidio's documentation names no approval step, because the operators run when the application calls them (Microsoft, Presidio, 2026).
For a reset the approval has to sit in front of a credential. A credential-proxy vendor states the rule: "In short, the agent should not be trusted with direct access to any secrets." (Infisical, 2026). Microsoft's page shows why the ticket is a credential case: the temporary password is generated on the admin page and "never expires", so a model that read the page holds a live value (Microsoft Learn, 2026).
The record answers a different question from the transcript. A summary the model writes describes its reasoning; a record of the run shows the page it read, the action it proposed and the person who approved. That is the artifact an assessor asks for: the agent proposes, the person approves, and the approval lands beside the screen (What Is Supervised Delegation?).
What does a governed environment change?
A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the ticket shows CUST_014, MAIL_014, DOB_014 and SSN_014. Real values resolve only at an approved destination, at the moment of an approved action. A named person approves each reply, refund, status change and reset, and every screen as tokens, every action and every approval lands in a record that exports to the organization's monitoring.
For a support ticket it changes the unit that reaches the model. The ticket's copy can still go through an analyzer and anonymizer on its way to the warehouse; the page the agent reads is governed at the point it is drawn. The temporary password the admin page generates becomes a value the model never reads, and the reset waits for the person who approves it.
Its scope is the rendered page. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so an agent that pulls the same ticket through the helpdesk API is outside it and the API's own controls apply there. The comparison with the library is in (RedactSure vs Microsoft Presidio: 2026 Comparison & Alternative).
What the record shows
Three things decide whether PII reaches an agent's model: what the rendered page shows, who approves the action that follows, and what record survives the run. On a support ticket the page shows the customer's name, address, date of birth and the note, while the library's analyzer and anonymizer are called by an application with text and never see the console as it draws. What changes the outcome is a value substituted on the page before the model reads it: the agent works CUST_014 and DOB_014, the password never renders to the model, a named person approves the reset, and the record holds the page the model read. Name one ticket with a marked field, run the agent's task with test values, and put the model's input beside the screenshot: if the field the screen drew appears there, the library never saw that page.
Methodology and limitations
This page rests on Presidio's documentation, Microsoft's password-reset procedure, a vendor research post from Brave, a credential-proxy vendor's blog, FINRA's 2026 oversight report, a systematic review of automation bias, a benchmark for GUI agents, a review of AI refusal, Zendesk's role page and existing RedactSure research pages. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 20, 2026 and October 22, 2026, and each Sources line carries the date for its page.
No product on this page was tested for it. The products here are described from public documentation, and vendor features change; the page carries its date. Where it says a page or a screen is not described in the pages reviewed, it refers to the pages reviewed here. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a support ticket in a helpdesk console, and not an organization. Determinations belong to counsel, assessors and the organization's own officers, and nothing here replaces a pilot on its screens.
Frequently asked questions
Is Microsoft Presidio enough to protect PII from AI agents?
No. Presidio's documentation describes an analyzer that identifies PII and an anonymizer that de-identifies it, both running on text an application supplies (Microsoft, Presidio, 2026). An agent that opens a support ticket reads a page the console drew, and no call to those modules is made when it renders. Passing the console's text through the library beforehand changes the copy, not the page. The condition that changes the answer is substitution on the page before the model reads it.
What does the model read when an agent opens a support ticket?
The page the console rendered: the list row, the customer's name, email address, order number, shipping address, date of birth and the note, plus a screenshot when the agent reads the page as an image. Nothing on that path anonymizes a field, so whether a ticket is safe to hand an agent is a question about what the page shows rather than about what the library was told.
Can Presidio find every PII field on a rendered ticket?
Not from the pages reviewed. Detection rests on recognizers built from patterns, deny lists, checksums, rule logic and named-entity models (Microsoft, Presidio, 2026), so a name in a free-text note depends on the model and its context. The documentation is a conceptual overview and publishes no rate for a support ticket. Treat detection as a filter with a failure rate, and decide what reaches the model somewhere that does not depend on that rate.
Who approves a password reset an agent performs?
On the pages reviewed, no person is named. The reset procedure is a role, a page and an autogenerated password that "never expires" (Microsoft Learn, 2026), and Presidio's documentation names no approval step. FINRA's 2026 oversight report raises the same concern: "AI agents acting autonomously without human validation and approval" (FINRA, 2025). An approval that counts names the person and lands in a record.
What record shows what the model read on the console?
The library's record covers the calls an application made: text in, entities out. It cannot show a page it never received. What an agent read has to come from the environment it worked in, screen by screen, with the action and the approver beside it. A transcript the model writes is its account of its reasoning, not a record of its input.
Could an agent work a ticket if the page rendered as tokens?
Yes, when the tokens are consistent for the run. Replacing identifiers with consistent pseudonyms and restoring them after the model's work reduces semantic utility errors by a factor of five. The work stays readable, as Does Masking Data on Screen Break Browser Agents? sets out. The agent still reads a subject line, a status and a note; what it loses is the real name, address and date of birth. Work that needs those values waits for the person who approves it.
How RedactSure Keeps Ticket PII Out of the Model's View
Presidio protects the copy an application sends it, and the console page an agent reads is never that copy. Microsoft's own procedure autogenerates a temporary password that "never expires", so a model that reads the admin page holds a working credential for the customer (Microsoft Learn, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the ticket and the model receives the name, address, date of birth and the generated password. Inside: the ticket draws as CUST_014, MAIL_014 and DOB_014, the password never reaches the model, and the support lead approves the reset.
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 ticket that renders as tokens leaves a work record instead of a customer list, which is what an audit asks for. Bring one ticket and see, with test values, what the model reads and who approves the reset. Book a demo