Tu equipo usa agentes de código y ocurre un cambio inesperado en un repositorio. Quieres saber qué cuenta y qué equipo ejecutaron la sesión, pero no quieres enviar prompts, fragmentos de código ni resultados de herramientas a otro sistema. GitHub anunció el 12 de octubre de 2026 un control que separa esas dos decisiones en la telemetría de Copilot. Es una mejora útil para auditoría, siempre que pruebes qué sale realmente de cada cliente antes de activar la captura para toda la empresa.

Qué permite la actualización

Según el anuncio oficial de GitHub, la opción telemetry.capture.identity agrega tres atributos a los datos OpenTelemetry: user.name es la cuenta autenticada de Copilot —actualmente el login de GitHub—, process.user.name es la cuenta local del sistema operativo y host.name es el nombre de la máquina. La captura de identidad está apagada por defecto y es independiente del identificador seudónimo que ya existía.

Esta función se dirige a administradores de Copilot Enterprise que gestionan ajustes de los clientes. GitHub indica controles de captura detallados en Copilot CLI, la app GitHub Copilot y sesiones de VS Code que usan Agent Host. No extrapoles automáticamente el mismo soporte a JetBrains o a otros entornos: la referencia de ajustes administrados pide comprobar la compatibilidad de cada propiedad y cliente.

Identidad y contenido son decisiones distintas

La identidad responde «¿quién y desde qué máquina?». El contenido responde «¿qué escribió, respondió o ejecutó?». GitHub separó cinco clases adicionales que un administrador puede controlar individualmente: prompts, responses, toolArguments, toolOutput y policyDetail. Las cinco están apagadas por defecto. captureContent sigue disponible como atajo heredado para esas clases, pero nunca habilita identidad.

La distinción evita dos errores. Activar identidad no significa que se hayan guardado conversaciones; activar alguna clase de contenido sí puede incluir código fuente, comandos, resultados de herramientas o rutas del equipo. A la inversa, dejar todo el contenido apagado tampoco equivale a anonimato si habilitas login, usuario local y nombre de máquina. Define una finalidad de auditoría concreta, quién tendrá acceso al colector y cuánto tiempo conservarás los registros.

Habilitar identidad no activa la captura de prompts, respuestas ni resultados de herramientas.

Un piloto que puedes revisar antes de extenderlo

Si administras una instalación compatible, empieza con un equipo de prueba y un colector OpenTelemetry aprobado por tu organización. La configuración de ejemplo de GitHub usa un objeto telemetry dentro de managed-settings.json. Este fragmento es una plantilla para adaptar; el endpoint es ficticio y no enviará nada útil hasta que lo sustituyas por un colector real:

{
  "telemetry": {
    "enabled": true,
    "endpoint": "https://otel-collector.example.com",
    "protocol": "http/protobuf",
    "capture": {
      "identity": true,
      "prompts": false,
      "responses": false,
      "toolArguments": false,
      "toolOutput": false,
      "policyDetail": false
    },
    "captureContent": false
  }
}

Antes de distribuir ese archivo, consulta la ruta y el método de despliegue de ajustes administrados para tu cliente. Los valores gestionados explícitos prevalecen sobre ajustes locales, SDK y variables de entorno. No añadas tokens del colector a una captura de pantalla ni a un artículo público; si necesitas autenticación, usa el mecanismo aprobado por tu organización.

1. Establece el resultado esperado. En una sesión de prueba deben aparecer los atributos de identidad permitidos y no debe aparecer el texto de un prompt de prueba, un argumento de herramienta ni la respuesta del agente.
2. Ejecuta una sesión inocua. Usa un repositorio de ensayo y una instrucción con una frase distintiva que no sea un secreto. Registra la hora y el cliente.
3. Inspecciona el destino. Busca en el colector el evento de esa sesión. Comprueba los tres campos de identidad y busca la frase distintiva en atributos y eventos exportados. Si aparece, revisa ajustes heredados y la configuración efectiva antes de ampliar el piloto.
4. Prueba el caso contrario. Deshabilita identity para el grupo de prueba y repite. Verifica que ya no se exporten los tres atributos nuevos. Documenta lo observado por versión y cliente.

Cuándo conviene activarlo

Para una empresa que investiga sesiones de agentes o necesita relacionar actividad con cuentas, la atribución puede ser útil sin convertir el colector en un archivo de conversaciones. Para un equipo pequeño sin colector, política de acceso ni necesidad de auditoría, encenderla solo «por si acaso» añade datos personales sin una decisión clara. Empieza por el evento que necesitas explicar y captura lo mínimo que permita responderlo.

Esta es una lectura práctica del cambio anunciado el 12 de octubre, no una prueba propia de todos los clientes. La comprobación decisiva está en la telemetría que recibe tu colector, no en que el archivo de configuración se haya guardado.