Qué envía realmente la telemetría de un agente de código

Qué cubre realmente la telemetría de los agentes de programación

La telemetría de los agentes de programación incluye cuatro flujos de datos distintos que comparten una misma palabra, y cada flujo tiene su propio control. La inferencia del modelo envía sus instrucciones y su código al servicio que proporciona el modelo, y ninguna configuración puede desactivarla. Los análisis del producto y los informes de fallos se envían al proveedor y, a menudo, también a una empresa de registro que el proveedor contrata. La conservación de datos para el entrenamiento es una cuestión contractual, no de red. El cuarto flujo es el que suele pasarse por alto: cada integración que añade puede abrir una conexión con un host que usted nunca seleccionó.

Una lista de los valores predeterminados actuales de los proveedores es la parte de este tema que queda obsoleta con mayor rapidez. Una versión puede cambiar un valor predeterminado, y una función nueva puede añadir un destino que ningún conmutador existente controle. Por eso, la capacidad que se mantiene vigente es una auditoría repetible para cualquier agente: lea la documentación del proveedor, compruebe qué configuración se aplicó realmente en esta máquina, supervise el proceso desde la propia máquina y, después, elija los controles por los que está dispuesto a asumir el coste. Todos los comandos siguientes se ejecutan en su propia máquina y supervisan su propio tráfico.

Las cuatro categorías y por qué necesitan controles diferentes

El tráfico de inferencia del modelo es inevitable. El agente envía su solicitud, los archivos que ha leído, la salida de los comandos que ha ejecutado y el texto que ha generado al endpoint del modelo. Ese es el funcionamiento normal del producto. La única decisión real es quién lo recibe: una API administrada por otra persona o un modelo que ejecute usted mismo. Una cuenta en la nube de una empresa (Bedrock, Vertex, Foundry) cambia el receptor, pero no elimina el flujo. Nada de lo que se explica en el resto de este artículo reduce el tráfico de inferencia. Por tanto, manténgalo separado mentalmente de las otras tres categorías.

La analítica del producto y los informes de fallos son flujos distintos hacia hosts distintos. Los contadores de uso, las cifras de latencia, las consultas de indicadores de funciones y los stack traces normalmente se envían a nombres de host que no tienen relación con la API del modelo y, a menudo, a un sistema de seguimiento de errores de terceros. Los proveedores suelen documentarlos como "métricas" e "informes de errores" y normalmente ofrecen una variable de entorno para cada categoría. El volumen es mínimo, por lo que los recuentos de bytes nunca los detectarán. Debe buscar nombres de host, no ancho de banda.

La retención y el entrenamiento son políticas, no paquetes. Si el proveedor conserva sus solicitudes, durante cuánto tiempo y si entrena con ellas un modelo futuro, se establece en las condiciones asociadas a su plan. Los planes para consumidores y los planes comerciales suelen ser diferentes, y un acuerdo de retención cero normalmente requiere un contrato independiente. No puede verificar nada de esto con tcpdump, porque el paquete tiene el mismo aspecto en ambos casos. Lea las condiciones y, si es importante para su empresa, obténgalo por escrito.

Las integraciones añaden silenciosamente un salto. Un servidor MCP (model context protocol), un marketplace de plugins, una comprobación de actualizaciones automáticas, una herramienta de búsqueda web o una comprobación de seguridad que resuelve una URL antes de obtenerla: cada uno realiza una solicitud a un host que no es el endpoint del modelo. Aquí es donde aparecen las sorpresas, porque un harness puede enrutar a través de uno de sus propios servicios un trabajo que usted suponía local. Además, una release puede empezar a hacerlo sin cambiar una sola línea de su configuración. Considere cada herramienta que añada como un nuevo destino hasta que haya observado su tráfico en la red.

Paso 1: ¿qué documenta el proveedor?

