[!NOTE] Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.
Les meilleurs modèles de sécurité pour les agents AI en 2026
La sécurité des agents concerne le contrôle des actions qu’ils peuvent effectuer. Un chatbot peut fournir une réponse erronée, tandis qu’un agent est en mesure d’utiliser des identifiants authentiques, d’appeler des outils et de modifier des données en environnement de production.
La règle de base est simple : il ne faut pas conférer à un agent des capacités dont il n’a pas besoin. Commencez par des outils restreints, des vérifications de politique avant chaque tool call, des sandboxes isolés, des identifiants limités, des mécanismes d’approbation humaine ainsi que des traces d’audit. Ajoutez également des garde-fous et des filtres de sortie, mais ne les considérez pas comme la principale barrière de sécurité.
Classement des motifs
| Pattern | Priorité | Protège contre | Note d’implémentation |
|---|---|---|---|
| Outils à privilèges minimaux | P0 | Agence excessive | Ne pas exposer les outils que l’agent ne doit en aucun cas utiliser. |
| Contrôles de politique pré-outil | P0 | Actions dangereuses | Vérifiez l’action concrète immédiatement avant son exécution. |
| Sandboxes | P0 | Dégâts sur les fichiers, le shell, le navigateur et le réseau | Isoler le code ainsi que les contenus non fiables. |
| Approbations humaines | P0 | Actions irréversibles ou régulées | Gère les écritures de portes, les déploiements, les paiements, les envois vers des systèmes externes ainsi que les modifications à privilèges élevés. |
| Identifiants à portée limitée | P0 | Dépassement des prérogatives de crédentiel et échecs dus à des délégués confus | Utilisez des scopes restreints, un par serveur et un par outil. |
| Isolation du serveur MCP | P1 | Empoisonnement d’outil, ombre d’outil, attaques inter-serveurs | Ne mélangez pas des serveurs non fiables avec des outils puissants dans le même contexte sans effectuer une analyse préalable. |
| Traçabilité des audits | P1 | Historique d’incidents inconnu | Persister la demande de l’utilisateur, tool call, les arguments, le résultat, la décision de politique et l’approbateur. |
| Contraintes de sécurité | P1 | Texte d’entrée et de sortie non sécurisé | Utile, mais insuffisant pour conférer une autorité à l’outil. |
| Évaluations de type red team | P1 | Voies d’attaque connues | Tester prompt injection, le poisonage d’outil, l’exfiltration de données ainsi que les contournements des permissions. |
Qu’il convient de mettre en œuvre en premier
Supprimez d’abord les capacités correspondantes. Si l’agent n’a pas besoin d’écrire sur GitHub, ne lui accordez pas de token d’écriture. S’il a uniquement besoin des informations relatives à ses disponibilités calendaires, ne lui donnez pas un accès complet à la boîte aux lettres. Une autorisation restreinte est plus sûre qu’un prompt trop large.
Ensuite, vérifiez la politique avant chaque tool call. Examinez le nom de l’outil, ses arguments, la ressource cible, l’utilisateur, l’environnement ainsi que les effets secondaires potentiels. Une requête qui semble inoffensive peut néanmoins générer une commande shell dangereuse.
Ajoutez sandboxes pour l’exécution de code, l’automatisation du navigateur, l’accès aux fichiers ainsi que le traitement de documents non fiables. Un sandbox ne rend pas l’action correcte en soi, mais il atténue les conséquences d’un tool result compromis ou d’un modèle perturbé.
Faire appel à l’approbation humaine pour les actions irréversibles. Il ne faut pas approuver chaque étape individuellement. Approuver uniquement les cas limites : les déploiements en production, la suppression de données, l’envoi d’e-mails, les mouvements financiers, les modifications de permissions, ainsi que les décisions soumises à réglementation.
Risques spécifiques à MCP
MCP est utile car il standardise l’accès aux outils. Il présente cependant des risques, puisque les descriptions des outils, leurs schémas, les identités des serveurs, les scopes OAuth ainsi que les sorties générées par ces outils font tous partie du contexte de décision du modèle.
Pour MCP, je conserverais ces règles lors des revues de code :
- Examiner les descriptions des outils ainsi que leurs schémas avant approbation
- Préférer des identifiants restreints au niveau de chaque serveur
- Isoler les serveurs non fiables MCP des outils sensibles
- Surveiller les modifications des définitions d’outils après leur installation
- Traiter la sortie des outils comme une entrée non fiable
- Enregistrer chaque serveur, outil, argument et résultat
Les garde-fous ne suffisent pas
Les garde-fous permettent de valider les entrées et les sorties. Ils ne résolvent pas les problèmes liés au principe du moindre privilège, à la portée des identifiants, au sandboxing, au poisonage d’outils, ni aux politiques d’approbation. Conservez-les, mais placez-les après la conception des capacités et avant la sortie visible par l’utilisateur.
Lecture approfondie
- AI Sécurité des agents en 2026 Il s’agit du guide complet sur l’architecture. AI Agent Tool Use en 2026 Il explique MCP, les outils, l’interface en ligne de commande, les compétences requises ainsi que l’exécution de code.
- AI Agent Runtime en 2026 Gère les frontières runtime des agents à exécution prolongée.