Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do You Assess an AI Agent Against the MLCommons Privacy Risk Taxonomy?

Take the taxonomy's risks one group at a time, name the control class for each, and record whether the risk is preventable at the rendered page or only managed afterward. For most groups it is preventable when values are replaced before the model reads the screen and the task still completes, so start with what the model receives.

A complex page is separated through successive layers into a small set of classified fields and shapes.

Take the taxonomy's risks one group at a time, name the control class for each, and record whether the risk is preventable at the rendered page or only managed afterward. For most groups it is preventable when values are replaced before the model reads the screen and the task still completes, so start with what the model receives. MLCommons published version 0.1 of an Agent Privacy Risk Taxonomy in October 2026 that catalogues 25 privacy risks posed by AI agents, as reported by PPC Land. A catalogue is not an assessment. A privacy officer handed a named agent and workflow needs a way to walk the list and reach a defensible answer for each entry: which control class addresses it, and whether that control acts before or after the agent is exposed to the data. This page groups the risks into four classes drawn from the standards it cites, maps each to a control class and a verdict, then sets out what the vendors document and what changes in a governed environment. It builds on research on AI agent data minimization and on research on whether it is safe to deploy AI agents in regulated enterprise environments.

Key findings

  • MLCommons has catalogued 25 privacy risks posed by AI agents in version 0.1 of its Agent Privacy Risk Taxonomy, as reported by PPC Land (PPC Land, 2026).
  • The GDPR's data minimisation principle, in Recital 39 and Article 5(1)(c), requires personal data to be adequate, relevant and limited to what is necessary for the purposes for which they are processed, which sets the standard for an agent's input (EUR-Lex, 2016).
  • The European Data Protection Board's pseudonymisation guidelines hold that pseudonymised data that can be attributed to a person remains personal data, while recognizing that pseudonymisation reduces risk; a token substituted for an identifier does not take the data out of scope (EDPB, 2025).
  • OWASP's sensitive information disclosure entry describes the exposure as data the model holds leaving through any output, which makes what the model receives the first variable in any privacy assessment (OWASP, 2025).
  • NIST's Generative AI Evaluation Program assesses generative AI technologies submitted by researchers and does not describe agent governance or screen-level controls, so an enterprise cannot outsource this assessment to it (NIST, 2026).
  • A consistent, repeatable assessment depends on knowing which data an agent received on each screen, the record type described in research on what an AI Control Record is.

Which risks concern what the agent collects, and can they be prevented at the page?

The first class is collection: the agent receives more personal data than the task requires. PPC Land's report describes the taxonomy as cataloguing 25 risks posed by agents handling personal data (PPC Land, 2026); the collection risks are those where the exposure happens at intake, before any use, storage or disclosure.

The standard is data minimisation. GDPR Recital 39 and Article 5(1)(c) require personal data to be adequate, relevant and limited to what is necessary for the purposes for which they are processed (EUR-Lex, 2016); for an agent, the purpose is the task. OWASP's sensitive information disclosure entry makes the same point from the security side: the data the model holds is the data that can leave (OWASP, 2025).

Take a patient scheduling screen in a practice management system showing name, date of birth, medical record number, insurance member ID, phone number and reason for visit. The agent's task is to move the appointment to the next open slot and send the standard confirmation. Without a control, the model reads all six fields and needed two. With substitution before the read, the model receives PATIENT_001 for the record number, MEMBER_001 for the insurance ID and PHONE_001 for the phone, and the appointment still moves, because the move is an action on the record the token denotes. The confirmation reaches the real number when PHONE_001 resolves at the approved send step.

Control class: substitution at the render. Verdict: preventable at the page, because the control acts before the exposure exists. The assessment should record, for each screen in the workflow, which fields the model received; research on AI agent data minimization sets out how to define the necessary set.

Which risks concern use and disclosure beyond the purpose, and where does the control act?

The second class is use and disclosure: data the agent received is used for a purpose other than the task, or disclosed to a party, a system or an output where it should not go. For health data, the HIPAA Privacy Rule's provision on uses and disclosures of protected health information at 45 CFR 164.502 is the operative text, and it governs an agent acting for a covered entity as it governs any other workforce action (eCFR). Treasury's report on AI in financial services recommends that firms prioritize review of AI use cases for compliance with existing laws before deployment (U.S. Department of the Treasury, 2024), which for this class means mapping each place the agent could send data before the agent runs.

The disclosure paths are the model provider, the agent's memory, every tool or form it can submit to, and its answers to the user. On the scheduling screen, the agent that read the real member ID can place it in the confirmation message, in a note on another patient's record if it confuses two tabs, or in a request to a web page it visits. Each path needs a control if the value is in the model. If the model holds MEMBER_001, each path carries a token, and the real value appears only at the approved destination at the moment of an approved action.

Control class: approved destinations with resolution only at the approved action, and a named person approving consequential actions. Verdict: preventable at the page for data the agent obtained from the screen, because a model that holds tokens cannot disclose values. Not preventable at the page for data the agent obtained elsewhere, through an API connector or a document store, where the page control never saw it. The assessment should record, for each disclosure path, whether the data on that path could have been real.

