Google Trends se disparó esta semana con «rogue AI agents», «agent executing unowned code» y «agent contacting outside researchers», y nada de eso es paranoia. Es el volumen de búsqueda de equipos que dieron a un agente autónomo acceso real a herramientas, lo lanzaron y solo entonces descubrieron lo que significa «autónomo» cuando nadie está mirando.
El patrón se repite porque el fallo no está en el modelo, sino en el backend que lo rodea. Un agente recibe un cliente de base de datos, una shell o una API de correo «para ir más rápido», corre bajo la misma cuenta de servicio que todo lo demás, sin registro de qué llamada hizo qué y sin forma de detenerlo a mitad de una tarea. El agente no es malicioso. Hace exactamente lo que hace un LLM sin restricciones: perseguir un objetivo con cualquier herramienta a su alcance.
Lo que aprenderás:
- Por qué «el modelo no hará eso» no es un límite de seguridad
- Cómo acotar los permisos de las herramientas por ejecución del agente, no por API key
- Qué debe registrar una auditoría para servir en pleno incidente y no solo después
- Dónde poner checkpoints con humanos sin frenar cada ejecución
- Cómo conectar un kill switch real a un backend de agentes con FastAPI, Celery y Redis
Acota los permisos por ejecución, no por API key
La mayoría de los backends de agentes entregan al LLM una única credencial de servicio compartida con el resto de la app. Así, cada llamada a una herramienta, ya sea leer, escribir, borrar o enviar, hereda todo el radio de impacto del backend. Acótalo por ejecución: emite credenciales estrechas y de corta vida al empezar (un rol de base de datos de solo lectura, un prefijo de S3 limitado, una clave de pago con tope de gasto) y haz que expiren al terminar. Un agente comprometido o confundido no podrá causar más daño del que esa ejecución tenía permitido.
Haz que la auditoría escriba antes de actuar
Un registro que escribe después de la llamada a la herramienta no sirve justo cuando esa es la llamada que necesitabas detectar. Escribe una fila append-only en Postgres, con el ID de ejecución, el nombre de la herramienta, el hash de los argumentos y la marca de tiempo, antes de que la herramienta se ejecute, y actualízala después con el resultado. En Celery es un único hook task_prerun, no código propio en cada tarea. Cuesta unos milisegundos por llamada y hace que una ejecución cancelada deje rastro hasta su última acción, en lugar de cortarse a mitad de la historia.
Pon checkpoints en las acciones que importan
Human-in-the-loop en cada llamada mata el rendimiento y enseña a las personas a pulsar «aprobar» sin leer. Protege solo las llamadas que escriben, borran, envían o gastan por encima de un umbral. Haz que la tarea escriba una fila pending_approval y espere con un sondeo corto de Redis (o pub/sub) y un timeout estricto que falle cerrado: sin respuesta, la acción no ocurre, en lugar de continuar de todos modos.
Construye un kill switch que de verdad sostenga carga
Un kill switch que solo funciona entre tareas es una sugerencia, no un control. Pon una única clave de Redis, agent:{run_id}:killed, detrás de un GET al inicio de cada tarea y entre las llamadas a herramientas dentro de las tareas largas; una lectura de Redis es lo bastante barata como para hacerla en cada iteración, algo que una consulta a la base de datos no permite. Expón un único endpoint autenticado de FastAPI, POST /agents/{run_id}/kill, que active la clave y llame a celery.control.revoke(task_id, terminate=True) para que las tareas posteriores en cola ni siquiera arranquen. Pruébalo como probarías un rollback de pagos: de forma programada, no solo cuando algo ya ha salido mal.
Nada de esto es seguridad de IA teórica. Es la misma disciplina de producción que aplicarías a cualquier sistema capaz de tomar acciones irreversibles por sí solo. El agente no necesita ser más listo para ser seguro. Necesita un radio de impacto menor, un rastro que sobreviva y un interruptor que de verdad corte la corriente.
Relacionado: una forma de mantener las decisiones del agente pequeñas, tipadas y verificables es un modelo de decisión dedicado como Jev de TypeSafe, con tu propio código responsable de cada acción.
