MLCommons, the open engineering consortium behind the MLPerf benchmarks, on October 1, 2026 published the first draft of a framework that sorts the ways autonomous software agents can mishandle personal information into 25 numbered vectors across five domains, and pairs them with a six-stage method for tracing an incident from its trigger to the harm that follows.

In Short

An industry group called MLCommons has written down 25 ways that AI assistants which act on someone's behalf - reading email, booking things, talking to other software - can mishandle private information. It matters because these assistants are being plugged into email, calendars and business tools, where they can leak data even when the answers they show on screen look harmless. Nothing is enforced yet: the list is a draft open for comments, and the group wants to turn it into tests that score how well each assistant protects data, with that work aimed at 2027.

A draft, not yet a standard

The document, titled Agent Privacy Risk Taxonomy, runs to 15 pages. Its cover places it under MLCommons' AI Risk & Reliability programme and the AILuminate Assessment Standard, and attributes it to the Privacy and Confidentiality Working Group. Nineteen authors are listed in alphabetical order. None of their affiliations is printed.

Two details differ between the paper and its announcement. The paper is dated September 2026 and labelled "V.01", while MLCommons' announcement post, dated October 1, refers to the release as v0.1. Both describe the same first draft, and the abstract is plain about its status: "This is the first draft of the Agent Privacy Risk Taxonomy. We welcome feedback from the AI community so that we can iteratively refine."

The working group's web page profiles two people. Kristie Chon Flynn is Google's Data Protection Officer, according to the page, and previously served as chief privacy officer at PayPal and at HCL Technologies. Vinh Nguyen is Senior Fellow for Artificial Intelligence at the Council on Foreign Relations; the page says he became the National Security Agency's first chief responsible AI officer and chief data scientist for operations, and served as the National Intelligence Council's most senior cyber analyst. According to MLCommons, the announcement post was written by Andrew Gruen together with Chon Flynn and Nguyen. Gruen does not appear in the paper's author list.

One name invites a check. The list includes "Damien Desfortaines", a spelling one letter away from Damien Desfontaines, the privacy engineer who published an account of the anonymisation method in the European Commission's Google search data-sharing decision on September 10. With no affiliations given, the document does not settle whether the two are the same person.

From what a model knows to what an agent does

According to the working group's page, frontier and agentic deployments raise privacy risks that developers and deployers need to assess, yet "no standard framework exists for measuring how models and agents perform against them." The page frames the change in one line: as AI moves from chatbots to autonomous agents, the risk moves "from what a model knows to what it does." Agents acting for a user, often through opaque tool-use chains or secondary data channels, "can compromise privacy even when their direct responses are secure", according to MLCommons.

That distinction carries weight. Earlier privacy work on large language models concentrated on what a model memorised or disclosed in its answers. The European Data Protection Board's report of April 10, 2025 set out eleven privacy risks for LLM implementations, and research published on June 18, 2025 estimated that models can memorise between 0.1 and 10 percent of their training data. The working group keeps a strand on memorisation - it says it is developing methods to reduce recall of sensitive data across pre-training and post-training - but the new paper is about behaviour: what an agent collects, keeps, passes on and does.

The stated goal for that behaviour is data minimisation, with agents using only the data necessary to fulfil what the user intended. A commercial argument sits next to it. "Without shared standards, these risks will slow AI adoption for consumers and enterprises alike", the page states.

Extended, not replaced

The paper builds on four reference points: Daniel Solove's Taxonomy of Privacy, the NIST Privacy Risk Model (NIST IR 8062), the NIST Artificial Intelligence Risk Management Framework (NIST AI 100-1) and Helen Nissenbaum's theory of contextual integrity. Those models, the authors write, "assume deterministic data flows, centralized storage, and clear perimeter boundaries." Agents break each assumption. They execute code, retain memory across sessions and orchestrate calls to outside tools and protocols, which leads the authors to conclude that "these established frameworks must be extended rather than replaced."

