Dérive du moindre privilège : détecter les agents IA surprivilégiés avant l'incident

Le moindre privilège est l’une des idées les plus anciennes et les plus fiables de la sécurité. Donnez à une identité exactement l’accès dont elle a besoin, rien de plus, et le rayon d’impact de toute compromission reste réduit. Pour les comptes humains et les comptes de service à longue durée de vie, le modèle tient raisonnablement bien : les rôles sont révisés, les autorisations sont cadrées, les certifications d’accès suivent une cadence trimestrielle.

Les agents IA brisent ce modèle en silence. On donne à un agent un identifiant, un outil, une connexion à un serveur MCP, et à partir de cet instant son comportement devient dynamique. Il décide à l’exécution quelles ressources lire, lesquelles écrire, quel outil invoquer ensuite. L’autorisation que vous avez consignée au jour un décrit un plafond, pas ce que l’agent fait réellement. Et comme les agents sont productifs, ce plafond tend à être généreux : rôles de base de données étendus, accès en écriture « au cas où », un compte de service partagé entre une demi-douzaine de workflows. Le résultat est un parc où l’accès permis et l’accès réellement utilisé dérivent l’un de l’autre, silencieusement, chaque jour.

Des recherches sectorielles indépendantes mesurent l’ampleur de cet angle mort : environ 82 % des organisations déclarent avoir des agents IA en fonctionnement dont elles ignoraient l’existence, alors qu’environ 21 % seulement maintiennent un inventaire en temps réel de ces agents (CSA/Token Security, n=418). On ne peut pas appliquer le moindre privilège à un parc que l’on ne voit pas.

Définir la dérive du moindre privilège

Nommons la chose avec précision. La dérive du moindre privilège est l’écart grandissant entre l’accès qu’un agent est autorisé à utiliser et l’accès qu’on l’observe utiliser. Elle comporte deux directions de défaillance, et une seule d’entre elles est évidente.

La direction évidente est la sous-utilisation : un agent détient un accès en écriture à une table dans laquelle il n’a jamais écrit. C’est un privilège mort, un risque que vous portez sans aucun bénéfice. La direction dangereuse est le signal inverse qu’il implique : lorsque l’ensemble observé contient quelque chose que l’ensemble permis n’a jamais délibérément accordé, c’est qu’une action a lieu sans que personne ne l’ait révisée. Un job d’export qui se met soudain à écrire dans un bucket d’où il n’a toujours fait que lire. Un agent que la politique cantonnait à un schéma et qui en atteint un autre. Ces cas ne sont pas exotiques ; ils sont le quotidien d’agents câblés ensemble avec des autorisations trop larges.

Si c’est difficile, et si c’est propre aux agents plutôt qu’aux humains, c’est parce que le comportement est généré, pas configuré. Un humain disposant de trop d’accès, le plus souvent, ne les exerce pas. Un agent disposant de trop d’accès exercera tout ce qui l’aide à accomplir la tâche qu’il a devant lui, y compris des chemins que personne n’avait anticipés. La revue statique des politiques ne peut pas suivre un comportement qui change à chaque exécution.

Transformer la dérive en un signal révisable

La dérive n’est dangereuse que tant qu’elle est invisible. Le travail consiste à en faire un signal qu’un humain peut réviser, et cela suppose deux choses qui fonctionnent de concert : l’observation continue de ce que les agents touchent réellement, et un enregistrement stable de ce qu’ils étaient autorisés à toucher.

L’observation doit être en lecture seule d’abord. Un collecteur qui observe à partir des journaux, des traces OpenTelemetry et des signaux noyau eBPF se tient en dehors du chemin de données de l’agent. Ce n’est pas un proxy, il ne filtre aucun appel, et s’il défaille il défaille en mode ouvert au bon sens du terme : l’agent continue de fonctionner, vous perdez de la visibilité et non de la disponibilité. Cette asymétrie compte : un contrôle de sécurité capable de faire tomber la production est un contrôle que les équipes désactivent en douce. La couche eBPF en particulier fait office de vérité terrain au niveau du noyau, la partie qu’un agent ne peut pas contourner, ce qui explique pourquoi des indices de niveau protocole comme les annotations d’outils MCP (readOnlyHint, destructiveHint) sont corroborés par rapport à elle plutôt que tenus pour acquis. La spécification MCP elle-même précise que ces annotations ne sont pas dignes de confiance ; ce sont les signaux noyau qui rendent la corroboration réelle.

