Le guide de sécurité des agents IA
Un plan de sécurité concret pour les agents IA qui utilisent des outils, des données d’entreprise, une mémoire, des navigateurs, des fichiers, des API et des validations humaines.
- Public concerné
- Fondateurs, responsables techniques, équipes opérationnelles et de conformité qui déploient des agents avec un accès réel aux systèmes de l’entreprise.
- Type de système
- Architecture de sécurité des agents
- Résultat pour l’entreprise
- Un modèle de sécurité qui donne aux agents des capacités utiles sans leur accorder un accès incontrôlé aux données, aux outils ou aux actions touchant les clients.
Réponse directe
Ce que recommande ce guide
La sécurité des agents IA consiste à contrôler ce qu’un agent peut voir, décider et faire. Elle associe des outils à périmètre limité, les permissions des sources, la défense contre les injections de prompt, des environnements isolés, des validations selon le risque, ainsi que des traces, évaluations et journaux d’audit pour les actions significatives.
Points essentiels
- Le risque principal vient de l’accès aux outils, pas seulement du texte généré.
- Chaque outil doit avoir un schéma d’entrée, des permissions, un budget, des seuils d’arrêt et un journal d’audit.
- Les documents, e-mails, pages web et tickets consultés doivent être traités comme des contenus non fiables.
- Les actions à fort impact nécessitent une validation humaine ou une exécution explicitement autorisée par les règles.
Architecture
- 01Identité et attribution des rôles
- 02Règles d’accès aux données
- 03Registre d’outils
- 04Détection des injections de prompt
- 05Espace de travail isolé
- 06Classification du risque
- 07File de validation humaine
- 08Traces et journal d’audit
- 09Tableau de bord de sécurité
Indicateurs
- Appels d’outils dangereux bloqués
- Taux de détection des injections
- Taux de refus d’accès
- Délai de validation
- Violations des règles
- Nombre d’incidents examinés
Les permissions doivent être explicites.
Commencer par une carte des accès
Avant de choisir le modèle ou les instructions, listez ce que l’agent peut lire, écrire, déclencher, envoyer, supprimer, publier ou acheter. La sécurité doit suivre l’impact sur l’entreprise.
Séparez les accès en lecture seule des accès en écriture. Consulter une base de connaissances n’a pas les mêmes conséquences qu’envoyer un e-mail, modifier un CRM, rembourser un client ou intervenir sur les données de production.
- Lecture : documents, CRM, statistiques, e-mails et tickets.
- Écriture : fiches, messages, factures, processus et fichiers.
- Fort impact : paiements, accès aux comptes, engagements juridiques et publications publiques.
L’injection de prompt est un problème de séparation entre données et instructions.
Traiter le contexte comme non fiable
Les documents, sites, tickets, e-mails, PDF, discussions et notes de bases de données peuvent contenir des instructions cherchant à contourner les règles de l’agent.
L’agent ne doit pas obéir aux instructions trouvées dans ces contenus, sauf si elles font partie d’un processus approuvé. Les sources apportent des éléments de réponse, pas une autorité sur le système.
- Séparez les instructions système des contenus récupérés.
- Validez les appels d’outils selon les règles, et non selon la confiance exprimée par le modèle.
- Signalez les demandes d’ignorer les règles, de révéler des secrets ou de contourner une validation.
Les contrôles de sécurité doivent exister en dehors du modèle.
Contrôler chaque appel d’outil
Le modèle propose une action ; l’application décide si elle est autorisée. Vérifiez les schémas, paramètres, permissions, budgets, limites de fréquence et règles métier avant toute exécution.
Une instruction de sécurité ne suffit pas. Les outils doivent eux-mêmes refuser les paramètres et les actions non autorisés.
Protéger les actions sensibles sans bloquer chaque tâche simple.
Adapter les validations au risque
Les actions à faible risque, réversibles et testées peuvent être automatiques. Un risque intermédiaire peut justifier un contrôle par échantillonnage, une notification ou une vérification. Les actions à fort impact nécessitent une validation préalable.
La demande de validation doit présenter la requête, les sources, l’outil, l’impact, le risque et l’étape suivante. Le responsable ne devrait pas avoir à reconstruire le contexte à partir de journaux bruts.
Une sécurité opérationnelle exige des actions explicables.
Prévoir la traçabilité et la réponse aux incidents
Il doit être possible de reconstituer la demande, les sources, les instructions, les résultats des outils, les contrôles, les validations et les erreurs.
Ces traces servent au diagnostic, à la conformité et aux évaluations, mais aussi à expliquer une action à un client, un salarié ou une autorité compétente.
Les évaluations doivent inclure des scénarios adverses.
Tester les tentatives d’abus
Testez les injections de prompt, tentatives d’extraction de données, appels d’outils non autorisés, contextes dangereux, paramètres malformés et demandes dont l’autorité est ambiguë.
Relancez ces évaluations lorsque les instructions, modèles, outils, permissions ou sources changent. La sécurité est un travail continu.
Questions fréquentes
Vos questions
Quel est le principal risque de sécurité d’un agent IA ?
L’accès incontrôlé aux outils. Un agent capable de lire des données privées, d’écrire dans des systèmes ou de déclencher des actions a besoin de permissions, de garde-fous, de journaux et de validations adaptés.
Comment se défendre contre les injections de prompt ?
Traitez les contenus externes comme non fiables, séparez-les des instructions système, validez les actions en dehors du modèle, limitez les identifiants et permissions disponibles et détectez les tentatives de contournement.
Les agents IA ont-ils besoin de journaux d’audit ?
Oui. Ils servent au diagnostic, à la conformité, à la gestion des incidents et aux évaluations. Ils doivent permettre de retrouver les sources, appels d’outils, contrôles, validations et résultats finaux.