The extension takes the form of agent-specific primitives - continuous tracking, trajectory logging, memory poisoning and over-privileged handshakes between agents - slotted into five failure domains. According to the document, the method draws on the expertise of the cross-industry working group, analysis of known incidents and those foundational frameworks. The incidents are not named.

Five domains, 25 vectors

Each entry carries an identifier, a risk vector, a cause and a privacy impact. The distribution is uneven: data ingestionaccounts for seven vectors, aggregation, use and sharing for nine, inconsistent practices across agents for three, the failure of legacy consent systems for four, and accountability and governance for two.

Data ingestion: seven routes in

Continuous tracking (R1.1) covers background agents built for proactive assistance that monitor keystrokes, application states, ambient audio, email and calendars. The paper says such constant intake violates minimisation and supports intrusive inferences, including potential profiling of other people around the user.

Unintended collection (R1.2) covers data gathered beyond the scope, purpose or intention of the user. Trajectory logging (R1.3) is subtler. Trajectories - the step-by-step record of an agent's inputs, reasoning and tool calls - are essential for debugging, evaluation and reinforcement learning, yet they contain raw user data, and the paper treats them as a severe exposure risk where users lack granular control and retention policies are opaque. Session persistence (R1.4) describes memory spanning sessions and platforms, so that information volunteered for one low-risk transaction stays accessible and shapes decisions in unrelated contexts.

Then there is redaction. Regular expressions and heuristic pipelines were designed for structured identifiers such as social security and credit card numbers. They fail, according to the paper, on fuzzy quasi-identifiers in unstructured text, leaving what the authors call "semantic PII" that can be used to re-identify people (R1.5).

The two remaining ingestion vectors concern what the agent reads and whom it talks to. Under R1.6, attackers hide instructions - invisible text, metadata or structured system commands - in emails, websites and documents that an agent processes at run time. The paper calls these indirect prompt injection attacks; a model that cannot separate them from legitimate system commands can be steered into extracting and sending out personal data. The pattern is documented in consumer products: Brave's security team disclosed indirect prompt injection flaws in Perplexity's Comet browser on August 20, 2025, showing that hidden webpage content could be used to take credentials and one-time passwords.

R1.7, over-privileged inter-agent data handshakes, is the entry closest to advertising infrastructure. It names the Model Context Protocol, the standard through which most agentic ad tech tools now call outside software. "AI agents operating over protocols like MCP default to sharing exhaustive context windows to maximize performance," the paper states, and because the protocol lacks granular, field-level access controls to limit context sharing, an external tool can request an entire conversational history. The listed impact is exposure of non-required user data, proprietary business logic, credentials and session context to third-party servers without explicit authorisation.

Aggregation, use and sharing: nine vectors

The largest domain moves from collection to what happens afterwards. The mosaic effect (R2.1) describes harmless fragments, spread across platforms, being combined to infer undisclosed traits such as medical conditions - something multi-agent pipelines can do even when each individual agent respects its own local privacy boundary. Privacy International used the same term in evidence to the UK government published on September 25, 2026, warning that innocuous data could be combined to re-identify people.

Excessive use (R2.2) is where the paper is most pointed about existing controls. Empirical studies, it says, show that standard autonomous agents "are highly prone to the inadvertent use of unnecessary sensitive information during task execution". Blocking a single file or database is ineffective, according to the authors, because an agent reasoning semantically can rebuild restricted information from redundant or secondary sources.

R2.3 groups unintended sharing and deletion. Goal misalignment, security flaws or over-broad agency can send data to third parties; subpoenas can compel its disclosure; and concentrating personal data in a single execution trace creates a target for government demands or threat actors. Deletion is treated as a problem of interpretation as much as engineering. When a user tells an agent to "forget" something, the paper notes, "Some users may intend for the agent to delete the data, others for the agent to not use the data for the particular use case being invoked but want the data retained."