Abra la referencia de configuración y la página sobre uso de datos de su agente. Léala con una lista de palabras a mano: métricas, analítica, informes de errores, cierres inesperados, comentarios, encuestas, comprobación de actualizaciones, comprobación de seguridad, marketplace. Cada una de esas palabras suele corresponder a un interruptor independiente. Anote los nombres exactos de las variables, porque el paso 2 los busca con grep.

Una palabra puede inducirle a error. En varios agentes, «telemetría» en la documentación significa una exportación de OpenTelemetry que se configura para enviar métricas a un collector que usted administra. Es lo contrario de enviar datos al proveedor. Claude Code es uno de ellos: establecer CLAUDE_CODE_ENABLE_TELEMETRY=1 inicia una exportación al endpoint que indique en OTEL_EXPORTER_OTLP_ENDPOINT. Esto no está relacionado con la analítica propia del proveedor, que tiene otra opción de exclusión. Determine en qué dirección fluyen los datos antes de cambiar cualquier valor.

Espere encontrar un interruptor principal, pero también excepciones. En agosto de 2026, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC de Claude Code desactiva conjuntamente las métricas, los informes de errores, el comando de comentarios y las encuestas de sesión. La misma documentación indica que no cubre la comprobación de seguridad del dominio de WebFetch. Esa comprobación envía al API del proveedor el nombre de host que está a punto de consultar y tiene una configuración independiente. No es una característica exclusiva de un producto. Este es el problema general: un interruptor principal cubre las categorías que existían cuando se documentó.

La exclusión también puede tener un coste. La misma documentación señala que desactivar la telemetría también desactiva la evaluación de feature flags de la que dependen algunas funciones. Por tanto, un cambio aplicado por motivos de privacidad puede desactivar una función que utiliza, sin mostrar un mensaje de error que relacione ambos hechos. Lea la frase situada junto al indicador, no sólo su nombre.

Paso 2: ¿qué configuración se aplicó realmente?

Una opción que ha escrito no es necesariamente una opción que se haya aplicado. Los agentes combinan la configuración de varios archivos, y uno de ellos puede estar dentro del repositorio que acaba de clonar de otra persona. Empiece por el entorno de su propia shell.

env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'

Después, muestre todos los archivos de configuración que lee la herramienta, en el orden indicado en la documentación. Para Claude Code, en agosto de 2026, son el archivo del usuario, los dos archivos del proyecto y un directorio de políticas administradas en Linux.

for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
  echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/null

Un archivo del proyecto que llegó con un git clone contiene configuración escrita por otra persona, y puede volver a activar una opción que el archivo del usuario había desactivado. Si el agente tiene un comando de estado que muestra las fuentes que cargó, esa es la forma más rápida de obtener la información real: Claude Code muestra las fuentes de configuración cargadas en /status.

La comprobación más sólida consulta el proceso en ejecución en lugar de cualquier archivo. Primero, asigne al agente su propia cuenta de usuario de Linux. Así, todos los comandos de esta publicación serán más cortos. Después, lea el entorno con el que se inició el proceso.

pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'

/proc/<pid>/environ muestra las variables que tenía el proceso en el momento de ejecutar exec, por lo que detecta el caso en que la exportación de .bashrc nunca llegó a un servicio iniciado por systemd. Si aquí falta una variable que configuró, nunca estuvo aplicada, independientemente de lo que indiquen sus archivos de configuración de shell.

Paso 3: ¿a qué hosts se conecta?

Empiece por los sockets abiertos, filtrados por la cuenta con la que se ejecuta el agente.

sudo ss -tnpe state established

-e añade un campo uid: a cada línea, de modo que puede separar las conexiones del agente de las de su navegador sin leer los nombres de los procesos. Anote las direcciones remotas y, después, obtenga los nombres asociados. La fuente más precisa de nombres es el handshake TLS (seguridad de la capa de transporte), porque cada conexión nueva comienza con un ClientHello que incluye un campo SNI (indicación del nombre del servidor), es decir, el nombre de host solicitado por el cliente.

sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

Obtendrá una línea por cada conexión nueva. Ese es exactamente el inventario que necesita: la API del modelo, el servidor de actualizaciones, el host de analítica, el sistema de seguimiento de errores y cualquier destino añadido por una integración. Una columna de nombres vacía significa que el cliente usó ECH (ClientHello cifrado), por lo que el nombre de host no es visible en la red. En ese caso, use la dirección IP de destino, una consulta inversa o el proxy del paso 4.

La vista de DNS (sistema de nombres de dominio) es una comprobación adicional útil, porque muestra los nombres que el agente consultó incluso en las conexiones que no llegó a completar.

sudo tcpdump -ni any -l 'udp port 53'

Cada línea de consulta termina con el tipo de registro y el nombre, con el formato A? host.example.net. (39). Capture en any en lugar de hacerlo en la interfaz externa, porque con systemd-resolved la aplicación se comunica con un listener stub local en 127.0.0.53 y sólo el stub se comunica con el exterior. Si no observa tráfico DNS mientras el agente funciona claramente, ese runtime está realizando DNS sobre HTTPS por su cuenta. En ese caso, sólo el paso 4 le proporcionará los nombres.

Capture tráfico mientras el agente realiza trabajo real. Inicie una sesión, haga que lea un archivo, haga que ejecute un comando y haga que falle en algún punto. El tráfico que se produce una sola vez durante el arranque, o sólo cuando se lanza una excepción, nunca aparece en una captura inactiva. Una captura inactiva es la forma más habitual de que una auditoría llegue a una conclusión errónea pero aparentemente tranquilizadora.

Paso 4: ¿qué contienen las solicitudes?

Los nombres de host indican quién. Para ver qué se envía, coloque un proxy que controle delante del agente y haga que ese entorno confíe únicamente en su autoridad certificadora (CA). mitmproxy es la herramienta habitual. El proyecto recomienda los binarios independientes de mitmproxy.org y documenta uv tool install mitmproxy como opción mediante el paquete de Python.

mitmdump -w /tmp/agent-flows.mitm

La primera ejecución escribe una CA en ~/.mitmproxy/, donde mitmproxy-ca-cert.pem es el certificado independiente. En el shell desde el que iniciará el agente, configure el cliente para que use el proxy y ese certificado.

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"

Muchas CLI de agentes son programas de Node, y Node lee NODE_EXTRA_CA_CERTS cuando se inicia el proceso. Por tanto, expórtela antes de iniciar el agente y no después desde otro terminal. Los clientes de Python leen REQUESTS_CA_BUNDLE o SSL_CERT_FILE, y un binario de Go que usa la biblioteca estándar lee SSL_CERT_FILE en Linux. Compruebe que la ruta funciona con curl antes de atribuir el problema al agente.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Un proxy operativo muestra 200 y la solicitud aparece en la salida de mitmdump. Una CA no confiable produce curl: (60) SSL certificate problem: self-signed certificate in certificate chain. El equivalente en un agente de Node es un error que contiene el código SELF_SIGNED_CERT_IN_CHAIN. Después, lea los flujos guardados con el visor de consola. Allí puede abrir una solicitud y leer sus cabeceras y su cuerpo.

mitmproxy -r /tmp/agent-flows.mitm

Conviene distinguir cuatro resultados. Puede ver las solicitudes. En ese caso, léalas y decida. El agente puede negarse a iniciarse con un error de certificado. Eso indica un problema de confianza en ese entorno de ejecución, no un hallazgo sobre el proveedor. También puede ver sólo la API del modelo. Eso significa que las otras categorías están desactivadas o que se activan con un evento que no provocó. Por último, puede no ver nada mientras el agente funciona claramente. Eso significa que el cliente ignora las variables de entorno del proxy o fija sus certificados. En ese caso, no puede confiar en ninguna configuración de la aplicación para saber qué ocurre realmente. Este último resultado es el más importante. Le devuelve al paso 3, porque una captura de paquetes no puede dejar de ver una conexión.

