GitHub Copilot: cómo auditar agentes y MCP sin capturar código ni conversaciones

Agentes conectados a un panel de observabilidad con protección del código y la identidad.

Observar un agente de programación ayuda a reconstruir sus acciones, medir consumo y analizar errores. El desafío consiste en obtener esa evidencia sin convertir el sistema de observabilidad en una segunda copia del código y las conversaciones del equipo.

GitHub anunció el 12 de octubre de 2026 nuevos controles que separan la atribución de identidad de la captura de contenido. La configuración administrada permite habilitar cada clase según el objetivo de la investigación.

Qué cambia

telemetry.capture.identity añade la cuenta de Copilot, el usuario del sistema operativo y el nombre del equipo. Su activación es independiente de prompts, respuestas y datos de herramientas. Todas las clases de captura están desactivadas de forma predeterminada.

Los controles granulares están disponibles en Copilot CLI, la aplicación GitHub Copilot y sesiones de VS Code con Agent Host. La compatibilidad debe comprobarse para el cliente y el modo de ejecución utilizados.

Una configuración inicial de mínima captura

El siguiente ejemplo es una línea base ilustrativa para un entorno de prueba. El endpoint debe sustituirse por un collector autorizado; su autenticación se configura según la infraestructura de observabilidad.

{
  "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,
    "lockCaptureContent": true
  }
}

La configuración explícita administrada prevalece sobre opciones locales. El campo heredado captureContent agrupa las clases de contenido, pero no habilita identidad. En VS Code con el harness local no se aplica la misma granularidad que en Agent Host.

Prueba antes del despliegue

  1. Preparar un backend OTLP seguro y un repositorio con datos sintéticos.
  2. Distribuir la política mediante el mecanismo de administración elegido y comprobar su recepción.
  3. Ejecutar una lectura de archivo, una llamada de herramienta y una operación MCP autorizada.
  4. Revisar trazas, duración y tokens; confirmar los atributos de identidad esperados.
  5. Buscar deliberadamente el texto sintético de prompts y archivos en el collector: no debe aparecer con esta política.
  6. Intentar habilitar captura local y verificar que la política efectiva conserve los límites.

Aplicación a equipos de tecnología empresarial

Para desarrollo de extensiones, integraciones o herramientas auxiliares de D365FO, este patrón permite relacionar sesiones con diagnósticos y pruebas. No demuestra por sí mismo la calidad del código X++ ni sustituye compilación, regresión o aprobación humana.

Conviene medir utilidad de las trazas, costo de almacenamiento y tiempo de investigación antes de ampliar el piloto. Un collector compartido puede reutilizarse entre proyectos, siempre con acceso segregado y retención definida.

Privacidad y mantenimiento

La identidad sigue siendo un dato personal. Las clases opcionales pueden contener código, secretos, resultados MCP y rutas del equipo. Cualquier excepción de captura debe tener alcance, responsable y vencimiento. También deben probarse los cambios de cliente y de esquema para evitar una pérdida silenciosa de observabilidad.

Recomendación editorial: comenzar con metadatos e identidad, validar lo que realmente se exporta y ampliar la captura únicamente cuando exista una necesidad concreta.

Fuentes oficiales

Deja un comentario

Scroll al inicio