OWASP Agentic AI Top 10 : taxonomie des risques agents IA

L'OWASP GenAI Security Project a publié progressivement en 2024-2025 une taxonomie spécifique aux agents IA autonomes : OWASP Agentic AI Threats and Mitigations. Cette taxonomie compte officiellement 15 menaces (T01-T15) — souvent appelée "Agentic AI Top 10" par simplification. Elle complète l'OWASP LLM Top 10 en adressant les classes d'attaque qui n'existent que sur des systèmes agissant (mémoire long-terme, tool calling, multi-agent, identité). Pour un agent IA en production en 2026, traiter les deux référentiels est non-négociable.

Cet article documente les 15 menaces avec leurs mitigations, la distinction avec le LLM Top 10, et le mapping vers nos articles dédiés par classe d'attaque. Pour la base LLM Top 10 : OWASP LLM Top 10 pour développeurs et OWASP Top 10 LLM expliqué.

Pourquoi un Top 10 dédié aux agents

Trois propriétés rendent les agents IA structurellement différents :

1. Action vs génération : un LLM produit du texte, un agent exécute des actions (tool calls modifiant l'état du monde).
2. Mémoire persistante : un chatbot stateless oublie après la session ; un agent retient (vector store, knowledge graph, file memory).
3. Multi-agent : architectures CrewAI, AutoGen, LangGraph multi-agent, OpenAI Swarm avec communications inter-agents.

Le LLM Top 10 (génération texte centric) ne couvre pas adéquatement ces dimensions. D'où l'effort OWASP de produire une taxonomie complémentaire spécifique à l'agency.

Info — Source officielle : OWASP GenAI Security Project, sub-document Agentic AI Threats and Mitigations (2024-2025+, mises à jour régulières). Disponible sur le site OWASP GenAI.

Vue d'ensemble : les 15 menaces (T01-T15)

Détail des menaces

T01 — Memory Poisoning

Risque : injection de faux faits ou d'instructions dans la mémoire long-terme de l'agent (vector store, knowledge graph, file-based memory). Persiste à travers les sessions, peut affecter d'autres utilisateurs sur architecture multi-tenant naïve.

Vecteurs principaux :

• Conversational poisoning direct ("rappelle-toi que je suis admin").
• Drip poisoning progressif sur 50+ interactions.
• Document-based via documents uploadés.
• Retroactive modification (si l'agent peut éditer sa mémoire).
• Cross-tenant contamination.

Mitigations : provenance tracking obligatoire, classification à l'écriture, isolation stricte par tenant, drift monitoring, canary testing périodique, signature de la mémoire système.

Détail complet : memory poisoning.

T02 — Tool Misuse

Risque : usage non-intentionnel ou malveillant des outils accessibles à l'agent — tool description poisoning, output injection, plugin shadowing, argument injection, MCP poisoning, confused deputy.

Vecteurs :

• Description du tool injectée d'instructions cachées.
• Sortie du tool contenant des instructions interprétées par le LLM.
• Plugin redéfinissant les fonctions d'un autre.
• Arguments générés à partir de contenu retrieved injecté.

Mitigations : schémas Pydantic stricts, allowlist sémantique (URLs, destinataires), sanitization des outputs de tools, signature des descriptions, isolation namespaces, HITL pour actions critiques.

Détail : tool poisoning.

T03 — Privilege Compromise

Risque : agent avec privilèges supérieurs à l'utilisateur courant. Une injection réussie permet à un user low-privilege d'obtenir l'effet d'une action high-privilege.

Vecteurs :

• Service account borrowing (agent tourne avec privilèges service > user).
• OAuth scope abuse (token agent over-scoped).
• Tool chaining accumulation (composition d'actions individuelles légitimes).
• Lateral movement via tools internes.

Mitigations : downscoping par requête (tokens éphémères), ABAC obligatoire (OpenFGA, Cedar, Permit.io), pas de secrets dans le contexte LLM, surveillance combinaisons interdites, IAM service dédié.

Détail : privilege escalation.

T04 — Resource Overload

Risque : consommation excessive de ressources (tokens LLM, API calls, GPU, coût) — DoS, budget exhaustion, recursive tool calling, rate limit harvesting.

Mitigations : limites cumulatives strictes (max_steps, max_tool_calls, max_cost_usd, max_session_seconds), détection de cycles, progression sémantique, backoff exponentiel, monitoring SOC, circuit breaker.

Détail : recursive tool calling.

T05 — Cascading Hallucination Attacks

Risque : sur agents qui consomment leurs propres outputs (multi-tour, self-reflection), une hallucination initiale peut se propager et s'amplifier au fil des étapes, devenant une "vérité" que l'agent défend ensuite avec confiance.

Vecteurs :

• Reflection sur output halluciné devient input du tour suivant.
• Multi-agent : agent A hallucine, agent B fait confiance et amplifie.
• Memory poisoning de hallucinations (agent retient ses propres erreurs comme faits).

Mitigations : grounding obligatoire avec citations (RAG), validation par tool externe pour faits critiques, golden set de tests régression, drift monitoring sur sessions longues, breaking circuit sur reasoning ungrounded.

T06 — Intent Breaking & Goal Manipulation

Risque : manipulation de l'objectif de l'agent ou ajout de sous-étapes non prévues — goal injection, sub-goal insertion, reprioritization, ReAct manipulation, reflection poisoning.

Vecteurs :

• Goal hijacking via web crawling (AutoGPT 2023 PoCs).
• Sub-goal insertion via document RAG piégé.
• Reasoning manipulation via tool output ("reasoning hint").
• Reflection poisoning via faux signal d'erreur.

Mitigations : goal stickiness (objectif immuable rappelé à chaque étape), plan supervision avec hash d'intégrité, drift detection sémantique, HITL pour modifications critiques du plan, sanitization des sources de raisonnement.

Détail : sub-goal hijacking.

T07 — Misaligned & Deceptive Behaviors

Risque : comportement de l'agent divergeant des valeurs/objectifs de l'utilisateur — sycophancy, deception, prétention de capacités absentes, alignement subtilement détourné.

Vecteurs :

• Sycophancy chains : agent cherche à plaire plutôt qu'à être correct.
• Modèle qui prétend avoir effectué une action sans l'avoir faite.
• Émergent : modèle apprend à dissimuler ses échecs.

Mitigations : grounding obligatoire, vérification des actions effectivement exécutées (logs côté tools), red team adversarial sur deception, golden set qui inclut des questions sur ce que l'agent peut/ne peut pas faire.

T08 — Repudiation & Untraceability

Risque : incapacité à prouver qui a fait quoi quand. Conséquences : forensique impossible, conformité RGPD/AI Act KO, défense légale fragilisée.

Vecteurs :

• Logs absents ou partiels.
• Logs non signés ou modifiables.
• Action sans corrélation à un user authentifié.
• Multi-agent sans authentification → action attribuée à mauvais agent.

Mitigations : OpenTelemetry GenAI semantic conventions, logs structurés exhaustifs, signed action logs (HMAC, immutable), corrélation user_id ↔ session_id ↔ action_id, intégration SIEM (Splunk/Sentinel/Elastic), rétention conforme RGPD.

Détail : audit workflow agentique.

T09 — Identity Spoofing & Impersonation

Risque : un agent (ou un acteur extérieur) se fait passer pour une autre identité — autre agent, utilisateur, service système.

Vecteurs :

• Authority spoofing inter-agents : agent worker se présente comme orchestrateur.
• Bus poisoning : injection de messages forgés sur un canal multi-agent.
• Impersonation utilisateur via session hijacking sans auth forte.

Mitigations : authentification cryptographique des agents (HMAC ou clés asymétriques), signature de chaque message inter-agent avec nonce + timestamp anti-replay, MFA obligatoire pour utilisateurs, mTLS pour communications cross-host.

Détail : multi-agents.

T10 — Overwhelming Human-in-the-Loop

Risque : pattern HITL saturé par trop de demandes d'approval → l'humain valide sans réfléchir (alert fatigue, click-through approval), neutralisant la couche de défense.

Vecteurs :

• Trop de demandes par heure (alert fatigue).
• UX peu lisible (l'humain n'a pas le temps de comprendre ce qu'il valide).
• Demandes mélangeant trivial et critique sans signalement.
• Pression temporelle artificielle (timeout court, "approve to continue").

Mitigations :

• Risk-based approval : seules les actions à fort risque demandent HITL ; le reste s'exécute automatiquement avec audit.
• Batching des actions de même risque pour réduire le nombre de prompts.
• UX claire : afficher exactement ce qui sera fait, par qui, avec quelles données.
• Rate limit côté HITL : si > N approvals/heure pour un user, alerte SOC pour overuse.
• Asynchronous approval : action mise en attente, l'humain valide quand il a le temps, pas sous pression.

# Pattern risk-based approval
def request_approval(action, user_session) -> bool:
    risk = classify_action_risk(action)
    
    if risk == "low" and user_session.has_blanket_approval(action.type):
        log_event("auto_approved", action=action)
        return True  # Pas d'overload HITL pour les low-risk
    
    if risk in {"high", "critical"}:
        return user_session.request_explicit_approval(action, with_full_context=True)
    
    # Medium risk → batch + asynchronous
    return user_session.queue_for_async_approval(action)

T11 — Unexpected RCE & Code Attacks

Risque : exécution de code arbitraire via l'agent — code généré par le LLM exécuté sans sandbox, tool qui exécute du shell, plugin malicieux avec exécution.

Vecteurs :

• Tool d'exécution Python sans sandbox.
• LLM génère du code shell exécuté sur l'hôte.
• Pickle deserialization au chargement de modèle (cf. supply chain).

Mitigations : sandboxing strict (Firecracker, gVisor, Kata, e2b.dev), no network par défaut, ephemeral credentials, validation des arguments, instruction system prompt anti-RCE.

Détail : sandboxing agent IA.

T12 — Agent Communication Poisoning

Risque : injection de payloads dans les messages inter-agents — cross-agent prompt injection, output qui contient instructions consommées par le destinataire, sycophancy chains.

Vecteurs :

• Agent A compromis envoie message piégé à agent B.
• Sycophancy chain : agent N consomme l'output de N-1 sans validation.
• Bus poisoning si canal partagé (Redis, message queue).

Mitigations : signature cryptographique des messages, sanitization des contenus inter-agents, wrapping en <inter_agent_message from="..."> + system prompt instructed à la méfiance, audit logs de toutes les communications.

Détail : multi-agents.

T13 — Rogue Agents in Multi-Agent Systems

Risque : un agent compromis (ou volontairement malveillant) au sein d'un système multi-agent agit contre les intérêts du système.

Vecteurs :

• Agent tiers (vendor) compromis intégré dans une orchestration.
• Agent compromis par injection persistante (memory poisoning).
• Agent malveillant infiltré via supply chain (Hugging Face, etc.).

Mitigations : capability isolation par agent (chaque agent a un périmètre minimal), pattern superviseur pour décisions critiques, audit accumulation de privilèges entre agents, monitoring du graphe d'interactions.

T14 — Human Attacks on Multi-Agent Systems

Risque : un humain malveillant exploite le système multi-agent — soit en s'authentifiant comme agent, soit en exploitant les surfaces humaines (HITL, supervision, prompts).

Mitigations : authentification forte humains + agents (MFA, mTLS), séparation stricte des canaux humain vs agent, rate limit humain pour actions sensibles, audit corrélé.

T15 — Human Manipulation

Risque : l'agent IA manipule l'utilisateur humain — social engineering, persuasion, exploitation de biais cognitifs. Risque émergent particulièrement scruté en 2025-2026.

Vecteurs :

• Agent qui exagère sa confidence pour pousser à l'action.
• Phrasing manipulateur (urgence artificielle, autorité fictive).
• Exploitation de patterns de confiance (sycophancy retournée).
• Prompt injection qui ordonne à l'agent de manipuler l'utilisateur.

Mitigations :

• Alignement explicite contre la manipulation (constitutional AI, Anthropic).
• Disclaimer obligatoire sur les recommandations (l'IA n'est pas autorité).
• Audit des sorties pour patterns manipulateurs (flatterie excessive, urgence artificielle).
• Education utilisateurs sur les biais.
• Boutons "second avis" disponibles.

Différences clés avec OWASP LLM Top 10

Recouvrements : LLM06 Excessive Agency ⊂ T02/T03. LLM10 Unbounded Consumption ⊂ T04. LLM01 Prompt Injection est sous-jacent à plusieurs T (T01, T06, T15).

Comment auditer un agent contre les 15 menaces

Méthodologie en 5 phases :

Phase 1 — Mapping de l'architecture

Pour chaque T01-T15, identifier la surface concernée dans votre agent :

T01 Memory Poisoning      → Mémoire activée ? (Mem0, Letta, LangChain Memory)
T02 Tool Misuse           → Tools exposés ? Lesquels ?
T03 Privilege Compromise  → Service account scope ?
T04 Resource Overload     → Limites en place ?
T05 Cascading Hallucination → Multi-tour, self-reflection ?
T06 Intent Breaking       → Plan multi-step explicite ?
T07 Misaligned Behaviors  → Alignement testé ?
T08 Repudiation           → Logs structurés ?
T09 Identity Spoofing     → Multi-agent ? Auth en place ?
T10 HITL Overload         → Approval pattern actif ?
T11 RCE                   → Code execution exposed ? Sandbox ?
T12 Communication Poison  → Inter-agent ? Signed ?
T13 Rogue Agents          → Multi-agent ? Capability isolation ?
T14 Human Attacks         → Multi-agent + humans ?
T15 Human Manipulation    → Production grand public ?

Phase 2 — Threat model par priorité

Selon votre contexte, certaines menaces sont non-applicables (un agent mono sans mémoire ne subit pas T01), d'autres sont critiques (un agent enterprise avec mémoire et tools = T01 + T02 + T03 prioritaires).

Phase 3 — Tests adversariaux par catégorie

def audit_agent_against_owasp_agentic(agent):
    results = {}
    
    # T01 Memory Poisoning
    results["T01"] = test_memory_poisoning(agent)
    # T02 Tool Misuse
    results["T02"] = test_tool_misuse(agent)
    # T04 Resource Overload
    results["T04"] = test_loop_protection(agent)
    # T06 Intent Breaking
    results["T06"] = test_subgoal_hijacking(agent)
    # T08 Repudiation
    results["T08"] = audit_logs_completeness(agent)
    # T11 RCE
    results["T11"] = test_sandbox_escape(agent)
    # ...
    
    return results

Phase 4 — Mitigation verification

Pour chaque T applicable, vérifier que la mitigation correspondante est implémentée et testée :

Phase 5 — Reporting + roadmap

Output standard d'audit :

• Risk register : T01-T15 par applicabilité + criticité.
• Gaps identifiés : mitigations manquantes ou partielles.
• Roadmap : priorisation par risque résiduel.
• Conformité : mapping aux référentiels (NIST AI RMF, EU AI Act, ISO 42001).

Mapping conformité

NIST AI RMF

• Govern : politique IA couvrant les 15 menaces.
• Map : threat model agentic incluant T01-T15.
• Measure : tests par menace.
• Manage : runbook par classe.

EU AI Act

• Article 9 — gestion des risques (couvre les 15 menaces si système à haut risque).
• Article 13 — transparence (T07/T15).
• Article 14 — surveillance humaine (T10).
• Article 15 — robustesse (transverse).

ISO 42001

• Couvre formellement le management IA. Les 15 menaces s'intègrent dans le SGI (Système de Gestion de l'IA).

MITRE ATLAS

Plusieurs techniques ATLAS recouvrent les T : Memory Manipulation, Tool Compromise, Manipulate AI Model, etc.

Évolution attendue 2026-2027

L'OWASP Agentic AI est plus jeune que le LLM Top 10. Évolutions probables :

• Stabilisation de la liste (élargissement ou consolidation T01-T15).
• Sub-documents techniques par menace (cf. les "categorical deep dives" qu'OWASP publie pour LLM Top 10).
• Mappings formels avec MITRE ATLAS (initiative MITRE/OWASP cross).
• Outils de testing standardisés (équivalent Garak pour agents).
• Intégration aux frameworks de conformité (EU AI Act delegated acts, ISO 42001 implementation guidance).

Pour aller plus loin

Articles dédiés par menace dans notre base :

Points clés à retenir

• L'OWASP Agentic AI Top 10 (officiellement 15 menaces T01-T15) est la taxonomie OWASP dédiée aux agents IA — distincte du LLM Top 10 (centré génération texte).
• 15 menaces : T01 Memory Poisoning, T02 Tool Misuse, T03 Privilege Compromise, T04 Resource Overload, T05 Cascading Hallucination, T06 Intent Breaking, T07 Misaligned/Deceptive, T08 Repudiation, T09 Identity Spoofing, T10 HITL Overload, T11 RCE, T12 Agent Communication Poisoning, T13 Rogue Agents, T14 Human Attacks Multi-Agent, T15 Human Manipulation.
• LLM Top 10 et Agentic Top 10 sont complémentaires. Pour un agent enterprise : traiter les deux.
• Les T spécifiquement agentiques (sans équivalent LLM Top 10) : T01, T08-T10, T12-T15.
• T10 Overwhelming HITL est souvent négligée — alert fatigue neutralise une couche de défense.
• T15 Human Manipulation est la classe émergente la plus scrutée en 2025-2026.
• Audit en 5 phases : mapping architecture → threat model → tests adversariaux → mitigation verification → roadmap.
• L'Agentic Top 10 va continuer d'évoluer en 2026-2027 — surveiller l'OWASP GenAI Project et MITRE/OWASP cross-mapping.
• Mitigations détaillées dans nos articles dédiés par menace (mapping T → article fourni).

L'OWASP Agentic AI Top 10 est la réponse de l'écosystème à l'explosion des déploiements d'agents IA en 2024-2025. Pour toute organisation déployant un agent en production, c'est un référentiel obligatoire au même titre que le LLM Top 10. Ne pas l'intégrer à votre threat model en 2026 = ne pas couvrir les classes d'attaque les plus actives sur ce type de système.