Présentation de Beacon : télémétrie des points de terminaison pour les agents IA

La première génération de sécurité IA était centrée sur la passerelle de modèle. La suivante se déplacera vers l'endpoint, là où les agents effectuent réellement le travail.

Les passerelles avaient du sens quand les systèmes IA répondaient principalement à des questions. Une équipe de sécurité pouvait placer un point de contrôle entre l'utilisateur et le modèle, inspecter les invites et les sorties, appliquer la DLP, gérer l'accès au modèle et journaliser les échanges.

Les agents forcent cette architecture à évoluer. Le problème de sécurité n'est plus seulement ce qu'un modèle dit ou voit. C'est ce qu'un agent peut faire : utiliser les outils de l'utilisateur, hériter de ses permissions et modifier l'état dans des environnements sensibles.

L'exemple le plus clair est la machine du développeur. Les agents de codage comme Claude Code, Codex et Cursor s'exécutent aux côtés du code source, des terminaux, des gestionnaires de paquets, des CLI cloud, des identifiants locaux et des systèmes proches de la production. Une seule requête en langage naturel peut se transformer en lectures de fichiers, commandes shell, modifications de dépendances, actions authentifiées et modifications de code.

Ce même modèle s'étend désormais au-delà des développeurs vers les travailleurs du savoir. Les agents connectés au bureau commencent à opérer à travers les applications SaaS, les outils locaux et les systèmes internes. Les espaces de travail agents comme Claude Cowork et OpenClaw pointent vers la prochaine phase de l'IA d'entreprise : l'ordinateur portable de l'utilisateur devient l'environnement d'exécution pour le travail délégué à travers les applications d'entreprise.

La dure réalité aujourd'hui est que les équipes de sécurité peuvent ne voir le rayon d'explosion qu'après qu'un agent a exécuté des commandes, modifié des fichiers, installé des dépendances ou exfiltré des données. Les modes de défaillance sont déjà graves : exécution de code à distance via la configuration de projet Claude Code, exposition de code privé via l'injection d'invite dans Copilot Chat, et vol d'identifiants via des packages npm malveillants qui transforment les agents de codage locaux en chemins d'attaque.

C'est le fossé de visibilité sur l'endpoint que Beacon est conçu pour combler.

Beacon est la couche de télémétrie d'endpoint open-source de @asymptotelabs pour les agents IA. C'est notre premier pas vers la rendue de l'activité locale des agents observable, compréhensible et éventuellement gouvernable à travers l'entreprise.

Ce que cela signifie pour les équipes de sécurité

Pour les équipes de sécurité, cela compte car la pile existante n'a pas été conçue pour expliquer le travail délégué. Les passerelles, l'EDR et la télémétrie native des agents restent importants, mais chacun ne voit qu'une partie de ce qu'un agent fait. Pour gouverner les agents en toute sécurité, les équipes doivent voir comment un agent passe de l'intention à l'action sur l'endpoint.

Trois lacunes se démarquent :

1. Les journaux d'endpoint montrent les effets, pas les workflows. Ils peuvent capturer les commandes, les modifications de fichiers et l'activité des processus, mais ils relient rarement ces événements à la requête de l'agent, à la décision d'outil, au chemin d'approbation ou au diff final.
2. La télémétrie des agents a besoin d'une couche commune. Les agents de codage IA comme Claude Code, Cursor, Codex et Claude Cowork exposent tous des signaux de télémétrie différents. Les équipes de sécurité ont besoin d'un enregistrement unifié au niveau de l'endpoint à travers eux.
3. La visibilité vient avant le contrôle. Les équipes ne peuvent pas appliquer les configurations, filtrer les actions sensibles, gouverner l'accès MCP ou protéger les secrets tant qu'elles ne savent pas quels agents sont en cours d'exécution, quelles permissions ils ont et quelles actions ils entreprennent.

Les journaux d'endpoint ne capturent pas les workflows des agents

