Sécurité des agents IA : accès, données et contrôles
La sécurité des agents IA organise les contrôles limitant accès et actions sur leur parcours d’exécution. Elle traite les contenus externes comme entrées non fiables, valide les appels, applique des autorisations étroites et vérifie les résultats. Les instructions du prompt constituent une couche, pas un remplacement des contrôles de l’opération.
Ce guide utilise un petit assistant de catalogue et des erreurs reproductibles avec des données fictives. Les exercices servent à comprendre les frontières avant de connecter un modèle à des informations privées ou des outils modifiant un système extérieur.
Idées essentielles
- Un document externe est une preuve, pas une nouvelle autorité.
- Limitez chaque rôle et outil à l’accès nécessaire.
- Vérifiez séparément structure, accès et effet prévu.
- Testez refus et preuves absentes avec les cas réussis.
Reconnaître une instruction cachée dans des données
Une injection de prompt apparaît lorsqu’un contenu non fiable tente de rediriger instructions ou actions. Une note peut exiger d’ignorer la personne et d’envoyer son carnet privé ailleurs. C’est du contenu retourné, pas une autorisation. Séparez instructions fiables et texte récupéré, puis examinez son influence sur les appels. L’exercice réussit si la note est traitée sans l’opération injectée. La qualifier de suspecte dans la réponse ne suffit pas si le système l’exécute ensuite.
Donner aux outils des accès étroits
La recherche nécessite le catalogue autorisé, pas tout le compte de la personne. Relire un brouillon exige ses preuves, pas tous les outils du chercheur. Appliquez ces distinctions à l’exécution. Une description d’outil n’empêche pas seule la lecture d’une fiche étrangère au périmètre. Définissez ressources et opérations, puis testez une demande extérieure avec des données fictives. Il faut constater le rejet avant obtention d’une information non autorisée, plutôt qu’une justification après coup.
Valider structure et effet attendu
Un JSON correct peut demander une mauvaise ressource ou un changement interdit. Vérifiez nom, arguments, périmètre et effet par rapport à la tâche. Rendez les changements importants inspectables avant leur exécution. Ensuite, examinez statut et preuves réels plutôt qu’un message de réussite généré. Une interface structurée réduit l’ambiguïté, mais ne prouve ni autorisation ni exactitude. Format, intention et résultat doivent donc être contrôlés à des points différents du parcours.
Protéger mémoire et traces
Une fiche mémorisée peut contenir une information privée ou une hypothèse erronée. Gardez ce qui sert un objectif autorisé et définissez sa récupération. Les traces aident au diagnostic, mais copier toutes les entrées crée un autre stockage privé. Préférez métadonnées et preuves limitées utiles à la vérification. Prévoyez correction et suppression afin qu’une ancienne erreur ne ressurgisse pas dans les recommandations. Observer le système nécessite aussi de contrôler les informations conservées et leurs usages futurs.
Construire de petits cas adversariaux
Utilisez note injectée, outil non enregistré, argument incorrect, fiche hors périmètre et action répétée. Définissez refus ou traitement sûr avant les essais. Vérifiez que l’opération interdite n’a réellement pas eu lieu : une réponse affirmant l’avoir bloquée ne suffit pas. Rejouez les cas après modification des prompts, schémas ou adaptateurs. Les contrôles ont besoin de preuves d’exécution, et un exercice réussi ne garantit pas une protection contre toutes les attaques possibles.
En mots simples
Imaginez l’accès à un atelier scolaire. Une note trouvée ne donne pas la clé du magasin. Les formulaires sont vérifiés, les clés ouvrent des pièces précises et les changements importants sont examinés. Il en va de même pour une action proposée après lecture d’un document.
À vous de jouer
Ajoutez à une fiche fictive une instruction demandant de révéler le carnet. Définissez réponse permise, opération interdite et point de rejet. Utilisez uniquement des données inventées.
Résultat attendu
Une exécution traitant l’instruction comme contenu non fiable et retournant un résultat du catalogue ou une issue ouverte sans opération interdite.
Vérifiez votre réponse: Un message rassurant prouve-t-il la protection des données ?
Non. Examinez opérations réelles et informations reçues ou transmises. La preuve d’exécution est le contrôle pertinent.
Questions et réponses
Un bon prompt peut-il sécuriser entièrement l’agent ?
Les instructions décrivent la politique sans remplacer contrôles d’exécution, autorisations et tests. Un contenu externe peut influencer une action et un malentendu peut aussi provoquer une erreur. Combinez consignes claires, outils limités, requêtes validées et preuves du déroulement réel.
Faut-il tester avec de vraies données privées ?
Commencez avec des fiches fictives reproduisant la frontière étudiée. Un carnet inventé et un catalogue limité peuvent révéler un accès défectueux sans divulguer de données personnelles. Les essais plus larges doivent avoir un périmètre défini et des contrôles adaptés au système.
Identifiez les frontières réelles d’accès et d’exécution, puis vérifiez leur maintien face à une entrée cherchant à changer la tâche.
Sources et lectures
- OpenAI — Safety in building agents ↗Sources consultées:
- Anthropic — Writing effective tools for agents ↗Sources consultées:
- Model Context Protocol — Architecture overview ↗Sources consultées: