Ce qui distingue un agent d'un simple modèle
Un modèle de langage classique traite ce qu'on lui envoie et rend une réponse. Un agent va plus loin : il consulte des sources, exécute des actions, mémorise un contexte, parfois sur plusieurs tours et via des services tiers. Cette autonomie élargit la surface d'exposition. Les données sensibles ne restent plus dans un seul système, elles circulent entre le modèle, la mémoire de l'agent, les outils qu'il appelle et les journaux d'exécution. Chacun de ces points est un endroit où une donnée peut fuiter si elle n'est pas protégée à bon escient. Plus un agent est capable, plus les chemins qu'il ouvre sont nombreux, et plus il devient difficile de savoir où passe réellement l'information sensible.
La difficulté vient de l'hétérogénéité. Un agent assemble souvent un fournisseur de modèle externe, une base interne et des API partenaires. Les régimes de sécurité diffèrent d'un maillon à l'autre. Concevoir la protection, c'est d'abord cartographier ces flux : quelles données sortent, vers qui, sous quelle forme, et à quel moment. Sans cette carte, le chiffrement se pose au hasard et laisse des passages découverts. La sécurité d'un agent se joue dans la cohérence d'un ensemble, pas dans la robustesse d'un seul composant. Le maillon le plus faible décide toujours du niveau réel de protection, et c'est rarement celui que l'on surveille.
Chiffrer au repos, en transit, et pendant l'usage
Le chiffrement au repos protège les données stockées : bases, sauvegardes, mémoires d'agents. Le chiffrement en transit protège les échanges, par des protocoles comme TLS, entre l'agent et les services qu'il interroge. Ces deux niveaux sont aujourd'hui attendus, mais ils ne suffisent pas. Pendant l'usage, la donnée est déchiffrée pour être traitée : c'est le moment le plus exposé, où le texte en clair existe en mémoire. Le chiffrement dit homomorphe ou les environnements d'exécution isolés cherchent à réduire cette fenêtre encore mal couverte. Le point sensible n'est pas le stockage, c'est l'instant où l'information devient lisible pour être traitée, car c'est là que le chiffrement cesse de protéger.
La conception des clés compte autant que l'algorithme. Des standards éprouvés, comme AES-256 pour le stockage et les suites recommandées pour le transport, valent mieux que des bricolages maison. Mais un chiffrement fort mal gouverné se contourne : clés stockées à côté des données, réutilisées d'un service à l'autre, partagées dans un dépôt de code. L'attention doit porter autant sur le cycle de vie des clés — génération, rotation, révocation — que sur les algorithmes. La cryptographie échoue rarement par faiblesse mathématique ; elle cède par négligence opérationnelle. C'est une dette de méthode plus qu'un défaut de technique, et elle ne se voit qu'au moment de l'incident.
Le point faible reste la clé
Un système chiffré ne vaut que par la manière dont il garde ses clés. Si la clé est accessible en même temps que la donnée, le chiffrement n'apporte qu'une illusion de sécurité. Les environnements de gestion de clés, les modules matériels et la séparation des rôles répondent à ce problème : celui qui lit la donnée n'est pas forcément celui qui peut la déchiffrer. Cette séparation des privilèges limite l'impact d'une compromission, sans prétendre l'empêcher. Elle transforme un vol unique en série d'obstacles à franchir, et donne le temps de détecter l'intrusion avant que les données ne soient exploitables.
La rotation des clés mérite une attention particulière. Une clé qui ne change jamais devient une cible d'autant plus précieuse qu'elle ouvre beaucoup de portes. Prévoir un renouvellement régulier et documenté, y compris pour les agents automatisés, réduit la durée pendant laquelle une clé volée reste utile. Ce travail est ingrat et rarement visible ; c'est pourtant lui qui décide de la résistance réelle du dispositif le jour où un incident survient. La sécurité se joue surtout avant l'incident, dans ces gestes discrets que personne ne remarque tant qu'ils fonctionnent, et que l'on regrette à chaque fois qu'on les a négligés.
Journaliser sans tout exposer
Pour comprendre ce que fait un agent, il faut enregistrer ses actions. Mais un journal qui recopie les requêtes et les réponses capture aussi des données sensibles : noms, identifiants, fragments de dossiers. La traçabilité entre alors en tension avec la confidentialité. La réponse tient dans la sélectivité : enregistrer les métadonnées utiles, masquer ou pseudonymiser les contenus, limiter la durée de conservation. On peut suivre un agent sans conserver une copie intégrale de tout ce qu'il a vu. Journaliser tout revient souvent à créer un second patrimoine de données sensibles à protéger, avec les mêmes obligations que le premier. Un journal pensé dès la conception coûte moins cher à tenir qu'un journal vidé après coup, une fois l'incident survenu.
Le cadre juridique renforce cette exigence. Le règlement général sur la protection des données impose de proportionner les mesures de sécurité à la sensibilité des traitements, et le chiffrement figure parmi les garanties qu'il mentionne. Journaliser massivement pour se protéger peut donc créer un nouveau risque. La bonne pratique consiste à définir d'abord ce qu'il faut pouvoir reconstituer en cas d'incident, puis à concevoir la collecte en conséquence. La sécurité d'un agent repose sur des choix explicites, pas sur l'accumulation de données. Une trace utile est une trace que l'on saurait lire, défendre et supprimer le moment venu.
Aller plus loin
Sécuriser un agent demande de maîtriser à la fois la cryptographie appliquée et l'architecture des systèmes d'IA. Notre catalogue des 31 formations propose des parcours dédiés à la sécurité des agents et à la protection des données. Ils s'adressent aux équipes qui doivent concevoir ces dispositifs, pas seulement les évaluer.
Vous voulez maîtriser ce sujet en pratique ?
Cabinet MARA forme en ligne, sur des cas réels, avec des modules courts et un suivi de progression.
Voir la formation liée Les 31 formations