Les agents IA sont-ils sûrs avec vos données ?

Oui, à condition de le tenir en laisse courte. Un agent IA n'est pas un simple chatbot. Il reçoit des accès à vos e-mails, votre agenda, vos fichiers et vos comptes. Et il peut agir à votre place, sur plusieurs étapes. Tout ce que vous connectez, il peut le lire. Ce contenu part ensuite vers le fournisseur du modèle pour être analysé. Deux risques dominent. Des permissions trop larges laissent un agent lire toute une boîte mail. Et l'injection de prompt permet à une instruction cachée de le détourner. La parade tient en un mot : le moindre privilège. Accordez l'accès le plus étroit, gardez une validation humaine, et anonymisez les données sensibles avant l'envoi.

Ce qu'est vraiment un agent IA

Commençons par la différence. Un chatbot répond. Un agent agit. Vous lui donnez un objectif, et il enchaîne les étapes seul. Il peut naviguer sur le web, lire vos fichiers et envoyer des messages. Pour cela, il lui faut des accès et des permissions sur vos comptes. Ce basculement — de répondre à agir — change tout le profil de risque.

Les agents prennent des formes variées. Un navigateur IA qui clique dans les pages à votre place. Une extension de navigateur qui lit ce qui est à l'écran. Un assistant de réunion qui rejoint vos appels. Chacun est un cas plus étroit de la même idée. Tous reçoivent des accès. Et tous envoient à un modèle ce qu'ils voient.

Le risque central : trop de permissions

C'est le cœur du sujet. Tout ce qu'un agent peut atteindre, il peut le lire. Connectez-le à toute votre boîte mail, et il lit chaque message. Connectez-le à votre espace de fichiers, et il lit chaque document. Le sur-permissionnement est le vrai risque pour vos données. La portée que vous accordez décide de ce qui peut fuiter.

Et cela ne reste pas en local. Tout ce que l'agent lit part vers le fournisseur du modèle pour y être analysé. Une portée large n'est donc pas qu'un accès. C'est un tuyau entre vos données privées et un système extérieur.

• Votre boîte mail entière : chaque message, fil et pièce jointe.
• Votre agenda : qui vous rencontrez, quand, et à quel sujet.
• Vos fichiers : contrats, exports, notes de travail.
• Vos comptes connectés : tout ce que la connexion déverrouille.

L'injection de prompt : la menace signature

Voici la menace signature. On l'appelle l'injection de prompt. L'OWASP la classe LLM01 : le risque de sécurité numéro un des applications à base de LLM (grands modèles de langage). Une entrée piégée fait suivre au modèle les instructions d'un attaquant, à la place des vôtres. Le piège : l'entrée n'a pas besoin d'être visible. Un texte caché, qu'un humain ne voit pas, compte quand même dès que le modèle le lit.

L'OWASP la coupe en deux. L'injection directe se trouve dans votre propre prompt. L'injection indirecte se cache dans une page web, un e-mail ou un document que l'agent lit. C'est cette seconde forme qui vise les agents. Une page malveillante peut porter des ordres qui détournent votre assistant — pour faire fuiter vos données ou agir contre vous.

L'« excessive agency » : quand l'action est dure à annuler

L'injection empire quand l'agent peut agir. L'OWASP liste ce point à part : l'« excessive agency », LLM06. C'est le risque de donner à un système trop de pouvoir — trop de permissions, d'outils, ou la capacité d'agir — sans contrôles adéquats. Un agent détourné qui ne fait que lire, c'est déjà grave. Un agent détourné qui peut aussi envoyer, supprimer ou acheter, c'est bien pire.

Les actions autonomes sont aussi dures à relire ou à annuler. Un agent peut envoyer un e-mail, supprimer un fichier ou passer une commande, en une étape. Vous pouvez ne pas le voir passer. Et vous pouvez ne pas pouvoir revenir en arrière. C'est pour cela qu'une validation humaine compte autant.

Comment rester en sécurité : le moindre privilège

La parade a un nom : le moindre privilège. Accordez l'accès le plus étroit que la tâche exige vraiment. C'est aussi la logique du droit. L'ICO applique un principe de minimisation des données. C'est l'article 5(1) du UK GDPR, la version britannique du RGPD. Il veut que les données personnelles se limitent au strict nécessaire. Le même principe figure dans le RGPD de l'UE. Connectez la plus petite portée possible, et il y a bien moins à faire fuiter.

1. 1Vérifiez exactement à quoi l'agent se connecte, et accordez la portée la plus étroite.
2. 2Tenez les agents loin de vos comptes et boîtes les plus sensibles.
3. 3Exigez une validation humaine avant tout envoi, suppression ou achat.
4. 4Préférez des outils qui montrent et journalisent ce que l'agent a fait.
5. 5Anonymisez les entrées sensibles avant qu'elles n'atteignent l'agent ou le modèle.

Le NCSC donne un conseil qui va dans le même sens. Limitez les pouvoirs que vous accordez aux agents. Accueillez leurs sorties avec scepticisme, et vérifiez-les. Pour les équipes, il recommande de journaliser l'entrée et la sortie complètes du modèle, plus chaque appel d'outil, avec une surveillance en direct. La même règle couvre les cas plus étroits : navigateurs IA, extensions et assistants de réunion.

Vous pouvez garder l'aide et couper l'exposition. Envoyez moins à l'agent. Anonymisez les parties sensibles avant qu'elles ne quittent votre appareil. L'agent raisonne toujours sur votre tâche. Il ne voit simplement jamais les vraies valeurs.

C'est là qu'ONYRI Sanitize intervient. Le moteur détecte les données sensibles — noms, e-mails, IBAN, clés d'API et plus — et les remplace par des jetons réversibles avant tout envoi. La détection et le mapping restent dans votre navigateur. L'agent et le modèle ne voient que des jetons. Vous restaurez les vraies valeurs en local, sur la réponse. Cela colle à la consigne « filtrer l'entrée » de l'OWASP et à la minimisation des données de l'ICO. Moins de données brutes atteignent l'agent, donc moins peut fuiter.