Datos sensibles en informes de errores: evita las filtraciones de contexto de los agentes

Los informes de errores pueden convertirse silenciosamente en la vía más amplia de exportación de datos de una aplicación con agentes. Los equipos protegen las credenciales de producción y luego permiten que un SDK de excepciones recopile breadcrumbs, contexto HTTP, detalles del proceso y entradas de herramientas copiadas antes de enviar el paquete a la cuenta de un proveedor. El error ocurrió localmente. Las pruebas no se quedaron allí.

La solución no es abandonar los informes de errores. Los necesitas cuando una integración con un agente falla de una forma que los registros normales no pueden explicar. Hay que decidir qué datos de depuración pueden salir del equipo, dejar de recopilar material sin filtrar de las solicitudes de forma predeterminada y demostrar que el recopilador respeta esos límites. He visto revisiones de incidentes descarrilarse porque el stack trace era inofensivo, pero un campo de contexto «útil» contenía la solicitud completa que había fallado.

Los informes de errores son paquetes de pruebas, no simples stack traces

Un informe de errores suele ser un paquete reunido desde varias capas. El sistema operativo puede crear un informe de diagnóstico nativo. La aplicación puede añadir metadatos de la excepción. Un SDK de errores puede incorporar datos del dispositivo, breadcrumbs, historial de la sesión, registros, campos de trazas y etiquetas definidas por el usuario. Es posible que un framework de agentes ya haya serializado el prompt, la entrada de una herramienta, la respuesta o el estado de un reintento en uno de esos campos.

Esta diferencia importa porque los desarrolladores suelen revisar el stack trace visible y dar por limpio el resultado. El material sensible normalmente está al lado.

Un informe puede exponer datos mediante:

• mensajes de excepción que interpolan una URL, un comando o el cuerpo de una respuesta
• breadcrumbs creados a partir de registros de solicitudes o eventos de llamadas a herramientas
• campos personalizados que reciben un objeto de solicitud completo
• argumentos de línea de comandos, rutas de archivos temporales y valores derivados del entorno
• archivos adjuntos, capturas de pantalla, reproducción de sesiones o comentarios de soporte

Una dirección de memoria en un informe nativo normalmente no revela por sí sola una clave de API. En cambio, una cadena copiada en un mensaje de pánico sí puede hacerlo. No mezcles ambos casos. Los diagnósticos nativos necesitan controles de acceso; la telemetría de la aplicación necesita una minimización de datos deliberada.

La documentación de Apple sobre los informes de diagnóstico los describe como registros que sirven para diagnosticar problemas de las aplicaciones, con información sobre procesos e hilos. Es útil y normalmente más limitado que un evento de monitorización de aplicaciones. Sin embargo, cuando un SDK enriquece ese informe con tu propio contexto de ejecución, cambia el límite de los datos. Trata el evento enriquecido como datos de la aplicación que se dirigen a otro sistema.

Los fallos de los agentes crean un contexto de diagnóstico especialmente rico

Un controlador de solicitudes normal podría fallar con una ruta y un código de estado. Una acción de agente puede incluir una instrucción del usuario, rutas de un repositorio, la salida de un comando, argumentos para una API remota, un destino SSH y los resultados anteriores de las herramientas que llevaron al fallo. Ese contexto ayuda a reproducir el error. También hace que una recopilación descuidada resulte mucho más costosa.

La ruta de riesgo es predecible. Un desarrollador envuelve cada llamada a una herramienta en un registrador práctico. El registrador emite el objeto completo de argumentos. El SDK de observabilidad convierte los registros en breadcrumbs. Un tiempo de espera de red activa una excepción. El informe ahora contiene la entrada de la herramienta, incluidos encabezados o un token pegado, y el proveedor la recibe.

El mismo fallo aparece cuando el código hace esto:

try {
  await runTool(toolName, input);
} catch (error) {
  throw new Error(`Tool failed: ${toolName} input=${JSON.stringify(input)} error=${error.message}`);
}

