Checklist de sécurité des AI agents : permissions et sandboxes
Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.
La sécurité des agents consiste à contrôler leurs actions. Un chatbot peut fournir une réponse incorrecte. Un agent peut utiliser de vrais credentials, appeler un outil et modifier des données de production.
La règle par défaut est simple : ne donnez pas à un agent des capacités dont il n’a pas besoin. Commencez par des outils limités, des vérifications de policy avant chaque tool call, des sandboxes isolées, des credentials restreints, des étapes d’approbation human-in-the-loop et des traces d’audit. Ajoutez également des guardrails et des filtres de sortie, mais ne les considérez pas comme la principale security boundary.
Modèle de menace et date de revue : 2026-08-10. Ces priorités supposent qu’un agent utilisant des outils peut traiter des entrées contrôlées par un attaquant, lire des données ou provoquer des effets de bord externes. Les assistants moins capables nécessitent moins de contrôles ; les actions à plus fort impact exigent une isolation et une approbation plus strictes.
Classement des patterns
| Pattern | Priorité | Protège contre | Note d’implémentation |
|---|---|---|---|
| Outils à privilèges minimaux | P0 | Agency excessive | Suivez les recommandations OWASP MCP : n’exposez pas les outils que l’agent ne devrait jamais utiliser. |
| Vérifications de policy avant l’outil | P0 | Actions dangereuses | Vérifiez l’action concrète juste avant son exécution. |
| Sandboxes | P0 | Dommages aux fichiers, au shell, au navigateur et au réseau | Isolez le code et les contenus non fiables ; interdisez par défaut les connexions réseau sortantes. |
| Approbations humaines | P0 | Actions irréversibles ou réglementées | Soumettez à approbation les écritures, déploiements, paiements, envois externes et modifications privilégiées. |
| Credentials limités | P0 | Dépassement de privilèges et confused deputy failures | Utilisez des scopes restreints par serveur et par outil. |
| Isolation des serveurs MCP | P1 | Tool poisoning, tool shadowing et attaques inter-serveurs | Ne mélangez pas des serveurs non fiables et des outils puissants dans un même contexte sans revue préalable. |
| Traces d’audit | P1 | Historique d’incident inconnu | Conservez la requête utilisateur, le tool call, les arguments, le résultat, la décision de policy et l’approbateur. |
| Guardrails | P1 | Texte d’entrée et de sortie dangereux | Utiles, mais insuffisants pour contrôler l’autorité des outils. |
| Évaluations red team | P1 | Vecteurs d’attaque connus | Testez le prompt injection, le tool poisoning, l’exfiltration de données et les contournements de permissions. |
Ce qu’il faut implémenter en premier
Commencez par supprimer des capacités. Si l’agent n’a pas besoin d’écrire sur GitHub, ne lui donnez pas de token d’écriture. S’il a uniquement besoin de connaître les disponibilités du calendrier, ne lui accordez pas un accès complet à la boîte mail. Une permission limitée est plus sûre qu’un prompt sévère.
Ensuite, vérifiez la policy avant chaque tool call. Inspectez le nom de l’outil, ses arguments, la ressource cible, l’utilisateur, l’environnement et l’effet de bord. Une requête apparemment inoffensive peut tout de même produire une commande shell dangereuse.
Ajoutez des sandboxes pour l’exécution de code, l’automatisation du navigateur, l’accès aux fichiers et le traitement de documents non fiables. Une sandbox ne rend pas l’action correcte, mais elle réduit les dommages causés par un tool result compromis ou par un modèle désorienté.
Contrôlez le flux de données aussi bien que l’exécution. Limitez les destinations réseau sortantes, masquez les secrets dans les tool results, séparez les contenus non fiables des credentials et journalisez les tentatives de connexion sortante. Une sandbox de système de fichiers qui autorise toujours un accès réseau arbitraire laisse une voie directe d’exfiltration.
Utilisez une approbation humaine pour les actions irréversibles. N’approuvez pas chaque étape. Approuvez les frontières : déploiements en production, suppression de données, envois d’e-mails, transferts d’argent, modifications de permissions et décisions réglementées.
Risques spécifiques à MCP
MCP est utile parce qu’il standardise l’accès aux outils. Il est risqué parce que les descriptions d’outils, les schemas, les identités des serveurs, les OAuth scopes et les tool outputs deviennent tous des éléments du contexte de décision du modèle.
Pour MCP, je conserverais ces règles dans le processus de code review :
- examinez les descriptions et schemas des outils avant approbation
- préférez des credentials limités par serveur
- isolez les serveurs MCP non fiables des outils sensibles
- surveillez les modifications des définitions d’outils après l’installation
- considérez les tool outputs comme des entrées non fiables
- journalisez chaque serveur, outil, argument et résultat
Les guardrails ne suffisent pas
Les guardrails peuvent valider les entrées et les sorties. Ils ne résolvent pas les problèmes de privilèges minimaux, de scope des credentials, de sandboxing, de tool poisoning ou de policy d’approbation. Conservez-les, mais placez-les après la conception des capacités et avant la sortie visible par l’utilisateur.
Pour approfondir
- Sécurité des AI agents présente le guide d’architecture complet.
- Utilisation des outils par les AI agents explique MCP, les outils, le CLI, les skills et l’exécution de code.
- Runtime pour AI agents de longue durée couvre les boundaries de runtime pour les agents de longue durée.