Pourquoi les agents IA créent de nouvelles failles de sécurité

La frontière de sécurité change lorsque l’IA peut agir

Un modèle qui renvoie une mauvaise réponse crée une certaine catégorie de problème de sécurité. Un agent IA capable de transformer une mauvaise décision en modification de base de données, en e-mail, en paiement ou en autre processus automatisé crée une frontière différente : le modèle dispose désormais d’un chemin entre les informations qu’il lit et les systèmes qu’il peut modifier. Un meilleur alignement reste important, mais c’est le workflow environnant qui détermine ce que le modèle est autorisé à faire.

Au cours des deux dernières années, une grande partie des discussions sur la sécurité de l’IA en entreprise s’est concentrée sur une interaction plus restreinte : un utilisateur soumet un prompt, un grand modèle de langage renvoie du texte, et un humain lit la réponse. Ce schéma place l’alignement, les jailbreaks et les hallucinations au cœur du débat sur la sécurité. Les agents en production changent ces hypothèses, car ils consomment des données en direct, invoquent des outils externes et des API, modifient des bases de données, lancent des automatisations en aval et, parfois, poursuivent sans validation humaine.

Ces capacités élargissent la question de la sécurité, qui ne porte plus seulement sur le comportement du modèle mais sur l’autorité attachée aux décisions du modèle. Les équipes doivent se demander quelle autorité possède un composant probabiliste, quelles données peuvent influencer ses décisions intermédiaires et ce qui se passe lorsque l’entrée ou la décision est erronée. Le risque central en production est qu’une conception de workflow conventionnelle puisse transformer une manipulation ou une erreur ordinaire du modèle en action autorisée sur un système réel.

Les entrées non fiables deviennent dangereuses lorsqu’elles héritent d’une autorité réelle

Ce risque commence avant même qu’un agent n’appelle un outil, car les données connectées deviennent une partie de son contexte de prise de décision. Un agent peut récupérer un enregistrement CRM, un ticket de support, une page web extraite ou un document partagé et utiliser son contenu pour décider de la suite. Un attaquant peut donc influencer le comportement en modifiant des éléments que le modèle finira par lire, sans accès direct au modèle.

Cette voie indirecte peut être difficile à repérer, car un contenu hostile peut arriver au sein de contenus métier ordinaires. Des instructions dissimulées dans un PDF, une signature d’e-mail ou un avis produit peuvent entrer dans le même contexte que celui que l’agent utilise pour interpréter sa tâche. Une fois présentes, elles peuvent rediriger une décision ultérieure, tout comme le ferait une instruction malveillante saisie directement dans un prompt. Connecter un agent à davantage d’informations élargit donc l’ensemble des parties et des documents susceptibles d’influencer son comportement.

Cette influence devient déterminante lorsque l’agent dispose aussi d’identifiants utiles. Les frameworks d’agents peuvent permettre à un modèle d’envoyer des e-mails, d’interroger une base de données, de modifier un enregistrement ou d’exécuter du code ; le jugement du modèle peut donc déterminer quelle opération est lancée et avec quels arguments. Une instruction manipulée dispose alors d’un chemin entre un contenu non fiable et un outil authentifié.

Ce chemin peut devenir plus puissant pendant le développement, car des clés API très larges et des comptes de service disposant d’un accès étendu sont souvent le moyen le plus rapide de faire fonctionner une démonstration. Dans ce contexte, les permissions peuvent refléter « ce qui est pratique pendant le développement ». Si ces identifiants survivent au passage en production, ou si une démonstration réussie mène directement à une intégration avec permissions complètes, l’agent reçoit une autorité choisie pour la rapidité de mise en œuvre plutôt que pour la tâche de production.

Le même problème d’identifiants s’applique lorsque le modèle commet une erreur. Une erreur de raisonnement combinée à un identifiant doté de privilèges étendus peut supprimer le mauvais enregistrement, envoyer un message au mauvais destinataire ou déclencher un paiement. L’identifiant autorise l’opération qui lui est présentée, que ce choix soit intentionnel, halluciné ou provoqué par un contenu hostile.

