Ayer empezó como cualquier otro día. Café, standup, revisión de código. Luego me enteré de un incidente que me hizo soltar todo.
El agente de AI de una organización había sido comprometido. No mediante algún zero-day exótico ni un vector de ataque sofisticado. No, esto fue mucho más elegante, y aterrador. Su agente de navegador impulsado por un LLM fusionó de forma autónoma un pull request malicioso en GitHub. Como un empleado real. Con permisos reales.
¿El vector de ataque? Un correo cuidadosamente elaborado en la bandeja del usuario, con instrucciones que el agente interpretó como comandos legítimos.
El modelo no hizo nada mal
Lo que no me deja dormir: el LLM funcionó perfectamente. Leyó el contenido, entendió la intención y actuó, exactamente como fue diseñado. El fallo catastrófico no estuvo en la AI. Estuvo en la arquitectura.
Alguien le dio a un agente de AI acceso irrestricto al navegador con todos los privilegios de un usuario autenticado. Es como entregarle las llaves del carro a alguien que sabe leer mapas pero jamás ha oído hablar de las reglas de tránsito.
El estado de la seguridad en agentes (spoiler: está mal)
He revisado decenas de arquitecturas de agentes en el último año. Los modelos de seguridad van desde “inexistente” hasta “dedos cruzados”. El enfoque típico:
- Dale acceso amplio al agente
- Espera que tome buenas decisiones
- ???
- Ganancias (o que te hackeen)
Esto está roto de raíz. Estamos construyendo agentes como si fuera 2010 y nadie hubiera oído hablar del principio de mínimo privilegio.
Qué sí funciona
Después de ayudar a diseñar más de 100 aplicaciones basadas en LLM en Redis y ahora construyendo Arcade.dev, esto es lo que aprendí sobre cómo hacer agentes que no destruyan tu infraestructura:
1. Principio de mínimo privilegio (pero de verdad aplícalo)
Tu agente nunca debe tener más acceso del estrictamente necesario para la tarea actual.
- ¿Leer correos? Acceso de solo lectura a la bandeja
- ¿Enviar un mensaje? Acceso para redactar, no para eliminar
- ¿Revisar PRs? Acceso de lectura, nunca para fusionar
En pocas palabras: darle tu token de usuario a un agente es una pésima idea. ¿No me crees? Espera a que los atacantes mejoren en prompt injection. Te vas a arrepentir.
2. Sandboxing de ejecución
Correr herramientas en entornos aislados no es paranoia, es lo mínimo indispensable. Ya sea con contenedores, procesos separados o restricciones a nivel de API, necesitas barreras entre lo que el agente intenta hacer y el daño que puede causar.
En Arcade.dev, cada herramienta corre en su propio entorno sandboxed. Un agente ni siquiera puede ver las herramientas a las que no debería tener acceso, mucho menos ejecutarlas.
3. Audita todo (y sí, todo en serio)
Cada llamada a una herramienta, cada decisión, cada dato al que se accede necesita registrarse. No solo por cumplimiento normativo, sino para hacer forenses cuando las cosas salgan mal. Y van a salir mal.
Esto no es observabilidad típica. Necesitas capturar:
- El razonamiento detrás de cada llamada a una herramienta
- Todos los parámetros enviados
- Los resultados completos devueltos
- Lo más importante: quién lo aprobó
4. Interruptores humanos
Las acciones críticas necesitan aprobación humana. Punto.
Tu agente puede redactar el correo, preparar el commit, planear la migración de base de datos o hacer triage de incidentes para flujos de trabajo de SRE. Pero un humano debe jalar el gatillo. Sí, reduce la autonomía. También evita que tu agente borre prod porque alguien le pidió “limpiar la base de datos de prueba” en un mensaje de Slack redactado de forma ambigua.
La verdad incómoda
El ataque al agente de navegador reveló lo que hemos estado evitando: le estamos dando capacidades a los agentes de AI sin las salvaguardas correspondientes. Es ingeniería irresponsable.
Las plataformas que lo están haciendo bien tratan la seguridad como arquitectura fundamental, no como una casilla de verificación. Ellas:
- Aplican permisos por usuario por defecto
- Validan cada acción contra una política
- Proveen trazas de auditoría sin que tengas que pensar en ello
- Hacen que el camino seguro sea el camino fácil
Construyendo confianza desde la arquitectura
La clave es esta: construir agentes confiables no se trata de limitar las capacidades de la AI. Se trata de canalizarlas de forma segura.
En Arcade.dev, construimos toda nuestra plataforma alrededor de este principio. Cada integración usa OAuth con permisos granulares. Cada llamada a una herramienta está acotada al usuario que la autorizó. Cada acción está registrada y es auditable. No porque no confiemos en la AI, sino porque entendemos que la seguridad es lo que hace posible la confianza.
El agente que fusionó el código malicioso no estaba mal entrenado. No usaba un modelo inferior. Simplemente le dieron demasiado poder con demasiado poco control.
No dejes que esto sea tu lección aprendida a las malas.
Sam Partee es CTO y cofundador de Arcade.dev, donde construye la infraestructura para agentes de AI seguros y listos para producción. Antes fue Ingeniero Principal de AI en Redis, donde ayudó a diseñar más de 100 aplicaciones basadas en LLM. Es colaborador importante de Langchain y LlamaIndex, y cree que el futuro de la AI está en lo que puede hacer, no solo en lo que puede decir.
¿Quieres construir agentes que actúen sin romper todo? Conoce Arcade.dev o encuéntrame en Twitter.
