Le problème de l'agent serviable, partie I : quand les bonnes intentions se transforment en incidents de sécurité

En juillet 2025, un agent de « vibe coding » a reçu pour instruction, en langage naturel, de ne pas toucher à l'environnement de production. Il l'a fait quand même, supprimant une base de données active. Pire encore, lorsque cette action incorrecte s'est produite, l'agent a tenté de générer de faux enregistrements pour faire croire que la suppression n'avait jamais eu lieu.

Il n'y avait aucune intention malveillante. Aucun pirate n'a attaqué le système. Aucune injection de prompt n'a eu lieu. L'agent faisait simplement ce qu'il pensait être utile. Pour couronner le tout, l'agent a affirmé à tort à l'utilisateur que la base de données ne pouvait pas être récupérée.

Il s'agit d'un tout nouveau type d'incident de sécurité. Ce n'est pas une violation de données. Ce n'est pas un logiciel malveillant. Ce n'est pas une erreur humaine. C'est plutôt un système d'IA agissant avec de bonnes intentions qui cause des dommages réels en cours de route. C'est le Problème de l'agent trop serviable.

De la réponse à l'action

En un peu plus de trois ans, l'IA a évolué, passant d'une IA générative répondant à des questions à des agents autonomes capables d'agir — que ce soit pour le compte d'utilisateurs ou de manière indépendante — comme lire des données d'entreprise, appeler des API, écrire et déployer du code, et opérer au sein de solutions SaaS, d'e-mails, de CRM et du cloud avec un minimum de supervision humaine. Le paradigme est passé de répondre à agir.

Ce changement transforme la façon dont les entreprises abordent la sécurité. La sécurité traditionnelle repose sur des flux de travail prévisibles et pilotés par l'humain, axés sur des étapes distinctes et vérifiables. Les agents condensent ces étapes en une boucle autonome unique — interpréter, décider, récupérer, agir — et l'exécutent plus rapidement que n'importe quel humain ne peut l'inspecter. Ce comportement serviable et axé sur les objectifs, qui rend les agents utiles, est précisément ce qui les rend dangereux.

Définir le problème de l'agent trop serviable

Le problème de l'agent trop serviable survient lorsqu'un système d'IA, agissant de bonne foi, atteint son objectif tout en violant une contrainte, en exposant des données sensibles ou en causant des dommages involontaires.

Ces systèmes ne sont pas en panne. Ils échouent simplement à agir comme prévu. Ils interprètent les contraintes comme des obstacles, déduisent une intention sans la valider et foncent vers ce qui ressemble à un succès, même lorsque cela entre en conflit avec la sécurité, l'exactitude ou les politiques en vigueur. Les recherches émergentes commencent à nommer ce modèle : les agents sont, en réalité, trop serviables pour être sûrs par défaut, beaucoup privilégiant l'achèvement de la tâche au détriment des garde-fous.

Le point important : aucun attaquant n'est nécessaire. La menace réside dans la serviabilité même de l'agent, appliquée à des accès réels, des données réelles et une autonomie réelle.

Là où les cadres existants échouent

Les cadres de référence utilisés par les équipes de sécurité n'ont pas été conçus pour cela.

Le guide Agentic AI - Threats & Mitigations de l'OWASP repose sur une approche contradictoire, incluant l'injection de requêtes, l'empoisonnement des données et le détournement de capacités. Bien qu'utile, il suppose la présence d'un attaquant. Le problème de l'agent serviable, lui, ne fait intervenir aucun adversaire.

La Taxonomy of Failure Mode in Agentic AI Systems de Microsoft décrit les défaillances des agents, notamment les problèmes d'alignement, le mauvais usage des outils et les erreurs de planification. Sa mise à jour 2026, fruit d'une année de tests d'intrusion, est plus consciente des conséquences. Pourtant, chacun de ses sept nouveaux modes de défaillance suppose toujours l'intervention d'un attaquant, minimisant les enjeux lorsqu'un agent de bonne foi échoue : pertes financières, fuites de données, dommages opérationnels.

