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 de produção.
A regra predefinida é simples: não dê a um agent capacidades de que não precisa. Comece por tools restritas, verificações de políticas antes de cada tool call, sandboxes isoladas, credenciais limitadas, aprovações humanas e traces de auditoria. Adicione também guardrails e filtros de output, mas não os trate como a principal fronteira de segurança.
Modelo de ameaças e data da revisão: 2026-09-08. Estas prioridades pressupõem que um agent com tool use pode processar input controlado por um atacante e ler dados ou causar efeitos externos. Assistentes com menos capacidades precisam de menos controlos; ações com maior impacto exigem isolamento e aprovação mais rigorosos.
Classificação dos padrões
| Padrão | 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 deverá utilizar. |
| Verificações de políticas 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 fiável; negue o egress de rede por predefinição. |
| Aprovações humanas | P0 | Ações irreversíveis ou regulamentadas | Exija aprovação para escritas, deployments, pagamentos, envios externos e alterações privilegiadas. |
| Credenciais com âmbito limitado | P0 | Excesso de permissões das 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 fiáveis e tools poderosas no mesmo contexto sem revisão. |
| Traces de auditoria | P1 | Histórico desconhecido de incidentes | Registe a identidade do utilizador, a ação, o alvo, a decisão da política, o aprovador e o resultado. Remova dados sensíveis dos payloads antes do armazenamento. |
| Guardrails | P1 | Inputs, outputs ou tool calls inseguros | Execute verificações da política da tool antes da execução; os filtros de texto, por si só, não podem autorizar ações. |
| Evals de red team | P1 | Vectores de ataque conhecidos | 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 apenas precisa de consultar a disponibilidade no calendário, não lhe conceda acesso completo à mailbox. Uma permissão restrita é mais segura do que um prompt severo.
Em seguida, verifique a política 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 shell perigoso.
Adicione sandboxes para execução de código, automatização de browser, acesso a ficheiros e processamento de documentos não fiáveis. Uma sandbox não torna a ação correta, mas reduz os danos causados por um tool result comprometido ou por um modelo confuso.
Controle também o fluxo de dados, além da execução. Restrinja os destinos da rede de saída, remova secrets dos tool results, separe conteúdo não fiável das credenciais e registe as tentativas de egress. Uma sandbox de sistema de ficheiros que continue a permitir acesso arbitrário à rede deixa uma via direta para exfiltração.
Utilize aprovação humana para ações irreversíveis. Não aprove todos os passos. Aprove ações específicas de elevado impacto: deployments em produção, eliminação de dados, envios de email, transferência de fundos, 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 âmbitos OAuth e os tool outputs passam todos a fazer parte do contexto de decisão do modelo.
Para MCP, manteria estas regras no processo de 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 fiáveis das tools sensíveis
- esteja atento a alterações nas definições das tools após a instalação
- trate o tool output como input não fiável
- registe as identidades do servidor e da tool, as decisões da política e os resultados; minimize e remova argumentos e resultados antes de os guardar
Os guardrails não são suficientes
Os guardrails podem verificar texto e tool calls. No OpenAI Agents SDK, os input tool guardrails podem bloquear uma function tool protegida antes de esta ser executada. As hosted tools e as built-in execution tools não utilizam esse mesmo pipeline; por isso, verifique a cobertura de cada tool que expõe. As verificações de output ocorrem depois da execução e não podem desfazer um efeito secundário.
Aplique as permissões antes da execução, em conjunto com quaisquer verificações de guardrails. Mantenha as credenciais restritas e isole as tools mesmo quando os seus inputs passam a validação.
Siga as orientações da OWASP para logging: exclua secrets e dados pessoais desnecessários dos traces. Restrinja quem pode ler os logs e defina um período de retenção. Um registo de auditoria deve ajudar a reconstruir uma ação sem copiar todos os payloads privados.
Leitura aprofundada
- AI Agent Security é o guia completo de arquitetura.
- AI Agent Tool Use explica MCP, tools, CLI, skills e execução de código.
- Long-Running AI Agent Runtime aborda as fronteiras de runtime para agents de longa duração.