AUTONOMÍA, PERMISOS Y CONTROL
Autonomía en agentes de IA: permisos, límites y cuándo dejarles actuar
Un agente puede razonar con mucha libertad y seguir teniendo permisos muy limitados. La autonomía útil consiste en decidir qué puede hacer solo, sobre qué recursos y hasta qué frontera.
La pregunta central no es si el agente es «autónomo», sino qué acciones puede ejecutar sin intervención y qué controles aparecen cuando intenta salir de ese perímetro.
RESPUESTA RÁPIDA
La autonomía de un agente de IA es el margen que tiene para decidir y continuar una tarea sin instrucciones humanas paso a paso. No equivale a autoridad: un agente puede investigar o planificar por sí mismo y, aun así, no tener permiso para enviar, pagar, borrar o modificar ciertos recursos. En producción conviene diseñar autonomía acción por acción mediante mínimo privilegio, scopes, límites de volumen o gasto, containment, approvals, stop conditions y mecanismos de revocación.
La regla práctica de este artículo: la autonomía se diseña por acción, no por agente.
Qué significa autonomía en un agente de IA
Decir que un agente es «autónomo» puede significar cosas muy distintas.
Un sistema puede investigar durante veinte minutos sin intervención y, aun así, no tener permiso para enviar un correo. Otro puede ejecutar cientos de actualizaciones automáticas, pero siguiendo un workflow fijo con muy poco margen de decisión. Un tercero puede elegir libremente qué herramientas usar dentro de un sandbox y detenerse en cuanto intenta acceder a un recurso externo.
Por eso autonomía no debería entenderse como una etiqueta que se añade al modelo.
Anthropic analizó en 2026 millones de interacciones reales y encontró una idea especialmente útil: la autonomía observada en producción está co-construida por el modelo, el usuario y el producto. El modelo puede detenerse o preguntar; el usuario puede intervenir; y el producto puede limitar herramientas, permisos, red, filesystem o acciones sensibles.
Para este artículo utilizaremos una definición operativa:
La autonomía de un agente es el margen que tiene para decidir y continuar una tarea sin recibir instrucciones humanas paso a paso, dentro de los límites técnicos y operativos que el sistema le impone.
Eso significa que el mismo modelo puede tener una autonomía muy distinta según dónde se despliegue.
La pregunta útil no es «¿qué nivel de autonomía tiene este modelo?», sino:
¿Qué decisiones puede tomar, qué acciones puede ejecutar, sobre qué recursos y hasta qué límite antes de necesitar una persona o detenerse?
Autonomía no es autoridad
Una parte importante de la confusión desaparece cuando separamos cuatro conceptos.
Capability: qué podría hacer
Es la capacidad técnica del sistema. Un modelo puede ser capaz de redactar, programar, clasificar, interpretar documentos o decidir entre herramientas.
Access: a qué puede llegar
Describe los recursos que puede consultar: una cuenta, una base de datos, un filesystem, una API, un dominio de red o un repositorio.
Permission o authority: qué puede ejecutar
Es la autorización real para leer, crear, modificar, enviar, borrar, transferir o producir un side effect sobre esos recursos.
Autonomy: qué puede decidir sin preguntar
Describe cuánto puede avanzar por sí mismo, elegir rutas y encadenar acciones antes de necesitar dirección humana.
Estas dimensiones pueden moverse de forma independiente.
Un agente puede tener mucha autonomía de razonamiento y poca autoridad: investigar, comparar alternativas y preparar un plan completo, pero no poder publicar, enviar, pagar ni borrar.
También puede ocurrir lo contrario: un proceso puede tener autoridad para actualizar cientos de registros pero poca autonomía porque todas las decisiones están determinadas por reglas.
Microsoft formula un principio parecido desde el mínimo privilegio: no basta preguntar si el agente puede completar una tarea; hay que preguntar si debería estar autorizado a ejecutar cada acción, contra qué recurso y bajo qué identidad.
Razonar sobre una acción no da permiso para ejecutarla.
Decidir y ejecutar son permisos distintos
Un agente puede tener amplio margen para investigar, comparar y proponer mientras mantiene una autoridad muy limitada para producir side effects.
Equivalente textual del diagrama
Autonomía de decisión: investigar, comparar, planificar, seleccionar entre opciones permitidas.
Autoridad de ejecución: enviar, pagar, borrar, publicar o cambiar permisos solo cuando policy lo permite.
La unidad de control debería ser la acción, no la etiqueta del agente
Clasificar un agente entero como «autonomía baja», «media» o «alta» puede ser útil para una conversación inicial, pero se vuelve demasiado impreciso cuando hay que operar el sistema.
Ejemplo orientativo — no es un caso de cliente.
Imaginemos un agente que ayuda a gestionar pedidos. Puede utilizar las mismas credenciales de aplicación y trabajar dentro del mismo proceso, pero cada acción merece una política distinta.
Leer un pedido de la cuenta autenticada puede ser rutinario. Preparar un borrador no produce un efecto externo. Cambiar una dirección requiere comprobar que el pedido todavía es editable. Emitir un reembolso necesita límites de importe. Borrar una cuenta quizá ni siquiera debería existir en el catálogo de herramientas.
Por eso una arquitectura operativa puede clasificar acciones como:
ALLOW → ALLOW WITH LIMITS → APPROVE → BLOCK
La ventaja es que la política deja de depender de una etiqueta abstracta. Podemos comprobarla y evaluarla.
Esta forma de diseñar encaja directamente con el flujo de tool calling: el modelo solicita una herramienta y el sistema decide si esa operación concreta está permitida antes de ejecutarla.
Una política distinta para cada clase de acción
En vez de asignar una etiqueta global al agente, podemos gobernar cada acción con una política explícita.
Equivalente textual del diagrama
- ALLOW: Lecturas y borradores dentro del scope.
- ALLOW WITH LIMITS: Cambios reversibles con cantidad y frecuencia acotadas.
- APPROVE: Acciones sensibles o que cruzan una frontera definida.
- BLOCK: Capacidades no necesarias o impacto fuera del mandato.
Least privilege: dar solo lo necesario para hacer el trabajo
Un agente no debería recibir acceso amplio porque «puede que algún día lo necesite».
El principio de mínimo privilegio consiste en proporcionar únicamente las capacidades y recursos necesarios para la función prevista, con el alcance mínimo razonable.
Esto puede afectar a varias capas:
- qué herramientas están disponibles;
- qué operaciones permite cada herramienta;
- qué cuentas, tenants o proyectos puede consultar;
- qué datos puede leer;
- qué credenciales utiliza;
- durante cuánto tiempo conserva una autorización elevada.
OWASP agrupa bajo Excessive Agency tres problemas relacionados: funcionalidad excesiva, permisos excesivos y autonomía excesiva. El patrón es sencillo: si el agente puede hacer más de lo necesario, un fallo tiene más posibilidades de convertirse en un efecto serio.
Por eso no basta con preguntar:
¿Puede hacer esto?
También:
¿Necesita poder hacerlo para cumplir su función?
Un agente de atención puede necesitar consultar pedidos y actualizar notas. Eso no implica que necesite exportar toda la base de clientes o modificar configuraciones de seguridad.
Reducir capacidad innecesaria también simplifica evaluación, observabilidad y respuesta ante incidentes.
Autonomía acotada: libertad dentro de un perímetro
Hay dos extremos poco útiles.
El primero es pedir autorización humana para cualquier acción, incluso las rutinarias y reversibles. El segundo es permitir que el agente haga «lo que considere necesario» con acceso amplio.
Una alternativa más operable es diseñar un sobre de autonomía: un perímetro técnico dentro del cual el agente puede trabajar con suficiente libertad y fuera del cual debe detenerse, pedir aprobación o recibir un bloqueo.
Ese perímetro puede limitar:
- herramientas;
- cuentas y datos;
- filesystem;
- acceso de red;
- importe y volumen;
- duración;
- número de pasos o reintentos;
- entorno de ejecución.
OpenAI describe en su operación interna de Codex una combinación de sandbox, políticas de red, approvals y telemetría. Anthropic utiliza un enfoque comparable en Claude Code: dentro del sandbox se permiten más acciones; al cruzar determinadas fronteras aparecen controles adicionales.
La idea no depende de esos productos.
El agente puede tener libertad dentro de un espacio que la aplicación ha decidido que es suficientemente seguro para esa función.
Autonomía dentro de un perímetro
El agente puede trabajar con libertad dentro de un espacio de capacidades y recursos previamente acotado. Cruzar ese espacio activa una aprobación o un bloqueo.
Equivalente textual del diagrama
Dentro del perímetro: herramientas, datos, volumen, red, entorno, tiempo y reintentos autorizados.
Fuera del perímetro: aprobación humana o bloqueo.
Approval no sustituye containment
Una confirmación humana antes de una acción sensible puede ser un control excelente. El problema aparece cuando convertimos cada paso en una solicitud de permiso.
Anthropic ha publicado datos de Claude Code donde aproximadamente el 93 % de los permission prompts observados eran aprobados. Esa cifra pertenece a ese producto y a esa población; no describe todos los agentes. Pero ilustra el problema de approval fatigue: cuando casi todo exige confirmar, la confirmación puede convertirse en un reflejo.
La alternativa no es eliminar al humano. Es mover parte del control a fronteras técnicas.
Por ejemplo, si un agente puede escribir libremente dentro de un directorio de trabajo aislado pero no tocar rutas sensibles, no necesitamos una persona para aprobar cada archivo temporal.
Si solo puede conectarse a dominios de una allowlist, no hace falta preguntar por cada petición de red rutinaria dentro de esa lista.
Si puede emitir reembolsos por debajo de un límite validado y solo los superiores necesitan approval, la atención humana se concentra donde cambia el riesgo.
Esto complementa lo que explicamos en Human-in-the-loop: una aprobación añade control cuando existe antes del efecto, la persona entiende la decisión y tiene autoridad real para rechazarla.
Pedir permiso para todo no es lo mismo que controlar bien.
Impacto y reversibilidad: no todas las acciones merecen el mismo control
La confianza en el modelo no debería ser la única variable para decidir autonomía.
Dos acciones con la misma probabilidad estimada de error pueden necesitar controles muy distintos si sus consecuencias no son comparables.
Crear un borrador interno es generalmente más reversible que enviar una comunicación a miles de clientes. Añadir una etiqueta es más fácil de corregir que borrar un registro. Preparar una orden de pago no tiene el mismo efecto que enviarla al banco.
Por eso conviene valorar al menos dos dimensiones:
Impacto: qué consecuencias tendría una acción incorrecta.
Reversibilidad: cuánto cuesta deshacer, compensar o corregir el efecto.
Una acción de bajo impacto y fácil reversión puede admitir más autonomía. Una acción de alto impacto y difícil reversión puede requerir límites más estrictos, approval o directamente estar fuera del mandato del agente.
Microsoft utiliza este principio de proporcionalidad en sus guías de gobernanza: las acciones que afectan dinero, personas, datos sensibles o sistemas críticos merecen controles adicionales.
No es una matriz universal. Es una forma de evitar que «el modelo funciona muy bien» sustituya el análisis del coste de equivocarse.
Blast radius: cuánto puede afectar un error
Anthropic utiliza el concepto de blast radius para pensar en containment. Podemos traducirlo operativamente como radio máximo de impacto: cuánto podría afectar una ejecución incorrecta dadas las capacidades y accesos que el agente tiene disponibles.
Un agente autorizado a modificar un único registro tiene un radio distinto de otro capaz de actualizar toda una base.
Un agente que puede gastar 20 euros por operación no tiene el mismo potencial de daño que otro con una credencial sin límite.
Un sandbox que permite trabajar únicamente en un proyecto temporal limita consecuencias diferentes a un entorno con acceso al filesystem del usuario y red abierta.
La pregunta útil es:
Si esta ejecución se equivoca de la peor manera plausible, ¿hasta dónde puede llegar el efecto antes de que otra barrera lo detenga?
El radio de impacto puede reducirse acotando sistemas, cuentas, volumen, dinero, red, tools y duración.
Esto cambia el enfoque de seguridad. No tratamos de demostrar que el agente nunca fallará. Diseñamos el sistema asumiendo que algún fallo es posible y limitamos su alcance.
No solo reduzcas la probabilidad de error: limita cuánto puede afectar un error.
Límites cuantitativos: autonomía con presupuesto
Los permisos suelen imaginarse como una decisión binaria: permitido o bloqueado.
En producción resulta útil introducir presupuestos operativos.
Un agente puede estar autorizado a modificar direcciones, pero solo para un pedido cada vez. Puede emitir un reembolso, pero hasta un importe determinado. Puede investigar, pero durante un número máximo de pasos. Puede reintentar una API, pero no indefinidamente.
Los límites pueden cubrir:
- importe;
- número de registros;
- frecuencia;
- peticiones por minuto;
- coste de modelo;
- tokens;
- duración;
- pasos;
- reintentos;
- profundidad de delegación;
- horario o entorno.
Estos controles permiten que el agente trabaje sin intervención en tareas rutinarias y, al mismo tiempo, tenga una frontera objetiva antes de que una ejecución se vuelva demasiado grande.
La autonomía no se limita únicamente con permisos. También puede limitarse con presupuestos de acción.
Stop conditions, circuit breaker y revocación
Dar capacidad de actuar implica diseñar cómo se detiene.
Un agente puede tener condiciones normales de salida: tarea completada, falta de información, necesidad de aprobación o handoff. Además necesita condiciones duras de parada cuando el comportamiento deja de ser aceptable.
Ejemplos:
reintentos > 3 → STOP
gasto > presupuesto → STOP
scope violation → BLOCK
error repetido → ESCALATE
anomalía grave → CIRCUIT BREAKER
Microsoft incluye circuit breakers y parada de emergencia entre los controles útiles para workloads agénticos. La idea es impedir que un error se convierta en una secuencia larga de efectos antes de que alguien pueda reaccionar.
Además de detener una ejecución concreta, necesitamos poder revocar autoridad operativamente.
Eso puede significar pausar el agente, retirar un token, deshabilitar una herramienta, reducir un scope, invalidar una sesión o bloquear acceso de red.
Una arquitectura que sabe conceder permisos pero no sabe retirarlos es difícil de operar.
Cómo aumentar autonomía sin saltar de cero a cien
No necesitamos una escala universal de niveles de autonomía para desplegar un agente de forma gradual.
Podemos utilizar una estrategia de rollout.
1. Lectura
El agente consulta información dentro de un scope controlado pero no modifica sistemas.
2. Propuesta o borrador
Produce recomendaciones, emails, cambios o transacciones preparadas para que una persona las revise antes de ejecutarlas.
3. Acciones reversibles y de bajo impacto
Puede ejecutar operaciones acotadas cuya corrección sea sencilla si algo falla.
4. Ejecución dentro de límites
Actúa automáticamente mientras se mantenga dentro de límites de scope, importe, volumen, tiempo o herramientas.
5. Approval por excepción
La persona deja de revisar cada paso y se concentra en cruces de frontera, anomalías y acciones de mayor impacto.
Esto no significa que la quinta etapa sea «más madura» en todos los procesos. Hay operaciones que deberían permanecer siempre en modo propuesta o con aprobación.
La decisión de ampliar autonomía debería apoyarse en evidencia de evaluaciones, trazas y resultados reales, además de una razón concreta de negocio.
El objetivo no es alcanzar autonomía máxima. Es encontrar el mínimo nivel de intervención que sigue ofreciendo control suficiente para el impacto de la tarea.
La autonomía real debe medirse en producción
Podemos configurar permisos antes de lanzar, pero el comportamiento real aparece cuando el sistema encuentra usuarios, datos y excepciones que no estaban en el entorno de prueba.
Anthropic señala precisamente que las evaluaciones previas al despliegue no describen completamente cuánto tiempo trabaja un agente solo ni cómo cambia la supervisión cuando los usuarios adquieren experiencia.
Por eso conviene observar señales como:
- duración sin intervención;
- acciones y tools por ejecución;
- acciones bloqueadas;
- approvals solicitados y rechazados;
- interrupciones humanas;
- reintentos;
- escalaciones;
- límites alcanzados;
- outcomes incorrectos;
- comportamientos anómalos.
Estas métricas no producen por sí solas un «score de autonomía». Sirven para comprobar si el sistema utiliza el espacio que le dimos de la forma prevista.
Podemos descubrir, por ejemplo, que un agente rara vez utiliza una tool sensible y conviene retirarla, que dispara demasiadas aprobaciones triviales o que consume todo su presupuesto de reintentos en una integración inestable.
La autonomía configurada y la autonomía ejercida no son exactamente lo mismo.
Framework para diseñar el sobre de autonomía
Antes de ampliar permisos o retirar una aprobación, conviene responder estas preguntas para cada proceso importante.
¿Qué objetivo concreto tiene el agente?
Define el trabajo que debe completar antes de pensar en permisos. Una autoridad amplia sin un mandato claro amplía riesgo sin añadir utilidad.
¿Qué decisiones puede tomar por sí mismo?
Separa interpretación, planificación y selección de acciones de la autoridad real para ejecutarlas.
¿Qué herramientas necesita de verdad?
Reduce la superficie de capacidades. Si una tool no es necesaria para la función, no debería estar disponible por comodidad.
¿A qué recursos puede llegar?
Acota cuentas, tenants, carpetas, proyectos, dominios, bases de datos o entornos antes de abrir acceso general.
¿En nombre de quién actúa?
Distingue identidad propia, contexto delegado de usuario y operaciones de servicio; cada modelo de identidad cambia permisos y auditoría.
¿Qué operaciones permite cada herramienta?
Leer, crear, actualizar, enviar, borrar o transferir no tienen el mismo riesgo aunque pertenezcan al mismo sistema.
¿Qué acciones son reversibles?
Una acción fácil de deshacer admite un margen distinto de otra que publica, paga, borra o modifica seguridad.
¿Cuál es el impacto máximo tolerable?
Define cuántos usuarios, registros, euros o sistemas podría afectar una ejecución equivocada antes de detenerse.
¿Qué límites de volumen o importe necesita?
Convierte el permiso binario en presupuestos: cantidad, frecuencia, importe, alcance o número máximo de objetos.
¿Qué presupuesto operativo tiene?
Limita tiempo, pasos, reintentos, coste, tokens o profundidad de delegación para evitar ejecuciones que se prolonguen sin control.
¿Qué acciones requieren aprobación?
Reserva el approval para cruces de frontera relevantes: alto impacto, difícil reversión, dinero, comunicación externa o datos sensibles.
¿Qué está absolutamente prohibido?
Algunas capacidades no deberían estar disponibles ni siquiera detrás de una confirmación si el agente no las necesita para su función.
¿Qué ocurre si una herramienta falla?
Define cuándo reintentar, cuándo comprobar el estado, cuándo usar una alternativa y cuándo detener o escalar.
¿Cuándo debe parar automáticamente?
Configura condiciones duras: máximo de errores, gasto, tiempo, acciones, anomalías o intentos de salir del scope.
¿Cómo se revoca su autoridad?
Debe existir una vía operativa para pausar el agente, retirar credenciales, deshabilitar tools o invalidar sesiones sin rediseñar el sistema.
¿Qué trazas demuestran que respetó los límites?
Registra tool calls, permisos, approvals, bloqueos, cambios de estado, outcomes y condiciones de parada.
¿Qué evidencia necesitamos antes de ampliar autonomía?
Exige resultados de evals y producción suficientes para justificar un perímetro mayor en lugar de ampliarlo por intuición.
El resultado no debería ser «nuestro agente tiene autonomía nivel 4».
Debería poder expresarse de una forma verificable:
Puede leer y analizar dentro de estas cuentas sin intervención; puede modificar estas operaciones hasta este límite; necesita aprobación para acciones externas; no puede borrar ni ampliar sus propios permisos; se detiene al superar este presupuesto y todas las acciones quedan registradas.
Eso es mucho más útil para diseñar, evaluar y operar el sistema.
Preguntas frecuentes
¿Qué es la autonomía de un agente de IA?
Es el margen que tiene para decidir y continuar una tarea sin recibir instrucciones humanas paso a paso. En la práctica depende del modelo, del producto, de las herramientas disponibles, de sus permisos y de la forma en que el usuario puede intervenir.
¿Autonomía y permisos son lo mismo?
No. Autonomía describe cuánto puede decidir sin pedir dirección; los permisos describen qué operaciones está autorizado a ejecutar. Un agente puede razonar con mucha libertad y tener permisos muy limitados.
¿Un agente autónomo actúa siempre sin humanos?
No. Puede trabajar de forma independiente dentro de un perímetro y requerir aprobación al cruzar determinadas fronteras, escalar excepciones o quedar sujeto a monitorización y parada.
¿Qué significa least privilege en un agente?
Dar al agente únicamente las herramientas, datos y operaciones necesarios para su función, con el alcance mínimo razonable y evitando permisos amplios por defecto.
¿Qué significa blast radius?
Es el impacto máximo plausible que podría producir un fallo dadas las capacidades y accesos disponibles: cuántos registros, usuarios, sistemas, dinero o datos podría afectar.
¿Pedir aprobación para todo es más seguro?
No necesariamente. Puede generar fricción y fatiga de aprobación. Cuando sea posible, resulta más robusto combinar límites técnicos fuertes con aprobación en acciones que realmente cruzan una frontera de riesgo.
¿Cómo se limita un agente sin hacerlo inútil?
Mediante un perímetro suficientemente amplio para el trabajo rutinario y límites claros sobre recursos, operaciones, volumen, gasto, duración, red, datos y acciones de alto impacto.
¿Cómo sé cuándo darle más autonomía?
Cuando evals y producción muestran comportamiento consistente dentro del perímetro actual, los fallos conocidos están controlados y existe una razón concreta de negocio para ampliar una capacidad o límite.
Fuentes y lecturas recomendadas
Estas fuentes sostienen la separación entre autonomía, autoridad, permisos y containment, además de los principios de mínimo privilegio, límites técnicos, supervisión proporcional al riesgo y medición del comportamiento real.
- 01Anthropic — Measuring AI agent autonomy in practice (enlace externo)anthropic.com
Estudio de 2026 sobre autonomía observada en uso real y sobre cómo modelo, usuario y producto co-construyen el grado de independencia.
- 02Anthropic — How we contain Claude across products (enlace externo)anthropic.com
Desarrolla containment, blast radius y la relación entre permisos, sandboxing y supervisión.
- 03Anthropic — Claude Code sandboxing (enlace externo)anthropic.com
Explica límites de filesystem y red que permiten más autonomía dentro de un perímetro técnico.
- 04Anthropic — Framework for safe and trustworthy agents (enlace externo)anthropic.com
Marco sobre control humano y autorización proporcional al impacto de las acciones.
- 05OpenAI — A practical guide to building agents (enlace externo)openai.com
Recomienda intervención humana ante acciones de alto riesgo y umbrales de fallo o reintento.
- 06OpenAI — Running Codex safely at OpenAI (enlace externo)openai.com
Ejemplo de sandbox, network policy, approval policy y telemetría para permitir acciones dentro de límites explícitos.
- 07Microsoft — Least privilege for AI agents (enlace externo)learn.microsoft.com
Aplica identidad, scope, autorización y privilegios temporales al diseño de agentes.
- 08Microsoft — Govern agents by risk (enlace externo)learn.microsoft.com
Propone ajustar controles al impacto y al nivel de ejecución del agente en lugar de usar un único checklist.
- 09Microsoft — Manage agentic risk (enlace externo)learn.microsoft.com
Incluye controles deterministas, aislamiento, logging y circuit breakers para sistemas agénticos.
- 10OWASP — Excessive Agency (enlace externo)genai.owasp.org
Describe riesgo por funcionalidad, permisos o autonomía excesivos y recomienda minimizar capacidades y privilegios.
Sobre el autor
Elvis Mendoza, fundador de Agentes Como Servicio. Trabaja en el diseño de producto, la arquitectura de soluciones, el diseño de agentes y flujos de trabajo y la construcción de software asistida por IA para conectar procesos, datos, herramientas y supervisión humana alrededor de necesidades empresariales concretas.
¿Qué debería poder hacer tu agente sin pedir permiso?
Antes de ampliar autonomía, conviene definir acción por acción qué puede decidir, qué puede ejecutar, qué límites no puede cruzar y cómo se detiene si algo sale mal.
En Agentes Como Servicio diseñamos ese perímetro como parte de la arquitectura: herramientas, permisos, presupuestos, supervisión, trazas y mecanismos de parada alrededor del proceso real de la empresa.
Solicitar acceso