Permisos para agentes de IA: cómo limitar herramientas, datos y acciones al mínimo necesario

La autoridad del agente no es la autoridad del sistema

Un agente puede interpretar una petición, elegir herramientas y encadenar operaciones. Eso no significa que deba decidir qué recursos está autorizado a consultar o modificar. La autorización efectiva corresponde a los sistemas que contienen los datos o ejecutan las acciones: el repositorio, el servicio de correo, la API o la plataforma empresarial. El modelo puede proponer una operación; el sistema de destino debe comprobar si la identidad que la solicita puede realizarla sobre ese recurso concreto.

Esta distinción importa porque el agente puede equivocarse, recibir instrucciones engañosas o escoger una herramienta inadecuada. Las instrucciones del prompt y las reglas que filtran qué herramientas aparecen disponibles ayudan a orientar el comportamiento, pero no deben ser el único control. Si una ruta alternativa permite ejecutar la misma operación con una credencial amplia, el filtro de herramientas no impide el acceso. Conviene combinar límites en la interfaz del agente con controles de identidad y autorización aplicados por las herramientas y servicios conectados.

La meta práctica no es que el agente sea incapaz de cualquier error. Es reducir qué puede ocurrir si interpreta mal la tarea: limitar los recursos accesibles, distinguir lectura de modificación, minimizar la duración del acceso y evitar que una sola credencial convierta una equivocación en una acción de gran alcance. Las recomendaciones de esta guía son criterios de diseño; su aplicación concreta depende de las capacidades y del modelo de permisos de cada plataforma.

Inventariar tareas, recursos y efectos antes de conceder acceso

Empieza por describir las tareas que el agente debe completar, no por enumerar todos los conectores que sería posible activar. Para cada tarea, identifica quién la solicita, qué datos necesita, qué herramienta los proporciona y qué resultado se espera. Después registra el efecto potencial de cada operación. Consultar un documento, editarlo, enviar un mensaje y borrar un registro son capacidades diferentes, aunque estén disponibles a través del mismo servicio.

Separa los datos propios del usuario de los compartidos por un equipo o una organización. La separación también debe considerar el recurso concreto: un agente que necesita leer una carpeta de proyecto no necesita por ese motivo acceso de lectura a todo el repositorio. Identifica, además, si la tarea actúa en nombre de una persona o como una aplicación autónoma. En plataformas que distinguen permisos delegados y de aplicación, esa diferencia afecta a qué identidad se representa y a qué límites se aplican.

No clasifiques una operación solo por el nombre de la herramienta. Una llamada de “actualización” puede cambiar un campo inocuo o alterar un estado que activa procesos posteriores. Describe el efecto observable y quién podría verse afectado. Si el impacto no está claro, no supongas que la operación es de bajo riesgo: delimita su alcance y prueba el comportamiento en un entorno controlado antes de habilitarla en producción.

Diseñar perfiles de mínimo privilegio por tarea y usuario

Con el inventario en mano, define un perfil para cada tarea. Especifica qué identidad lo ejecuta, qué herramientas puede invocar, sobre qué recursos, con qué acciones y durante cuánto tiempo. Un perfil como “acceso al correo” resulta demasiado impreciso. Un perfil útil expresa, por ejemplo, que una tarea puede consultar mensajes de una persona para preparar un resumen, pero no enviar, borrar ni modificar mensajes.

Cuando el usuario debe conservar sus límites, una autorización delegada puede ser más adecuada que una credencial de aplicación con acceso independiente y amplio. La documentación de Microsoft Graph distingue permisos delegados, limitados por lo que puede hacer el usuario, de permisos de aplicación, que se conceden a la aplicación. Esta distinción no elimina la necesidad de configurar permisos de mínimo privilegio ni garantiza por sí sola que cada operación esté bien delimitada: hay que verificar qué permisos pide la integración y qué hace el sistema con ellos.

En algunos entornos, el intercambio de tokens permite obtener credenciales orientadas a un recurso de destino o representar una delegación. El estándar de intercambio de tokens de OAuth describe este mecanismo, pero la disponibilidad y las restricciones concretas dependen de la implementación. No presentes un token temporal como automáticamente seguro: comprueba audiencia, sujeto, acciones autorizadas, duración y condiciones de renovación. Si el entorno no admite credenciales acotadas, documenta el límite y compénsalo con controles de destino, separación de funciones y supervisión.

Autorizar cada operación en el sistema de destino

