Agent Permissions and Approval Boundaries
Autoridad para actuar
Agent Permissions define qué recursos, capacidades y acciones está autorizado a utilizar el agente o la identidad bajo la que ejecuta. Approval Boundary es el punto donde una acción debe detenerse o escalar para obtener autorización explícita adicional antes de continuar. Este canonical mantiene ambos conceptos juntos porque explican límites complementarios de la ejecución, sin convertirlos en sinónimos.
La diferencia importa cuando una tarea pasa de observar a modificar. Un sistema puede disponer de herramientas para leer un repositorio, editar archivos y ejecutar comandos sin tener autoridad para publicar cambios. La capacidad técnica permite una operación; la autorización establece si corresponde realizarla bajo las condiciones actuales. Un objetivo amplio tampoco concede acceso a cualquier sistema que parezca útil para alcanzarlo.
En Commerce, investigar un bug de Payments UI puede incluir leer código, proponer un cambio y correr tests. Modificar datos de cobros o desplegar constituye otro alcance. El coding-agent sigue siendo un sistema orientado a la tarea aunque encuentre esa frontera. Reconocerla y presentar evidencia puede ser el resultado correcto de un paso; cruzarla silenciosamente no demuestra mayor autonomía útil.
Scope de permisos
El alcance puede expresarse por filesystem, directorio, herramienta, comando, destino de red, API, recurso cloud, operación de base de datos o identidad. También puede distinguir lectura, escritura y acciones destructivas. Son dimensiones posibles, no un esquema universal de permisos para agentes. Cada runtime y sistema externo combina mecanismos propios que deben interpretarse por sus efectos reales.
La autorización puede provenir de distintas capas: política de organización, configuración del runtime, sistema operativo, servicio remoto o una decisión temporal para la tarea. La autoridad efectiva depende de cómo se componen. Permitir una herramienta en el harness no obliga a una API a aceptar la solicitud; denegarla allí no elimina el riesgo si existe otro camino accesible con credenciales amplias.
Importa identificar quién actúa. Un agente puede operar bajo identidad del usuario, servicio o credencial efímera. «Lo hizo el agente» no sustituye saber qué principal autorizó el efecto. Esa distinción permite acotar permisos y revisar responsabilidades sin desarrollar aquí un capítulo de IAM. El modelo interpreta una solicitud; no crea una identidad ni obtiene autoridad porque afirme necesitarla.
Instrucciones, herramientas y autorización
Una instrucción como «no borres archivos» comunica intención. Un control efectivo impide o rechaza la operación cuando no está permitida. El modelo puede equivocarse al seguir la instrucción, y un texto externo puede intentar desviarlo. Por eso la guía de comportamiento no debe presentarse como frontera de seguridad. La autorización necesita aplicación fuera de la decisión generada por el modelo.
La documentación de permisos de Claude Code distingue reglas aplicadas por el producto de instrucciones que orientan al modelo. También describe modos con revisión automática. Esa implementación ilustra dos precauciones: no todo control de permisos es una pregunta humana, y no corresponde afirmar que todas sus decisiones son deterministas. Aquí se conserva la responsabilidad de autorizar sin universalizar reglas o precedencias de ese producto.
Una tool registrada o visible tampoco concede autorización sobre todas sus operaciones. Una función de consulta puede restringir tablas; una shell puede estar disponible para un conjunto de acciones; un conector puede verificar destinos y argumentos. Ocultar herramientas puede reducir la superficie expuesta al modelo, pero interfaz y política siguen siendo dimensiones diferentes. La descripción de una función no demuestra que el control exista en su ejecución.
Least privilege y límites de tarea
Least privilege busca otorgar autoridad suficiente para el trabajo permitido sin acceso innecesario. En agentes importa tanto el recurso como la acción: leer un checkout y desplegar una aplicación tienen efectos diferentes. El hogar general de este principio permanece en seguridad, y V0.5 prevé su perspectiva en AI Security; este documento explica su aplicación operativa sin materializar otro canonical de seguridad.
Un encargo puede tener límites más estrechos que las capacidades técnicas disponibles. «Corregí Payments UI» es scope lógico; una credencial con acceso a toda la suscripción es autoridad técnica más amplia. La diferencia no queda resuelta por repetir la instrucción. Es necesario saber qué controles limitan realmente las acciones y qué decisiones quedan en manos de una persona o política externa.
Permisos demasiado amplios aumentan consecuencias posibles; permisos insuficientes pueden bloquear trabajo válido o fomentar solicitudes repetidas de ampliación. No existe una cantidad óptima universal. La respuesta útil identifica la operación necesaria, sus destinos y el alcance que la habilitaría. No convierte cada fallo de herramienta en justificación para conceder acceso general ni cada consulta inocua en una aprobación adicional.
Qué es una approval boundary
Una approval boundary aparece antes de un efecto que necesita autorización adicional. El sistema presenta o somete una acción a revisión, conserva la decisión pendiente y solo continúa bajo el alcance aprobado. La autorización puede referirse a una llamada, un destino, una sesión u otro ámbito definido. Esos alcances no son equivalentes y no deben inferirse de una respuesta ambigua.
En coding agents es frecuente que apruebe una persona. Hay también revisión por políticas o servicios: la guía de guardrails y human review de OpenAI distingue controles automáticos y aprobaciones, y advierte que una aplicación debe establecer sus propias fronteras. El Atlas utiliza Human Approval cuando existe autorización humana; no define toda aprobación posible como intervención manual.
Approval no equivale a permission. Puede existir capacidad autorizada para ejecutar comandos y requerirse una decisión adicional para uno concreto por sus efectos. A la inversa, una aprobación en el runtime no concede automáticamente una capacidad que el sistema operativo o una API niegan. Si aprobar también cambia privilegios o habilita otra ruta de ejecución, ese cambio necesita ser explícito: no es una propiedad universal de cualquier botón de aprobación.
Human approval y Human in the Loop
Human in the Loop comprende intervenciones humanas como aclarar objetivos, aportar contexto, revisar, corregir o aceptar resultados. Human Approval es un caso: autorizar continuar antes de una acción. Una revisión posterior puede detectar un error sin haber autorizado el efecto previo. Una aprobación previa puede permitir ejecutar sin demostrar que el resultado final cumpla los requisitos.
La relación importa para describir autonomía. Un agente puede elegir próximos pasos dentro del alcance y pausar al llegar a una frontera. Esa pausa no elimina toda delegación ni obliga al usuario a conducir la investigación completa. Del mismo modo, eliminar preguntas no demuestra que el sistema sea más competente: puede significar que una política preautoriza operaciones o que el control está mal configurado.
La documentación de Gemini CLI Policy Engine separa decisiones de permitir, denegar y pedir confirmación, con tratamiento específico del modo no interactivo. Es un ejemplo de cómo el contexto de ejecución cambia la resolución de un pedido, no un contrato que deba copiarse al Atlas. Un proceso en background debe conservar límites aunque no haya una persona observando cada paso.
Decisiones sensibles al riesgo
Lectura, mutación reversible y acción destructiva pueden justificar tratamientos distintos. Los destinos, datos, reversibilidad, costo y autoridad implicada ayudan a entender el efecto. Leer estado de Git, editar un archivo, crear un commit, hacer push, mergear y desplegar son operaciones diferentes. La posibilidad de escribir código no concede autoridad para liberar una versión ni enviar comunicaciones a terceros.
No se prescribe que toda acción de una categoría requiera la misma aprobación. Una escritura sobre datos sintéticos puede estar previamente autorizada; una lectura de secretos puede tener consecuencias relevantes. Una operación local puede emitir tráfico externo mediante un script. La revisión necesita el significado real del paso, no únicamente verbos tranquilizadores como «verificar» o «preparar».
Una solicitud útil de autorización permite conocer acción, destino, argumentos relevantes y efectos esperados. También debe permitir distinguir el paso puntual de una ampliación persistente de acceso. No se exige aquí una UI ni un formato. El criterio es que quien decide disponga de evidencia suficiente para comprender qué habilita, especialmente cuando el efecto sale del workspace o no se revierte fácilmente.
Aprobación, tiempo y fallos
Entre proponer una acción y ejecutarla pueden cambiar archivos, destino o estado externo. Aprobar una descripción no debería usarse para sustituir silenciosamente otra operación. El runtime necesita relacionar decisión y acción efectiva. Cuando el alcance ya no coincide, conservar la autorización anterior como permiso general oculta precisamente la frontera que debía protegerse.
Las decisiones pendientes también pueden expirar, ser rechazadas o quedar sin respuesta. El sistema debe comunicar qué pasó y qué trabajo permanece sin realizar. La falta de una respuesta no demuestra autorización. Reintentar el mismo efecto por otro camino puede cambiar el riesgo y eludir la decisión pendiente; resolver una indisponibilidad técnica no equivale a resolver una denegación.
Solicitar demasiadas aprobaciones tiene un costo de atención. La repetición puede favorecer aceptación mecánica, mientras pocas revisiones pueden dejar acciones importantes sin supervisión. Approval fatigue describe ese trade-off, no un argumento para desactivar controles. Reducir preguntas innecesarias requiere mejor alcance y contexto; acumular avisos idénticos no garantiza que la persona entienda las consecuencias.
Un alcance persistente merece distinguirse de una autorización puntual. Recordar una aprobación para futuras tareas puede ser útil, pero cambia quién podrá actuar después y bajo qué condiciones. La decisión no debería ampliarse solamente porque dos comandos comparten una palabra o una herramienta. El destino, los argumentos y el contexto pueden cambiar el efecto; un prefijo técnico no demuestra por sí solo equivalencia de autorización.
Permisos, sandbox y guardrails
| Mecanismo | Pregunta principal | Aplicación y límite |
|---|---|---|
| Instrucciones | ¿Qué comportamiento se solicita? | Orientan decisiones; no son enforcement por sí solas. |
| Permissions | ¿Qué acción está autorizada? | Runtime, identidad o servicio aplican política con garantías concretas. |
| Approval | ¿Se autoriza este paso bajo estas condiciones? | Persona o política adicional; no prueba corrección ni crea todo privilegio. |
| Sandbox | ¿Qué recursos y efectos quedan técnicamente restringidos? | Frontera de ejecución; no determina toda la autoridad remota. |
| Guardrail | ¿Debe continuar, transformarse o detenerse esta ejecución? | Check contextual, posiblemente probabilístico; no reemplaza autorización. |
agent-sandboxing describe restricciones del entorno. Pueden implementar parte de una política, pero no agotan autorización: un proceso aislado puede poseer una credencial demasiado poderosa. Aprobación y sandbox tampoco son equivalentes. Una acción autorizada sigue teniendo los límites técnicos vigentes; si la aprobación solicita salir de ellos, esa transición cambia la ejecución y debe explicarse.
AI Guardrails puede rechazar una acción normalmente autorizada por criterios adicionales. No constituye un permiso nuevo ni una garantía de seguridad perfecta. La defensa combina responsabilidades: autorización del tool/API, restricciones técnicas y evidencia del resultado pueden coexistir sin convertirse en una pila universal obligatoria para todo agente.
Ejemplo y relaciones en el Atlas
En Payments UI, el agente puede leer y editar el código acordado. Para reproducir un caso propone un comando que contacta una API de cobros. La pregunta deja de ser únicamente si existe shell: importan el destino, datos, identidad y efecto. Si el encargo solo cubría datos sintéticos, presentar esa diferencia es necesario aunque la conexión resulte técnicamente posible.
La persona puede autorizar una consulta limitada sin autorizar mutaciones ni despliegue. El agent-harness conserva y media esa decisión; el agent-execution-environment aporta recursos; el servicio aplica su autorización propia. El resultado vuelve como evidencia, no como licencia para ampliar la investigación. La verificación del arreglo y la aceptación del cambio siguen siendo decisiones distintas de habilitar la consulta.
Los fallos habituales incluyen alcance excesivo o insuficiente, políticas en conflicto, solicitudes ambiguas y aprobaciones mecánicas. Explicar límites permite detectar esos problemas sin convertir este canonical en manual de configuración. Agents conserva la definición del sistema, y ai-assisted-software-engineering conecta su uso en desarrollo. Las mismas fronteras aplican a un agente de soporte que puede leer tickets sin poder reembolsar pagos.
Fuentes
Fuentes primarias consultadas el 2026-10-25. Las definiciones, tabla, ejemplos y criterios de revisión son síntesis editorial del Atlas, no una política universal ni recomendación de configuración.
- Claude Code: Permissions, políticas efectivas, modos y revisión de acciones.
- OpenAI: Guardrails and human review, controles y autorización antes de efectos.
- Gemini CLI: Policy engine, decisiones sobre invocaciones y contexto interactivo.
- GitHub: Building guardrails for Copilot cloud agent, ejemplo de restricciones de plataforma y políticas del repositorio; no se adoptan sus defaults como reglas del Atlas.