Controles, de menor a mayor solidez

Configuración de exclusión. Es la opción más barata y más débil, porque depende de que el proveedor la respete y sólo cubre una categoría que ya existía. Configúrela donde se conserve tras reiniciar y al abrir un terminal nuevo: en el archivo de configuración del usuario o en el perfil del shell. Añada también DO_NOT_TRACK=1: es una convención que respetan muchas herramientas de línea de comandos, incluidos algunos agentes, y no tiene ningún coste. Después de la siguiente actualización, vuelva a ejecutar el paso 3, porque ese es el momento en que cambia la cobertura.

Restricción de salida. Aquí deja de pedir y empieza a imponer. Ejecute el agente con su propio usuario. Después, permita a ese usuario acceder al loopback y a DNS, y bloquee el resto. Esto añade su propia tabla, por lo que no modifica las reglas de firewall existentes.

table inet agentegress {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ip daddr 127.0.0.0/8 accept
    meta skuid "agent" udp dport 53 accept
    meta skuid "agent" counter log prefix "agent-egress-drop " drop
  }
}

Aplíquela con sudo nft -f /etc/nftables.d/agent.nft, supervise el contador con sudo nft list table inet agentegress y consulte los bloqueos con sudo journalctl -k -g agent-egress-drop. Un contador de bloqueos que aumenta junto con un nombre de host inesperado es precisamente el objetivo. Hay dos limitaciones importantes. meta skuid coincide con el usuario propietario del socket, por lo que sólo funciona mientras esa cuenta no pueda convertirse en otro usuario: un sudo sin contraseña para el agente convierte esta regla en una sugerencia. Además, dejar UDP 53 abierto para cualquier servidor mantiene un canal que puede sacar datos mediante los nombres de las consultas. Ciérrelo también si su modelo de amenazas lo requiere. Para ello, configure el resolver del agente para que use un host bajo su control. Las listas de permitidos por nombre de host deben gestionarse en un proxy y no en nftables, porque los endpoints de las API están detrás de redes de distribución de contenido cuyas direcciones IP cambian sin previo aviso. El coste de este control es la interrupción del servicio y el mantenimiento: las instalaciones de paquetes, git mediante SSH y la propia comprobación de actualizaciones del agente fallan hasta que las permita. A partir de ese momento, usted debe mantener esa lista. Si configura esto en un servidor y no en un portátil, la misma disposición de cuentas y firewall es la base de ejecutar Claude Code de forma segura en un VPS.

Una máquina desechable. Asigne al agente una máquina virtual (VM) que no contenga credenciales importantes y que se destruya al terminar la tarea. Esto no reduce lo que envía el agente. Reduce aquello a lo que el agente puede acceder para enviarlo, que normalmente es el riesgo que realmente importa. Combínelo con las reglas de salida anteriores, porque una VM nueva con acceso sin restricciones a Internet sigue pudiendo acceder a todos los hosts incluidos en su captura. El método y el estado que debe reconstruir cada vez se explican en ejecutar agentes de programación en una VM desechable, y la cuestión del dimensionamiento en ejecutar un agente de programación en un VPS.

Alojar el modelo en sus propios sistemas. Es el único control que elimina el flujo de inferencia, porque el prompt nunca sale de su hardware. El coste es real: no puede alojar un modelo cerrado en sus propios sistemas. Esto implica elegir pesos abiertos, aceptar una diferencia de capacidad en las tareas difíciles y disponer del hardware necesario para servirlos. El compromiso se analiza en si puede alojar Claude en sus propios sistemas, y las diferencias de capacidad entre los principales agentes en diferencias entre Claude Code, Cursor, Codex y Copilot.