L’injection de prompt et les permissions excessives se renforcent donc mutuellement. L’injection détermine comment un attaquant peut influencer la décision de l’agent, tandis que les permissions déterminent dans quelle mesure cette décision influencée peut modifier le système. Réduire l’un ou l’autre côté réduit les dommages possibles, mais la sécurité en production doit traiter l’ensemble du chemin causal : un contenu externe entre dans le contexte, modifie une décision et atteint un outil porteur d’une autorité légitime.

Les pipelines d’agents peuvent transporter une influence non fiable à travers des frontières de confiance cachées

Ce chemin causal devient plus difficile à voir lorsque plusieurs modèles et outils participent à un workflow. Les pipelines multi-outils et multi-agents transmettent couramment la sortie d’un composant à un autre, et un composant en aval peut accepter cette sortie sans revalider le contenu qui l’a façonnée. Le traitement peut modifier l’apparence des données tout en préservant l’influence exercée sur elles par une partie externe.

Prenons le cas d’un modèle qui lit un document non fiable et produit un résumé pour un second agent. Si ce second agent dispose d’un accès en écriture à un système de production et traite le résumé comme une entrée fiable, un contenu contrôlé par une partie externe peut indirectement influencer une écriture en production. Aucun humain n’a explicitement donné à cette partie un accès à la production, et pourtant le pipeline crée un chemin de décision vers un composant qui le possède déjà.

Ce chemin persiste parce que la synthèse ne rend pas intrinsèquement un contenu non fiable digne de confiance. Une transformation peut raccourcir, restructurer ou réinterpréter un contenu tout en préservant l’effet d’une instruction intégrée sur le comportement en aval. Les décisions de sécurité doivent donc suivre la provenance, c’est-à-dire l’origine et l’historique de traitement des données, ainsi que leur influence à travers les frontières entre composants, afin que la transformation opérée par un modèle en amont ne devienne pas une garantie de sécurité implicite.

Suivre la provenance devient particulièrement important lorsque l’autorité augmente en aval. Le composant exposé à un contenu externe peut avoir peu de pouvoir, tandis que le composant suivant peut modifier des données de production. Une revalidation lors de ces transferts empêche qu’un chemin d’entrée à faible confiance ne devienne discrètement un chemin d’action à forte autorité.

L’autonomie multiplie les erreurs, tandis que l’exécution des agents peut être plus difficile à reconstituer

Une fois qu’un pipeline peut atteindre des actions privilégiées, une plus grande autonomie change l’ampleur d’une défaillance. Un workflow peut passer de la rédaction d’une réponse à son envoi, ou de l’identification d’une anomalie à une action sur celle-ci, supprimant une interruption qui donnait auparavant à une personne la possibilité de détecter une erreur. Sans limite de débit, étape d’approbation ou kill switch entre la décision et l’exécution, un seul mauvais choix peut déclencher de nombreuses actions automatisées.

Cette première action compte, car le problème qui en résulte peut s’accumuler. Une mauvaise chaîne de raisonnement peut continuer à effectuer des appels d’outils ou à déclencher des processus en aval jusqu’à ce qu’autre chose l’arrête, produisant potentiellement « des milliers de mauvaises actions » avant qu’une personne ne s’en aperçoive. L’autonomie modifie donc l’effet attendu d’une erreur, car le workflow peut répéter ou prolonger les conséquences sans attendre une nouvelle décision humaine.

À mesure que ces conséquences s’accumulent, la réponse à incident peut devenir plus difficile. La sécurité applicative conventionnelle peut utiliser une requête journalisée et le traçage de la pile d’appels pour reconstituer comment un logiciel est parvenu à un résultat. Les traces de raisonnement d’un agent peuvent varier de manière non déterministe, les séquences d’appels d’outils peuvent différer d’une exécution à l’autre, et les équipes peuvent manquer d’enregistrements granulaires des décisions intermédiaires du modèle.

