Una API key estática conectada a un agente de IA autónomo es peligrosa porque no caduca, se propaga por cada log y transcript que el agente genera solo, y suele dar acceso a todo el sistema aunque la tarea real solo necesite leer un dato. Zero Trust aplicado a agentes significa emitir credenciales de corta duración, específicas para cada tarea y verificadas en cada llamada, en lugar de guardar una clave fija en un .env que vive meses sin que nadie la mire.
Qué cambia cuando quien usa la clave ya no es una persona, sino un bucle
Un desarrollador usa una API key un puñado de veces al día y, si algo huele raro, se detiene y pregunta. Un agente autónomo hace cientos o miles de llamadas sin que nadie revise ninguna antes de que salga hacia el proveedor externo, la base de datos o la API del cliente. La clave vive en una variable de entorno que el propio agente puede leer, imprimir o pasar a cualquier herramienta que decida invocar, incluida una shell que él mismo genera para depurar un error. El agente no protege secretos por instinto: los trata como cualquier otro string en su contexto salvo que alguien haya construido explícitamente una capa de redacción. Eso significa que una inyección de prompt, un error de parseo o simplemente una tarea de depuración mal diseñada puede filtrar la clave sin que exista intención maliciosa por ninguna parte. El riesgo no es que un atacante robe la clave con esfuerzo: es que el propio agente la exponga como efecto secundario de hacer su trabajo.
El mecanismo oculto: dónde se filtra de verdad una clave de un agente (no es el commit a GitHub)
El transcript del agente es el endpoint sin proteger que nadie audita
El canal de fuga que casi nadie revisa no es el repositorio de código, es la plataforma de observabilidad. Herramientas como LangSmith, Langfuse, Helicone o un simple sistema de logs propio guardan el historial completo de prompts, respuestas y llamadas a herramientas, y ese historial incluye a menudo las cabeceras HTTP completas de las peticiones que el agente hizo, con la clave de autenticación dentro. Esas plataformas suelen tener un control de acceso mucho más laxo que el gestor de secretos original, precisamente porque nadie las trata como almacén de credenciales, sino como herramienta de debugging. A eso se suma el flujo humano de soporte: cuando algo falla, alguien copia el traceback del agente y lo pega en un ticket o en un canal de Slack para pedir ayuda, y ese traceback puede contener la clave en texto plano dentro del mensaje de error de la excepción. La clave no se roba con un exploit sofisticado: se hereda por descuido operativo, exactamente igual que ocurría con los logs de aplicaciones web hace quince años, solo que ahora el volumen de texto generado es muchísimo mayor y nadie lo está mirando con ese criterio.
Por qué rotar la API key cada 90 días no arregla nada
La política de rotación trimestral o mensual está pensada para un ritmo humano: alguien cambia la clave, actualiza el gestor de secretos, avisa al equipo. Un agente opera a un ritmo completamente distinto, con cientos de llamadas en una sola jornada, así que si la clave se filtra en la llamada número cuarenta del día, sigue siendo válida hasta la próxima rotación programada, sin importar lo estricta que sea la política sobre el papel. La ventana de exposición que realmente importa no se mide en meses, se mide en la duración de una sesión o incluso de una sola tarea. Este es el punto contraintuitivo que suele faltar en las guías genéricas de seguridad: mejorar la higiene de rotación no reduce el riesgo real de un agente, porque el problema no es la frecuencia de cambio, es que la credencial sigue siendo válida mucho después de que termine la tarea para la que se usó. La solución no es rotar más rápido, es que la credencial caduque sola en minutos porque nunca se emitió para durar más que eso.
Qué dice Zero Trust de verdad aplicado a agentes (NIST SP 800-207)
El marco de referencia de Zero Trust Architecture del NIST (SP 800-207, 2020) parte de un principio simple: no confiar nunca por defecto, verificar cada petición de forma independiente, sin importar si viene de dentro o fuera de la red. Aplicado a un agente, eso significa que la unidad de confianza no debería ser la sesión completa del agente, sino cada llamada individual a cada herramienta: cada tool call debería llevar su propia credencial de alcance mínimo, verificada contra un motor de políticas, en vez de heredar automáticamente la confianza que se le dio al arrancar el proceso. El proyecto OWASP para aplicaciones LLM incluye explícitamente la «agencia excesiva» (excessive agency) y la gestión insegura de credenciales entre los riesgos a mitigar en sistemas con agentes, precisamente porque un agente con permisos amplios y una clave que no expira combina los dos problemas a la vez.
Identidad de carga de trabajo en vez de secretos estáticos
La alternativa técnica real se llama workload identity: el agente se autentica como sí mismo mediante un token firmado y de corta duración, emitido para esa tarea concreta, en lugar de portar una clave fija equivalente a una contraseña. En la práctica esto ya existe en la mayoría de nubes: AWS STS AssumeRole, Workload Identity Federation de Google Cloud o Managed Identity de Azure permiten que un proceso obtenga credenciales temporales sin que ningún humano ni ningún agente tenga que manejar nunca el secreto de larga duración. El límite honesto es que muchas APIs de terceros que un agente necesita usar (CRMs, ERPs, pasarelas de pago) todavía solo ofrecen API keys clásicas, así que el patrón de identidad federada no siempre está disponible fuera del propio stack cloud.
La verdad incómoda: no toda pyme necesita SPIFFE y mTLS mañana mismo
Aquí conviene ser honesto: montar un stack completo de Zero Trust con service mesh, mTLS en cada conexión interna y federación de identidad de carga de trabajo es desproporcionado para una pyme que tiene un agente leyendo un Excel o contestando tickets de soporte de nivel uno. Si el agente solo lee datos y el radio de impacto de una fuga es bajo, una clave de alcance mínimo, de solo lectura, con una lista explícita de endpoints permitidos y alertas de volumen anómalo suele ser una respuesta proporcionada y realista para un equipo de veinte o cincuenta personas. El Zero Trust completo empieza a justificarse cuando el agente tiene permisos de escritura o borrado, toca datos financieros o de clientes, o está conectado a más de un sistema crítico a la vez. Recomendar la arquitectura más completa a todo el mundo, sin mirar el radio de impacto real, es la misma trampa que vender un SOC 24/7 a una empresa de ocho personas.
La pregunta que de verdad importa no es «qué API key le doy al agente», es «qué puede hacer alguien con esa clave si la encuentra dentro de un log dentro de tres meses». Si la respuesta te incomoda, esa es la señal de que hay que cambiar el modelo de credenciales, no solo la política de contraseñas.
Qué hacer esta semana antes de dar credenciales a un agente de IA
- Inventariar qué credenciales tiene cada agente activo y qué puede hacer con ellas realmente, no solo qué debería hacer según el diseño
- Sustituir claves estáticas por tokens de corta duración donde el proveedor lo permita (OAuth con refresh, STS, managed identity)
- Aplicar permisos de mínimo alcance por tarea, no un único rol amplio por servicio completo
- Sacar los logs y transcripts del agente del mismo nivel de exposición que la clave original: no deben ser más accesibles que el secreto que documentan
- Configurar alertas de volumen o patrón anómalo de llamadas, no solo de fallos de autenticación
- Revisar quién dentro de la empresa puede leer el historial completo de conversaciones y llamadas del agente
¿Tienes agentes de IA con acceso a sistemas de empresa y no sabes qué credenciales están manejando ni dónde quedan sus logs? Pide una auditoría de credenciales y permisos de tus agentes con Blurtek.
Solicitar diagnóstico