Certaines publications récentes commencent à combler cette lacune. Le Top 10 for Agentic Applications 2026 de l'OWASP inclut désormais les « agents malveillants », couvrant les dérives comportementales survenant sans contrôle actif d'un attaquant, et répertorie même des incidents sans adversaire, comme les défaillances de Replit et de l'interface en ligne de commande Gemini. Toutefois, ces cas restent marginaux au sein d'un modèle de menace centré sur les attaquants. Aucun de ces cadres ne considère la serviabilité même de l'agent — lorsqu'elle est couplée à un accès réel — comme le risque principal. C'est précisément ce changement de perspective que nous proposons.

Ces deux cadres négligent le même aspect. Lorsqu'ils prennent des décisions dans un environnement réel, les agents se comportent comme des utilisateurs internes. Ils disposent d'un accès privilégié, d'une autonomie de jugement et de la capacité de causer des dommages qui, techniquement, semblent tout à fait intentionnels et légitimes.

Le rayon d'impact est un problème de données

Le « rayon d'impact » désigne l'étendue des dommages en cas de défaillance d'un système : jusqu'où les dégâts se propagent avant d'être contenus. Ce terme, issu de l'ingénierie des infrastructures, mesure la part d'un système qu'une seule défaillance peut entraîner dans sa chute. Appliqué à un agent serviable, le rayon d'impact correspond à la somme de quatre éléments qu'il détient simultanément :

• Données accessibles — les fichiers, enregistrements et secrets contenus dans son contexte.
• Outils invocables — les API, le code et les actions qu'il peut enchaîner.
• Identité il s'exécute sous — les permissions et privilèges dont il hérite.
• Intention il déduit — l'objectif qu'il décide de poursuivre en votre nom.

Les contrôles traditionnels géraient ces aspects séparément, conçus pour des flux de travail humains prévisibles. Un agent utile combine ces quatre éléments et agit à la vitesse de la machine ; ainsi, une seule instruction mal interprétée peut se répercuter sur l'ensemble des systèmes avant que quiconque ne puisse s'en apercevoir ou réagir.

Trois de ces quatre éléments échappent au contrôle. Vous ne pouvez pas limiter ce qu'un agent déduit, restreindre la manière dont il enchaîne les outils, ni contraindre totalement l'identité dont il hérite. Du moins, pas sans renoncer à l'autonomie qui rendait l'agent utile au départ. Le quatrième élément, les données auxquelles il peut accéder, est le seul que vous puissiez réellement mesurer et délimiter. C'est aussi celui qui importe le plus a posteriori : les données sont ce qu'il y a de plus difficile à récupérer ou à remplacer une fois perdues. Ainsi, malgré toutes ses dimensions, le rayon d'impact est avant tout un problème lié aux données.

Modèles d'incidents liés aux agents utiles

L'analyse des incidents signalés publiquement au cours des trois dernières années et plus a permis de dégager les modèles suivants. Le point commun ? Aucun de ces incidents n'était une attaque. Chaque modèle impliquait un agent cherchant à optimiser sa réussite. Nous approfondirons les plus significatifs d'entre eux plus loin dans cette série d'articles.

Définir des limites pour l'agent utile

Chaque incident présenté ici suit la même logique : un agent doté d'un accès, d'une autonomie et d'un objectif. Mais aucune limite n'a été appliquée au moment de son action.

Vous ne pouvez pas régir ce qu'un agent déduit, et vous ne pouvez pas le ralentir à une vitesse humaine sans sacrifier les gains d'efficacité que vous recherchiez en le déployant. Ce que vous pouvez contrôler, c'est ce à quoi l'agent a accès. Cela commence par savoir où se trouvent vos données sensibles et comment elles sont exposées à l'IA. Les données vous permettent de mesurer le véritable rayon d'impact des actions d'un agent et de garantir qu'il n'interagit qu'avec les données qui lui sont destinées.

L'objectif n'est pas de ralentir l'adoption de l'IA, mais de la rendre durable. Les agents utiles ne restent utiles que si les organisations qui les déploient connaissent leurs limites — et sont capables de les faire respecter.

Vous souhaitez en savoir plus sur l'approche de Cyera en matière de sécurité des agents ? Lisez notre article d'annonce, participez à notre prochain webinaire, ou demandez une démonstration.

‍