Segurança de agentes de AI: permissões, sandboxes e aprovações

Tradução automática

Este artigo foi traduzido automaticamente a partir da versão original em inglês.

A segurança de agentes de AI controla o que a aplicação pode ler, alterar e enviar. Um agente que utiliza ferramentas pode processar dados privados, utilizar credenciais e alterar sistemas externos. As ações permitidas precisam de verificações no código, mesmo quando a resposta do modelo parece segura.

Exponha apenas as ferramentas necessárias para a tarefa. Verifique as permissões antes de cada tool call, isole a execução, limite as credenciais e registe o resultado. Exija aprovação para ações de elevado impacto. Os filtros de texto podem ajudar a detetar conteúdo inseguro, mas não substituem esses controlos.

Esta lista de verificação pressupõe que o agente lê dados de entrada não fiáveis e pode aceder a dados privados ou alterar sistemas externos. Uma prompt injection é uma instrução nesses dados que tenta redirecionar o agente. Por exemplo, um documento obtido pode dizer-lhe para carregar ficheiros privados. Restringir as ferramentas e os pedidos de saída limita as consequências dessa instrução.

Controlos por capacidade

CapacidadeControloO que impor
Qualquer utilização de ferramentasPrivilégio mínimoExponha apenas as ferramentas necessárias, como recomendam as orientações da OWASP para MCP.
Leitura de dados privados ou alterações externasVerificações de permissõesVerifique o utilizador, os argumentos, o destino e a ação permitida imediatamente antes da execução.
Código, ficheiros ou automatização do navegadorSandboxLimite os ficheiros, processos e estados do navegador acessíveis, bem como os destinos de saída.
Ações de elevado impactoAprovação humanaMostre o destino exato e a alteração antes de uma implantação em produção, um pagamento, uma eliminação ou um envio externo.
Serviços autenticadosCredenciais com âmbito limitadoRestrinja cada integração aos recursos e às ações necessários.
Servidores MCP não fiáveisIsolamento de servidoresReveja as definições das ferramentas e impeça que as instruções devolvidas por um servidor concedam acesso a outra ferramenta.
Execução de ferramentasRegistos de auditoriaRegiste a identidade, o destino, a decisão sobre permissões, a aprovação e o resultado; oculte os dados privados do conteúdo registado.
Processamento de dados de entrada e saídaGuardrailsVerifique a cobertura de cada ferramenta. Um filtro de texto não concede permissões nem reverte uma ação concluída.
Testes de versões e de regressãoTestes de ataquesTeste prompt injection, definições de ferramentas enganosas, divulgação de dados privados e formas de contornar permissões.

O que implementar primeiro

Comece por remover capacidades desnecessárias. Se o agente 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 à caixa de correio.

Em seguida, verifique a política antes de cada tool call. Inspecione o nome da ferramenta, os argumentos, o recurso de destino, 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 do navegador, 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 o fluxo de dados, além da execução. Restrinja os destinos de rede de saída, oculte segredos nos tool results, separe o conteúdo não fiável das credenciais e registe as tentativas de saída. Uma sandbox do 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: implantações em produção, eliminação de dados, envios de correio eletrónico, transferências de dinheiro, alterações de permissões e decisões regulamentadas.

Riscos específicos do MCP

O MCP é útil porque normaliza o acesso a ferramentas. É arriscado porque as descrições das ferramentas, os esquemas, as identidades dos servidores, os âmbitos OAuth e os resultados das ferramentas passam todos a fazer parte do contexto de decisão do modelo.

Para MCP, manteria estas regras na revisão de código:

  • reveja as descrições e os esquemas das ferramentas antes da aprovação
  • prefira credenciais restritas por servidor
  • isole servidores MCP não fiáveis das ferramentas sensíveis
  • esteja atento a alterações nas definições das ferramentas após a instalação
  • trate os resultados das ferramentas como dados de entrada não fiáveis
  • registe as identidades dos servidores e das ferramentas, as decisões da política e os resultados; minimize os argumentos e resultados e oculte os seus dados sensíveis antes de os guardar

Os guardrails não são suficientes

Os guardrails podem verificar texto e tool calls. No OpenAI Agents SDK, os guardrails de entrada das ferramentas podem bloquear uma ferramenta de função protegida antes de esta ser executada. As ferramentas alojadas e as ferramentas de execução integradas não utilizam esse mesmo pipeline; por isso, verifique a cobertura de cada ferramenta que expõe. As verificações de saída 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 ferramentas mesmo quando os seus dados de entrada passam a validação.

Siga as orientações da OWASP para registo de eventos: exclua segredos e dados pessoais desnecessários dos registos de execução. Restrinja quem pode ler os registos e defina um período de retenção. Um registo de auditoria deve ajudar a reconstruir uma ação sem copiar todos os dados privados.

Leitura aprofundada

Referências