Securite IA en 2026 : prompt injection, tool poisoning et nouveau risque agentique

Le modele de menace a change entre mars 2025 et juin 2026

Le 12 mars 2025, le projet OWASP GenAI Security a publie le Top 10 2025 pour les LLM et a rendu le changement explicite. La liste commence toujours par la prompt injection, mais elle met aussi en avant la divulgation d'informations sensibles, l'improper output handling, l'excessive agency, la fuite de system prompt, les faiblesses des vecteurs et embeddings, ainsi que la consommation non bornee. La surface de securite runtime est donc beaucoup plus large que l'ancien reflexe "il suffit de moderer la reponse".

Le signal suivant est arrive le 17 fevrier 2025, quand OWASP a publie Agentic AI - Threats and Mitigations. Le cadrage est passe du mauvais usage d'un seul model au risque des systemes autonomes : appels d'outils repetes, capacites plus larges et rayon d'impact plus fort quand des instructions sont manipulees.

Le 23 mars 2026, des travaux specifiques a MCP ont encore pousse cette logique. Des papiers comme Are AI-assisted Development Tools Immune to Prompt Injection? et Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning expliquent que les metadonnees des outils et le comportement du client peuvent devenir des surfaces d'attaque a part entiere. Puis, le 1 juin 2026, le rapport OWASP State of Agentic AI Security and Governance 2.01 et, le 25 mai 2026, le crosswalk AIUC-1 ont renforce l'accent sur l'identite des agents, le runtime containment, l'architectural monitoring et l'abus de privileges.

Le changement pratique est simple : la securite de l'infrastructure IA est maintenant un probleme de control plane a couches, pas un probleme de mise en forme de prompts.

Les risques runtime qui comptent le plus aujourd'hui

La prompt injection et les jailbreaks restent des risques majeurs. OWASP place toujours la prompt injection en LLM01:2025 et precise que le RAG ou le fine-tuning ne suppriment pas cette vulnerabilite. Si le gateway ne peut pas inspecter les entrees non fiables avant l'appel provider, le reste de la stack herite du risque.

L'excessive agency transforme un comportement faible du model en actions reelles. LLM06:2025 Excessive Agency vise directement trop de fonctionnalites, trop de permissions et trop d'autonomie. En pratique, la question de securite n'est plus seulement "qu'a dit le model ?" mais "qu'avait-il le droit de faire ensuite ?"

Le tool poisoning fait maintenant partie de la surface d'attaque agentique. Les recherches MCP recentes insistent sur les metadonnees d'outils empoisonnees, les parametres caches, le cross-tool poisoning et l'invocation non autorisee. C'est important parce que beaucoup d'equipes traitent encore l'integration d'outils comme une simple fonctionnalite produit au lieu d'une frontiere de capacites gouvernee.

La consommation non bornee est a la fois un sujet de resilience et de securite. LLM10:2025 Unbounded Consumption relie explicitement l'inference non controlee au deni de service, au denial of wallet, a la degradation de service et a la pression d'extraction de model. Dans les systemes IA, l'abus de cout et l'abus de disponibilite sont souvent le meme evenement operationnel.

La divulgation sensible n'est pas seulement un sujet provider. Le Top 10 2025 distingue la divulgation d'informations sensibles et l'improper output handling parce qu'un model peut fuir des donnees meme si le prompt initial semblait acceptable. L'enforcement cote reponse compte autant que le filtrage cote requete.

Comment Odock traite ces risques dans le security engine

Chez Odock, nous faisons une separation claire : les policy guardrails gerent la forme du trafic, l'acces, le payload, les tokens, les budgets et les quotas, tandis que notre Security Engine, SafetySec, gere le contenu du prompt et de la reponse.

Cette separation colle bien aux recommandations recentes :

• Prompt injection et jailbreaks :

Nous appliquons des verifications de contenu cote requete avant l'execution upstream avec les modules SafetySec de prompt injection et de jailbreak patterns.

• Donnees sensibles entrant ou sortant de la frontiere provider :

Nous prenons en charge la redaction avant l'upstream et les controles de fuite apres la reponse upstream grace aux modules de sensitive redaction et de data leakage.

• Attaques repetes a faible signal :

Nous utilisons la repeated-risk awareness afin d'escalader selon le comportement plutot que sur un score isole.

• Excessive agency et abus d'outils :

Nous imposons des frontieres de capacites explicites sur l'acces aux outils avec les MCP grants, le scope par team ou API key, et les allowed ou blocked tools.

• Tool poisoning MCP ou payloads risques :

Nous inspectons les appels d'outils au runtime et appliquons des regles de contenu etroites avec des semantic filters sur les payloads MCP.

