3. Autorisations dès la conception : liez les outils aux tâches, pas aux modèles
Un anti-modèle courant consiste à donner au modèle une crédibilité de longue durée et des messages d’espoir pour le garder poli. Le SAIF et le NIST soutiennent le contraire : les informations d’identification et les domaines d’application doivent être liés à des outils et à des tâches, alternés régulièrement et vérifiables. Les agents demandent ensuite des capacités limitées via ces outils.
En pratique, cela ressemble à : « l’agent des opérations financières peut lire, mais pas écrire, certains grands livres sans l’approbation du directeur financier ».
La question du PDG : Pouvons-nous révoquer une capacité spécifique d’un agent sans ré-architecturer l’ensemble du système ?
Contrôler les données et le comportement
Ces étapes contrôlent les entrées, les sorties et contraignent le comportement.
4. Entrées, mémoire et RAG : traitez le contenu externe comme hostile jusqu’à preuve du contraire
La plupart des incidents liés aux agents commencent par des données sournoises : une page Web empoisonnée, un PDF, un courrier électronique ou un référentiel qui introduit clandestinement des instructions contradictoires dans le système. L’aide-mémoire d’injection rapide de l’OWASP et les propres directives d’OpenAI insistent toutes deux sur une séparation stricte des instructions système du contenu utilisateur et sur le traitement des sources de récupération non vérifiées comme non fiables.
Sur le plan opérationnel, effectuez un contrôle avant que quoi que ce soit n’entre dans la récupération ou la mémoire à long terme : les nouvelles sources sont examinées, étiquetées et intégrées ; la mémoire persistante est désactivée lorsqu’un contexte non fiable est présent ; la provenance est attachée à chaque morceau.
La question du PDG : Pouvons-nous énumérer toutes les sources de contenu externe dont nos agents apprennent et qui les a approuvées ?
5. Gestion des sorties et rendu : rien ne s’exécute « juste parce que le modèle l’a dit »
Dans le cas d’Anthropic, le code d’exploitation et les informations d’identification générées par l’IA sont directement entrés en action. Toute sortie pouvant provoquer un effet secondaire nécessite un validateur entre l’agent et le monde réel. La catégorie de gestion des sorties non sécurisées de l’OWASP est explicite sur ce point, tout comme les meilleures pratiques de sécurité du navigateur autour des limites d’origine.