OWASP publie la version 2 de son guide pour sécuriser les agents IA

L'OWASP, la fondation connue pour ses référentiels de sécurité applicative, publie la deuxième version de son guide consacré aux applications agentiques, c'est-à-dire aux assistants IA capables d'agir : appeler des outils, lire des fichiers, envoyer des requêtes. Le document, sous-titré « A Builder & Defender's Guide », porte la mention « Version 2.0, October 2026 » ; la page de téléchargement est datée du 10 novembre 2026. Il compte 106 pages et est diffusé sous licence Creative Commons BY-SA 4.0.

À qui il s'adresse

Le guide vise explicitement des développeurs de niveau intermédiaire à avancé, des ingénieurs IA et des architectes sécurité. Il écarte la gouvernance et la stratégie, renvoyées à un futur guide distinct. La conformité juridique par pays ou par secteur est aussi hors périmètre.

Il couvre neuf chapitres : architectures, consignes de développement sur tout le cycle de vie, systèmes à un ou plusieurs agents, capacités opérationnelles (API, exécution de code, base de données, navigation web, pilotage du poste), chaîne d'approvisionnement, tests d'assurance, déploiement et durcissement des environnements d'exécution.

Quatre idées à retenir

1. La sortie du modèle est une entrée non fiable. Le guide pose que ce que produit un modèle doit être validé et autorisé par du code déterministe avant toute action à conséquence. Les rôles et délimiteurs dans un prompt sont décrits comme des indices de provenance, pas comme des barrières de sécurité. Les décisions d'autorisation doivent rester en dehors du modèle.

2. La règle de deux. Le guide reprend la « trifecta létale » formulée par Simon Willison : un agent qui cumule l'accès à des données sensibles, l'exposition à du contenu non fiable et la capacité de communiquer vers l'extérieur peut être manipulé pour faire fuiter des données. La parade, attribuée à Meta : ne donner à un agent que deux de ces trois capacités au plus. Quand une conception réunit les trois, la consigne par défaut est d'en retirer une ou de les répartir entre composants cloisonnés.

3. Jamais les identifiants de l'utilisateur. Chaque agent doit avoir sa propre identité, et la délégation passe par un échange de jetons à périmètre de plus en plus étroit à chaque étape, pas par le mot de passe ou la clé de la personne.

4. Un disjoncteur, pas seulement des journaux. Le guide juge qu'une détection sans réponse automatique revient à payer cher pour des journaux. Il décrit un mécanisme gradué en quatre paliers (avertir, limiter, suspendre, arrêter) et recommande de figer le contexte avant l'arrêt pour pouvoir enquêter.

Le passage sur MCP

Une section entière traite des outils branchés via MCP. Elle demande d'analyser le nom, la description et le schéma de chaque outil avant de l'admettre, d'afficher la description complète à l'opérateur lors de l'enregistrement, et de valider chaque réponse d'outil par rapport au schéma approuvé. Le guide prévient que le filtrage par motifs ne suffit pas comme défense principale et qu'il faut privilégier le contrôle de schéma et l'isolation à l'exécution.

Les limites

• La page de présentation ne dit pas ce qui change par rapport à la première version ; il faut comparer soi-même.
• Le document est en anglais et ne propose pas de version courte.
• Il ne détaille pas la mise en œuvre sur une plateforme ou un framework précis ; les exemples restent illustratifs.
• Ce sont des recommandations d'un projet communautaire, pas une norme ni une obligation réglementaire.

Notre lecture

Pour une petite équipe, 106 pages ne se lisent pas d'une traite. Nous conseillons de commencer par la règle de deux : listez vos agents, et pour chacun, cochez les trois capacités. Tout agent qui les cumule mérite d'être revu en premier. Ensuite, demandez à votre prestataire où se prend la décision d'autoriser une action : si la réponse est « dans le prompt », le guide donne les arguments pour exiger mieux.