Ese mensaje parece útil durante una prueba local. En producción crea un campo de datos sin límites que cada recopilador de errores, destino de registros e integración de alertas puede copiar. Sustitúyelo por identificadores estables y un resumen basado en una lista permitida:

try {
  await runTool(toolName, input);
} catch (error) {
  throw new Error(`Tool failed: name=${toolName} request_id=${requestId} input_shape=${inputShape}`);
}

inputShape puede ser una lista de nombres de campos aprobados y sus tamaños, nunca sus valores. Si no puedes explicar por qué un campo pertenece a un evento de error, déjalo fuera. La reproducción debería comenzar con un ID de correlación que apunte a un registro local protegido, no con una solicitud completa pegada en un panel alojado.

Capturar solicitudes sin filtrar es un mal valor predeterminado

La captura de solicitudes completas sigue siendo popular porque agiliza la primera sesión de depuración. Es una mala opción predeterminada para los servicios que gestionan acciones de agentes. Los encabezados de autorización, las cookies, las URL firmadas, los parámetros de consulta, los cuerpos de las solicitudes y los encabezados personalizados contienen habitualmente información que no tiene cabida en un sistema de errores.

Un evento seguro contiene suficientes datos para agrupar, clasificar y dirigir el incidente:

{
  "request_id": "rq_8c2f1a",
  "channel": "http",
  "method": "POST",
  "route": "/v1/issues/{issue_id}/comments",
  "status_class": "5xx",
  "duration_ms": 8120,
  "attempt": 2,
  "error_kind": "upstream_timeout"
}

La ruta usa una plantilla, no la ruta literal. El evento indica que la solicitud se reintentó, no qué datos envió. El ID opaco permite que una persona autorizada consulte el registro local de origen si lo necesita.

No hagas un hash de los secretos y lo llames redacción. Un hash determinista todavía puede identificar un token bearer repetido y ser vulnerable cuando el original tiene un espacio de búsqueda reducido. Sustituye los valores sensibles por una marca constante u omítelos. Si necesitas saber si había una credencial, registra auth_present: true, no su tipo, longitud, prefijo ni huella.

Revisa también el tratamiento de las URL. Muchas bibliotecas registran automáticamente las URL completas. Una ruta como /callback?code=... o una URL de descarga firmada puede filtrarse a través de un campo que el desarrollador nunca añadió manualmente. Elimina las cadenas de consulta antes de que el evento entre en el SDK, en lugar de confiar en que un procesador posterior reconocerá todas las variantes.

La redacción debe ejecutarse antes de almacenar y exportar

Un filtro es una barrera de seguridad, no un permiso para recopilarlo todo. Los hooks de los SDK funcionan de forma distinta: algunos procesan el evento final, otros solo determinados campos y algunos no cubren los adjuntos de errores nativos ni los breadcrumbs creados por una integración independiente. Una regla que redacta Authorization puede pasar por alto authorization, x-api-token, un parámetro de URL o una cadena JSON incrustada en una excepción.

Construye el límite por capas. Primero, desactiva la captura automática que no necesites. Después, crea eventos a partir de campos permitidos. Luego ejecuta un filtro defensivo sobre todas las cadenas restantes. Por último, prueba los datos serializados que recibe el recopilador.

Este pseudocódigo muestra el orden que evita la mayoría de los problemas:

request arrives
  -> derive route template and request ID
  -> retain protected local diagnostic record if policy permits
  -> create minimal crash context from allowlisted fields
  -> scrub all residual strings
  -> send minimized event

No pases el objeto de solicitud original a un callback de «before send». Cuando una biblioteca ya ha inspeccionado ese objeto, los plugins pueden haberlo convertido en breadcrumbs o spans. Entrega al código de telemetría un objeto pequeño que no pueda contener campos sensibles desde el principio.