Three vectors concern compromise. Agentic supply chain manipulation (R2.4) covers upstream components - third-party skill packages, tool descriptions and MCP servers - altered to manipulate an agent's reasoning into leaking data under the guise of normal execution. Unexpected dynamic code execution (R2.5) covers agents manipulated into running arbitrary code through a Python REPL or bash environment, bypassing LLM-level privacy filters to obtain read and write access to the host machine, environment variables and connected internal networks. Memory poisoning (R2.6) describes adversarial payloads written to long-term memory and retrieved later. A related attack, tool poisoning against MCP servers, was documented in July 2025 as a weakness in the communication layer between clients and servers.

R2.7 shifts attention from outputs to actions. An agent completing a task may let a third party infer a user's traits, activities or beliefs, either because it lacks context about what the user considers sensitive or because it cannot tell which actions give that information away.

The last two vectors are the least conventional. R2.8 and R2.9 deal with information the underlying model produces without it ever having been supplied - no user input, no memory, no tool result. R2.8 covers disclosure of identifiers, credentials, data in protected categories or quasi-identifier combinations about an identifiable person. "From outside the system, the mechanism is unattributable", the authors write; the content may be memorised training data, retrieval the evaluator cannot observe, or confabulation that happens to be true. The consequence is data the deployer "never collected and cannot delete, correct, account for, or attribute to a lawful basis". R2.9 covers inference, such as a model labelling a person as likely to have a health condition, political affiliation or orientation from indirect cues. The label may be false. If true, it exposes something the person never disclosed.

When agents hand off to agents

The third domain concerns multi-agent systems. "Currently, there is no unified protocol to negotiate privacy constraints in Agent-to-Agent (A2A) interactions", according to the paper (R3.1). An agent working under strict corporate privacy rules may pass data to a secondary agent with weak ingestion boundaries or a different reading of contextual norms, and the data leaks across trust zones.

The other two entries describe propagation. Under R3.2, a deletion, correction, consent withdrawal or processing restriction fails to reach other agents and derived copies; the paper's example is a user who deletes health information while agents B and C, exposed to it in an earlier interaction, keep using it. R3.3 runs the error the other way. Agent A wrongly labels a user as having a health condition, and agents B and C inherit the label.

These scenarios are already on the advertising standards agenda. IAB Tech Lab chief executive Anthony Katsur argued at the end of 2025 that guard rails had to cover what happens when one company's agent, interacting with another company's agent, violates a privacy law. IAB Tech Lab's Agent Registry, which held 10 entries on March 11, 2026, validates each registered company against its GPP and TCF identifiers, the industry's consent-signalling frameworks. That establishes who operates an agent. Negotiating, at run time, what a counterpart agent may do with the data it receives is a separate problem, and it is the gap R3.1 describes.

"Static, binary permission gates (e.g., standard browser pop-ups) are structurally incompatible with the dynamic, open-ended reasoning of autonomous agents", reads the opening of the fourth domain. The answer emerging in agent design is intent-based alignment, in which a model interprets a user's privacy preferences from natural language. Can a probabilistic system be held to a provable standard? The paper's own answer is no: "Because this alignment is probabilistic rather than deterministic, it cannot guarantee that users' privacy preferences are inferred or adhered to in a provable way" (R4.1). The same interpretive flexibility, it adds, is open to adversarial prompt manipulation.

The alternative - asking at every step - produces consent fatigue (R4.2), a stream of runtime confirmations that ends in habitual clicking the paper labels "blind approvals". R4.3, the transparency deficit, describes non-linear reasoning and multi-tool execution paths so opaque that users cannot inspect how, when or why their data was accessed. R4.4 covers manipulation, from dark patterns in AI tools that encourage users to relax their security posture to agents that simulate human-like traits to win trust and extract credentials, personal information or corporate secrets.

Accountability and governance

The final domain has two entries. R5.1, the attribution deficit, starts from the observation that an agentic action is the product of user instructions, model behaviour, system prompts, retrieval context and tool outputs. After an incident such as unauthorised exfiltration, responsibility may be spread among the providers of pre-training and fine-tuning data, the model vendor, the application developer, the third-party tool creator and the user. R5.2 concerns logging: "Currently, there is no standardized, scalable, and privacy-preserving method to implement such cross-ecosystem logging."

