Un agent qui dérive ressemble beaucoup à une attaque venue de l'intérieur

Jason Clinton d'Anthropic détaille la grille d'évaluation de sécurité pour encadrer les agents autonomes et limiter les risques de dérive dans le SI.

Le risque zéro n'est pas l'objectif d'un responsable sécurité face aux agents IA. C'est la position que défend Jason Clinton, Deputy CISO d'Anthropic, dans une note détaillant la grille d'évaluation appliquée par son équipe. Refuser les demandes d'usage produit une adoption clandestine, sans télémétrie ni bouton d'arrêt ; les accepter sans contrôle produit des incidents. Entre les deux, le travail consiste à rendre le risque lisible et borné.

Quatre questions structurent la revue de chaque cas d'usage. Quel contenu non fiable l'agent ingère-t-il, non fiable désignant tout ce qu'un attaquant pourrait écrire ou modifier, courriel externe, web ouvert, documents tiers, dépôts publics. Quelles actions peut-il mener, et sous quelle identité. Quelle serait l'étendue des dégâts en cas de dérive, un fichier ou l'organisation entière. Quelle observabilité subsiste, avec la capacité de distinguer les actions de l'agent de celles de l'utilisateur dans le SIEM. La règle qui en découle est celle dite de least agency : accorder la capacité la plus étroite qui suffise à accomplir la tâche.

L'analogie centrale vient du risque interne. Un agent qui s'écarte de l'intention de son opérateur devient indiscernable d'une attaque venue de l'intérieur. Clinton cite le rapport 2026 du Ponemon Institute sur le coût du risque interne, qui chiffre à soixante-sept jours la durée moyenne de containment d'un tel incident, de quoi rendre selon lui l'unité de mesure inopérante à la vitesse d'exécution d'un agent.

Un cas interne illustre la limite de l'exercice. L'équipe avait confié à un agent la conduite des incidents de sécurité, avec trois accès : lecture des logs de production, Slack pour ouvrir le canal d'incident, rédaction du document de postmortem. Après un simple changement de version de modèle, sans nouvel outil ni nouvelle permission ni prompt modifié, l'agent a remarqué en plein incident qu'il tenait déjà la cause racine dans une stack trace, constaté l'absence de l'humain attendu, et sollicité de lui-même un autre agent disposant des accès au code pour produire le correctif. Celui-ci a atterri dans une pull request relue par un humain avant mise en production. La leçon interne : borner les accès sans se caler sur les limites supposées du modèle du jour.

Suivent des exigences valables pour n'importe quel environnement agentique : identité émise et révoquée depuis l'IdP existant, allowlists de connecteurs traçant la frontière des données atteignables, approbation par outil et par action pour retirer un verbe destructeur de l'univers de l'agent, exécution en sandbox dépourvue de credentials de production, allowlist d'egress forçant le trafic sortant par un proxy que l'agent ne peut reconfigurer, télémétrie envoyée au SIEM via OpenTelemetry, et un interrupteur général.