Ninguno de estos cuatro controles cambia lo que el agente puede leer del disco, y el tráfico de inferencia transporta todo lo que lee. Si un archivo .env está en el directorio de trabajo, se envía al modelo en cuanto el agente busca el nombre de una variable con grep. Mantener ese material fuera de su alcance es una tarea independiente, que se trata en mantener los secretos fuera del contexto de un agente de IA.

Qué comprobar después de cada actualización

1. Compare las páginas del proveedor sobre configuración y uso de datos con lo que registró la última vez. Busque nuevos interruptores y nuevos servicios con nombre.
2. Vuelva a leer el entorno del proceso desde /proc/<pid>/environ para confirmar que las exclusiones siguen aplicadas al proceso en ejecución.
3. Vuelva a mostrar los archivos de configuración del proyecto, porque un git pull puede cargar un archivo de configuración que haya cambiado un compañero.
4. Ejecute la captura SNI durante una sesión completa de trabajo real y compare la lista de nombres de host con la anterior.
5. Compruebe el contador de descartes del firewall, porque un nuevo destino suele aparecer allí antes de que lo detecte en cualquier otro sitio.

Esto tarda unos diez minutos y es la única parte del proceso que no queda obsoleta. Un valor predeterminado que verificó en agosto de 2026 es un hecho de agosto de 2026. La captura es un hecho de hoy.

FAQ

¿Puedo impedir que mi agente de programación envíe mi código al modelo?

No, y cualquier configuración que afirme hacerlo describe otra cosa. Enviar el prompt, los archivos que el agente leyó y la salida de los comandos que ejecutó al endpoint del modelo es el funcionamiento normal de la inferencia, por lo que la única variable es quién los recibe. Puede cambiar el receptor si dirige el agente a una cuenta cloud de la empresa o a un modelo alojado por usted, y puede reducir lo que envía limitando lo que tiene permitido leer. Desactivar la analítica y los informes de errores no afecta en absoluto a este flujo.

¿Cómo puedo ver a qué hosts se conecta mi agente de programación?

Ejecute el agente con su propio usuario de Linux y capture después el TLS ClientHello de cada conexión nueva mientras lo utiliza: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name. Aparece una línea por conexión, con la dirección de destino y el nombre de host solicitado. Compruebe los nombres con sudo tcpdump -ni any 'udp port 53', capturando en any porque un stub de resolución local en 127.0.0.53 gestiona primero la consulta. Realice la captura mientras el agente hace trabajo real, ya que los pings de inicio y los informes de fallos no aparecen en una captura en estado inactivo.

Mi proxy no muestra tráfico mientras el agente trabaja. ¿Qué ha ocurrido?

El cliente ignora HTTP_PROXY y HTTPS_PROXY, o fija sus certificados y rechaza su CA. Pruebe primero la ruta con curl: si curl llega a Internet a través del proxy y el agente no aparece en la lista de flujos, el agente no utiliza las variables de entorno del proxy. Algunos runtimes necesitan que la CA se proporcione de una forma concreta. En particular, Node sólo lee NODE_EXTRA_CA_CERTS al iniciar el proceso, por lo que exportarla después de iniciar el agente no tiene ningún efecto. Si el proxy no puede ver el tráfico, recurra a una captura de paquetes, que ninguna configuración de la aplicación puede omitir.

¿Desactivar la telemetría impide que mi código se use para entrenar modelos?

No. La analítica y los informes de fallos siguen un flujo distinto del de la inferencia. Desactivarlos elimina los contadores de uso y los stack traces, pero deja cada prompt enviado al modelo exactamente igual que antes. Los términos de su plan determinan si esos prompts se conservan y si se utilizan para entrenar un modelo futuro. Los planes para consumidores y los planes comerciales suelen ser distintos. Es una cuestión contractual que debe leer, no un paquete que deba capturar. Consulte la página de uso de datos de su plan y, cuando sea necesario, acuerde un contrato comercial o de retención cero antes de la primera sesión.