Ce que l’observation produit, c’est une carte des accès : pour chaque agent, quelles ressources il a atteintes et s’il a lu (R) ou lu/écrit (RW). La carte stocke des relations d’accès, pas des charges utiles, des secrets ou des données personnelles. La partie intéressante, c’est le diff :

La ligne qui compte est celle du milieu. La politique a accordé la lecture sur le bucket d’export ; le collecteur a observé une écriture. Cette unique ligne est le risque majeur que la dérive du moindre privilège est censée faire émerger : un privilège exercé que personne n’a révisé, attribué à un agent précis plutôt qu’à un compte de service partagé, car c’est l’identité par agent qui rend l’attribution et l’audit possibles tout court.

Appliquer au moment de l’accès, pas seulement journaliser

La détection vous dit que la dérive a eu lieu. Pour boucler la boucle, vous voulez que l’écriture non révisée soit un chemin refusé, pas un chemin journalisé. C’est là qu’intervient la policy-as-code évaluée au moment de l’accès. Le diff même qui a signalé la dérive devient la règle qui l’empêche.

Imaginez d’épingler le job d’export en lecture seule sur la base de données de production et de refuser purement et simplement les écritures, avec une violation qui bloque et alerte au lieu de passer en silence :

agent "data-export-job" {
  # Read-only on the operational database. No writes, ever.
  access "prod-postgres" {
    mode  = "read"
    deny  = ["write", "delete", "ddl"]
  }

  # The export target the job is *supposed* to use.
  access "s3://billing-exports" {
    mode = "read"
  }

  on_violation {
    action = "block"        # deny the call at access time
    alert  = "security-oncall"
    audit  = "append"       # write to the tamper-evident ledger
  }
}

Déroulons concrètement l’avant et l’après.

Avant. Le job d’export, détenteur d’un rôle étendu, émet une écriture vers s3://billing-exports. Rien ne l’arrête. L’action réussit, se fond dans le trafic normal et refait surface des jours plus tard, si tant est qu’elle le fasse, comme une anomalie dans la carte des accès. L’écart entre permis et observé s’est creusé, et le seul artefact est une ligne de journal que personne n’a lue.

Après. La même écriture arrive. La politique est évaluée au moment de l’accès, voit un write sur une ressource cantonnée à read, et renvoie un refus avant que l’opération n’aboutisse. La violation bloque l’appel, déclenche une alerte vers l’astreinte et ajoute une entrée au registre d’audit append-only chaîné par hachage. L’écriture non révisée ne devient jamais une modification non révisée. La dérive est reconvertie, dans l’instant, en un chemin conforme au moindre privilège.

Deux propriétés gardent tout cela honnête. Premièrement, chaque consultation privilégiée de la carte des accès est elle-même auditée — qui a regardé quoi — car la carte est sensible et un outil de sécurité incapable de rendre compte de ses propres opérateurs n’est pas digne de confiance. Deuxièmement, le niveau de confiance est affiché clairement : une action attribuée à un agent par des preuves de niveau noyau est marquée différemment d’une action déduite de manière approximative. On ne vous demande jamais d’agir sur une certitude fabriquée.

Ce qu’il faut retenir

Le moindre privilège n’a pas échoué face aux agents IA ; c’est la cadence de revue qui a échoué. Les autorisations sont trop larges, le comportement est dynamique, et les certifications trimestrielles ne peuvent pas suivre une surface d’accès qui change à chaque exécution. La solution n’est pas un proxy plus lourd dans le chemin critique. C’est une observation continue, en lecture seule d’abord, qui produit un diff permis-versus-observé, complétée par une policy-as-code qui applique la frontière corrigée au moment de l’accès, de sorte qu’un agent surprivilégié soit détecté comme un signal révisable bien avant de devenir un incident.

Si vous voulez voir comment le collecteur, la carte des accès et l’application au moment de l’accès s’articulent sans se placer sur le chemin de données de vos agents, la page architecture détaille la conception, et le produit montre à quoi ressemble la vue permis-versus-observé sur un parc réel.