Telemetría de agentes: observar sin capturar secretos

Observe primero la estructura de la ejecución, no su contenido. Para operar un agente suele bastar con saber qué modelo respondió, cuánto duró la sesión, cuántos turnos y llamadas de herramientas ocurrieron, qué tipo de herramienta falló, si una política bloqueó la acción y si el cambio fue aceptado o revertido. La identidad puede añadirse como una clase independiente cuando exista un propósito de auditoría válido; prompts, respuestas, argumentos, resultados y rutas crudas deben permanecer apagados hasta que una investigación concreta justifique cada campo. GitHub formalizó esta separación el 12 de octubre de 2026: su telemetría administrada permite atribuir actividad a una cuenta, usuario local y máquina sin habilitar el contenido de la conversación. El cambio no demuestra por sí solo cumplimiento ni seguridad. Sí ofrece una arquitectura útil: minimizar por defecto, gobernar cada clase por separado y dirigir las señales solo a un collector aprobado con acceso, retención y borrado explícitos.

La noticia central tenía dos días calendario en America/Lima al consultarla el 14 de octubre. GitHub documenta que identidad y cinco clases de contenido están desactivadas por defecto y que la configuración administrada prevalece sobre ajustes locales. La guía de VS Code confirma que, sin captura de contenido, siguen disponibles nombres de modelos, tokens, duraciones, conteos, resultados de hooks y métricas de aceptación. Esas son afirmaciones de contrato del proveedor; este artículo no presenta una auditoría independiente de todos los clientes ni supone que cada harness emita exactamente los mismos atributos.

Una traza de agente tiene varias capas. El span de invocación envuelve la sesión completa; debajo aparecen llamadas al modelo, ejecuciones de herramientas y hooks. Sin copiar el texto, cada capa puede conservar estructura: proveedor y modelo resuelto, tokens de entrada y salida, tiempo hasta el primer token, duración total, nombre o tipo de herramienta, éxito o error, decisión de un hook y conteo de turnos. También pueden emitirse métricas agregables de llamadas, latencia, aceptación de ediciones y supervivencia de cambios. Esa estructura responde preguntas operativas sin reconstruir la conversación.

La nueva separación convierte la captura en seis interruptores conceptuales. Identidad añade cuenta autenticada, usuario del sistema operativo y nombre de host. Prompts puede incluir instrucciones del usuario, sistema y desarrollador, contexto del workspace, adjuntos, resúmenes de compactación y skills. Respuestas puede incluir la salida y razonamiento soportado. Argumentos y resultados de herramientas pueden revelar comandos, archivos, esquemas, errores e identificadores de MCP o plugins. Policy detail puede exponer rutas completas del sandbox. Que un campo sea útil para depurar no lo vuelve automáticamente necesario para operación continua.

El punto de diseño es separar atribución de inspección. Para saber quién inició una sesión o qué equipo concentra errores no hace falta guardar el prompt. Para conocer qué herramienta falla puede bastar su tipo, resultado y duración; el argumento crudo solo entra en una ventana de diagnóstico aprobada. Incluso la identidad debe cuestionarse: un identificador pseudónimo o una dimensión de equipo puede responder una pregunta de capacidad sin convertir el dashboard en control individual. Cada campo necesita propósito, propietario, consumidor, retención y prueba de borrado.

No empiece preguntando qué puede exportar la herramienta. Empiece por la decisión que una señal permitirá tomar. Las cinco decisiones siguientes forman un contrato mínimo; si una no tiene respuesta verificable, la captura debe permanecer apagada o limitarse a un piloto aislado.

Imagine una empresa SaaS que permite a un agente leer tickets, consultar repositorios, ejecutar pruebas y proponer pull requests. El equipo de plataforma quiere responder tres preguntas: qué porcentaje de sesiones llega a un cambio aceptado, qué herramientas concentran errores y qué usuario inició una ejecución que modificó un repositorio regulado. El camino fácil sería guardar cada prompt, comando y salida. Ese diseño duplicaría tickets, código, rutas locales y posibles secretos dentro del backend de observabilidad.

El piloto hipotético empieza con spans y métricas sin contenido. Conserva session ID, tipo de agente, modelo, repositorio normalizado, commit inicial, categoría de herramienta, resultado, duración, bloqueo de política y decisión de aceptación. La identidad nominal solo se habilita para el grupo regulado, con acceso del equipo de auditoría y retención corta; los demás equipos usan identificadores seudónimos. Los argumentos, outputs y detalles crudos de policy permanecen apagados. Un mapa separado vincula errores conocidos con códigos normalizados para investigar sin copiar stderr completo.

