c4.1 Acota los roles de las herramientas con mínimo privilegio y permission boundaries
Otorga a cada integración de herramienta solo los permisos que necesita, y usa permission boundaries para que combinar herramientas no pueda escalar privilegios.
Guía de implementación
Cómo implementarlo en AWS
Crea roles de servicio personalizados por integración de herramienta que otorguen solo las herramientas y servicios de AWS específicos requeridos. Aplica permission boundaries de IAM para topar el privilegio máximo que cualquier cadena de herramientas puede alcanzar. Exige identidad acotada por tarea en vez de roles amplios por defecto.
Cada herramienta es un nuevo privilegio que gana el agente
Cuando un agente puede llamar a herramientas, cada integración de herramienta es un rol con permisos. El riesgo es doble: un rol de herramienta individual demasiado amplio y —de forma más sutil— la combinación de privilegios, donde un agente que encadena varias herramientas logra algo que ninguna herramienta por sí sola debía permitir. El mínimo privilegio por herramienta atiende lo primero; los límites de permisos (permission boundaries) atienden lo segundo al topar lo que cualquier rol de herramienta puede llegar a hacer, sin importar las políticas que se le adjunten.
Acota cada rol de herramienta estrechamente
Da a cada herramienta su propio rol con solo las acciones y los recursos que esa herramienta necesita: una herramienta de "leer registro de cliente" debería leer una tabla de DynamoDB, no tener dynamodb:*. Es la misma disciplina de mínimo privilegio que el rol de invocación del modelo, aplicada por herramienta.
Topa el techo con un límite de permisos
Un límite de permisos es una política administrada adjunta a un rol que establece sus permisos máximos. Los permisos efectivos del rol se convierten en la intersección de su política de identidad Y el límite, de modo que aunque la política de una herramienta se amplíe después (o un atacante intente adjuntar una más amplia), nunca puede exceder el límite:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ToolMaxPermissions",
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:Query",
"s3:GetObject"
],
"Resource": "*"
},
{
"Sid": "NeverTouchIdentityOrSecurity",
"Effect": "Deny",
"Action": [
"iam:*",
"kms:ScheduleKeyDeletion",
"organizations:*"
],
"Resource": "*"
}
]
}
Adjúntalo al crear el rol de la herramienta:
aws iam create-role \
--role-name agent-tool-read-customer \
--assume-role-policy-document file://trust.json \
--permissions-boundary arn:aws:iam::111122223333:policy/AgentToolBoundary
Haz obligatorio el límite para los roles de herramienta
El límite solo es efectivo si siempre está adjunto. Imponlo con una SCP o una condición de IAM (iam:PermissionsBoundary) para que cualquier rol creado para una herramienta deba llevar el límite; de lo contrario, un desarrollador puede crear un rol de herramienta sin límite al omitirlo. Así es como detienes la combinación de privilegios en un conjunto creciente de herramientas.
Nota de nomenclatura: el límite no concede nada por sí mismo; sigues necesitando la política de identidad de cada herramienta. El bloque Deny es el verdadero valor: acciones que ninguna herramienta debería realizar jamás (tocar IAM, borrar claves, administrar la organización).Criterios de aceptación
Cada herramienta tiene un rol dedicado de mínimo privilegio; los permission boundaries topan el privilegio de la cadena; no se reutiliza un rol amplio compartido entre herramientas.
Implementación práctica
Cómo se implementa este control en cada arquitectura de referencia:
Cada integración de herramienta en la cuenta de IA generativa recibe su propio rol acotado, y un permission boundary de OU/cuenta topa lo que cualquier cadena de herramientas puede alcanzar.
- Crea un rol de servicio dedicado por integración de herramienta que otorgue solo las herramientas y servicios de AWS específicos que esa herramienta necesita, en la cuenta de IA generativa.
- Adjunta un permission boundary de IAM para topar el privilegio máximo que cualquier cadena de herramientas puede alcanzar, de modo que combinarlas no pueda escalar.
- Exige identidad acotada por tarea para la ejecución de herramientas en vez de un rol amplio por defecto, y mantén los permisos de administración de herramientas con los operadores.
Cómo validar: Cada herramienta tiene un rol dedicado de mínimo privilegio; los permission boundaries topan el privilegio de la cadena; combinar dos herramientas no puede alcanzar un recurso que ninguna tiene permitido por separado.
Evita: Un solo 'rol de agente' compartido que todas las herramientas asumen. La agencia excesiva significa que una sola prompt injection puede accionar cualquier herramienta; acota por herramienta y topa la cadena.
Roles de mínimo privilegio por herramienta más permission boundaries en la cuenta evitan que una sola herramienta —o una cadena de ellas— actúe más allá de su propósito.
- Crea un rol dedicado por integración de herramienta acotado solo a las herramientas y servicios que esa herramienta requiere.
- Aplica permission boundaries de IAM para que una cadena de herramientas no pueda escalar más allá del máximo previsto.
- Usa identidad acotada por tarea para la ejecución de herramientas en vez de un rol amplio por defecto.
Cómo validar: Cada herramienta tiene su propio rol de mínimo privilegio; los permission boundaries topan la cadena; no se reutiliza un rol amplio compartido entre herramientas.
Evita: Darle a la capa de herramientas el rol completo de la app. Acota cada herramienta para prevenir estructuralmente la agencia excesiva y la escalada.
Amenazas que atiende
- Agencia excesiva: una herramienta capaz de actuar más allá de su alcance previsto.
- Escalada de privilegios mediante combinaciones no previstas de herramientas.
Servicios AWS
Precios
Los roles, las políticas y los límites de permisos de IAM son gratuitos. Este control no tiene costo; es puramente una disciplina de diseño y gobernanza. Consulta Permissions boundaries for IAM entities.
Mapeos de frameworks
OWASP GenAI/LLM Top 10 (2026)
- LLM03 Excessive Agency
- LLM06 Unbounded Consumption
NIST AI Risk Management Framework (AI 100-1)
- GOVERN.1 Policies, processes, procedures and accountability structures
- MANAGE.1 AI risks are prioritized, responded to and managed
AWS Well-Architected Generative AI Lens (Security)
- GENSEC05-BP01 Implement least privilege and permission boundaries for agentic workflows
OWASP GenAI Top 10 for Agentic Applications (2025)
- ASI03 Identity and Privilege Abuse
- ASI02 Tool Misuse and Exploitation
Recursos de aprendizaje
Referencias
- AWS SRA para IA — Capacidad 4, Gestión de identidad y acceso
AI Security Maturity Model