OWASP Top 10 for Agentic AI:
PII Risks and Mitigations

OWASP published its Top 10 for Agentic AI in December 2025 — a framework specifically for autonomous AI agents that can take actions, call tools, and chain decisions without per-step human oversight. Unlike the LLM Top 10, the Agentic AI list recognises that agents amplify every PII risk: a single poisoned memory entry or misconfigured tool can leak data across an entire workflow. Here's what each risk means for personal data — and how to mitigate it.

What changed: LLM risks vs. agentic AI risks

The original OWASP LLM Top 10 (2023/2025) focused on risks where a human was still in the loop — prompt injection, training data poisoning, excessive agency. The Agentic AI Top 10 assumes a fundamentally different threat model: the AI is running a multi-step workflow, calling real APIs, writing to real databases, and making decisions faster than any human can review.

The consequence for PII is stark. In an agentic workflow, personal data doesn't just pass through one model — it can be stored in vector memory, forwarded to sub-agents, written to external tools, and logged at each step. Every hop is a potential exposure point.

The OWASP Agentic AI Top 10 (2026)

The full list was released in December 2025 as part of OWASP's response to the rapid adoption of autonomous agent frameworks. The top seven entries with direct PII relevance:

AA1 — Memory Poisoning: the most dangerous PII risk

Memory poisoning tops the OWASP Agentic AI list because it is the hardest to detect and the widest in impact. Unlike a single-turn prompt injection (which affects one response), a poisoned memory entry persists across all future sessions and all users who share the same memory store.

The PII scenario: an attacker submits a document containing a carefully crafted "data about a user" that includes real personal identifiers embedded in apparently innocuous text. The agent extracts these as facts and stores them in its vector memory. In a future session — for a completely different user — the agent retrieves this memory entry when a semantically similar query is made, and the injected PII surfaces in the response.

AA3 & AA4 — Sensitive Information Disclosure and Tool Poisoning

AA3 (Sensitive Information Disclosure) and AA4 (Tool Poisoning) are the two Agentic AI risks that map most directly to the MCP security crisis of early 2026. The Model Context Protocol has no native authentication, no encryption, and no PII-aware filtering — making it an ideal attack surface for both risks.

Tool Poisoning (AA4) exploits the fact that MCP tool descriptions are trust-implicitly executed by agents. A malicious tool description can instruct the agent to include env:ANTHROPIC_API_KEY or the contents of ~/.ssh/id_rsa in its next tool call — both real vulnerabilities documented in the January–February 2026 CVE disclosures against MCP servers.

The only structural defence against AA4 is ensuring that even if an agent is manipulated into including sensitive content in a tool call payload, that content has been anonymized before it exits the trust boundary. An anonymized payload containing [CREDENTIAL_1] gives an attacker nothing useful.

AA7 — Data Exfiltration: agentic automation as an exfil channel

Traditional data exfiltration required an attacker to actively extract data — gain access, run queries, move data out. Agentic AI inverts this: the agent itself becomes the exfiltration mechanism. A compromised or poorly configured agent with access to customer data and the ability to make outbound HTTP calls (via webhooks, notification tools, or file uploads) can be instructed to forward that data to an attacker-controlled endpoint in a single, auditably normal-looking tool call.

The OWASP AA7 mitigation is twofold: restrict outbound tool permissions, and anonymize all outbound payloads. anonymize.dev addresses the second control — every parameter passed to an outbound tool call is processed through the anonymization pipeline before dispatch.

The Toxic Agent Flow: combining AA1 + AA3 + AA7

The most dangerous agentic PII scenario isn't a single vulnerability — it's a chain. Security researchers have documented what's now called the "Toxic Agent Flow":

1. AA1 (Memory Poisoning): Attacker poisons the agent's memory with a trigger instruction embedded in a customer document.
2. AA3 (Privilege Compromise): The trigger activates when a privileged user queries the agent — their session token or context is passed to the poisoned memory retrieval.
3. AA7 (Data Exfiltration): The memory-retrieved instruction directs the agent to summarise the user's recent documents and POST the summary to an external URL.

The full chain requires no code execution, no vulnerability exploitation, and no network intrusion. It requires only that the agent processes untrusted document content and has sufficient permissions.

How anonymize.dev addresses the Agentic AI Top 10

The MCP Server integration model is aligned with the OWASP Agentic AI defensive architecture: treat every AI input and every tool call parameter as untrusted, and apply PII controls at the protocol layer rather than in application code.

The operator system allows fine-grained control over which entities are anonymized per tool and per workflow step. A financial agentic workflow might use replace for customer names and redact for account numbers — applied consistently across all 7 MCP tools in the integration.

GDPR compliance implications of agentic AI processing

From a GDPR perspective, agentic AI workflows introduce three distinct legal obligations that single-model integrations do not:

• Data minimisation (Art. 5(1)(c)): Each agent step should process only the personal data necessary for that specific operation. Anonymization at each step enforces data minimisation structurally.
• Purpose limitation (Art. 5(1)(b)): Data collected for one agentic task must not be repurposed by other agents or memory lookups. Anonymized memory stores cannot be repurposed because they contain no identifiable data.
• Data processing agreements (Art. 28): Each external tool called by an agent is a separate data processor. If the tool receives PII, a DPA is required. Anonymizing tool inputs may eliminate this requirement for many tools.

Implementation: privacy-as-code for agentic workflows

The practical implementation pattern for OWASP Agentic AI compliance with anonymize.dev is four lines of configuration in your MCP server setup:

{
  "anonymize": {
    "command": "npx",
    "args": ["-y", "@anonymize/mcp-server"],
    "env": {
      "ANONYMIZE_API_KEY": "your-key",
      "ANONYMIZE_OPERATORS": "replace"
    }
  }
}

With this configuration, every tool call made by your AI coding agent passes through the anonymize.dev MCP Server. PII in prompts, file reads, and tool outputs is intercepted and replaced before it reaches the model — addressing AA1, AA2, AA3, AA4, and AA7 with a single infrastructure control.