La prueba de incidente introduce tres fallos controlados: timeout del test runner, intento de leer una ruta bloqueada y rechazo humano del diff. El equipo debe localizar la fase, sesión y responsable permitido, pero no reconstruir el ticket ni ver contenido del archivo. Después verifica que la expiración elimina las identidades, que un analista sin rol no puede consultar el grupo regulado y que ningún evento contiene tokens simulados. Este ejemplo no describe un cliente ni un resultado de Wasyra; ilustra cómo convertir privacidad en una propiedad comprobable del pipeline.

Evalúe tres resultados por separado. Utilidad operacional: tiempo para localizar la etapa fallida, porcentaje de incidentes diagnosticables, latencia del pipeline y costo por sesión. Resultado del agente: cambios aceptados, rechazados o revertidos, errores por tipo de herramienta, duración end-to-end y supervivencia del cambio. Exposición: campos sensibles por evento, identidades accesibles por rol, sesiones fuera de retención, muestras con secretos sembrados y destinos no aprobados. Una telemetría más detallada solo gana si mejora una decisión concreta sin empeorar el tercer grupo.

Añada pruebas negativas al release. Ejecute prompts con un secreto canario, nombres de archivos sensibles, rutas de perfil y un argumento de herramienta que parezca un token. Inspeccione el payload en el cliente, en el collector y en el backend; probar solo el dashboard no detecta datos descartados después de la ingestión. Cambie además una preferencia local para intentar habilitar contenido y confirme que la política administrada efectiva la bloquea. Repita por CLI, aplicación y cada harness de VS Code usado, porque el soporte fino no es uniforme.

Registre la versión de la política junto con cada sesión. Si una configuración administrada reemplaza el objeto completo en vez de fusionarlo, una actualización parcial puede retirar una restricción sin que el dashboard lo muestre. La evidencia de rollout debe incluir el archivo esperado, la configuración efectiva observada, el cliente mínimo soportado, un evento de prueba y la consulta que demuestra retención. Sin esa cadena, la política está escrita pero no necesariamente aplicada.

Apagar contenido reduce exposición, pero no anonimiza la telemetría. Un login, usuario local y hostname identifican a una persona o dispositivo; una URL de repositorio, branch o commit puede revelar proyectos; un nombre de herramienta o código de error puede ser sensible en determinados contextos. Trate esos metadatos según su clasificación real y la normativa aplicable. Este artículo ofrece criterios de ingeniería, no asesoría legal ni una base automática para monitoreo laboral.

Tampoco confunda observabilidad con evaluación semántica. Conteos de tokens, duración y aceptación de un diff no prueban que la respuesta sea correcta, segura o útil. Mantenga datasets y revisiones de calidad separados, con ejemplos autorizados y minimizados. Si una investigación exige contenido, use una ventana temporal, una cohorte explícita y aprobación registrada; no transforme una excepción en el nuevo valor por defecto.

Finalmente, compruebe cobertura. La referencia de GitHub indica diferencias entre Copilot CLI, la app, Agent Host y el harness local de VS Code. Una política central no compensa un cliente antiguo o una superficie que solo soporta el interruptor legado. Inventarie versiones, bloquee configuraciones incompatibles cuando corresponda y trate cualquier sesión sin postura confirmada como una ruta distinta, no como telemetría equivalente.

La telemetría de agentes madura cuando estructura, identidad y contenido dejan de ser un paquete inseparable. Empiece con spans y métricas operativas, agregue atribución solo al perímetro que la necesita y habilite contenido únicamente para una investigación delimitada. Los cinco gates —propósito, mínimo, frontera, vigencia y resultado— convierten esa intención en evidencia que puede auditarse y revertirse.

Si necesitas diseñar un piloto con herramientas, permisos, trazas y evaluaciones, el servicio de agentes a medida de Wasyra puede ayudar a convertir estos gates en un contrato operativo. Es un servicio de implementación en wasyra.com, separado del producto Agents disponible en agents.wasyra.com. La meta no es observar más: es conservar la señal suficiente para actuar sin crear otra superficie de riesgo.