Rodrigo Jorge · Preparado el 29 de octubre de 2026 a las 06:05 (hora de Brasilia, UTC-3). Hora de publicación por confirmar.
El agente consulta una herramienta con una credencial protegida. La llamada falla. Para investigar, la integración registra la solicitud completa, incluido el header de autenticación.
En este escenario hipotético, el almacenamiento de la credencial puede estar bien protegido y, aun así, el secreto terminar en otro lugar: el log de errores. Quien puede consultar ese log obtiene acceso a una copia que el diseño original quizá no contemplaba.
La misma pregunta aplica a prompts, argumentos de herramientas, documentos recuperados y respuestas. Activar la captura completa para facilitar el debug cambia los datos que recibe el sistema de observabilidad. Ese cambio requiere una decisión explícita.
OWASP recomienda que datos como access tokens, contraseñas y claves no se registren directamente en condiciones normales. La documentación de OpenTelemetry recomienda minimizar la recopilación y revisar qué emiten las bibliotecas de instrumentación. También aclara que la herramienta, por sí sola, no determina qué es sensible en cada contexto.
Para un agente que puede actuar, propongo empezar por un contrato de eventos. ¿Qué información permite reconstruir la acción sin volver a copiar su contenido sensible? Un ejemplo conceptual, con valores ilustrativos, sería:
operation_id:op-exemplotool:consultar-alertaauthorization:allowedresult:upstream_errorcontent_recorded:false
Este registro ayuda a correlacionar llamadas, pero no constituye una auditoría completa. Según la operación, todavía harán falta la hora, una referencia al objetivo con acceso controlado, la versión de la policy y la identidad responsable. Esos campos también necesitan clasificación y control de acceso. Un metadato no es sinónimo de dato público.
El error también forma parte de la prueba
Una verificación que solo observa la llamada exitosa puede pasar por alto la ruta que imprime el request completo cuando ocurre una excepción. Pediría repetir la prueba con un error de autenticación, un timeout y una respuesta malformada, usando marcadores sintéticos en lugar de secretos reales.
La revisión debe abarcar los destinos que usa la integración: logs de la aplicación, traces, colas de exportación y posibles paquetes de soporte. Buscar el marcador solo en la pantalla de debug no muestra qué se transmitió o conservó en los demás puntos.
OpenTelemetry documenta procesadores para eliminar o transformar atributos. Pueden ayudar, pero filtrar en el Collector no elimina una copia que la aplicación ya haya guardado antes. Por eso, reducir la captura en el origen y revisar todo el recorrido son decisiones distintas.
Algunas investigaciones requieren contenido detallado. En esos casos, separaría la captura excepcional del log operativo: una finalidad definida, un alcance limitado, acceso controlado y un plazo de retención elegido para esa necesidad. Este artículo no establece un plazo universal ni promete que enmascarar algunos patrones elimine todos los datos sensibles.
La prueba debe producir dos resultados: permitir explicar qué acción se intentó y qué respuesta recibió, y demostrar dónde apareció o no apareció el marcador sintético. Si quitar el secreto hace imposible investigar, hay que rediseñar la evidencia que se recopila. Copiarlo todo para descubrir después qué importa traslada el problema a quienes almacenan y consultan los logs.
Referencias
- OWASP: Logging Cheat Sheet, sección Data to exclude, consultada el 29 de octubre de 2026.
- OpenTelemetry: Handling sensitive data, consultado el 29 de octubre de 2026.