OWASP Top 10 pour l'IA agentique :
Risques et mitigations liés aux données personnelles

OWASP a publié son Top 10 pour l'IA agentique en décembre 2025 — un référentiel spécifiquement conçu pour les agents IA autonomes capables d'agir, d'appeler des outils et d'enchaîner des décisions sans supervision humaine à chaque étape. Contrairement au Top 10 des LLM, la liste IA agentique reconnaît que les agents amplifient chaque risque lié aux données personnelles : une seule entrée de mémoire empoisonnée ou un outil mal configuré peut faire fuiter des données à travers tout un workflow. Voici ce que signifie chaque risque pour les données personnelles — et comment l'atténuer.

Ce qui a changé : risques LLM contre risques IA agentique

Le Top 10 LLM original d'OWASP (2023/2025) se concentrait sur les risques où un humain restait dans la boucle — injection de prompt, empoisonnement des données d'entraînement, agentivité excessive. Le Top 10 IA agentique part d'un modèle de menace fondamentalement différent : l'IA exécute un workflow multi-étapes, appelle de vraies API, écrit dans de vraies bases de données et prend des décisions plus vite qu'un humain ne peut les vérifier.

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 (divulgation d'informations sensibles) et AA4 (empoisonnement d'outils) sont les deux risques IA agentique qui correspondent le plus directement à la crise de sécurité MCP du début 2026. Le Model Context Protocol ne dispose d'aucune authentification native, d'aucun chiffrement et d'aucun filtrage sensible aux données personnelles — ce qui en fait une surface d'attaque idéale pour ces deux risques.

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.

La mitigation OWASP pour AA7 est double : restreindre les permissions des outils sortants et anonymiser toutes les charges utiles sortantes. anonymize.dev répond au second contrôle — chaque paramètre transmis à un appel d'outil sortant est traité par le pipeline d'anonymisation avant l'envoi.

Le « Toxic Agent Flow » : combinaison d'AA1 + AA3 + AA7

Le scénario le plus dangereux pour les données personnelles en contexte agentique n'est pas une vulnérabilité isolée — c'est une chaîne. Des chercheurs en sécurité ont documenté ce que l'on appelle désormais le « Toxic Agent Flow » :

1. AA1 (empoisonnement de mémoire) : l'attaquant empoisonne la mémoire de l'agent avec une instruction déclencheuse intégrée dans un document client.
2. AA3 (compromission de privilèges) : le déclencheur s'active lorsqu'un utilisateur privilégié interroge l'agent — son jeton de session ou son contexte est transmis lors de la récupération de la mémoire empoisonnée.
3. AA7 (exfiltration de données) : l'instruction récupérée depuis la mémoire ordonne à l'agent de résumer les documents récents de l'utilisateur et d'envoyer ce résumé (POST) vers une URL externe.

La chaîne complète ne nécessite ni exécution de code, ni exploitation de vulnérabilité, ni intrusion réseau. Il suffit que l'agent traite du contenu documentaire non fiable et dispose de permissions suffisantes.

Comment anonymize.dev répond au Top 10 IA agentique

Le modèle d'intégration du MCP Server s'aligne sur l'architecture défensive OWASP IA agentique : traiter chaque entrée IA et chaque paramètre d'appel d'outil comme non fiable, et appliquer les contrôles sur les données personnelles au niveau de la couche protocole plutôt que dans le code applicatif.

Le système d'opérateurs permet un contrôle fin des entités anonymisées, outil par outil et étape par étape. Un workflow agentique financier peut utiliser replace pour les noms des clients et redact pour les numéros de compte — appliqué de manière cohérente sur les 7 outils MCP de l'intégration.

Implications du GDPR pour le traitement par IA agentique

Du point de vue du GDPR, les workflows d'IA agentique introduisent trois obligations légales distinctes que les intégrations à modèle unique n'imposent pas :

• Minimisation des données (art. 5(1)(c)) : chaque étape de l'agent ne devrait traiter que les données personnelles nécessaires à cette opération spécifique. L'anonymisation à chaque étape impose la minimisation des données au niveau structurel.
• Limitation de la finalité (art. 5(1)(b)) : les données collectées pour une tâche agentique donnée ne doivent pas être réutilisées à d'autres fins par d'autres agents ou lors de recherches en mémoire. Un magasin de mémoire anonymisé ne peut pas être détourné de sa finalité car il ne contient aucune donnée identifiable.
• Accords de sous-traitance (art. 28) : chaque outil externe appelé par un agent constitue un sous-traitant distinct. Si l'outil reçoit des données personnelles, un accord de sous-traitance (DPA) est requis. Anonymiser les entrées des outils peut supprimer cette obligation pour un grand nombre d'entre eux.

Mise en œuvre : la confidentialité en tant que code pour les workflows agentiques

Le modèle d'implémentation pratique pour la conformité OWASP IA agentique avec anonymize.dev tient en quatre lignes de configuration dans votre installation de serveur MCP :

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

Avec cette configuration, chaque appel d'outil effectué par votre agent IA de développement passe par le MCP Server d'anonymize.dev. Les données personnelles présentes dans les prompts, les lectures de fichiers et les sorties d'outils sont interceptées et remplacées avant d'atteindre le modèle — répondant ainsi à AA1, AA2, AA3, AA4 et AA7 avec un seul contrôle d'infrastructure.