Presentamos Beacon: Telemetría de puntos finales para agentes de IA

La primera generación de seguridad en IA se centró en la puerta de enlace del modelo. La siguiente se moverá al endpoint, donde los agentes realmente hacen el trabajo.

Las puertas de enlace tenían sentido cuando los sistemas de IA principalmente respondían preguntas. Un equipo de seguridad podía colocar un punto de control entre el usuario y el modelo, inspeccionar indicaciones y salidas, aplicar DLP, mediar el acceso al modelo y registrar el intercambio.

Los agentes obligan a que esa arquitectura evolucione. El problema de seguridad ya no es solo lo que un modelo dice o ve. Es lo que un agente puede hacer: usar las herramientas del usuario, heredar sus permisos y cambiar el estado dentro de entornos sensibles.

El ejemplo más claro es la máquina del desarrollador. Agentes de codificación como Claude Code, Codex y Cursor se ejecutan junto al código fuente, terminales, gestores de paquetes, CLIs en la nube, credenciales locales y sistemas cercanos a producción. Una sola solicitud en lenguaje natural puede convertirse en lecturas de archivos, comandos de shell, cambios de dependencias, acciones con credenciales y modificaciones de código.

Ese mismo patrón ahora se está expandiendo más allá de los desarrolladores hacia los trabajadores del conocimiento. Los agentes conectados al escritorio están comenzando a operar en aplicaciones SaaS, herramientas locales y sistemas internos. Espacios de trabajo de agentes como Claude Cowork y OpenClaw apuntan a la siguiente fase de la IA empresarial: la laptop del usuario se convierte en el entorno de ejecución para el trabajo delegado en aplicaciones empresariales.

La dura realidad hoy es que los equipos de seguridad solo pueden ver el radio de explosión después de que un agente haya ejecutado comandos, modificado archivos, instalado dependencias o exfiltrado datos. Los modos de fallo ya son graves: ejecución remota de código a través de la configuración de proyectos de Claude Code, exposición de código privado mediante inyección de indicaciones en Copilot Chat, y robo de credenciales a través de paquetes npm maliciosos que convierten a los agentes de codificación locales en vectores de ataque.

Esa es la brecha de visibilidad en el endpoint que Beacon está diseñado para cerrar.

Beacon es la capa de telemetría de endpoint de código abierto de @asymptotelabs para agentes de IA. Es nuestro primer paso para hacer que la actividad local de los agentes sea observable, comprensible y, eventualmente, gobernable en toda la empresa.

Qué Significa Esto para los Equipos de Seguridad

Para los equipos de seguridad, esto importa porque el stack existente no fue diseñado para explicar el trabajo delegado. Las puertas de enlace, EDR y la telemetría nativa de agentes siguen siendo importantes, pero cada una ve solo una parte de lo que el agente está haciendo. Para gobernar los agentes de manera segura, los equipos necesitan ver cómo un agente pasa de la intención a la acción en el endpoint.

Tres brechas destacan:

1. Los registros del endpoint muestran efectos, no flujos de trabajo. Pueden capturar comandos, cambios de archivos y actividad de procesos, pero rara vez conectan esos eventos con la solicitud del agente, la decisión de la herramienta, la ruta de aprobación o el diff final.
2. La telemetría de agentes necesita una capa común. Los agentes de codificación de IA como Claude Code, Cursor, Codex y Claude Cowork exponen diferentes señales de telemetría. Los equipos de seguridad necesitan un registro unificado a nivel de endpoint entre ellos.
3. La visibilidad viene antes que el control. Los equipos no pueden aplicar configuraciones, restringir acciones sensibles, gobernar el acceso a MCP o proteger secretos hasta que sepan qué agentes se están ejecutando, qué permisos tienen y qué acciones están tomando.

Los Registros del Endpoint No Capturan los Flujos de Trabajo de los Agentes

La telemetría tradicional del endpoint es necesaria, pero insuficiente para entender el comportamiento de los agentes.

Puede mostrar que se ejecutaron comandos, se modificaron archivos, se generaron procesos o se abrieron conexiones. Lo que normalmente no puede mostrar es el flujo de trabajo detrás del evento: qué se le pidió al agente que hiciera, qué decidió hacer y si la acción tenía sentido para la tarea.

La misma acción de un agente puede ser segura o arriesgada dependiendo de la tarea que la rodea. Por ejemplo:

• Un comando kubectl puede ser apropiado durante un incidente de infraestructura, pero inapropiado para un agente de codificación al que se le pidió actualizar una prueba unitaria.
• Una lectura de .env puede ser esperada durante la depuración local, pero sospechosa durante una edición de documentación.
• Un cambio en Terraform puede ser normal en un repositorio de infraestructura, pero peligroso cuando se introduce como efecto secundario de una actualización de dependencias.

En cada caso, el evento bruto no es suficiente. El significado de seguridad depende del flujo de trabajo que lo rodea: la indicación, el plan, el contexto al que se accedió, las herramientas invocadas, los archivos tocados, las credenciales utilizadas y las aprobaciones otorgadas.

Considere un agente de codificación al que se le pide hacer un cambio de prueba limitado: La solicitud del usuario podría verse así: "Actualiza la prueba unitaria para la lógica de reintento de facturación."

La telemetría tradicional podría mostrar:

Esos eventos son útiles, pero están desconectados del flujo de trabajo del agente. El registro muestra que una prueba cambió, se leyó un archivo secreto, se modificó Terraform y se ejecutó un comando de despliegue. No muestra si esas acciones eran parte de la solicitud del usuario, qué decisión de herramienta las produjo, o si el usuario aprobó los pasos sensibles.

Un registro consciente del agente conecta esos mismos eventos de vuelta al flujo de trabajo:

Sin ese rastro, los equipos de seguridad se quedan reconstruyendo la intención a partir de artefactos de bajo nivel después del hecho. Pueden ver los efectos de la actividad del agente, pero no si el comportamiento del agente era apropiado para el trabajo que se le pidió hacer.

Beacon: Una Capa de Telemetría de Endpoint para Agentes de IA

La mayoría de los equipos de seguridad y TI pueden responder qué modelos están aprobados o qué puertas de enlace están desplegadas. Una vez que los agentes se ejecutan localmente, las preguntas de seguridad se acercan al endpoint:

Inventario de agentes: ¿Qué herramientas de agente están instaladas? ¿Qué usuarios y dispositivos las están ejecutando?

Contexto de ejecución: ¿En qué repositorios y espacios de trabajo están operando los agentes? ¿Qué herramientas, credenciales y permisos locales pueden heredar?

Actividad del agente: ¿Qué archivos están leyendo o modificando los agentes? ¿Qué comandos, aprobaciones y diffs están generando?

Telemetría y auditoría: ¿Qué telemetría se está recopilando y a dónde se está enviando? ¿Pueden los equipos de seguridad conectar la solicitud original del usuario con las acciones tomadas?

La telemetría nativa de agentes ayuda, pero está fragmentada. Claude Code y Codex pueden exportar OpenTelemetry. Cursor expone hooks para sesiones, indicaciones, uso de herramientas, ejecución de comandos, aprobaciones, actividad similar a MCP y ediciones de archivos. Claude Cowork puede exportar telemetría a través de un endpoint OTLP configurado por el administrador.

Lo que los equipos de seguridad necesitan es un registro de flujo de trabajo que los abarque: qué se le pidió al agente que hiciera, qué contexto tenía, qué herramientas invocó, qué aprobaciones se requirieron y qué cambió en el endpoint.

Beacon llena ese vacío configurando OpenTelemetry donde sea compatible, recopilando señales locales cuando estén disponibles y mapeando la actividad fragmentada de los agentes en un formato de evento de endpoint común.

Como se muestra en la Figura 1, Beacon conecta cuatro capas:

1. Entornos de ejecución de agentes: Claude Code, Codex, Cursor, Claude Cowork, OpenClaw y modelos locales generan indicaciones, planes, llamadas a herramientas, aprobaciones, diffs y estado de ejecución.
2. Actividad del endpoint: Esos agentes interactúan con la máquina: archivos, terminales, gestores de paquetes, servidores MCP, CLIs en la nube, repositorios, credenciales y configuración local.
3. Normalización de Beacon: Beacon convierte señales fragmentadas de OpenTelemetry, basadas en hooks y del endpoint en un flujo común de eventos JSON, para que los equipos de seguridad puedan seguir la cadena desde la solicitud del agente hasta la acción local.
4. Destinos de seguridad: Beacon escribe JSONL compatible con Wazuh hoy. El mismo flujo de eventos normalizado puede extenderse a los SIEMs, lagos de datos, plataformas de observabilidad, pipelines de detección y flujos de trabajo de endpoint que las empresas ya utilizan.

Con Beacon, las indicaciones, llamadas a herramientas, comandos, ediciones de archivos, aprobaciones, interacciones MCP y cambios en tiempo de ejecución se convierten en parte de un registro a nivel de endpoint: una cadena más clara desde la solicitud del usuario hasta la acción local, a través de agentes y herramientas.

Visibilidad Primero, Control Después

Los agentes se están convirtiendo en una nueva capa de ejecución dentro de la empresa.

Leen archivos, llaman a herramientas, usan credenciales, modifican sistemas y actúan con la autoridad de las personas que les delegan trabajo. Esa actividad no puede ser entendida ni gobernada solo desde la puerta de enlace del modelo.

El endpoint es donde el contexto, la autoridad y la acción del agente se unen. Es donde las indicaciones se convierten en comandos, las herramientas heredan permisos, las credenciales se utilizan y se realizan cambios.

Eso hace que la telemetría del endpoint sea la base para la seguridad de los agentes.

Beacon hace que la actividad local de los agentes sea observable a través de las herramientas que las empresas ya están adoptando. Proporciona a los equipos de seguridad un registro común de qué se les pidió a los agentes que hicieran, qué tocaron, qué cambiaron y si las acciones sensibles fueron aprobadas.

Esta capa debe ser confiable. Beacon es de código abierto y tiene licencia MIT porque se ejecuta cerca del flujo de trabajo del desarrollador, el código fuente, las credenciales y los sistemas cercanos a producción. Los desarrolladores deberían poder inspeccionar lo que se recopila. Los equipos de seguridad deberían poder verificar la telemetría. Los equipos de TI deberían entender exactamente lo que están desplegando.

La actividad de los agentes debería ser observable antes de ser gobernable.

Beacon es nuestro primer paso para hacer eso realidad.