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 (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
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 (la capture noyau provient d’un capteur Tetragon que vous déployez ; Olivares AI lit l’export de Tetragon et ne charge lui-même aucun programme eBPF), 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 :
| Agent | Ressource | Permis | Observé | Dérive |
|---|---|---|---|---|
| data-export-job | prod-postgres | R | R | aucune |
| data-export-job | s3://billing-exports | R | RW | écriture non révisée |
| report-builder | analytics-db | R | (inutilisé) | privilège mort |
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 politique évaluée au moment de l’accès.
Olivares AI évalue Cedar comme une surcouche d’interdictions (forbid) au-dessus de rôles refusés par défaut : une règle ne peut donc que retirer des accès ; celle-ci refuse toute requête qui touche un identifiant secret, quoi que dise le rôle.
permit(principal, action, resource);
forbid(principal, action, resource)
when { resource.kind == "credential" && resource.sensitivity == "secret" };Écrire vos propres règles Cedar requiert Business ; Community applique les rôles intégrés, la surcouche de refus native et le kill switch ; les rôles personnalisés et les autorisations délimitées relèvent de Business.
Déroulons concrètement l’avant et l’après.
Avant. Un agent de code, détenteur d’un rôle étendu, appelle un outil MCP qui écrit dans 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. Le même appel d’outil atteint le point de contrôle MCP. Le rôle de l’agent n’autorise pas l’écriture : le point de contrôle refuse donc l’appel avant son exécution (deny-closed) et consigne le refus dans le journal d’audit signé, dont toute altération est détectable. L’écriture non révisée ne devient jamais une modification non révisée. Olivares AI ne bloque une action qu’à ses quatre points d’application : à l’intérieur de Claude Code, dans le proxy de modèle, à chaque appel d’outil MCP et entre les agents. Un job qui écrit directement dans S3, en dehors de ces points, n’est pas bloqué : la carte des accès enregistre l’écriture et la signale comme dérive à examiner.
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 : un lien dont la source porte une identité par agent est marqué attributed, tandis qu’un lien vu uniquement par le noyau est marqué approximate, parce que les signaux noyau désignent un processus, un cgroup ou un conteneur, et non un agent. 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.