Una política de herramientas disponibles puede reducir errores de selección: por ejemplo, hacer que el agente solo vea un conjunto aprobado de herramientas. Sin embargo, no demuestra que la llamada concreta esté autorizada. La documentación de Amazon Bedrock AgentCore describe listas permitidas de herramientas y advierte que ese filtro no sustituye a los permisos IAM para otras vías de ejecución. En términos de diseño, el filtro del agente y la política del recurso son capas distintas y deben revisarse por separado.

El sistema de destino debe comprobar, como mínimo, la identidad efectiva, la acción solicitada y el recurso afectado. Si la autorización depende del usuario, no basta con verificarla una vez al crear la sesión y después confiar sin más en el contexto. Define cómo se valida la identidad en cada operación y qué ocurre si cambian los permisos mientras la tarea sigue activa. La forma de implementar esta comprobación depende de la plataforma, por lo que no debe asumirse que todos los conectores vuelven a evaluar permisos del mismo modo.

Las políticas basadas en recursos y las basadas en identidades pueden combinarse con reglas de contexto. AWS documenta políticas de recursos para AgentCore en las que pueden expresarse principales, acciones y condiciones, y recomienda conceder únicamente los permisos necesarios. Usa esa clase de documentación para entender el modelo de evaluación del servicio elegido; no copies una política de ejemplo sin comprobar el recurso, el principal y la acción que afectan en tu despliegue.

Separar preparación, aprobación y ejecución de acciones sensibles

Una aprobación humana es útil cuando una operación puede enviar información a terceros, modificar datos compartidos, borrar contenido o cambiar permisos. No debería consistir en un botón genérico de “continuar”. Antes de decidir, la persona necesita entender qué operación se realizará, sobre qué recurso, con qué datos y cuál será el efecto esperado. Si la vista previa omite el destinatario, el contenido que se enviará o el alcance del cambio, la aprobación no permite valorar adecuadamente el riesgo.

La aprobación también debe estar vinculada a la operación que se revisó. Si después de aprobar cambian el destino, los argumentos, el recurso o la acción, solicita una nueva decisión. Evita convertir una aprobación puntual en un permiso general que el agente pueda reutilizar para otras tareas. La interfaz debe dejar claro quién aprueba y en nombre de quién se ejecutará la operación.

La documentación del SDK de agentes de OpenAI describe un flujo en el que una llamada sensible a una herramienta puede pausarse para revisión, con inspección de la herramienta y sus argumentos antes de reanudarla o rechazarla. Es un ejemplo de mecanismo de revisión, no una garantía de que cualquier operación sea segura: el equipo aún debe decidir qué herramientas requieren pausa y si los datos presentados al aprobador bastan para juzgar el efecto.

Limitar duración y revocar el acceso de forma comprobable

Conceder acceso durante una sesión o tarea concreta reduce el tiempo en que una credencial puede ser reutilizada, siempre que el entorno permita esa modalidad. Define cuándo comienza y termina la autorización, si puede renovarse y quién puede hacerlo. No confundas una sesión corta con un alcance estrecho: una credencial breve que permite borrar todos los datos sigue teniendo un impacto potencial amplio mientras esté activa.

Diseña la revocación como una operación que debe poder probarse. Retira el permiso o invalida la credencial y ejecuta después nuevas solicitudes con la misma identidad. Comprueba también las sesiones ya abiertas, los tokens en caché, los trabajos en segundo plano y los reintentos. La respuesta depende del proveedor: algunos cambios pueden surtir efecto de inmediato y otros estar sujetos a propagación o a la duración de credenciales emitidas anteriormente. Si la documentación no aclara el comportamiento, registra esa incertidumbre y prueba el caso en el entorno correspondiente.

Para reducir el riesgo de acceso persistente, asigna credenciales distintas a agentes, entornos y tareas cuando sea viable, y evita copiar secretos de usuario en prompts, historiales o registros. Si se usa delegación o intercambio de tokens, conserva únicamente los datos necesarios para operar y auditar. La revocación no sustituye al diseño inicial de permisos: es una defensa adicional para responder a cambios de personal, incidentes o tareas que han terminado.

Registrar decisiones y resultados sin convertir los logs en otro riesgo

Un registro útil permite reconstruir quién pidió una tarea, qué identidad se utilizó, qué herramienta se llamó, qué recurso se intentó alcanzar, qué decisión tomó el sistema y cuál fue el resultado. Guarda identificadores de solicitud y marcas temporales suficientes para correlacionar eventos entre el agente y el servicio de destino. Distingue entre una llamada intentada, una autorización concedida y una operación completada: no son el mismo hecho.

No guardes tokens, claves, contraseñas ni otros secretos en registros o trazas. Tampoco almacenes automáticamente todo el contenido consultado o enviado. Define qué datos son necesarios para investigar fallos y cómo se protegen, quién puede acceder a ellos y durante cuánto tiempo se conservan. En algunos casos, registrar el identificador del recurso y un resumen del tipo de operación bastará; en otros, será preciso guardar una vista previa con controles de privacidad.

