Sécurité des agents d’AI : permissions, sandboxes et approbations
Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
La sécurité des agents d’AI contrôle ce que l’application peut lire, modifier et envoyer. Un agent utilisant des outils peut traiter des données privées, utiliser des identifiants et modifier des systèmes externes. Les actions qu’il est autorisé à effectuer doivent être vérifiées dans le code, même lorsque la réponse du modèle paraît sûre.
N’exposez que les outils nécessaires à la tâche. Vérifiez les permissions avant chaque tool call, isolez l’exécution, limitez les identifiants et enregistrez le résultat. Exigez une approbation pour les actions à fort impact. Les filtres textuels peuvent aider à détecter les contenus dangereux, mais ils ne remplacent pas ces contrôles.
Cette liste de contrôle suppose que l’agent lit des entrées non fiables et peut accéder à des données privées ou modifier des systèmes externes. Une prompt injection est une instruction contenue dans ces entrées qui tente de rediriger l’agent. Par exemple, un document récupéré peut lui demander d’envoyer des fichiers privés. Restreindre les outils et les requêtes sortantes limite les conséquences de cette instruction.
Contrôles par capacité
| Capacité | Contrôle | Ce qu’il faut imposer |
|---|---|---|
| Toute utilisation d’outils | Moindre privilège | N’exposez que les outils nécessaires, comme le recommandent les directives OWASP pour MCP. |
| Lecture de données privées ou modifications externes | Vérifications de permissions | Vérifiez l’utilisateur, les arguments, la cible et l’action autorisée juste avant l’exécution. |
| Code, fichiers ou automatisation du navigateur | Sandbox | Limitez les fichiers, les processus et les états du navigateur accessibles, ainsi que les destinations sortantes. |
| Actions à fort impact | Approbation humaine | Montrez la cible exacte et la modification avant un déploiement en production, un paiement, une suppression ou un envoi externe. |
| Services authentifiés | Identifiants à portée limitée | Restreignez chaque intégration aux ressources et aux actions nécessaires. |
| Serveurs MCP non fiables | Isolation des serveurs | Examinez les définitions des outils et empêchez les instructions renvoyées par un serveur d’accorder l’accès à un autre outil. |
| Exécution d’outils | Traces d’audit | Enregistrez l’identité, la cible, la décision sur les permissions, l’approbation et le résultat ; masquez les données privées des charges utiles. |
| Traitement des entrées et des sorties | Guardrails | Vérifiez la couverture de chaque outil. Un filtre textuel n’accorde pas de permission et n’annule pas une action terminée. |
| Tests de version et de régression | Tests d’attaque | Testez la prompt injection, les définitions d’outils trompeuses, la divulgation de données privées et les contournements de permissions. |
Que faut-il implémenter en premier ?
Commencez par supprimer les capacités inutiles. Si l’agent n’a pas besoin d’écrire dans GitHub, ne lui donnez pas de jeton autorisant l’é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.
Ensuite, vérifiez la politique 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 identifiants 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 des outils, les schémas, les identités des serveurs, les portées OAuth et les sorties des outils deviennent tous des éléments du contexte décisionnel du modèle.
Pour MCP, je conserverais ces règles dans la revue de code :
- examiner les descriptions et les schémas des outils avant approbation
- privilégier des identifiants à portée limitée 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 sorties des outils comme des entrées non fiables
- journaliser les identités des serveurs et des outils, les décisions de politique et les résultats ; minimiser les arguments et les résultats et masquer leurs données sensibles 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 guardrails d’entrée des outils peuvent bloquer un outil de fonction protégé avant son exécution. Les outils hébergés et les outils d’exécution intégrés n’empruntent pas ce 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 identifiants à portée limitée et isolez les outils même lorsque leurs entrées passent la validation.
Suivez les directives de journalisation OWASP : excluez des traces les secrets et les données personnelles inutiles. Limitez les personnes autorisées à lire les journaux et définissez une durée de conservation. Un journal d’audit doit permettre de reconstituer une action sans copier toutes les charges utiles privées.
Pour approfondir
- Sécurité des agents d’AI est le guide complet d’architecture.
- Tool Use des agents d’AI explique MCP, les outils, le CLI, les skills et l’exécution de code.
- Runtime des agents d’AI de longue durée traite des limites du runtime pour les agents de longue durée.