La mayoría de los agentes que están haciendo trabajo real todavía tiene una persona cerca. Bien.

“Autónomo” se convirtió en una palabra que puede significar casi cualquier cosa. Se usa para un agente que redacta un correo y también para otro que lo envía, cambia una regla de firewall o mueve dinero. No son variantes del mismo problema de seguridad.

Cuando miro un flujo con agentes, quiero saber cuánto puede avanzar antes de que algo externo al modelo lo detenga. A veces ese límite es una persona. A veces es una política. Si la respuesta honesta es “lo vamos a ver en los logs”, el agente ya tiene demasiado espacio.

La persona no desapareció

No hay una cifra única y confiable sobre autonomía en producción. Las encuestas usan definiciones distintas y consultan a grupos diferentes. No las mezclaría. El patrón, en cambio, vale la pena.

Una encuesta de Stack Overflow de mayo de 2026 encontró que el 63% rara vez o nunca deja que los agentes trabajen por completo en autopilot. El 60% bloquea cambios de sistema que no fueron aprobados. En otra encuesta de Zapier, human-in-the-loop fue el modelo de gestión más común.

El uso real del producto cuenta una historia más interesante. Anthropic analizó millones de interacciones en Claude Code y su API. Los usuarios experimentados habilitaban full auto-approve más seguido que los nuevos. También interrumpían al agente con mayor frecuencia.

Ese último dato importa. La experiencia no eliminó a la persona. La movió desde la aprobación de cada paso hacia el monitoreo del recorrido y la intervención cuando hacía falta. Menos clics, más criterio.

Los cuatro modos que uso

Uso cuatro etiquetas cuando reviso estos sistemas. No forman una escalera, y la autonomía completa no es el premio de arriba. Un producto sensato puede necesitar las cuatro. Leer un documento público y transferir fondos no deberían heredar la misma autoridad por ocurrir en una sola interfaz.

Human-in-the-loop. El agente prepara una acción y espera. La pantalla de aprobación tiene mucho peso: debe mostrar la herramienta real, la identidad, el destino, los argumentos y el efecto esperado. “Permitir” no alcanza.

He visto flujos en los que el pedido visible y la acción ejecutada estaban vinculados apenas de forma indirecta. Eso no es un control. La aprobación debe quedar atada a la acción exacta que corre.

Human-on-the-loop. El agente ya está avanzando. La persona observa y puede intervenir. Suena simple hasta que el agente ejecuta diez acciones en el tiempo que el operador necesita para entender las primeras tres.

Un botón de detención tiene que detener algo. El operador también necesita saber qué queda abierto: una transacción, un registro modificado a medias, una credencial que ya se copió a otro sistema. Sin eso, la “supervisión” es solamente un incidente transmitido en vivo.

Autonomía limitada. Es el modo en el que más confío hoy para trabajo relevante en producción. El agente avanza sin pedir permiso cada vez, pero el software hace cumplir los límites.

Esos límites deben mirar algo más que el nombre de la herramienta. Importan la identidad, el tenant, el recurso, los argumentos y los efectos. También la procedencia. Una skill, un server MCP o un cambio de configuración pueden alterar el recorrido sin tocar el modelo.

Autonomía completa. Ninguna persona participa en el camino normal. La frase todavía oculta bastante trabajo humano: alguien definió el objetivo, emitió las credenciales, eligió las herramientas y escribió la política.

Lo que desaparece es la oportunidad de frenar una mala decisión en vivo. La recuperación debe existir de antemano. Credenciales limitadas a la task, presupuestos, circuit breakers, idempotencia y rollback son el modelo de seguridad, no trabajo pendiente para otro sprint.

Qué nos muestra JADEPUFFER

JADEPUFFER es un caso útil porque muestra la velocidad de la ejecución automática. También es fácil exagerarlo. Sysdig reportó que el agente encadenó reconocimiento, recolección de credenciales, movimiento lateral y extorsión destructiva de una base de datos después de entrar en un despliegue vulnerable de Langflow.

No eligió a la víctima ni construyó toda la operación por sí solo. Sysdig aclaró después que una persona eligió el objetivo, preparó la infraestructura de command-and-control y staging, y entregó credenciales obtenidas antes.

No me resulta tranquilizador. Una cantidad relativamente pequeña de dirección humana inició una secuencia larga y adaptable. Los controles human-on-the-loop deben seguir ese ritmo. La autonomía limitada debe impedir ciertos pasos, aunque el razonamiento del modelo parezca convincente.

Una revisión práctica

No le asignes un único nivel de autonomía al producto. Asignalo a cada acción relevante. Después preguntá:

  • ¿Qué identidad presenta el agente ante cada herramienta y cómo se vincula con la persona y la task?
  • ¿Qué políticas se ejecutan antes de actuar y qué señales se revisan solamente después?
  • ¿Con qué velocidad puede una persona o un circuit breaker automático interrumpir la secuencia?
  • ¿Qué estado queda después de la interrupción y puede el sistema revertirlo o continuar de forma segura?
  • ¿Qué sucede cuando cambia un modelo, una skill, un server MCP o la definición de una herramienta sin una revisión de políticas?

Si esas preguntas no tienen respuestas concretas, reducí la autoridad. No es falta de ambición. Es la forma de ganar el derecho a automatizar más después.

La autonomía no es un feature flag. Es un límite de seguridad.

Fuentes

Fuentes y estado del incidente revisados el 21 de julio de 2026.