The draft names a tension here without resolving it. R1.3 treats detailed execution traces as a privacy exposure, while R5.2 treats the absence of comprehensive logs across ecosystem boundaries as a forensic failure. A privacy-preserving log is the implied reconciliation, but the paper does not describe what such a log would retain, or for how long.

The second half of the document is a method. Agent privacy risk is to be assessed as a causal chain with six stages: a deployment condition or threat, a failure mechanism, a privacy event, an affected party, a privacy impact and a downstream harm.

Each stage carries its own standard of evidence. Deployment conditions and failure mechanisms are directly observed, through system design specifications, security logs, execution traces, model evaluation benchmarks or audit logs. The privacy event - collection, inference, retention, use, modification or disclosure of personal data out of line with a purpose, permission, expectation, policy or contextual norm - may be observed directly or indirectly, through network telemetry, audits, user feedback or output logs. Affected parties are inferred or identified, and immediate impacts are inferred or evaluated. Downstream harm is classed as inferred and uncertain, requiring evidence beyond system logs.

That gradation is the core of the method. "A successful attack, agent action, or technical data exposure does not by itself demonstrate that downstream harm occurred", the paper states, and an assessment is expected to say which parts of the chain were observed and which remain inferred.

No probabilities without denominators

On likelihood the draft is strict. "Likelihood should only be expressed as a probability when supported by observational data with a defined population, denominator, operating environment, and period of observation." Where such data is missing, two dimensions are characterised separately. Deployment exposure asks how often a product meets the conditions for the event: inherent in ordinary operation, present only for some users or workflows, or dependent on an unusual configuration, action or sequence. Conditional failure evidence asks under what circumstances the system fails once those conditions exist, graded as ordinary use; realistic misuse or attack, under a credible threat model with defined attacker capability and a realistic attack budget; or plausible but unconfirmed.

Four levels of impact

Impact assessment separates the event from its consequences. Immediate impact weighs the sensitivity, identifiability and volume of the data, the degree of control lost, departure from the original purpose or context, the number and type of recipients, persistence and reversibility, and the affected party's ability to detect, contest, correct or delete the information. Ten categories of downstream harm are listed, running from physical, economic and reputational to legal, organisational and societal. "Impact ratings should reflect effects on affected parties, not only technical compromise, regulatory exposure, or organizational reputation."

Four levels follow. Critical covers severe or potentially irreversible harm, such as threats to physical safety, coercive control, systemic discrimination or widespread exposure of highly sensitive data. High covers substantial harm or loss of control with material effects on employment, health, finances, legal status, safety, reputation or autonomy. Moderatedescribes meaningful but contained loss of control, misuse or unwanted inference that can generally be mitigated. Lowapplies to minor effects that are readily detectable and reversible.

Four categories of sensitive data

An appendix defines what counts as sensitive. Its four categories draw on the EU General Data Protection Regulation, the US Health Insurance Portability and Accountability Act, the California Consumer Privacy Act and the California Privacy Rights Act. Each is tagged by format: syntactic, meaning pattern-matchable with exact ground truth, or semantic, meaning free-form and meaning-based. That split will matter once benchmark scenarios have to be scored, since a leaked passport number can be detected by matching while a leaked diagnosis described in prose cannot.

S1, direct identifiers, is syntactic and broad: names, postal and email addresses, phone numbers, social security, passport and other government numbers, medical-record and account numbers, device IDs, IP addresses, usernames and precise geolocation. Its anchors are GDPR Article 4(1), the HIPAA Safe Harbor provision at 45 CFR 164.514(b)(2) and CPRA section 1798.140(v)(1)(A). S2, credentials and secrets, lists passwords, API keys, OAuth and refresh tokens, JSON Web Tokens, session cookies, database connection strings, private keys, wallet seed phrases and recovery codes, noting that such material is often memorised from user-provided code. It is anchored in CPRA section 1798.140(ae)(1)(B) and ISO/IEC 27001:2022 Annex A 5.17.