Which risks concern re-identification and inference, and do tokens remove them?

The third class is re-identification and inference: the agent, or a party reading its outputs or memory, links pseudonymous data back to a person or infers a sensitive attribute from what remains. This is the class where token substitution is most often oversold. The European Data Protection Board's pseudonymisation guidelines hold that pseudonymised data that can be attributed to a person remains information related to an identifiable natural person, so it is still personal data, while recognizing that pseudonymisation can reduce risk and support legitimate interests as a legal basis (EDPB, 2025).

On the scheduling screen, PATIENT_001 is a pseudonym: the organization holding the mapping can re-identify the patient, and the record remains personal data. What changes is who else can. A model that received PATIENT_001, a reason for visit and an appointment time holds less than a model that received the record number, the name and the date of birth, and a party who extracts the model's memory or reads its output holds the same reduced set. The inference risk, that the reason for visit alone reveals a health condition, is not removed by tokenizing identifiers; it is addressed by deciding whether the reason-for-visit field is in the necessary set at all.

NIST's Privacy Framework frames this as the identification and inference problem the enterprise manages through its own risk assessment rather than a property a tool provides (NIST, 2020). Control class: consistent tokens that resolve only inside the governing environment, with a named person setting the policy. Verdict: partly preventable at the page. Linkage by anyone outside the environment is prevented; legal scope is unchanged; inference from non-identifier fields depends on the policy, not the mechanism.

Which risks concern oversight and accountability, and what evidence does the assessment need?

The fourth class is oversight: no person is accountable for what the agent did, no record exists of what it received and did, and no process reviews either. NIST's AI Risk Management Framework organizes this under its govern, map, measure and manage functions (NIST, 2023). It does not name agents; it applies.

An external evaluation does not substitute for this. NIST's Generative AI Evaluation Program assesses generative AI technologies developed by the research community, evaluating systems submitted by researchers; it does not describe agent governance or screen-level controls (NIST, 2026). A privacy officer cannot cite that program as an assessment of the agent in front of them.

The worksheet below is the output of the four sections.