Sentry documenta la limpieza de datos y los procesadores de eventos, mientras que Firebase Crashlytics documenta las claves personalizadas y la recopilación de registros. Lee esos ajustes como controles de recopilación, no como una garantía de privacidad general. En ambos casos, el contexto personalizado y los registros son los lugares donde los equipos de aplicaciones suelen anular sus propias protecciones predeterminadas.

Los valores predeterminados del SDK cambian al cambiar las integraciones

Una actualización del SDK de errores puede añadir trazas, captura de la consola, breadcrumbs, reproducción de sesiones, instrumentación de rendimiento o una integración con un framework que tenga acceso a más información de las solicitudes. Una revisión de seguridad hecha cuando la aplicación solo tenía stack traces no cubre la nueva ruta de datos.

Mantén un inventario pequeño de recopilación para cada entorno de ejecución. Registra el recopilador de errores nativo, el SDK de excepciones, el puente de registros, el paquete de trazas, el widget de comentarios y el mecanismo de paquetes de soporte. Para cada uno, responde cuatro preguntas sencillas: qué activa la recopilación, qué campos recopila automáticamente, dónde almacena los datos antes de subirlos y quién puede leerlos después.

No olvides los canales secundarios. Los desarrolladores suelen desactivar los cuerpos de las solicitudes en el producto de errores, pero reenvían la misma excepción a un agregador de registros. Las reglas de alertas pueden copiar el texto de la excepción en notificaciones de chat. Un botón de soporte puede adjuntar un archivo local de registros. Necesitas un único mapa de datos para la ruta del incidente, no una historia optimista e independiente para cada proveedor.

En macOS, revisa tanto los informes de la aplicación como los diagnósticos del sistema operativo. Los informes de errores de Apple pueden permanecer locales o compartirse según las opciones de informes del sistema, mientras que los SDK de terceros siguen su propia configuración y ruta de red. Una aplicación de escritorio debe dejar clara esta diferencia a las personas que la operan. «Los informes de errores están desactivados» no significa nada si un cliente independiente de monitorización sigue subiendo eventos enriquecidos.

Mantén las credenciales fuera del proceso del agente

La redacción reduce la exposición después de que el código haya manejado un secreto. Una medida más sólida consiste en impedir que el proceso del agente tenga el secreto. Así, un error del agente, una copia del entorno o un volcado de depuración accidental tienen menos material sensible que capturar.

Esto no significa que un informe de errores pase a ser inofensivo. El agente todavía puede tener código fuente privado, prompts o argumentos de herramientas. Pero un token bearer no puede filtrarse desde un proceso que nunca lo recibió.

Sallyport aplica este límite a las API HTTP y las acciones SSH: la aplicación guarda las credenciales en su bóveda cifrada, ejecuta la acción y devuelve el resultado al agente sin entregarle el material de las credenciales. Esto elimina un modo habitual de fallo de la telemetría de errores, pero aún necesitas minimizar los datos de las solicitudes y el texto de los resultados que maneja el agente.

Evita también poner secretos en los argumentos de los comandos. Los argumentos de los procesos aparecen en las herramientas de diagnóstico con más frecuencia de la que los desarrolladores esperan, y el historial del shell o la inspección de procesos pueden exponerlos por separado de los informes de errores. Pasa el material secreto mediante un intermediario protegido o un mecanismo local gestionado con cuidado, no mediante un argumento visible como --token=....

La conservación local también necesita una regla

Guardar informes completos en el equipo puede ser adecuado para fallos difíciles, sobre todo durante un desarrollo controlado. No es automáticamente seguro. Un almacenamiento temporal local puede sobrevivir al incidente, copiarse en un archivo de soporte o quedar en un perfil de usuario compartido donde otro proceso pueda leerlo.

Separa dos registros. Envía un evento remoto reducido para agrupar y generar alertas. Guarda cualquier registro de reproducción más completo localmente, en una ubicación protegida, durante un periodo corto y con una vía de eliminación explícita. El evento remoto necesita el ID opaco del registro local, no su contenido.