La télémétrie d'endpoint traditionnelle est nécessaire, mais insuffisante pour comprendre le comportement des agents.

Elle peut montrer que des commandes ont été exécutées, des fichiers modifiés, des processus lancés ou des connexions ouvertes. Ce qu'elle ne peut généralement pas montrer, c'est le workflow derrière l'événement : ce qu'on a demandé à l'agent de faire, ce qu'il a décidé de faire et si l'action avait du sens pour la tâche.

La même action d'agent peut être sûre ou risquée selon la tâche qui l'entoure. Par exemple :

• Une commande kubectl peut être appropriée lors d'un incident d'infrastructure, mais inappropriée pour un agent de codage chargé de mettre à jour un test unitaire.
• Une lecture de .env peut être attendue lors du débogage local, mais suspecte lors d'une modification de documentation.
• Un changement Terraform peut être normal dans un dépôt d'infrastructure, mais dangereux lorsqu'il est introduit comme effet secondaire d'une mise à jour de dépendance.

Dans chaque cas, l'événement brut ne suffit pas. La signification sécuritaire dépend du workflow qui l'entoure : l'invite, le plan, le contexte accédé, les outils invoqués, les fichiers touchés, les identifiants utilisés et les approbations accordées.

Considérez un agent de codage chargé d'effectuer un changement de test restreint : la requête utilisateur pourrait ressembler à ceci : « Mettez à jour le test unitaire pour la logique de nouvelle tentative de facturation. »

La télémétrie traditionnelle pourrait montrer :

• test_retry.py modifié
• .env lu
• main.tf modifié
• kubectl apply exécuté

Ces événements sont utiles, mais ils sont déconnectés du workflow de l'agent. Le journal montre qu'un test a changé, qu'un fichier secret a été lu, que Terraform a été modifié et qu'une commande de déploiement a été exécutée. Il ne montre pas si ces actions faisaient partie de la requête de l'utilisateur, quelle décision d'outil les a produites, ou si l'utilisateur a approuvé les étapes sensibles.

Un enregistrement conscient de l'agent relie ces mêmes événements au workflow :

• Requête : « Mettez à jour le test unitaire pour la logique de nouvelle tentative de facturation. »
• Plan : Lire le fichier de test, comprendre la logique, mettre à jour le test, vérifier.
• Appel d'outil : read_file(test_retry.py)
• Lecture de fichier : test_retry.py
• Appel d'outil : read_file(.env) — inattendu
• Lecture de fichier : .env — inattendu
• Appel d'outil : edit_file(main.tf) — inattendu
• Modification de fichier : main.tf — inattendu
• Appel d'outil : execute_command(kubectl apply -f main.tf) — inattendu
• Commande : kubectl apply -f main.tf — inattendu
• Approbation : L'utilisateur a-t-il approuvé kubectl apply ? (inconnu)

Sans cette trace, les équipes de sécurité doivent reconstruire l'intention à partir d'artefacts de bas niveau après coup. Elles peuvent voir les effets de l'activité de l'agent, mais pas si le comportement de l'agent était approprié pour le travail qu'on lui a demandé d'effectuer.

Beacon : une couche de télémétrie d'endpoint pour les agents IA

La plupart des équipes de sécurité et informatiques peuvent répondre quels modèles sont approuvés ou quelles passerelles sont déployées. Une fois que les agents s'exécutent localement, les questions de sécurité se rapprochent de l'endpoint :

Inventaire des agents : Quels outils d'agent sont installés ? Quels utilisateurs et appareils les exécutent ?

Contexte d'exécution : Dans quels dépôts et espaces de travail les agents opèrent-ils ? Quels outils, identifiants et permissions locales peuvent-ils hériter ?

Activité des agents : Quels fichiers les agents lisent-ils ou modifient-ils ? Quelles commandes, approbations et diffs génèrent-ils ?

