c4.1 Restrinja os papéis das ferramentas com privilégio mínimo e permission boundaries
Conceda a cada integração de ferramenta apenas as permissões de que precisa, e use permission boundaries para que combinar ferramentas não possa escalar privilégios.
Guia de implementação
Como implementar na AWS
Crie papéis de serviço personalizados por integração de ferramenta que concedam apenas as ferramentas e serviços da AWS específicos necessários. Aplique permission boundaries de IAM para limitar o privilégio máximo que qualquer cadeia de ferramentas pode alcançar. Exija identidade restrita por tarefa em vez de papéis amplos padrão.
Cada ferramenta é um novo privilégio que o agente ganha
Quando um agente pode chamar ferramentas, cada integração de ferramenta é uma função com permissões. O risco é duplo: uma função de ferramenta individual ampla demais e — de forma mais sutil — a combinação de privilégios, em que um agente que encadeia várias ferramentas consegue algo que nenhuma ferramenta sozinha deveria permitir. O privilégio mínimo por ferramenta trata do primeiro; os limites de permissões (permission boundaries) tratam do segundo ao limitar o que qualquer função de ferramenta pode chegar a fazer, independentemente das políticas anexadas a ela.
Restrinja cada função de ferramenta de forma estreita
Dê a cada ferramenta sua própria função com apenas as ações e os recursos de que essa ferramenta precisa — uma ferramenta de "ler registro de cliente" deveria ler uma tabela do DynamoDB, não ter dynamodb:*. É a mesma disciplina de privilégio mínimo da função de invocação do modelo, aplicada por ferramenta.
Limite o teto com um limite de permissões
Um limite de permissões é uma política gerenciada anexada a uma função que define suas permissões máximas. As permissões efetivas da função tornam-se a interseção de sua política de identidade E o limite — então, mesmo que a política de uma ferramenta seja ampliada depois (ou um atacante tente anexar uma mais ampla), ela nunca pode exceder o limite:
{
"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": "*"
}
]
}
Anexe-o ao criar a função da ferramenta:
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
Torne o limite obrigatório para as funções de ferramenta
O limite só é efetivo se estiver sempre anexado. Imponha-o com uma SCP ou uma condição do IAM (iam:PermissionsBoundary) para que qualquer função criada para uma ferramenta precise carregar o limite; caso contrário, um desenvolvedor pode criar uma função de ferramenta sem limite ao omiti-lo. É assim que você interrompe a combinação de privilégios em um conjunto crescente de ferramentas.
Nota de nomenclatura: o limite não concede nada por si só — você ainda precisa da política de identidade de cada ferramenta. O bloco Deny é o real valor: ações que nenhuma ferramenta deveria jamais executar (tocar IAM, excluir chaves, administrar a organização).Critérios de aceitação
Cada ferramenta tem um papel dedicado de privilégio mínimo; os permission boundaries limitam o privilégio da cadeia; nenhum papel amplo compartilhado é reutilizado entre ferramentas.
Implementação prática
Como este controle é implementado em cada arquitetura de referência:
Cada integração de ferramenta na conta de IA generativa recebe seu próprio papel restrito, e um permission boundary de OU/conta limita o que qualquer cadeia de ferramentas pode alcançar.
- Crie um papel de serviço dedicado por integração de ferramenta que conceda apenas as ferramentas e serviços da AWS específicos de que essa ferramenta precisa, na conta de IA generativa.
- Anexe um permission boundary de IAM para limitar o privilégio máximo que qualquer cadeia de ferramentas pode alcançar, de modo que combiná-las não possa escalar.
- Exija identidade restrita por tarefa para a execução de ferramentas em vez de um papel amplo padrão, e mantenha as permissões de administração de ferramentas com os operadores.
Como validar: Cada ferramenta tem um papel dedicado de privilégio mínimo; os permission boundaries limitam o privilégio da cadeia; combinar duas ferramentas não pode alcançar um recurso que nenhuma tem permitido individualmente.
Evite: Um único 'papel de agente' compartilhado que todas as ferramentas assumem. A agência excessiva significa que uma única prompt injection pode acionar qualquer ferramenta; restrinja por ferramenta e limite a cadeia.
Papéis de privilégio mínimo por ferramenta mais permission boundaries na conta impedem que uma única ferramenta — ou uma cadeia delas — aja além do seu propósito.
- Crie um papel dedicado por integração de ferramenta restrito apenas às ferramentas e serviços de que essa ferramenta precisa.
- Aplique permission boundaries de IAM para que uma cadeia de ferramentas não possa escalar além do máximo previsto.
- Use identidade restrita por tarefa para a execução de ferramentas em vez de um papel amplo padrão.
Como validar: Cada ferramenta tem seu próprio papel de privilégio mínimo; os permission boundaries limitam a cadeia; nenhum papel amplo compartilhado é reutilizado entre ferramentas.
Evite: Dar à camada de ferramentas o papel completo do app. Restrinja cada ferramenta para prevenir estruturalmente a agência excessiva e a escalada.
Ameaças atendidas
- Agência excessiva: uma ferramenta capaz de agir além do seu escopo previsto.
- Escalada de privilégios por combinações não previstas de ferramentas.
Serviços AWS
Preços
Funções, políticas e limites de permissões do IAM são gratuitos. Este controle não tem custo; é puramente uma disciplina de design e governança. Consulte Permissions boundaries for IAM entities.
Mapeamentos 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 aprendizado
Referências
- AWS SRA para IA — Capacidade 4, Gestão de identidade e acesso
AI Security Maturity Model