Sécuriser un agent IA : protéger les données et maîtriser les actions

Un agent devient utile lorsqu'il peut consulter vos documents et agir dans vos outils. Ces accès lui donnent aussi la capacité de provoquer une fuite de données, de modifier le mauvais dossier ou d'exécuter une demande qu'il aurait dû refuser. La sécurité doit donc être définie en même temps que son périmètre fonctionnel.

Mon approche consiste à examiner ce que le système peut lire, transmettre et modifier, puis à placer les contrôles là où ces opérations deviennent effectives. Une consigne dans un prompt peut orienter le comportement du modèle. Les limites critiques doivent également être appliquées par l'application et les services connectés.

Cartographier les données et les actions autorisées

Avant de choisir un mécanisme de filtrage, je propose de décrire les parcours réels : identité de l'utilisateur, documents accessibles, modèles sollicités, outils disponibles et destinataires possibles des sorties. Cette cartographie inclut les journaux et les systèmes d'évaluation, qui peuvent eux aussi recevoir des contenus sensibles.

Une matrice simple rend les arbitrages plus faciles. Un assistant chargé de préparer une réponse commerciale peut lire une documentation produit publique et rédiger un brouillon. Il n'a pas besoin, par défaut, d'accéder aux marges de tous les clients ou d'envoyer ce brouillon sans validation.

Ce travail rejoint la conception d'une architecture d'agent. Chaque capacité doit correspondre à un besoin explicite, avec une identité d'exécution et un contrôle d'accès vérifiable.

Traiter les contenus externes comme des données non fiables

L'injection de prompt ne vient pas seulement de l'utilisateur. Une instruction malveillante peut être placée dans une page web, un document récupéré par le RAG ou la réponse d'un outil. Le modèle risque de l'interpréter comme une instruction à suivre.

Les filtres d'entrée, la séparation des contenus et les consignes de rôle peuvent réduire ce risque. Ils ne permettent pas de promettre qu'aucune tentative ne passera. L'OWASP décrit ces injections directes et indirectes et recommande plusieurs mesures complémentaires.

Dans une architecture que je recommande, un document peut fournir des informations utiles à une réponse, mais il ne peut pas modifier les permissions de l'utilisateur. Le contrôle d'accès reste exécuté par le serveur. Un texte récupéré qui demande un export vers une adresse inconnue ne doit pas suffire à rendre cet export possible.

Limiter les outils et vérifier leurs paramètres

Les interfaces proposées à l'agent gagnent à être étroites : rechercher une facture dans un périmètre autorisé, préparer une mise à jour, consulter un statut. Un outil générique capable d'exécuter n'importe quelle requête multiplie les conséquences possibles d'une erreur.

Les permissions doivent être vérifiées à chaque opération dans le service concerné. Je recommande également une validation des paramètres, des quotas et des limites de durée. Pour les actions sensibles, une confirmation humaine doit présenter l'opération exacte, ses destinataires et son périmètre. Les recommandations de l'OWASP sur l'autonomie excessive placent ces contrôles au niveau des outils et des systèmes en aval.

Exemple fictif : un agent prépare une modification d'adresse de facturation. L'application contrôle que le dossier appartient au compte connecté, présente l'ancienne et la nouvelle valeur, puis exécute uniquement la modification validée. Une reprise après erreur ne doit pas déclencher une autre opération ; une clé d'idempotence peut aider à gérer cette répétition.

Réduire l'exposition des données dès la recherche

Dans un RAG métier, filtrer uniquement la réponse finale arrive trop tard si le modèle a déjà reçu un document interdit. La recherche doit tenir compte des droits de l'utilisateur avant de transmettre les extraits au modèle. Les caches et la mémoire de conversation doivent préserver cette séparation.

Le nettoyage à l'ingestion complète ce dispositif : retirer les champs inutiles, détecter les identifiants personnels, exclure les secrets et conserver la provenance des documents. Il faut également prévoir la suppression ou la mise à jour des données dans les index et les copies dérivées.

Remplacer un nom par un identifiant ne garantit pas l'anonymat. D'autres éléments peuvent permettre une réidentification, ou une table de correspondance peut rendre l'opération réversible. La CNIL distingue ainsi anonymisation et pseudonymisation. Pour concevoir le système, je traite donc le masquage comme une mesure de réduction du risque dont l'efficacité doit être évaluée sur les données réelles.

Combiner les garde-fous avec des règles d'application

Un classifieur ou un modèle de contrôle peut repérer une demande suspecte, une réponse hors périmètre ou certains contenus sensibles. Des règles déterministes peuvent vérifier un format, interdire un domaine de destination ou bloquer un identifiant connu. Chaque mécanisme apporte une couverture différente.

Une expression régulière détecte certains motifs, mais ne reconnaît pas toutes les informations confidentielles. Un nom, une situation personnelle ou un secret reformulé peuvent ne correspondre à aucun motif prévu. Je recommande de tester les faux négatifs autant que les faux positifs : un filtre qui bloque les demandes légitimes peut rendre le service inutilisable.

Le prompt système ne doit pas contenir de clés d'accès ou porter seul une règle d'autorisation. Son éventuelle divulgation ne doit pas ouvrir des droits supplémentaires. L'OWASP précise cette distinction dans sa fiche sur la fuite du prompt système.

Préparer les incidents et mesurer les protections

Je propose de vérifier les contrôles avec des scénarios représentatifs : accès croisé entre comptes, instructions cachées dans un document, outil qui renvoie une donnée inattendue, validation expirée ou répétition d'une action. Les résultats rejoignent le protocole d'évaluation de l'agent.

L'exploitation doit aussi prévoir l'arrêt d'un outil, la révocation de ses accès et une investigation à partir de traces protégées. Une alerte n'est utile que si une personne sait comment la traiter. Le périmètre d'autonomie peut ensuite augmenter progressivement, sur la base des résultats observés.

Avec LeoWeb, je vous accompagne pour transformer ces exigences en choix d'architecture et en contrôles testables. Si vous préparez un agent connecté à vos données ou à vos outils métier, échangeons sur ses accès et ses actions pour définir un périmètre de déploiement maîtrisé.