Risk class (this page's grouping) Control class Preventable at the rendered page?
Collection beyond the task Substitution before the model reads the screen Yes
Use and disclosure beyond purpose Approved destinations; named approver for consequential actions Yes for screen-read data; no for data obtained through connectors
Re-identification and inference Tokens resolve only inside the environment; policy sets the necessary set Partly; legal scope unchanged
Oversight and accountability Exported record of every screen, action and approval Evidence produced at the page; review process is the organization's

Verdict for this row: the page produces the evidence; the oversight itself is a process. The assessment should name the accountable person for each agent and workflow and confirm the record exists before the agent runs.

What do the vendors themselves say?

The vendor documentation reviewed here comes from Microsoft Purview and describes a control class that sits after the model rather than before it. Microsoft's page on Purview data security and compliance protections for generative AI apps describes the use of Purview's classification, data loss prevention and audit capabilities to govern interactions with generative AI applications (Microsoft Learn, 2025). Its deployment model for preventing data leaks to shadow AI, together with discovery of AI apps through Defender for Cloud Apps, describes finding which AI applications users reach and applying policy to the data flowing to them (Microsoft Learn, 2025).

Mapped to the worksheet, these capabilities address the disclosure and oversight rows: they inspect what moves toward an AI application and record it. What the model receives from a rendered screen inside an application a user is permitted to open, the collection row, is not described in the pages reviewed as something these controls change. Whether Purview can substitute a value on a screen before an agent reads it is not described in the pages reviewed. The collection row should be answered with other evidence.

The MLCommons taxonomy itself is known to this page only through PPC Land's report, which describes 25 risks in version 0.1 (PPC Land, 2026); the primary MLCommons page was not reachable when this page was prepared, and the taxonomy's own text is not quoted here beyond what the report gives. A privacy officer should obtain the primary document and align the four classes above with its grouping.

What does a governed environment change?

In a governed environment, the collection row of the worksheet is answered before any other, because the sensitive values on each screen are replaced with tokens before the model reads them and the task still completes, so most of the taxonomy's risks are assessed against a model that never held the values.

The mechanism is a class of control that sits between the rendered page and the model. Identifiers and other sensitive values on each screen are replaced with consistent tokens before the model receives the screen, so the same patient reads as PATIENT_001 across every page of the run and the agent can act on the record as a stable reference. The real value resolves only at an approved destination at the moment of an approved action, such as the recipient field of the confirmation message. A named person confirms which values are tokenized and approves consequential actions, including record changes and submissions. Every screen as the model received it, in token form, and every action and approval is recorded and exported to the organization's own logging.

Against the four classes, the effect is uneven. Collection is prevented for the tokenized fields, which is what data minimisation requires (EUR-Lex, 2016). Disclosure through any path the model controls carries tokens. Re-identification by parties outside the environment is prevented, while the data remains personal data in the EDPB's sense (EDPB, 2025). Oversight receives its evidence. The control does not reach data the agent obtains outside the rendered page, and it does not change the organization's accountability for deciding what is necessary.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Agents work inside a governed environment in the customer's own cloud. On every rendered page, including the patient scheduling screen described above, substitution happens at the render layer before any model reads the screen, so the medical record number reaches the model as a consistent token such as PATIENT_001 for the whole run, and an account identifier on a billing screen as ACCT_001. Real values resolve only at approved destinations at the moment of an approved action, which for the scheduling task is the recipient field of the confirmation when the send is approved. A named person confirms the tokenization policy and approves every payment, submission and record change, the arrangement RedactSure calls Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged. The legal status of the tokens and the necessary set remain the customer's determinations.

Deployments are in pilot. A pilot on the reader's own workflow would produce the worksheet filled for one agent and one record type, with the screens as the model received them attached as evidence for each row. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on PPC Land's October 2026 report of the MLCommons Agent Privacy Risk Taxonomy version 0.1, the GDPR as published on EUR-Lex, the European Data Protection Board's January 2025 announcement of its pseudonymisation guidelines, the HIPAA Privacy Rule provision on uses and disclosures at 45 CFR 164.502, the NIST Privacy Framework, the NIST AI Risk Management Framework, NIST's Generative AI Evaluation Program page, Treasury's December 2024 report on AI in financial services, OWASP's sensitive information disclosure entry, Microsoft's Purview documentation, and published RedactSure research pages on regulated deployment, data minimization, render-layer tokenization and the AI Control Record. All sources were read as of October 16, 2026.

The MLCommons taxonomy is cited as reported by PPC Land; the primary MLCommons page returned a server error when this page was prepared, and the four risk classes used here are this page's grouping drawn from the cited standards, not the taxonomy's own structure. No hands-on testing of any product was performed. Where Purview is described as not changing what a model receives from a screen, the statement means not described in the pages reviewed. Vendor features change and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The patient scheduling screen describes a record type, not any organization; the fields and token names are illustrative.

Whether a given agent and workflow meet an organization's obligations under the GDPR, HIPAA or any other regime is a determination for its counsel, its assessors and its own privacy, security and compliance officers, not for a research page.

What the record shows

A taxonomy of 25 agent privacy risks becomes an assessment when each risk is placed in a class, matched to a control class and given a verdict on where the control acts. Grouped against the standards cited here, the risks fall into collection, use and disclosure, re-identification and inference, and oversight. Collection can be prevented at the rendered page by replacing values before the model reads them; disclosure of screen-read data follows from that; re-identification by outsiders is prevented while the data stays personal data in the regulator's sense; oversight is a process that the page can evidence but not perform. RedactSure's environment is one implementation of the page-level control. The test is to name one agent and one task on one record type, run the four rows, and ask for the record of what the model received on each screen as the evidence for the first.

Frequently asked questions

Does this page reproduce the MLCommons taxonomy's list of 25 risks?

No. The taxonomy is known to this page through PPC Land's report, which describes version 0.1 cataloguing 25 privacy risks posed by AI agents. The primary MLCommons page was not reachable when this page was prepared, so the taxonomy's text is not quoted beyond what the report gives, and the four classes used here are this page's grouping. A privacy officer should obtain the primary document and map its entries into the worksheet rows.

If identifiers are tokenized, is the data still personal data under the GDPR?

Yes. The EDPB's pseudonymisation guidelines hold that pseudonymised data that can be attributed to a person remains information related to an identifiable natural person. The organization holding the token mapping can re-identify the record, so GDPR obligations continue to apply. Pseudonymisation reduces risk and can support a legitimate interests basis; it does not remove the data from scope, and an assessment should say so.

Why does the assessment start with what the model receives?

Because every later risk depends on it. Use, disclosure, memory extraction, inference and re-identification all operate on data the model holds. If the model received a token in place of an identifier, the disclosure, memory and linkage risks for that identifier are assessed against a value that is not there. Starting anywhere else assesses controls on channels while leaving the first variable unmeasured.

Can an external evaluation program assess the agent for us?

Not the programs reviewed here. NIST's Generative AI Evaluation Program assesses generative AI technologies submitted by the research community and does not describe agent governance or screen-level controls. The assessment on this page is specific to a named agent, a named workflow and the organization's own record types, which no general program evaluates. The organization's privacy officer runs it, with the vendor supplying the evidence for each row and the organization keeping the completed worksheet with its risk register.

How does Microsoft Purview fit the worksheet?

Its documented capabilities, classification, data loss prevention, audit and discovery of AI applications, fit the disclosure and oversight rows: they inspect and record what moves toward an AI application. Whether it changes what a model receives from a rendered screen inside a permitted application is not described in the pages reviewed, so the collection row should be answered with other evidence, such as the screens as the model received them during a test run.

What does a completed worksheet look like for one agent?

Four rows, each with the control class in place, the verdict, and the evidence attached: for collection, the screens as the model received them; for disclosure, the list of destinations and who approved consequential actions; for re-identification, the tokenization policy and a statement that the data remains personal data; for oversight, the accountable person and the exported record. One agent, one workflow, one record type per worksheet.

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.