Ce que vos agents IA peuvent réellement atteindre : cartographier l'accès des agents sur une infrastructure réelle

Un agent IA est, sur le plan opérationnel, un processus détenant des identifiants. Quelqu’un lui provisionne un compte de service, une clé d’API ou un rôle IAM pour qu’il fasse son travail, et dès cet instant il peut atteindre tout ce que ces identifiants atteignent. La fiche de poste disait « exporter les données de facturation chaque nuit ». L’identifiant, lui, disait « lire et écrire dans la base de production, le stockage objet et la file d’attente ». Personne n’a réconcilié les deux. Des mois plus tard, plus personne dans l’équipe ne sait répondre à une question qui devrait être triviale : que peut réellement atteindre cet agent, et que touche-t-il réellement ?

Cet écart n’a rien d’hypothétique. Une recherche indépendante du secteur (CSA/Token) a constaté qu’environ 82 % des organisations exécutent des agents IA dont elles ignorent l’existence, alors que seulement 21 % environ maintiennent un inventaire en temps réel de ces agents. On ne peut pas gouverner ce qu’on ne voit pas, et à l’heure actuelle la plupart des parcs ne voient pas du tout leurs agents — encore moins les arêtes reliant chaque agent aux ressources qu’il peut atteindre.

Trois questions différentes, régulièrement confondues

Si « que peut atteindre cet agent » est difficile à trancher, c’est que cette question en fusionne trois distinctes. Les garder séparées, c’est tout l’enjeu.

• Détenu — les identifiants que possède l’agent. Un jeton, une clé, une liaison de rôle. C’est un fait d’identité : les portes dont l’agent a les clés.
• Autorisé — ce que ces identifiants ont le droit de faire, selon la politique : les octrois IAM, les rôles de base de données, les règles réseau. C’est un fait de politique, et il est presque toujours plus large que ce dont on se souvient, parce que les octrois s’accumulent et que personne ne les révoque.
• Observé — ce que l’agent a effectivement été vu en train de faire : quelles ressources il a atteintes, et si chaque accès était une lecture ou une écriture. C’est un fait comportemental, et tant que vous ne le collectez pas, il n’existe tout simplement nulle part.

La plupart des outils de sécurité s’arrêtent à l’autorisé. Ils lisent votre IAM et vous disent que l’agent pourrait écrire dans le bucket d’exports de facturation. C’est nécessaire mais insuffisant, car « pourrait » désigne un ensemble de milliers de capacités latentes, et un humain ne peut pas trier des milliers de « peut-être ». Ce qui change la donne, c’est de placer l’observé à côté de l’autorisé et d’en regarder la différence.

La carte d’accès

Une carte d’accès est le graphe de ces arêtes : pour chaque agent découvert, une arête vers chaque ressource qu’il peut atteindre, annotée de ce qui a réellement été observé sur cette arête. L’unité qui compte est l’arête, et l’annotation la plus importante sur l’arête est la distinction lecture/écriture.

R (lecture) signifie que l’agent a récupéré des données sans les modifier : un SELECT, un GET, une lecture de fichier. RW (lecture/écriture) signifie qu’il a muté l’état : un INSERT/UPDATE/DELETE, un PUT vers un stockage objet, une migration de schéma. Le rayon d’impact de ces deux cas n’est pas comparable. Une arête en lecture sur une table sensible est une question d’exposition. Une arête en écriture — surtout non voulue — est une question d’intégrité et d’incident. Les traiter comme un même « accès », c’est ainsi que les équipes passent à côté du constat qui comptait.

Voici à quoi ressemble la ligne d’un seul agent une fois la carte construite :

Regardez la première ligne. Le travail d’export était censé lire depuis prod-postgres et écrire le résultat dans s3://billing-exports. Lire la source, écrire la destination. Mais l’identifiant qui lui a été remis octroie RW sur la base de données, et le collecteur l’a observé en train d’écrire dans prod-postgres — une mutation sur le système de référence de production que personne n’a examinée, voulue, ni ne sait actuellement expliquer. La colonne autorisé indiquait discrètement, depuis le début, que c’était permis. C’est le germe d’un incident, exposé au grand jour, et sans la colonne observé il n’y a rien à signaler.

Autorisé moins observé égale dérive

Le résultat caractéristique est le diff. La dérive du moindre privilège est ce que l’on obtient en soustrayant une colonne de l’autre, et elle joue dans les deux sens :