Télémétrie et audit : Quelle télémétrie est collectée et où est-elle envoyée ? Les équipes de sécurité peuvent-elles relier la requête utilisateur originale aux actions effectuées ?

La télémétrie native des agents aide, mais elle est fragmentée. Claude Code et Codex peuvent exporter OpenTelemetry. Cursor expose des hooks pour les sessions, les invites, l'utilisation d'outils, l'exécution de commandes, les approbations, les activités de type MCP et les modifications de fichiers. Claude Cowork peut exporter la télémétrie via un point de terminaison OTLP configuré par l'administrateur.

Ce dont les équipes de sécurité ont besoin, c'est d'un enregistrement de workflow qui les couvre : ce qu'on a demandé à l'agent de faire, quel contexte il avait, quels outils il a invoqués, quelles approbations étaient requises et ce qui a changé sur l'endpoint.

Beacon comble ce fossé en configurant OpenTelemetry là où c'est pris en charge, en collectant les signaux locaux là où ils sont disponibles, et en mappant l'activité fragmentée des agents dans un format d'événement d'endpoint commun.

Comme le montre la Figure 1, Beacon connecte quatre couches :

1. Environnements d'exécution des agents : Claude Code, Codex, Cursor, Claude Cowork, OpenClaw et les modèles locaux génèrent des invites, des plans, des appels d'outils, des approbations, des diffs et des états d'exécution.
2. Activité d'endpoint : Ces agents interagissent avec la machine : fichiers, terminaux, gestionnaires de paquets, serveurs MCP, CLI cloud, dépôts, identifiants et configuration locale.
3. Normalisation Beacon : Beacon transforme les signaux fragmentés d'OpenTelemetry, basés sur des hooks et d'endpoint en un flux d'événements JSON commun, afin que les équipes de sécurité puissent suivre la chaîne de la requête de l'agent à l'action locale.
4. Destinations de sécurité : Beacon écrit du JSONL compatible Wazuh aujourd'hui. Le même flux d'événements normalisé peut s'étendre aux SIEM, lacs de données, plateformes d'observabilité, pipelines de détection et workflows d'endpoint que les entreprises utilisent déjà.

Avec Beacon, les invites, les appels d'outils, les commandes, les modifications de fichiers, les approbations, les interactions MCP et les changements d'exécution deviennent partie d'un seul enregistrement au niveau de l'endpoint : une chaîne plus claire de la requête utilisateur à l'action locale, à travers les agents et les outils.

La visibilité d'abord, le contrôle ensuite

Les agents deviennent une nouvelle couche d'exécution au sein de l'entreprise.

Ils lisent des fichiers, appellent des outils, utilisent des identifiants, modifient des systèmes et agissent avec l'autorité des personnes qui leur délèguent du travail. Cette activité ne peut être comprise ou gouvernée depuis la seule passerelle de modèle.

L'endpoint est l'endroit où le contexte, l'autorité et l'action de l'agent se rejoignent. C'est là que les invites deviennent des commandes, que les outils héritent des permissions, que les identifiants sont utilisés et que les modifications sont effectuées.

Cela fait de la télémétrie d'endpoint le fondement de la sécurité des agents.

Beacon rend l'activité locale des agents observable à travers les outils que les entreprises adoptent déjà. Il donne aux équipes de sécurité un enregistrement commun de ce qu'on a demandé aux agents de faire, ce qu'ils ont touché, ce qu'ils ont modifié et si les actions sensibles ont été approuvées.

Cette couche doit être digne de confiance. Beacon est open source et sous licence MIT car il s'exécute près du workflow des développeurs, du code source, des identifiants et des systèmes proches de la production. Les développeurs devraient pouvoir inspecter ce qui est collecté. Les équipes de sécurité devraient pouvoir vérifier la télémétrie. Les équipes informatiques devraient comprendre exactement ce qu'elles déploient.

L'activité des agents devrait être observable avant d'être gouvernable.

Beacon est notre premier pas pour rendre cela vrai.