La plupart des équipes découvrent le même constat inconfortable dans le même ordre. Elles réalisent d’abord que des agents IA tournent déjà à travers leur parc, appellent des modèles, ouvrent des serveurs MCP, accèdent à des bases de données et à des stockages d’objets. Puis elles tentent de les inventorier et constatent qu’il n’existe aucune liste. Des recherches indépendantes du secteur (CSA/Token, n=418) chiffrent l’écart : environ 82 % des organisations ont des agents en fonctionnement dont elles ignorent l’existence, et seulement 21 % environ tiennent un inventaire en temps réel. Avant de pouvoir gouverner quoi que ce soit, il faut le voir. La question est : comment obtenir cette visibilité sans aggraver la situation.
Il existe deux réponses honnêtes, et elles se situent aux extrémités opposées d’un spectre de risque.
Deux façons de voir un agent
La première est un proxy en ligne. Vous acheminez le trafic de l’agent à travers un composant que vous contrôlez et, parce que chaque requête et chaque réponse y transitent, vous pouvez voir, façonner et bloquer en temps réel. C’est une conception légitime et puissante. C’est ainsi que sont aujourd’hui appliqués bon nombre de filtrages de sortie, de courtages de secrets et de politiques au niveau de la requête.
La seconde est la découverte passive. Au lieu de vous placer dans le flux, vous l’observez de côté : la télémétrie OpenTelemetry qu’un agent émet déjà, les journaux d’audit natifs des systèmes qu’il touche (pgAudit pour PostgreSQL, les journaux d’audit du cloud comme AWS CloudTrail, l’audit Kubernetes), et les signaux au niveau du noyau via eBPF comme filet de sécurité de référence. Vous ne terminez jamais la connexion. Vous observez ce qui s’est passé et reconstituez qui a touché à quoi.
La différence qui compte n’est pas ce que chaque approche peut voir dans le meilleur des cas. C’est ce qui se produit lorsque la couche de visibilité elle-même tombe en panne.
Le rayon d’impact est le véritable axe
Un proxy en ligne est, par construction, sur le chemin des données. Cela vous procure un contrôle en temps réel, et cela vous coûte un mode de défaillance partagé. Si le proxy est lent, vos agents sont lents. S’il s’effondre, le comportement sûr par défaut consiste généralement à échouer en mode fermé, ce qui signifie que vos agents s’arrêtent, ou en mode ouvert, ce qui signifie que votre contrôle disparaît discrètement au pire moment. Dans les deux cas, le composant de visibilité partage désormais un rayon d’impact avec la production. Il ajoute aussi un saut de latence à chaque appel et une surface de déploiement que quelqu’un doit exploiter, mettre à l’échelle et corriger sur le chemin critique.
La découverte passive présente le profil inverse. Le collecteur est hors bande et en lecture d’abord : il lit la télémétrie, les journaux d’audit et les événements du noyau ; il ne relaie ni ne réécrit le trafic de l’agent. S’il se dégrade ou meurt, rien ne change sur le chemin des requêtes. Vous perdez la visibilité fraîche jusqu’à son rétablissement, ni le débit, ni la disponibilité. Voilà ce que signifie, en pratique, la lecture d’abord à faible risque asymétrique : la chose dont l’unique rôle est d’observer ne fait courir aucun risque à la hausse à la production.
| Proxy en ligne | Découverte passive | |
|---|---|---|
| Position | Sur le chemin des données | Hors bande, à côté |
| Blocage en temps réel | Natif | Nécessite l’application au point d’accès |
| Latence ajoutée | Oui, à chaque appel | Aucune |
| En cas de panne | Les agents calent ou le contrôle disparaît | La visibilité devient obsolète ; les agents ne sont pas affectés |
| Couverture des chemins silencieux | Élevée (il termine le flux) | Dépend des signaux émis + filet de sécurité eBPF |
C’est pourquoi le positionnement du produit est aucun proxy obligatoire plutôt que « les proxies ne servent à rien ». Il existe des chemins où un composant en ligne est le bon choix, et ils se composent. Mais la découverte, la partie qui ne devrait jamais être autorisée à faire tomber ce qu’elle inventorie, est la mauvaise tâche à greffer sur le chemin critique.
L’arbitrage, énoncé honnêtement
La découverte passive a une faiblesse réelle, et prétendre le contraire relèverait du genre d’homme de paille qui fait discrètement perdre confiance dans une conception. Un proxy qui termine un flux en voit chaque octet. Un collecteur passif ne voit que ce que l’agent, son runtime ou la ressource ont choisi d’émettre. Sur un chemin pleinement non coopératif, qui journalise peu et n’émet aucune télémétrie utile, la découverte au niveau applicatif s’amenuise. On peut déduire que quelque chose s’est produit, mais l’attribution devient plus difficile.
Deux éléments maintiennent cela honnête plutôt que fatal.
Le premier est le filet de sécurité noyau eBPF. Les journaux applicatifs peuvent être incomplets, retardés ou, dans un cas adverse, délibérément supprimés. On ne peut pas demander poliment au noyau d’oublier un appel système. Un agent qui ouvre une socket vers une base de données ou écrit un fichier laisse une trace à la frontière des appels système, quel que soit ce que sa journalisation a choisi d’enregistrer. Cela fait d’eBPF la référence anti-évasion : lorsque les signaux de plus haut niveau divergent ou se taisent, la vue du noyau est la couche de corroboration. C’est aussi pourquoi les annotations d’outils MCP telles que readOnlyHint et destructiveHint, utiles à titre d’indices, sont traitées comme non fiables conformément à la spécification MCP. Un outil qui se prétend en lecture seule et qu’on observe en train d’écrire est précisément la divergence qui mérite d’être mise en lumière, et on ne la détecte qu’en corroborant l’affirmation avec ce qui s’est réellement passé.
Le second est l’usage de niveaux de confiance honnêtes. Toutes les observations ne méritent pas le même poids, aussi la carte d’accès ne fait-elle pas semblant du contraire. Une arête étayée par un signal du noyau et une entrée d’audit concordante est marquée attribuée ; une arête déduite d’une télémétrie partielle est marquée approximative. Le produit ne blanchit jamais une supposition en fait. Un relecteur doit pouvoir voir, d’un coup d’œil, quel degré de confiance accorder à chaque ligne.
De l’observation à l’écart qui compte
La découverte n’est que l’entrée. La sortie est la comparaison entre PERMITTED, ce que la politique autorise, et OBSERVED, ce que le collecteur a réellement vu. Cet écart constitue la dérive du moindre privilège, et le cas emblématique est une écriture observée que la politique n’a jamais accordée et que personne n’a relue.
Quelques lignes d’un flux d’accès rendent la chose concrète. Les lectures sont routinières ; l’écriture signalée est le véritable sujet :
agent action resource outcome confidence
data-export-job READ s3://billing-exports allowed attributed
data-export-job READ prod-postgres allowed attributed
data-export-job WRITE prod-postgres flagged attributed
support-rag READ internal-wiki-mcp allowed approximateUne tâche d’export qui lit une base de données de production n’a rien de remarquable. La même tâche qui y écrit, alors que la politique n’a jamais accordé que la lecture, est le type d’arête qui ne devrait jamais passer sans relecture. Parce que l’écriture est corroborée à la frontière du noyau, elle est marquée attributed, et non comme une réserve prudente.
Voir la dérive ne représente que la moitié du travail ; la résorber en est l’autre moitié. L’application revient au point d’accès, exprimée sous forme de politique en tant que code, afin que la règle soit relisible et que la violation donne lieu à une action, et non simplement à une consignation :
policy "data-export-readonly" {
agent = "data-export-job"
resource = "prod-postgres"
allow = ["read"]
deny = ["write"]
on_violation = "block + alert"
}La découverte passive trouve l’écriture non autorisée ; la politique ramène l’agent au moindre privilège et bloque la suivante. Visibilité et contrôle restent des préoccupations distinctes, ce qui est exactement la raison pour laquelle la couche de découverte peut se permettre d’être en lecture d’abord.
À retenir
La visibilité sur les agents IA est une décision de risque avant d’être une décision de fonctionnalité. Un proxy en ligne vous offre un contrôle en temps réel au prix d’un rayon d’impact partagé avec la production. La découverte passive renonce à une partie de sa portée sur les chemins silencieux en échange de l’impossibilité absolue de faire tomber la production, puis récupère l’essentiel de cette portée grâce à un filet de sécurité de référence eBPF et à des niveaux de confiance qui restent honnêtes sur ce qui a réellement été vu. Pour un inventaire, la couche dont l’unique rôle est d’observer, cette asymétrie est le bon réglage par défaut.
Si vous voulez la vue d’ensemble de l’articulation entre les collecteurs, la carte d’accès et le registre d’audit, l’aperçu de l’architecture la détaille de bout en bout.