• Autorisé mais jamais observé — l’agent peut atteindre internal-metrics-api mais ne l’a jamais fait pendant toute la fenêtre d’observation. C’est du périmètre mort : un octroi que vous pouvez proposer de révoquer en toute sécurité, réduisant la surface d’attaque sans toucher au comportement.
• Observé au-delà de ce qui a été examiné — l’écriture dans prod-postgres que personne n’a validée. C’est le constat à fort signal : une action qui se produit et que, si l’on avait posé la question au moment du provisionnement, personne n’aurait approuvée.

La seconde catégorie est le risque principal, et la version honnête du produit ne l’invente jamais. Chaque arête observée porte un niveau de confiance — attribué lorsque l’action est rattachée à une identité d’agent précise avec un signal corroborant, approximatif lorsque les preuves sont plus faibles. On montre la différence plutôt que de blanchir une supposition en certitude. Un constat que l’on ne peut pas assumer est pire que pas de constat du tout.

Découvert passivement, attribué par agent

Deux choix de conception rendent cela digne de confiance plutôt qu’un tableau de bord de plus.

D’abord, la découverte est passive. Le collecteur observe — journaux, traces OpenTelemetry, flux d’audit de base de données comme pgAudit de PostgreSQL, et eBPF au niveau du noyau comme filet de sécurité de référence — et il ne se place pas sur le chemin de données de l’agent. Il n’y a aucun proxy obligatoire. Si le collecteur tombe en panne, l’agent continue de fonctionner ; l’observabilité se dégrade, pas la production. Pour un système dont toute la raison d’être est de gouverner des infrastructures critiques, cette asymétrie est le principe de conception : faible inconvénient, fort signal.

Ensuite, chaque action est attribuée à une identité d’agent précise, et non à un compte de service partagé. C’est la différence entre un registre d’audit qui dit « le rôle d’export a écrit dans prod-postgres à 02h14 » et un registre qui dit quel agent l’a fait, sous la responsabilité de qui, par rapport à quel périmètre voulu. L’identité par agent est la condition préalable pour que le moindre privilège ait le moindre sens — sans elle, une action peut être vue mais jamais retracée jusqu’à un responsable.

Les arêtes et les faits de lecture/écriture sont la seule chose stockée. La carte enregistre des relations — agent vers ressource, R ou RW — pas les charges utiles, pas les lignes qui ont été lues, pas les secrets. Les entrées susceptibles de contenir des secrets ou des données personnelles sont caviardées et analysées à la recherche de secrets avant que quoi que ce soit ne soit écrit. Le graphe est sensible précisément parce que c’est une carte d’accès ; il est donc conçu pour ne contenir que le minimum qui rend la gouvernance possible, et rien de plus.

Les signaux issus de l’écosystème propre de l’agent aident, mais on ne leur fait pas confiance à eux seuls. Un serveur MCP peut annoncer qu’un outil est en lecture seule via des annotations comme readOnlyHint ; selon la spécification MCP, ces indications sont non fiables et doivent être corroborées, jamais crues aveuglément. C’est la vue au niveau du noyau qui repère un outil ayant prétendu être en lecture seule et qui a écrit malgré tout.

Une fois la carte établie, l’étape suivante est l’application : épingler le travail d’export en lecture seule sur la base de données, refuser l’écriture et alerter au lieu de simplement journaliser — une politique appliquée au moment de l’accès, et non reconstituée après l’incident.

agent "data-export-job" {
  resource "prod-postgres" {
    access = "read"        # périmètre voulu : lecture de la source uniquement
    deny   = ["write", "ddl"]
  }
  resource "s3://billing-exports" {
    access = "read-write"  # périmètre voulu : écriture de la destination
  }
  on_violation {
    action = "block"
    alert  = "secops"
  }
}

La carte vous indique la politique que vous auriez dû écrire, parce qu’elle vous montre le seul accès dont l’agent avait réellement besoin et la douzaine qu’il n’a jamais utilisés. C’est toute la différence entre deviner le moindre privilège et le déduire de la réalité du terrain.

Si c’est la question à laquelle votre parc ne sait pas répondre aujourd’hui — que peut atteindre chaque agent, et que touche-t-il réellement — c’est précisément à cela que sert la carte d’accès. La présentation du produit déroule la découverte et le diff autorisé-versus-observé ; l’architecture explique comment la collecte passive, l’identité par agent et le registre d’audit s’articulent sans jamais se placer sur le chemin de données de vos agents.