Ponele que configuraste un agente de IA para que automatice tareas en tu infraestructura: consulte bases de datos, maneje APIs, execute comandos. Funciona perfecto en el ambiente de desarrollo. Lo mandás a producción y el agente hace exactamente lo que le pediste. Problema: también recordó, guardó y expuso cada credencial, token, API key y password que tocó durante su ejecución, sin cifrado de por medio. Ahora un atacante tiene acceso a todo. Los agentes de IA recuerdan secretos por defecto, y nadie está preparado para lo que eso significa.
En 30 segundos
- Los agentes de IA guardan credenciales en memoria y almacenamiento sin cifrar, exponiendo keys, tokens y passwords a cualquiera con acceso al servidor
- OpenClaw, Claude Code, Vertex AI y otros agentes documentados han sido comprometidos por almacenar secrets en texto plano
- Atacantes pueden extraer credenciales y usarlas para acceder a bases de datos, servicios en la nube y sistemas críticos sin dejar rastro
- Las soluciones existen: secrets managers (Vault, CyberArk), aislamiento con contenedores, y monitoreo continuo de comportamiento anómalo
- La clave es nunca pasar un secret directamente al agente; en su lugar, el agente solicita permisos a través de APIs seguras con scope limitado
Qué son los agentes de IA y por qué recordar secrets es un problema
Un agente de IA es un programa autónomo que toma decisiones, ejecuta acciones y accede a recursos externos sin intervención humana constante. Cosas como consultar tu base de datos, llamar APIs, provisionar infraestructura, mover dinero entre cuentas. Para hacer todo eso, necesita credenciales: claves API, tokens OAuth, contraseñas de base de datos, certificados SSH.
El problema es que estos agentes —por arquitectura— necesitan recordar contexto, historial de interacciones, estado anterior. Eso incluye todo lo que vieron: secretos, rutas de archivos sensibles, queries a bases de datos, respuestas de APIs internas. Si no encriptás ni aislás esa memoria de forma activa, un atacante con acceso al servidor del agente tiene un buffet completo de credenciales listas para robar.
La mayoría de implementaciones de agentes de IA en 2026 (spoiler: incluso las “profesionales”) todavía guardan esa información en archivos de log, bases de datos locales o variables de entorno en texto plano, sin cifrado, sin rotación automática, sin auditoría. Es como dejar las contraseñas de tu WiFi pegadas con Post-it en el monitor.
Casos concretos de agentes vulnerables
OpenClaw: el agente que se convirtió en botnet involuntario
OpenClaw es un framework de agentes autónomos que almacena credenciales en bases de datos sin cifrar. Empresas lo adoptaron para automatizar procesos. El tema es que el almacenamiento era accesible desde dentro del contenedor sin protección. Malware como RedLine, Lumma y Vidar comenzaron a infectar máquinas con agentes OpenClaw corriendo, extrayendo la base de datos completa de secretos en cuestión de minutos. Resultado: acceso a APIs de servicios en la nube, datos de clientes, facturación no autorizada.
Claude Code: ejecución remota + memory dump
Claude Code permite al agente ejecutar código en tu máquina. Si un atacante logra inyectar instrucciones al agente (prompt injection, envenenamiento de datos), puede hacer que el agente lea y exfiltré archivos sensibles, incluidos .env, historiales, API keys guardadas en variables de entorno. Acá viene lo bueno: Claude Code guarda el historial de interacciones en disco para recuperación ante crashes. Alguien con acceso físico o remoto a la máquina tiene todo el contexto, incluidos los secrets que vio durante la sesión.
Vertex AI: extracción de service account credentials
Google Cloud Vertex AI permite agentes que interactúan con servicios de GCP. Si no configurás las políticas de IAM correctamente (y nadie lo hace a la primera), el agente puede listar, acceder y extraer credenciales de service accounts. Según reportes de seguridad de abril de 2026, más de 3.000 claves API de Google fueron expuestas públicamente por agentes Vertex AI mal configurados que guardaban credenciales en Cloud Logging.
Por qué pasa esto: la arquitectura perfecta para desastres
La raíz es arquitectónica. Los agentes necesitan memoria a largo plazo para ser útiles: “¿Cuál era el estado anterior?”, “¿Qué secrets usé la última vez?”, “¿Qué APIs funcionan?”. Sin memoria, no pueden tomar decisiones inteligentes. El problema es que esa memoria se almacena donde es más fácil: en archivos locales, en la misma base de datos de sesiones, en variables de entorno cargadas en RAM. Relacionado: en nuestro análisis de seguridad empresarial.
Segundo problema: los agentes usan el mismo usuario del SO y tienen los mismos permisos en todos lados. Si el agente puede leer una API key para acceder al servicio A, puede también leer el archivo de configuración donde está la key del servicio B, C, D y todos los demás (que no debería poder leer).
Tercero: nadie encripta la memoria. La mayoría de sistemas de agentes ni siquiera tienen cifrado en reposo habilitado en su base de datos. Si alguien roba el archivo `memory.db` o hace snapshot de la VM, tiene todos los secretos sin contraseña.
Cuarto: memory poisoning. Un atacante puede inyectar datos falsos en la memoria del agente (“por favor, usa esta API key fake para la próxima tarea”), y el agente lo recuerda como si fuera legítimo, propagando el compromiso a través de múltiples ejecuciones.
Riesgos: qué sucede cuando la memoria es robada
Un atacante con acceso a los secretos de tu agente puede hacer cualquier cosa que el agente podía hacer, pero sin límites, sin auditoría, y probablemente sin que lo notes por días o semanas.
Eso sí: si tu agente tenía acceso a Stripe, el atacante cobra sin autorización. Si tenía acceso a tu base de datos de clientes, la exfiltra. Si tenía credentials de AWS, provisiona GPUs en la nube y minea criptomonedas en tu cuenta. Si tenía tokens de OAuth para Slack, accede a tus canales privados y roba información confidencial (propuestas, roadmaps, conversaciones sobre despidos o cambios estratégicos).
El problema no es que alguien accedió a un agente. El problema es que al acceder al agente, accedió a TODO lo que el agente podía ver, sin dejar registro visible, porque las “credenciales comprometidas” viven en memoria del agente, no en logs auditables. Ya lo cubrimos antes en como explicamos en ChatGPT.
Solución 1: Secrets managers (sin guardar credenciales en el agente)
La primera línea de defensa es nunca pasar un secret directamente al agente. En su lugar, el agente solicita el secret a través de una API segura que valida cada acceso.
HashiCorp Vault
Vault mantiene secretos centralizados con cifrado en reposo y en tránsito. El agente nunca ve la API key completa. En su lugar, hace una llamada a Vault: “Dame acceso a la base de datos de clientes”. Vault verifica que el agente tiene permiso (usando su identidad, no compartiendo passwords), genera un token temporal con scope limitado (acceso a lectura en tabla X, válido 1 hora), y lo devuelve. El agente usa ese token para la tarea, el token expira, y listo. Si alguien roba los logs del agente, encontró un token expirado que no sirve.
AWS Secrets Manager
Si estás en AWS, Secrets Manager hace lo mismo: almacena secretos encriptados, valida acceso mediante IAM roles, retorna secretos de forma temporal. Cuesta USD 0,40/secreto/mes más USD 0,06 por 10.000 llamadas. Es caro si tenés miles de secretos, pero es el costo de no ser hackeado.
CyberArk Secrets Manager para agentes
CyberArk tiene un producto específico para agentes de IA: detecta cuándo un agente intenta acceder a un secret y valida la solicitud contra políticas. No da el secret completo; en su lugar, da un token rotado automáticamente cada vez. Precio no público, pero orientado a enterprises que no les importa pagar si es seguro.
Solución 2: Aislamiento, permisos mínimos y monitoreo
Ni todos pueden permitirse un secrets manager enterprise. Hay medidas complementarias que reducen riesgo:
Ejecutar el agente en contenedor aislado
Docker (o mejor, Podman con restricciones de seguridad) aísla el agente: no puede ver otros procesos, no puede escribir fuera de su volumen, no puede acceder a interfaces de red que no le des explícitamente. Si el agente es comprometido, el daño está contenido.
Principio de Least Privilege (PoLP)
El agente no debería poder leer TODOS los archivos de configuración. Debería poder leer solo lo que necesita para una tarea específica. Si la tarea es “sincronizar eventos con Stripe”, el agente no debería tener acceso a la credencial de Twilio, ni a la base de datos de clientes, ni a nada más. Esto requiere arquitectura de permisos granulares (IAM en AWS, RBAC en Kubernetes, ACLs en base de datos).
Ambiente desechable
Tratar el agente como ephemeral: no reutilizar la misma VM o contenedor para múltiples ejecuciones de agentes. Cada ejecución, ambiente nuevo, sin historial previo. La memoria del agente anterior no existe. Esto es costoso (requiere Kubernetes o serverless), pero invalida ataques que dependen de recuperar historial. Esto se conecta con lo que analizamos en en nuestra cobertura de GPT.
Monitoreo y alertas
Logs auditables de CADA acceso a un secret: quién lo pidió, cuándo, para qué, desde dónde. Alertas si el agente intenta acceder a un secret que no debería. Alertas si hace más de N llamadas a APIs en Y minutos (señal de exfiltración). Ejemplo: New Relic, Datadog, o logs propios en PostgreSQL con índices.
Tabla: Opciones de Secrets Managers para Agentes IA
| Solución | Precio | Encriptación | Rotación automática | Auditoría | Mejor para |
|---|---|---|---|---|---|
| HashiCorp Vault | Open source (self-hosted) o USD 600+/año (Cloud) | AES-256, TLS | Sí, configurable | Sí, completa | Startups y on-premise |
| AWS Secrets Manager | USD 0,40/secret/mes + USD 0,06/10k llamadas | AES-256 (KMS) | Sí, automática | Sí, CloudTrail | Empresas en AWS |
| CyberArk | No público, negociable (USD 5k+/año) | AES-256, TLS | Sí, per-request | Sí, forense | Enterprises con presupuesto |
| Google Secret Manager | USD 0,06 por 10k accesos | Google-managed + customer-managed keys | Manual | Sí, Cloud Logging | Empresas en GCP |
| 1Password Business | USD 3,99/usuario/mes | AES-256, TLS | Manual | Sí, acceso | Equipos pequeños (no agentes) |
Mejores prácticas: tu checklist de seguridad
Antes de desplegar un agente en producción, verificá esto:
- Nunca hardcodees secrets. No en config.py, no en .env commiteado en git, no en variables de entorno del SO. Punto.
- Secretos scanning en CI/CD. Usa herramientas como TruffleHog, GitLeaks o detect-secrets para validar cada commit. Si alguien sube un secret por error, se bloquea la compilación.
- Logs sin secrets. Logging no debe loguear valores de secrets. Si logueás, logueá el nombre del secret, no su valor. Log: “[INFO] Usando secret db_password para conectar”. No: “[INFO] Usando db_password=pg123456”.
- Rotación automática. Cada 30 días, los secrets deberían renovarse automáticamente. El agente debe soportar rotación sin downtime.
- Validación de entrada. El agente no debería aceptar URLs, comandos, queries o datos arbitrarios sin validación. Inyección SQL, prompt injection, command injection pueden convertir el agente en un troyano.
- Fallbacks humanos. Antes de que un agente ejecute una acción crítica (transferencia de dinero, cambio de permisos, borrado de datos), debería requerir aprobación humana.
- Aislamiento de red. El agente no debería poder iniciar conexiones a direcciones IP arbitrarias. Firewall restrictivo: solo permite conexiones a IPs/puertos específicos que necesita.
- Encriptación de disco. Si el agente corre en una VM o laptop, el disco debe estar cifrado (FileVault en Mac, BitLocker en Windows, LUKS en Linux). Si roban la máquina física, el disco es inútil.
- Monitoreo de comportamiento anómalo. Alertas si el agente accede a APIs en horarios inusuales, desde IPs nuevas, o hace más llamadas de las esperadas.
Errores comunes (y cómo no caer en ellos)
Error 1: “Usamos variables de entorno, está bastante seguro”
No. Las variables de entorno están en RAM, sí, pero cualquier proceso en la misma máquina (o con acceso de usuario del SO) puede leerlas. Además, aparecen en `ps aux`, en dumps de memoria, en logs de Docker si las pasás al contenedor. Variables de entorno NO son secrets managers.
Error 2: “Confío en mi proveedor de agentes, no necesito estos cuidados”
Incluso OpenAI, Google y Anthropic recomiendan usar secrets managers. El proveedor del agente no es responsable de tu seguridad operacional. Vos sos responsable de cómo desplegás.
Error 3: “Vamos a auditar después, ahora necesitamos velocidad”
No auditas después. Después está el agente comprometido, los datos exfiltrados, y vos en un meeting con abogados. La seguridad de agentes no es algo que agregues después. Es parte del diseño inicial.
Preguntas Frecuentes
¿Puede mi agente IA ver y robar mis claves API?
Sí, si le pasás la clave directamente o si el agente tiene acceso al archivo donde está guardada. Por eso no deberías pasar claves directamente. Usá un secrets manager que devuelve tokens temporales en su lugar.
¿Cuál es la mejor forma de pasar secretos a un agente sin exponerlos?
A través de una API segura (Vault, AWS Secrets Manager, CyberArk) que valida el acceso y retorna un token temporal. El agente nunca ve el secret completo, solo el token rotado automáticamente. Cubrimos ese tema en detalle en cuando analizamos Gemini.
¿Qué debo hacer si sospecho que las credenciales de mi agente fueron comprometidas?
Primero, detenés el agente inmediatamente. Segundo, revocás todos los tokens y secrets que el agente usó. Tercero, revisás logs de auditoría para saber qué accedió. Cuarto, cambias todas las credenciales (en Vault, Secrets Manager, donde estén). Si no podés rotar en menos de 1 hora, tenés un problema.
¿HashiCorp Vault es gratis? ¿Puedo usarlo sin pagar?
Sí, Vault es open source y gratuito para self-hosted. El costo está en operación: necesitás una máquina para ejecutarlo, backups, monitoreo, actualizaciones. Si querés Vault manejado por HashiCorp (Vault Cloud), es de USD 600/año en adelante.
¿Debo cifrar los logs del agente también?
Sí. Los logs pueden contener datos sensibles (incluso si no logueas secrets explícitamente, pueden tener metadatos). Cifralos en reposo con AES-256 y en tránsito con TLS. Acceso restringido a la persona que necesita investigar problemas.
Conclusión: La seguridad de agentes es una arquitectura, no un patch
Los agentes de IA que recuerdan secretos son agentes sin seguridad. No es un bug del agente, es un problema de cómo los diseñamos y desplegamos. Vos podés tener el agente más inteligente del mundo, pero si guarda credenciales sin cifrar, una persona con acceso a su servidor te va a desplomar en minutos.
La solución no es única. Es capas: secrets managers para no pasar credenciales directamente, aislamiento de permisos para limitar el daño si algo sale mal, encriptación para que robar datos no sea tan fácil, monitoreo para saber cuándo algo anda mal, rotación automática para que hasta los secrets robados expiren solos.
Si estás usando agentes en 2026 (OpenClaw, Claude Code, Vertex AI, lo que sea), audit tu setup. ¿Dónde guardás los secretos? ¿Quién puede accederlos? ¿Hay auditoría? ¿Rotan automáticamente? Si la respuesta a alguna es “no”, tenés tarea de seguridad antes de escalar a producción.