• Denial of wallet et usage hors de controle :

Nous appliquons des gates sensibles aux tokens et au cout via les token limits, budgets, quotas et la reconciliation finale de l'usage.

Le point architectural important est le timing. Chez Odock, notre runtime applique des gates par etapes : controles request-aware, controles d'identite et d'acces, contexte resource-aware, gates de tokens et de cout, securite cote requete, plugin gates, execution upstream, securite cote reponse puis preuves d'usage. Cela correspond au fait que des risques differents deviennent visibles a des moments differents.

SafetySec est lui-meme lifecycle-aware. Dans notre runtime, les modules cote requete peuvent attraper la manipulation de prompt et rediger des donnees sensibles avant l'appel provider. Les modules cote reponse peuvent ensuite attraper une fuite de donnees ou une sortie sensible avant que le client ne la recoive. C'est beaucoup plus proche de ce que demande OWASP 2025 qu'une simple couche de regex en preflight.

Ou Odock est particulierement solide dans la comparaison

Des controles gateway sur les prompts et les reponses. Le Security Engine n'est pas decrit comme une simple verification d'admission. Il peut agir avant et apres l'upstream, ce qui est important pour la prompt injection a l'entree et les fuites a la sortie.

Une gouvernance de capacites pour MCP. Chez Odock, nous traitons l'acces aux outils comme un acces runtime a des capacites. Un serveur doit etre accorde a une virtual API key, peut etre limite par team ou key scope, et peut avoir des allowed tools, blocked tools et des semantic filters. C'est le bon modele mental pour la securite agentique.

Protection cout et abus dans le meme chemin. Budgets, quotas, token gates, concurrency et usage reconciliation sont separes de SafetySec mais restent dans le pipeline d'enforcement. C'est important parce que la categorie OWASP sur la consommation non bornee n'est pas seulement un sujet FinOps ; c'est aussi un controle de securite et de disponibilite.

Preuves et auditabilite. SafetySec produit des safety evidence, et le modele runtime enregistre usage, statut, tokens, cout, latency et resultats du cycle de vie. Pour les equipes plateforme, c'est la difference entre une requete bloquee et une requete bloquee mais explicable.

Ce qu'Odock ne pretend pas resoudre seul

Nous sommes volontairement clairs sur cette frontiere. Notre gateway apporte de forts controles runtime, mais nous ne pretendons pas qu'il regle a lui seul tous les problemes de securite IA.

Les sujets qui demandent encore des controles adjacents incluent :

• l'attestation de supply chain des models et des datasets
• la defense contre le poisoning des donnees d'entrainement et des embeddings en amont de l'inference
• le secure SDLC et la gestion de correctifs pour les serveurs MCP eux-memes
• la validation de schema approfondie dans les handlers d'outils metier
• les evaluations de models, les workflows de red team et la gouvernance de release hors du chemin de requete

C'est la position comparative honnete. Odock couvre une grande partie de la couche runtime de l'infrastructure IA. Il ne doit pas etre presente comme un remplacement de tout le programme securite.

Le standard de production pour la securite de l'infrastructure IA

Si votre stack inclut des LLM, des serveurs MCP ou des boucles d'agents, votre plateforme doit pouvoir repondre a quelques questions difficiles :

• Quels prompts ont ete bloques avant d'atteindre le provider ?
• Quelles valeurs sensibles ont ete redigees a l'entree ou a la sortie ?
• Quels outils chaque API key peut-elle reellement appeler ?
• Quels evenements suspects repetes sont passes de observe a block ?
• Quels workloads sont les plus proches d'une limite de cout, de tokens ou de concurrence ?
• Quelles requetes ont ete refusees pour une politique de contenu, de capacite ou de budget ?

C'est la direction des recommandations recentes. Le bon design n'est pas "de meilleurs templates de prompt". C'est un enforcement runtime lifecycle-aware avec des frontieres de capacites explicites et des preuves.

Sources

• OWASP Top 10 Risk & Mitigations for LLMs and Gen AI Apps, 2025
• OWASP LLM01:2025 Prompt Injection
• OWASP LLM06:2025 Excessive Agency
• OWASP LLM10:2025 Unbounded Consumption
• OWASP Agentic AI - Threats and Mitigations, 17 fevrier 2025
• OWASP State of Agentic AI Security and Governance 2.01, 1 juin 2026
• OWASP AIUC-1 Crosswalks for Agentic Applications, 25 mai 2026
• Are AI-assisted Development Tools Immune to Prompt Injection?, 23 mars 2026
• Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning, 23 mars 2026
• Odock Security Engine
• Odock MCP Security