Cette variabilité complique une question de base en cas d’incident : « Qu’a réellement fait le système, et pourquoi ? » Un opérateur qui ne peut voir que « le modèle a décidé », puis « l’action s’est produite », ne dispose pas des éléments de preuve entre ces événements. Relancer la même requête peut produire une séquence différente ; la reconstitution dépend donc de la conservation des entrées, décisions et appels d’origine au moment où l’exécution se produit.

Ces risques d’exécution n’exigent pas que chaque workflow fonctionne manuellement. L’autonomie a des degrés : un modèle peut effectuer une analyse substantielle et préparer une action, tandis que les exigences d’intervention augmentent avec les conséquences potentielles. Cette conception préserve des workflows utiles pilotés par le modèle tout en réservant l’autorité d’exécution aux étapes où l’impact possible le justifie.

Les pratiques éprouvées de l’ingénierie de production ont leur place à la frontière d’action de l’agent

Parce que le workflow accorde une autorité d’exécution, les améliorations du seul modèle ne peuvent pas sécuriser l’architecture qui l’entoure. Un composant probabiliste et parfois imprévisible consomme des contenus potentiellement non fiables, prend des décisions intermédiaires, choisit des outils et initie des actions, ce qui rend les faiblesses d’intégration ordinaires plus lourdes de conséquences. Les disciplines établies de la production traitent ces faiblesses au moyen de permissions limitées au périmètre nécessaire, de validation des entrées, d’observabilité, de déploiements progressifs et de validation humaine pour les actions à conséquences importantes.

Le moindre privilège commence par l’alignement des droits sur la tâche. Si un agent n’a besoin que de lire des dossiers clients, son identifiant doit autoriser la lecture et exclure l’accès en écriture à ces dossiers. Supprimer les droits inutiles réduit les opérations que le workflow peut exécuter lorsque le modèle commet une erreur ou qu’un contenu hostile l’influence.

Une fois les permissions limitées au bon périmètre, le sandboxing contrôle la manière dont les nouvelles intégrations obtiennent un accès à la production. Les nouveaux outils et les nouvelles capacités d’agent peuvent d’abord fonctionner dans un environnement où les erreurs ont un faible coût, avant un passage délibéré et surveillé vers des privilèges de production. Une démonstration réussie montre que le workflow peut accomplir la tâche prévue ; les permissions de production exigent toujours une décision distincte fondée sur les systèmes et les opérations dont cette tâche a besoin.

Après qu’une capacité atteint la production, des étapes d’approbation peuvent contenir les actions aux conséquences importantes. Un modèle peut préparer un remboursement, rédiger un e-mail à un client ou proposer une modification d’un système en direct, tandis qu’une autorisation explicite reste nécessaire avant que l’action externe n’ait lieu. Le rayon d’impact potentiel fournit un critère utile pour cette étape, car la confiance du modèle ne réduit pas les conséquences d’une exécution erronée.

Les actions qui franchissent ces étapes ont également besoin de suffisamment d’éléments de preuve pour une enquête ultérieure. La journalisation au niveau des décisions doit enregistrer ce qu’un agent a consommé, quels outils il a invoqués, quels arguments il a fournis et la logique sous-jacente à ces décisions. Capturer cette chaîne transforme « ce qui s’est passé et pourquoi » en une question de réponse à incident que les équipes peuvent examiner à partir du registre d’exécution.

Ces enregistrements doivent aussi préserver l’origine du contenu externe à mesure qu’il traverse le workflow. Une page web, un fichier téléversé ou un e-mail peut affecter le comportement du modèle même lorsqu’il arrive via un système de récupération plutôt que par une fenêtre de chat. Traiter ces entrées avec la même méfiance que celle qu’une application web conventionnelle applique aux entrées utilisateur permet de garder leur origine visible tout au long du traitement et aide les équipes à faire respecter les contrôles avant que les informations qui en résultent n’atteignent un composant doté de privilèges plus élevés.

Même avec ces contrôles préventifs, des coupe-circuits limitent les dommages une fois l’exécution commencée. Les limites de débit contraignent la vitesse à laquelle les actions automatisées s’accumulent, la détection d’anomalies peut identifier des comportements inhabituels, et une reprise en main manuelle donne aux opérateurs un moyen d’arrêter l’exécution. Ces contrôles sont importants, car une seule chaîne de raisonnement défaillante peut sinon continuer à transformer une défaillance initiale en un grand nombre d’actions erronées avant d’être détectée.