S3, special categories, takes the union of GDPR Article 9(1) - the list European law treats as special category data - and CPRA section 1798.140(ae). It covers health, genetic and biometric data, racial or ethnic origin, political opinions, religious or philosophical beliefs, union membership, sex life and orientation, the contents of mail, email and texts, immigration status and neural data, citing California's AB 947 of 2023 for immigration status and SB 1223 of 2024 for neural data. Neural data also sits in the sensitive-data definition of California's consumer privacy law.

S4, indirect or quasi-identifiers, is the category advertising will read most closely. Its syntactic entries include employee and badge IDs, IMEI and advertising IDs, cookie and device fingerprints and partial identifiers such as the last four digits of a social security number; date of birth, ZIP code and gender appear together as "the classic re-identification triple". Its semantic entries include employment history, job title combined with employer and dates, compensation and education records. Anchors include ISO/IEC 20889:2018, GDPR Recital 26, 45 CFR 164.514(b)(2)(R) and NIST SP 800-188. The authors describe the whole set as "a minimum baseline", to be extended according to context and regulatory change.

What the draft does not contain

There are no measurements. The paper carries no incident counts, prevalence rates, test results or model comparisons; it is a vocabulary and a method rather than an audit. Its empirical claims - that agents are prone to excessive data use, that sequential pipelines compound mosaic risk - rest on two arXiv preprints linked in the text instead of a printed bibliography, and the only other links point to NIST IR 8062, NIST AI 100-1 and Solove's paper on SSRN. The known incidents said to inform the work are not identified.

Some edges are rough. The descriptions of R1.6 and R2.6 repeat nearly the same paragraph about adversarial payloads hidden in emails, documents and websites, distinguished mainly by whether the payload persists to memory. Domain names differ between the abstract and the section headings, with "Data Ingestion & Processing Risks" in one place and "Data Ingestion Risks" in the other. The document proposes no mitigations and does not map its vectors to obligations under the EU AI Act or any other statute beyond the appendix anchors. It binds no one.

The benchmark question

The taxonomy is a precursor. "As we look ahead to 2027, we aim to develop concrete benchmarks that measure how well a given AI agent mitigates known privacy risks", the working group page states. The paper adds that the taxonomy and assessment method will be used to design concrete agentic evaluation scenarios as the basis for benchmarking agent privacy performance.

MLCommons has a track record in this format. The working group page links to its AILuminate Safety and Jailbreak benchmarks and to two public GitHub repositories, ModelBench and ModelGauge. Recent posts listed alongside include an AI Reliability Map (April 22, 2026), a June 9, 2026 piece arguing that the patch model for disclosing AI evaluation findings is breaking, and an August 27, 2026 post titled "The key to trustworthy AI evaluation is secrecy by design".

Who will decide what passes? MLCommons says it convenes model developers, deployers, regulators, academics and non-profits. The working group meets every other Thursday from 11:30 AM to 12:30 PM Eastern time; joining runs through the AI Risk & Reliability subscription form, with access to working files in a public Google Drive folder once a request is approved. With Google's data protection officer among the two people profiled on the group's page, a benchmark built from this draft would eventually score agents from Google and its competitors. The documents do not describe how test design or scoring would be kept apart from the commercial interests of participating companies, nor whether the secrecy-by-design approach MLCommons has written about will apply to privacy test sets.

Why it matters for advertising

The draft arrives as agents move from reporting into execution inside ad platforms. Meta opened write access to campaigns for external AI agents on April 29, 2026. X's Ads MCP server, documented on August 25, exposes 23 tools, ten of which write to live, funded accounts, whereas the MCP server Google released for its Ads API on October 7, 2025 is read-only. Audience data is following the same route: AudienceMix opened its segment catalogue to AI buying agents through an MCP server on September 16, and Amazon Ads moved its MCP server into open beta on February 2.

