AI Security Maturity Model·AWS v1.0.0

Arrastra para explorar · pellizca para ampliar

Fundacional Gestión de identidad y accesoCapa de defensa en profundidad: Identidad y datos Capacidad 4 · HerramientasCaso de uso: IA que actúa 👤 ClienteModelo de Responsabilidad Compartida de AWS: quién implementa y opera este control. Cliente = es tuyo; AWS = lo opera AWS y tú lo heredas; Compartida = ambos tienen obligaciones.

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.

Fundacional
Mejorada
Avanzada
Esfuerzo: Medio Impacto: Alto Scopes de IA generativaDe la AWS Generative AI Security Scoping Matrix.: 3 · Modelos preentrenados; 4 · Modelos ajustados (fine-tuned) Dimensiones de seguridad agénticaDe la AWS Agentic AI Security Scoping Matrix.: Identidad, Límites operativos

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.

  1. 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.
    Cuenta de IA generativa IAM Bedrock AgentCore
  2. 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.
    Cuenta de IA generativa IAM
  3. 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.
    Cuenta de IA generativa IAM Bedrock AgentCore

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.

OU de IA generativa (multi-cuenta) →

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.

  1. Crea un rol dedicado por integración de herramienta acotado solo a las herramientas y servicios que esa herramienta requiere.
    Capa de IA generativa (rol IAM) IAM Bedrock AgentCore
  2. Aplica permission boundaries de IAM para que una cadena de herramientas no pueda escalar más allá del máximo previsto.
    Capa de IA generativa (rol IAM) IAM
  3. Usa identidad acotada por tarea para la ejecución de herramientas en vez de un rol amplio por defecto.
    Capa de aplicación (rol IAM) IAM

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.

Cuenta única (punto de entrada) →

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

AWS IAM Amazon Bedrock AgentCore

Precios

Sin cargo adicional

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