Usa la telemetría para detectar patrones que merecen revisión: denegaciones repetidas, intentos de acceder a recursos ajenos a la tarea, llamadas de escritura inesperadas o uso de una credencial después de una revocación. Un patrón observado no prueba por sí solo que haya habido abuso; es una señal para investigar con el contexto de la solicitud y las políticas vigentes.

Probar los límites, incluidos los intentos fuera de alcance

Antes del despliegue, transforma cada permiso concedido en una prueba positiva y varias negativas. La prueba positiva demuestra que la tarea legítima funciona con el alcance previsto. Las negativas comprueban que el mismo agente no puede cambiar de usuario, acceder a un recurso compartido no autorizado, usar una operación de escritura cuando solo tiene lectura, borrar registros o invocar una herramienta fuera de su finalidad. Repite las pruebas cuando cambien conectores, roles, políticas o flujos de aprobación.

Prueba tanto la interfaz del agente como el sistema de destino. Si el agente no ofrece una herramienta prohibida, verifica además que una llamada directa o una ruta alternativa tampoco logra ejecutar la acción con las credenciales disponibles. Comprueba que una aprobación no autoriza argumentos distintos de los revisados y que un permiso revocado bloquea las solicitudes posteriores. Para operaciones de alto impacto, emplea datos y recursos de prueba que permitan observar el efecto sin afectar a personas o servicios reales.

Una prueba aprobada no demuestra que el sistema sea seguro en todas las circunstancias. Acredita que ciertos casos se comportaron como se esperaba bajo una configuración concreta. Conserva la identidad de prueba, la política aplicada, los pasos y el resultado; así podrás repetir la comprobación después de una actualización. Si una plataforma oculta parte de la evaluación de permisos o no ofrece registros suficientes, anótalo como limitación en lugar de asumir que el control funcionó.

Límites del control y errores que conviene evitar

Los permisos reducen el conjunto de acciones posibles, pero no garantizan que el agente interprete correctamente una tarea ni que la respuesta sea exacta. Un permiso de lectura puede revelar información sensible si el conjunto de documentos autorizado es demasiado amplio. Un permiso de escritura acotado puede causar un cambio equivocado dentro de ese alcance. Por eso el diseño combina autorización, validación de entradas, revisión proporcional al riesgo y pruebas de comportamiento.

Evita conceder una credencial administrativa para simplificar la integración, confiar en que el prompt impedirá las operaciones no deseadas o suponer que una lista de herramientas permitidas equivale a una política completa. Tampoco conviertas el consentimiento del usuario para una tarea en una autorización persistente para otras. Las instrucciones y aprobaciones guían el proceso; el permiso efectivo debe seguir limitado en la identidad y en el sistema conectado.

Esta guía se ocupa de la autoridad técnica y de cómo acotarla. Es distinta de una guía sobre inyección indirecta de instrucciones, cuyo foco es el contenido no fiable que intenta dirigir al agente, y de una guía de recuperación ante fallos, que trata la respuesta a errores y efectos parciales. Los temas se relacionan: una instrucción hostil puede intentar provocar una acción no deseada, mientras que los permisos y controles de destino determinan qué acciones llegan a ser posibles.

Lista de verificación antes del despliegue y después de un cambio

Revisa el modelo de permisos antes de activar un agente y repite la revisión cuando se añada una herramienta, cambie un conector, se amplíe el conjunto de datos o se modifique una política. La persona responsable debe poder explicar qué tarea justifica cada permiso y qué efecto tendría una llamada equivocada. Si no puede identificarse el uso legítimo de una capacidad, desactívala hasta aclararlo.

Como referencia operativa, comprueba que la configuración separa lectura, escritura, envío, borrado y cambios de acceso; que delimita usuario y recurso; y que no depende exclusivamente de instrucciones del modelo. Verifica el proceso de aprobación para operaciones sensibles, la información que ve quien aprueba, el registro de decisiones y resultados y el procedimiento para revocar el acceso. Prueba los casos negativos descritos anteriormente con las identidades y los sistemas que se usarán en producción.

La lista no reemplaza la revisión de seguridad del producto ni la documentación específica del proveedor. Es un método para hacer visibles los supuestos que suelen quedar ocultos al conectar herramientas. Cuando una capacidad del entorno no permita aplicar un límite necesario, registra la brecha, evalúa el riesgo y cambia el diseño de la tarea o el flujo antes de conceder acceso amplio.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.