Dar más autonomía a un agente implica mucho más que quitar cuadros de confirmación. El equipo necesita decidir qué pasa cuando la persona no percibe una desviación, cuando el modelo interpreta una instrucción de forma inesperada o cuando un archivo externo inyecta una acción que nadie pretendía autorizar.
Anthropic resume el problema como blast radius: el tamaño del daño que puede causar una falla. La probabilidad de un error importa, pero no es la única variable. Un agente más capaz puede equivocarse menos y, al mismo tiempo, encontrar caminos más eficientes para alcanzar un objetivo dentro de un entorno demasiado amplio.
Esa distinción cambia el orden de la decisión. Antes de preguntar si el agente puede trabajar sin supervisión en cada paso, el equipo necesita definir qué recursos puede alcanzar, qué credenciales entran en el entorno y por dónde pueden salir los datos.
Aprobar cada acción no escala como control
La supervisión humana parece una barrera sencilla: el agente pide permiso y una persona decide. En la práctica, el volumen de solicitudes convierte la barrera en rutina. Anthropic informa que los usuarios de Claude Code aprobaron alrededor del 93% de las solicitudes de permiso observadas. Cuando casi todo se aprueba, cada solicitud pierde parte de su valor como señal de riesgo.
Eso no vuelve inútil la revisión humana. Sigue siendo importante para decisiones de alcance, cambios de producto y acciones de alto impacto. El problema es usar el mismo mecanismo para cada comando, como si la atención humana fuera un recurso infinito y homogéneo.
Un control más duradero limita lo que el agente puede hacer incluso cuando falla la supervisión. Si un secreto nunca entra en el entorno, un camino que intente copiarlo no encuentra nada. Si la red solo permite destinos y operaciones específicos, una instrucción maliciosa no recibe automáticamente el mismo alcance que toda la aplicación.
El entorno es una frontera de seguridad
Contener no significa confiar en que el modelo siempre elegirá la acción correcta. Significa poner una frontera determinista alrededor de lo que puede hacer. Los sandboxes, las máquinas virtuales, los límites del sistema de archivos y los controles de salida cumplen ese papel.
La fuerza de la frontera depende del trabajo que el producto tiene que realizar. Un contenedor efímero para ejecutar código puede ofrecer poco acceso persistente y, por eso, un alcance de daño menor. Un agente de desarrollo necesita leer y modificar un workspace, ejecutar comandos y quizá acceder a servicios. Un sistema orientado a trabajo general puede necesitar archivos locales sin suponer que la persona usuaria sabe evaluar una línea de shell.
No existe una configuración universal de autonomía. El diseño tiene que combinar la capacidad del agente, la competencia de quien supervisa y la sensibilidad de los recursos disponibles.
Tres superficies necesitan defensa
La fuente de Anthropic separa tres componentes que suelen tratarse como un único problema:
- el entorno en el que se ejecuta el agente;
- el modelo que elige las acciones;
- el contenido externo que entra en el contexto.
Los prompts de sistema, los clasificadores y el entrenamiento influyen en el comportamiento probable del modelo. No convierten una capacidad probabilística en una garantía. Un agente puede seguir una instrucción inesperada, descubrir una ruta no prevista o interpretar una restricción de forma demasiado estrecha.
El contenido externo amplía el problema. Un servidor MCP, un plugin o un repositorio pueden aportar datos útiles y también instrucciones inyectadas. Auditar el conector no es lo mismo que auditar cada archivo que carga. Por eso, limitar los permisos de la herramienta e inspeccionar lo que devuelve debe formar parte de la frontera, no quedarse solo en la documentación de uso.
La lista de destinos no basta
Un detalle importante aparece cuando la red permite acceder a un dominio confiable. Autorizar api.ejemplo.com puede parecer distinto de autorizar la subida de archivos, pero toda función accesible en ese dominio pasa a formar parte de la superficie de ataque.
El caso que describe Anthropic muestra por qué destino y capacidad no son sinónimos. Una clave insertada en un archivo malicioso puede usar una API permitida para enviar datos a una cuenta controlada por el atacante. El dominio era legítimo; la operación y la identidad no lo eran.
El control necesita verificar algo más que el destino de la conexión. Debe considerar qué credencial se está usando, qué operación se está llamando, qué datos pueden cruzar la frontera y si la sesión tiene autorización para esa acción. Una allowlist amplia reduce la fricción, pero también puede conceder capacidades que el equipo no pretendía delegar.
La persistencia aumenta la responsabilidad
Un entorno efímero vuelve a empezar en cada sesión. Un workspace persistente, un archivo de instrucciones o la memoria de un agente llevan estado al siguiente trabajo. Si una instrucción maliciosa entra en ese estado, deja de ser un evento aislado y pasa a ser contexto recurrente.
Eso exige tratar los archivos de configuración, los directorios de estado y las memorias como superficies de entrada. Que un contenido esté en el propio repositorio no prueba que sea confiable. Los proyectos clonados, las dependencias actualizadas y los conectores remotos tienen que pasar por el mismo razonamiento sobre origen, permiso y persistencia.
La decisión para el equipo
Antes de aumentar la autonomía, el equipo puede responder cinco preguntas: cuál es el workspace autorizado, qué credenciales quedan fuera de él, qué acciones exigen una identidad propia, qué destinos son necesarios y cómo se cierra o revoca la sesión.
Las respuestas no necesitan producir un sistema perfecto. Necesitan establecer un límite que siga valiendo cuando un prompt sea ambiguo, una aprobación sea automática o el agente encuentre contenido hostil. La autonomía útil empieza cuando el peor resultado plausible ya tiene un tamaño deliberadamente limitado.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