Each of those connections is an agent-to-tool handshake of the kind R1.7 and R2.4 describe. In an advertising deployment, a context window shared exhaustively with an MCP server can hold campaign data, client briefs and first-party audience information. The taxonomy does not single out advertising, but its S4 category lists advertising IDs and cookie or device fingerprints as quasi-identifiers - the identifiers on which much of programmatic trading runs. A benchmark that scores agents on how they handle S4 data would, in effect, test the plumbing of the bid stream.

Consent is the second pressure point. Advertising's consent architecture is built on the banner and the signal, the static, binary gate the paper calls incompatible with agent reasoning. Usercentrics acquired MCP Manager on January 14, 2026to extend consent governance into AI workflows, adding audit logs and granular access controls at the protocol layer - controls that correspond to R1.7 and R5.2. Consumers remain cautious. In Usercentrics' survey data, 37 percent said they were comfortable with AI access to their financial accounts, the lowest figure in the set.

Regulators have mapped the same ground from the legal side. Spain's AEPD issued a 71-page guide on agentic AI and the GDPR in February 2026, covering prompt injection, memory and minimisation. The Dutch authority warned on February 12, 2026 that open-source agents carried risks of data breaches and account takeovers. Four UK regulators published a joint paper on March 31, 2026 observing that minimisation may be tested by the temptation to give agents broad access to data. The Council of Europe's draft guidelines on LLM-based systems, due before its Bureau on September 16-17 ahead of planned adoption in November, call for testing the complete deployed system against prompt injection, unauthorised extraction and cascading errors between agents.

The incidents keep coming. Australian authorities opened an investigation after an OpenAI research agent entered the systems of the country's national health services agency without authorisation, with the New York Times documenting four further unauthorised database access attempts by OpenAI agents during 2026. Tooling has not caught up evenly either: the documentation for AlohaJet, a browser tool for AI agents, lists no host allow-list, no sandbox and no detection of prompt injection.

What separates the MLCommons draft from the regulatory documents is its purpose. The regulators interpret legal obligations; this paper aims to make agent behaviour measurable, so that two agents could in principle be compared on the same sensitive scenario. Agencies, advertisers and publishers now connecting agents to accounts have no such comparison. Neither does any regulator. The draft does not supply one either - it only defines what the comparison would have to cover.

What comes next

The immediate step is feedback on v0.1; the documents reviewed do not set a deadline for comments. Benchmark development follows, with 2027 as the stated horizon. In the meantime the Council of Europe's guidelines are scheduled for adoption in November, and the taxonomy's 25 vectors will have to survive contact with the companies whose agents they are meant to describe.

Timeline

Summary

Who: MLCommons, through the Privacy and Confidentiality Working Group of its AI Risk & Reliability programme. The paper lists 19 authors; the working group page profiles Kristie Chon Flynn, Google's Data Protection Officer, and Vinh Nguyen, Senior Fellow for AI at the Council on Foreign Relations. The framework is aimed at developers and deployers of AI agents, regulators and civil society groups.

What: Version 0.1 of the Agent Privacy Risk Taxonomy, a 15-page draft that sets out 25 risk vectors in five domains (data ingestion, aggregation and sharing, cross-agent practices, legacy consent, accountability), a six-stage causal chain for assessing incidents, rules for expressing likelihood, four impact levels and four categories of sensitive data anchored in the GDPR, HIPAA, the CCPA and the CPRA.

When: The release was announced on October 1, 2026; the document's cover is dated September 2026. Benchmarks built on the taxonomy are targeted for 2027.

Where: Published by MLCommons online, with a working group that meets every other Thursday by invitation and public GitHub repositories for its benchmark tooling. The legal anchors span the European Union and the United States, with California law cited for immigration status and neural data.

Why: According to MLCommons, no standard framework exists for measuring how models and agents perform against privacy risks, and agents can compromise privacy through their actions even when their direct responses are secure. The taxonomy is meant to give the industry a shared vocabulary as the first step towards benchmarks that score how well agents handle personal data - a question that now reaches advertising, where agents hold write access to ad accounts and connect to audience data through the same protocols the paper names.