Post LinkedIn, OWASP Top 10 for LLM (28 février 2026)

On déploie des LLM en production. On ne les audite pas comme on audite le reste.

La sortie d’un LLM est traitée comme du texte de confiance. Elle est injectée dans des pages web, des requêtes SQL, des commandes système. Sans échappement, sans validation. Les mêmes failles qu’on corrige depuis 20 ans sur les entrées utilisateur réapparaissent, côté modèle.

J’ai suivi la formation OWASP Top 10 for LLM Applications. Ce qui m’a marqué, ce n’est pas la liste des vulnérabilités. C’est à quel point elles se combinent sur un déploiement standard.

Ce qui surprend quand on creuse :

• L’injection indirecte : un agent consulte un document externe qui contient des instructions cachées. Il les exécute. L’attaquant n’a jamais touché au prompt
• Un modèle téléchargé depuis un hub public peut contenir du code arbitraire qui s’exécute au chargement. Qui scanne les modèles ML comme on scanne les packages npm ?
• Les bases vectorielles (RAG) ont rarement le même niveau de contrôle d’accès que les bases relationnelles. Si quelqu’un peut modifier un document indexé, il contrôle ce que le LLM cite comme source fiable
• Le déni de service économique : pas besoin de faire tomber le serveur. Des requêtes qui maximisent la consommation de tokens suffisent

Le changement mental le plus important : traiter la sortie du LLM comme de l’input non fiable. Pas parce qu’il est compromis, mais parce qu’il traverse les mêmes chemins que n’importe quelle entrée utilisateur.

Le retour complet est sur mon blog, avec un schéma de la surface d’attaque d’un système LLM. Lien en commentaire.

#OWASP #LLMSecurity #AppSec #AIEngineering #SecOps