Consent Was a Gate. Agents Decide Every Second — MLCommons Maps 25 Privacy Risks

2026-10-05 AI Security Research by al-ice.ai Editorial

On 1 October 2026, MLCommons — the open engineering consortium behind the MLPerf benchmarks — published v0.1 of the Agent Privacy Risk Taxonomy: 25 numbered risk vectors organised across five domains, with a six-stage causal-chain methodology meant to turn each one into something benchmarkable. The paper itself is marked V.01 and dated September 2026; it sits under MLCommons’ AI Risk & Reliability programme and the AILuminate Assessment Standard, and comes from the Privacy and Confidentiality Working Group.

The framing line, from the working group’s announcement, is worth quoting because it states the whole problem in one move: as AI shifts from chatbots to autonomous agents, privacy risk moves “from what a model knows to what it does.” Agents acting through opaque tool-use chains or secondary data channels, MLCommons notes, “can compromise privacy even when their direct responses are secure.” If you secure the chat window and ignore the tool calls, you have secured the demo, not the system.

The five domains, and what is actually new in each

The taxonomy’s domains are: data ingestion and processing; aggregation, use and sharing; inconsistent privacy practices across agents; failure of legacy consent systems; and accountability and governance. Much of this will sound familiar to anyone who has read Solove, NIST’s privacy-risk work, or Nissenbaum — the paper builds on all three explicitly. What is new is the agent-specific machinery it hangs on those foundations: continuous tracking, trajectory logging, memory poisoning, and over-privileged inter-agent handshakes. Four observations stood out on a close read of the paper:

It names MCP’s access-control gap directly (R1.7). The vector on over-privileged inter-agent data handshakes states that agents prioritise task completion over data minimisation and that “modern protocols like MCP lack granular, field-level access controls to limit context sharing” — exposing non-required user data, proprietary business logic and session context to external third-party servers. That is a standards-track document saying what our coverage of 8,000 exposed MCP servers and the October MCP SDK advisories have been showing empirically: the connector layer ships data first and asks permission questions never.
Prompt injection appears as a privacy vector, not a security one (R1.6). “Untrusted content/tool/agent” describes runtime processing of external content — emails, websites — that conceals malicious instructions the model fails to separate from valid commands, letting a compromised model silently extract personal data and exfiltrate it. That is exactly the SalesBleed pattern from last month: a poisoned lead form, a hijacked Agentforce agent, CRM records out through image tags. The taxonomy gives defenders a stable ID for the shape, so the next instance is recognised as a known class instead of a novel incident.
Deletion does not propagate (R3.2). When a user deletes something, corrects it, or withdraws consent, downstream agents in a multi-agent workflow often never get the message and preserve what the user asked removed — while conflicting per-agent policies (R3.1) and upstream failure propagation (R3.3) widen the gap. For anyone operating under GDPR-style erasure duties, this domain quietly states that deletion across an agent graph is currently an unsolved enforcement problem, not a ticket to close.
Consent fatigue is load-bearing (R4.2). The paper’s consent analysis is its most honest section: consent was designed as a gate you pass through once, but agents make privacy-relevant decisions continuously at runtime. Either the agent guesses the user’s expectations in context (R4.1 — and can be wrong), or it prompts every time and trains users to click through. Combined with the transparency deficit (R4.3, opaque multi-step reasoning) and the finding that benign planners already smuggle secrets past monitors, the implication is that runtime consent UX, not the privacy policy, is now the control surface — and it is failing.

The six-stage chain is the point

Each vector is modelled as a causal chain — threat, failure mechanism, privacy event, affected parties, immediate impacts, downstream harms. That structure matters more than the count of 25, because it is what converts a vocabulary into future benchmarks: if every risk has the same anatomy, evaluators can build scenarios that walk the chain end to end. The stated plan is to work with large-scale deployers to prioritise which risks matter in which deployments, define detection indicators, pilot benchmarks, and publish mitigations — aiming to complete that effort by Q1 2027, with the draft open for community feedback now.

The enforcement counterpart is already visible. Deterministic information-flow control — the mechanism behind OpenAPPA’s reported zero-attack evaluations — is precisely the kind of control this taxonomy implies: policy attached to data as it crosses tool and agent boundaries, rather than a classifier guessing at intent. Taxonomies do not stop leaks; flow controls might. The two efforts rhyme, and deployers should read them together.

What this draft does not do

It ranks nothing, by design. v0.1 explicitly declines to order the risks: a bank’s service agent and an inbox-connected assistant face different risks in a different order. Until the deployer studies land, nobody can cite this document to say which vector to fix first.
There are no measurements yet. This is step one of a benchmark-development process — common language first, tests later. Treat any vendor claim of “MLCommons-aligned” agent privacy scoring as premature until the pilot benchmarks exist.
Two domains resist benchmarking entirely. The paper is candid that accountability and governance risks concern the organisation around the agent, which a benchmark will not capture. R5.1 (who is accountable for a given action) and R5.2 (inadequate cross-ecosystem logging) are audit and contract problems. Note the tension the announcement itself flags: the logs and memory stores you need for accountability become high-value targets for attackers seeking system access.

What to do

Map the 25 vectors against your agent’s actual data flows. The taxonomy’s value this week is as an audit checklist: which of R1.1–R5.2 can your deployment exhibit, and which have you tested? Start with trajectory-log retention (R1.3) and session persistence (R1.4) — the stores most teams never scoped.
Test deletion propagation across agent handoffs (R3.2). Issue a deletion request, then check every downstream agent, log, and memory store. If the data survives anywhere, your erasure story is fiction.
Scope tool permissions yourself — the protocol will not (R1.7). Until MCP or its equivalents grow field-level access controls, minimise context at the integration layer: per-tool credentials, minimal scopes, and no session context forwarded by default.
Treat trajectory logs and memory as sensitive stores. Detailed execution traces containing inputs, reasoning and tool calls need the same protection as the databases they touched — encryption, retention limits, and access logging — because attackers will read them the way they read backups.
Contribute failure data while the draft is open. The working group is asking for practitioner, academic, civil-society and regulator feedback, and the Q1 2027 benchmarks will only cover what deployers report. If SalesBleed-shaped incidents keep arriving without IDs, the taxonomy cannot absorb them.

Verification note: we read the MLCommons announcement post (1 October 2026, by Andrew Gruen, Kristie Chon Flynn and Vinh Nguyen) and the full V.01 paper (September 2026, AILuminate Assessment Standard, Privacy and Confidentiality Working Group) via the official PDF, enumerating all 25 risk IDs (R1.1–R1.7, R2.1–R2.9, R3.1–R3.3, R4.1–R4.4, R5.1–R5.2) and confirming the five domain names, the six-stage causal-chain methodology, the MCP field-level-controls language, and the Q1 2027 benchmarking goal from the primary text. Author count (19, alphabetical, no affiliations) and the September-dating detail were cross-checked against secondary coverage. We did not contact MLCommons before publication.

Sources: