Checklist de segurança de AI Agents: permissões e sandboxes
Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.
A segurança de um agent consiste em controlar as ações. Um chatbot pode dar uma resposta errada. Um agent pode utilizar credenciais reais, chamar uma tool e alterar dados em produção.
A regra por defeito é simples: não dê a um agent capacidades de que não necessita. Comece por tools restritas, verificações de policy antes de cada tool call, sandboxes isoladas, credenciais limitadas, gates de aprovação humana e audit traces. Adicione também guardrails e filtros de output, mas não os trate como o principal limite de segurança.
Modelo de ameaças e data da revisão: 2026-08-10. Estas prioridades assumem que um agent que utiliza tools pode processar input controlado por um atacante e ler dados ou provocar efeitos externos. Assistentes com menos capacidades precisam de menos controlos; ações de maior impacto exigem isolamento e aprovação mais rigorosos.
Classificação de patterns
| Pattern | Prioridade | Protege contra | Nota de implementação |
|---|---|---|---|
| Tools com least privilege | P0 | Agência excessiva | Siga as orientações da OWASP para MCP: não exponha tools que o agent nunca deve utilizar. |
| Verificações de policy antes da tool | P0 | Ações perigosas | Verifique a ação concreta imediatamente antes da execução. |
| Sandboxes | P0 | Danos em ficheiros, shell, browser e rede | Isole código e conteúdo não fidedigno; negue o acesso de saída à rede por defeito. |
| Aprovações humanas | P0 | Ações irreversíveis ou regulamentadas | Exija um gate para writes, deploys, pagamentos, envios externos e alterações privilegiadas. |
| Credenciais com âmbito limitado | P0 | Acesso excessivo a credenciais e falhas de confused deputy | Utilize âmbitos restritos por servidor e por tool. |
| Isolamento de servidores MCP | P1 | Tool poisoning, tool shadowing e ataques entre servidores | Não misture servidores não fidedignos com tools poderosas no mesmo contexto sem revisão. |
| Audit traces | P1 | Histórico de incidentes desconhecido | Persista o pedido do utilizador, a tool call, os argumentos, o resultado, a decisão da policy e o aprovador. |
| Guardrails | P1 | Texto de input e output inseguro | São úteis, mas não são suficientes para controlar a autoridade das tools. |
| Red-team evals | P1 | Vias de ataque conhecidas | Teste prompt injection, tool poisoning, exfiltração de dados e bypasses de permissões. |
O que implementar primeiro
Comece por remover capacidades. Se o agent não precisa de escrever no GitHub, não lhe dê um token de escrita. Se só precisa da disponibilidade do calendário, não lhe conceda acesso completo à mailbox. Uma permissão restrita é mais segura do que um prompt severo.
Em seguida, verifique a policy antes de cada tool call. Inspecione o nome da tool, os argumentos, o recurso-alvo, o utilizador, o ambiente e o efeito secundário. Um pedido aparentemente inofensivo pode ainda produzir um comando de shell perigoso.
Adicione sandboxes para execução de código, automação de browser, acesso a ficheiros e processamento de documentos não fidedignos. Uma sandbox não torna a ação correta, mas reduz os danos causados por um resultado de tool comprometido ou por um modelo confuso.
Controle o fluxo de dados, além da execução. Restrinja os destinos de saída da rede, remova secrets dos resultados das tools, separe conteúdo não fidedigno das credenciais e registe as tentativas de saída. Uma sandbox do sistema de ficheiros que permita acesso arbitrário à rede continua a deixar um caminho direto para a exfiltração.
Utilize aprovação humana para ações irreversíveis. Não aprove todos os passos. Aprove limites: deploys em produção, eliminação de dados, envios de email, movimentação de dinheiro, alterações de permissões e decisões regulamentadas.
Riscos específicos do MCP
O MCP é útil porque normaliza o acesso a tools. É arriscado porque as descrições das tools, os schemas, as identidades dos servidores, os OAuth scopes e os outputs das tools passam todos a fazer parte do contexto de decisão do modelo.
Para MCP, manteria estas regras no code review:
- reveja as descrições e os schemas das tools antes da aprovação
- prefira credenciais restritas por servidor
- isole servidores MCP não fidedignos de tools sensíveis
- esteja atento a alterações nas definições das tools após a instalação
- trate o output das tools como input não fidedigno
- registe todos os servidores, tools, argumentos e resultados
Os guardrails não são suficientes
Os guardrails podem validar o input e o output. Não resolvem least privilege, o âmbito das credenciais, sandboxing, tool poisoning ou a policy de aprovação. Mantenha-os, mas coloque-os depois da definição das capacidades e antes do output visível para o utilizador.
Leitura adicional
- Segurança de AI Agents é o guia completo de arquitetura.
- Utilização de tools por AI Agents explica MCP, tools, CLI, skills e execução de código.
- Runtime de AI Agents de longa duração aborda os limites de runtime para agents de longa duração.