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 erronée. 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 aux capacités limitées, des vérifications de policy avant chaque tool call, des sandboxes isolées, des credentials à portée limitée, des approbations humaines et des traces d’audit. Ajoutez également des guardrails et des filtres de sortie, mais ne les considérez pas comme la principale frontière de sécurité.
Modèle de menace et date de revue : 2026-09-08. 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 doit 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 liés aux fichiers, au shell, au navigateur et au réseau | Isolez le code et les contenus non fiables ; refusez par défaut les connexions réseau sortantes. |
| Approbations humaines | P0 | Actions irréversibles ou réglementées | Exigez une validation pour les écritures, les déploiements, les paiements, les envois externes et les modifications privilégiées. |
| Credentials à portée limitée | P0 | Dépassement de privilèges et défaillances de confused deputy | Utilisez des portées limitées 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. |
| Traces d’audit | P1 | Historique d’incident inconnu | Enregistrez l’identité de l’utilisateur, l’action, la cible, la décision de policy, l’approbateur et le résultat. Masquez les payloads sensibles avant stockage. |
| Guardrails | P1 | Entrées, sorties ou tool calls dangereux | Effectuez les vérifications de policy des outils avant l’exécution ; les seuls filtres textuels ne peuvent pas autoriser des actions. |
| Évaluations red team | P1 | Vecteurs d’attaque connus | Testez la prompt injection, le tool poisoning, l’exfiltration de données et les contournements de permissions. |
Que faut-il implémenter en premier ?
Commencez par supprimer des capacités. Si l’agent n’a pas besoin d’écrire dans GitHub, ne lui donnez pas de token en é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 les 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 sortie. 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. Ne validez pas chaque étape. Approuvez les actions spécifiques à fort impact : déploiements en production, suppression de données, envois d’e-mails, transferts d’argent, changements 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 et schemas des outils, les identités des serveurs, les portées OAuth et les tool outputs deviennent tous des éléments du contexte décisionnel du modèle.
Pour MCP, je conserverais ces règles dans la code review :
- relire les descriptions et schemas des outils avant approbation
- privilégier des credentials limités par serveur
- isoler les serveurs MCP non fiables des outils sensibles
- surveiller les changements de définition des outils après l’installation
- considérer les tool outputs comme des entrées non fiables
- journaliser les identités des serveurs et des outils, les décisions de policy et les résultats ; minimiser et masquer les arguments et résultats avant leur enregistrement
Les guardrails ne suffisent pas
Les guardrails peuvent vérifier le texte et les tool calls. Dans le OpenAI Agents SDK, les input tool guardrails peuvent bloquer un function tool protégé avant son exécution. Les outils hébergés et les outils d’exécution intégrés n’empruntent pas cette même pipeline ; vérifiez donc la couverture pour chaque outil que vous exposez. Les contrôles de sortie ont lieu après l’exécution et ne peuvent pas annuler un effet de bord.
Appliquez les permissions avant l’exécution, en complément des vérifications des guardrails. Conservez des credentials à portée limitée et isolez les outils même lorsque leurs entrées passent la validation.
Suivez les recommandations de journalisation OWASP : excluez des traces les secrets et les données personnelles inutiles. Limitez les personnes autorisées à lire les logs et définissez une durée de conservation. Une piste d’audit doit permettre de reconstituer une action sans copier chaque payload privé.
Pour approfondir
- AI Agent Security est le guide complet d’architecture.
- AI Agent Tool Use explique MCP, les outils, le CLI, les skills et l’exécution de code.
- Long-Running AI Agent Runtime traite des frontières de runtime pour les agents de longue durée.