Un registro local útil incluye el identificador exacto de la compilación, una huella de configuración saneada, los tiempos y una referencia al intento de acción. No debería ser un archivo de texto suelto que concatene variables de entorno, cuerpos de solicitudes y salidas del terminal. El almacenamiento estructurado permite aplicar las mismas reglas de lista permitida y eliminación que usas para las exportaciones.

En las pasarelas de acciones de agentes, los registros de auditoría merecen una atención especial. Ayudan a establecer qué intentó hacer el agente, pero no autorizan a duplicar credenciales sin filtrar ni prompts completos en cada subsistema de diagnóstico. El registro de auditoría de Sallyport separa los registros de acciones del propio agente, y su comando sp audit verify verifica sin conexión la cadena de hashes cifrada sin una clave de bóveda. La verificación indica si el historial ha cambiado; la minimización de datos sigue determinando qué contexto de diagnóstico debe ir a otro lugar.

Demuestra el comportamiento del recopilador con secretos de prueba

La revisión de la configuración detecta errores evidentes. Una prueba con datos colocados a propósito detecta los errores que importan. Ejecútala antes del lanzamiento, después de actualizar los SDK de telemetría y cada vez que un framework de agentes incorpore una herramienta o integración de registros nueva.

Usa cadenas de marcador únicas que no puedan confundirse con credenciales reales. Coloca marcadores distintos en los lugares que los equipos suelen olvidar: un encabezado de autorización, un parámetro de consulta, un campo del cuerpo JSON, una instrucción del agente, una variable de entorno, un argumento de comando y un resultado de herramienta. Activa una excepción controlada y luego busca en todos los destinos.

Comprueba la vista del evento del proveedor, la exportación del evento sin procesar si está disponible, el almacenamiento temporal local de errores, los registros de la aplicación, los eventos de trazas, las cargas de las alertas, los adjuntos de soporte y cualquier cola entre la aplicación y el recopilador. Busca los marcadores exactos y transformaciones habituales como la codificación de URL o el JSON escapado. Revisar solo el panel web es la forma de pasar por alto una filtración en un breadcrumb o en un registro adjunto.

Escribe el resultado esperado. Por ejemplo, un informe puede contener route=/v1/files/{file_id} y request_id=rq_test_01, pero no debe contener MARKER_HEADER_7, MARKER_PROMPT_7 ni la cadena de consulta literal. Trata una prueba fallida como un defecto de seguridad: desactiva la vía de captura responsable, añade una prueba de regresión y vuelve a probar el evento serializado.

Una revisión breve detecta la mayoría de las exportaciones accidentales

Revisa la telemetría de errores cada vez que alguien cambie el manejo de errores, la observabilidad, una herramienta del agente o los diagnósticos de soporte. La persona revisora debe preguntar si el código nuevo puede serializar un objeto con forma de solicitud, no solo si añadió un campo secreto nuevo.

Usa esta lista breve durante la revisión:

• Los mensajes de error contienen identificadores y categorías, no entradas ni salidas serializadas.
• La telemetría recibe contexto permitido, nunca un objeto de solicitud o de estado del agente sin filtrar.
• Las URL pierden las cadenas de consulta y los encabezados nunca entran en breadcrumbs ni campos personalizados.
• Los diagnósticos locales completos tienen almacenamiento protegido, reglas de eliminación y un motivo definido para existir.
• Una prueba con marcadores colocados a propósito cubre todos los destinos de exportación configurados.

La parte incómoda es que los buenos hábitos de depuración suelen causar la filtración. Los desarrolladores añaden contexto porque al último incidente le faltaba. Conserva el contexto que clasifica el fallo, guarda pruebas más completas bajo control local cuando esté justificado y deja de exportar material sin filtrar solo porque un SDK de errores ofrece un campo para ello.