La responsabilité de la sécurité de l’IA doit s’étendre au-delà de l’équipe modèle

Mettre en place ces contrôles de production autour d’un agent exige une responsabilité qui dépasse le comportement du modèle. Les questions de sécurité de l’IA reviennent souvent aux équipes ML ou data science, qui peuvent évaluer le comportement du modèle mais n’ont pas forcément la position organisationnelle ni le budget pour prendre en charge la sécurité des intégrations, le contrôle d’accès et l’observabilité en production. Une fois qu’un agent obtient un accès en écriture à des systèmes réels, ces responsabilités périphériques font partie de sa sécurité, qu’elles relèvent ou non du mandat de l’équipe modèle.

Ces responsabilités recoupent déjà le travail des équipes sécurité et d’ingénierie de plateforme, qui ont une longue expérience de la sécurité de service à service, des identifiants à périmètre limité, de la journalisation d’audit et de la réponse à incident. Le moment est important, car ces équipes peuvent n’intervenir qu’après la mise en service d’un workflow agentique, lorsque les permissions et les choix d’intégration se sont déjà figés dans une conception de production. Les organisations qui réussissent à faire évoluer l’IA à grande échelle ont tendance à combler tôt cet écart organisationnel et à traiter un agent comme un service de production dès qu’il peut écrire dans des systèmes réels.

Cet écart organisationnel affecte directement la manière dont l’autorité est accordée. La responsabilité doit suivre l’autorité donnée au workflow ; ainsi, les décisions médiées par le modèle qui peuvent modifier des systèmes de production nécessitent la participation des équipes sécurité et plateforme avant que ces permissions ne soient accordées. Leurs contrôles existants régissent alors ce que ces décisions sont autorisées à devenir dans les systèmes que l’agent peut modifier.

Principaux enseignements pour les dirigeants

• Contrôlez la frontière d’action : les agents IA créent un risque de sécurité plus important dès lors que les décisions du modèle peuvent déclencher des actions en production. Les équipes sécurité et plateforme doivent adapter les contrôles à l’autorité que reçoit chaque workflow.
• Limitez l’autorité attachée aux entrées non fiables : l’injection de prompt et les erreurs du modèle deviennent plus dommageables lorsque les agents disposent d’identifiants étendus. Les équipes plateforme peuvent réduire le rayon d’impact en appliquant le principe du moindre privilège à chaque outil, API et compte de service utilisé par un agent.
• Préservez les frontières de confiance à travers les pipelines d’agents : les résumés et autres transformations du modèle peuvent transporter une influence non fiable vers des composants dotés de privilèges plus élevés. Les équipes d’ingénierie doivent suivre la provenance des données et revalider les entrées lorsque l’autorité augmente en aval.
• Encadrez l’autonomie et conservez les preuves d’exécution : les workflows automatisés peuvent multiplier une seule décision défaillante en de nombreuses actions, tandis qu’une exécution non déterministe complique l’investigation. Les opérateurs doivent utiliser des étapes d’approbation, des limites de débit, des kill switches et une journalisation au niveau des décisions pour les workflows à conséquences importantes.
• Appliquez les contrôles de production aux actions des agents : la sécurité des agents dépend de contrôles éprouvés, notamment des permissions limitées au périmètre nécessaire, du sandboxing, des déploiements progressifs, de l’approbation humaine, de l’observabilité et des coupe-circuits. Les équipes d’ingénierie doivent intégrer ces contrôles au chemin entre les décisions du modèle et les actions externes.
• Attribuez la responsabilité avant d’accorder l’accès à la production : la sécurité des agents couvre le comportement du modèle, l’identité, le contrôle d’accès, la sécurité des intégrations et la réponse à incident. Les équipes sécurité et plateforme doivent participer avant qu’un agent n’obtienne un accès en écriture afin que l’autorité de production soit gouvernée dès le départ.