[!NOTE] Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.
Melhores padrões de segurança para agentes AI em 2026
A segurança de um agente diz respeito ao controlo das suas ações. Um chatbot pode retornar uma resposta incorreta. Por outro lado, um agente é capaz de utilizar credenciais reais, aceder a ferramentas e modificar dados em produção.
A regra padrão é simples: não se deve conceder a um agente capacidades de que ele não precisa. Comece com ferramentas específicas, verificações de política antes de cada tool call, sandboxes isolados, credenciais limitadas, mecanismos de aprovação humana e rastreios de auditoria. Adicione também restrições e filtros de saída, mas não os considere como a principal barreira de segurança.
Classificação de padrões
| Padrão | Prioridade | Protege contra | Nota de implementação |
|---|---|---|---|
| Ferramentas de menor privilégio | P0 | Agência excessiva | Não exponha ferramentas que o agente nunca deve utilizar. |
| Verificações de política pré-ferramenta | P0 | Ações perigosas | Verifique a ação concreta imediatamente antes da execução. |
| Sandboxes | P0 | Danos em ficheiros, shell, navegador e rede | Isolar o código e o conteúdo não confiável. |
| Aprovações humanas | P0 | Ações irreversíveis ou reguladas | Escritas de gate, implementações, pagamentos, envios externos e alterações privilegiadas. |
| Credenciais com escopo definido | P0 | Excesso de permissões de credenciais e falhas de representante confuso | Utilize escopos restritos, um por servidor e um por ferramenta. |
| Isolamento do servidor MCP | P1 | Envenenamento de ferramentas, sombreamento de ferramentas, ataques entre servidores | Não misture servidores não confiáveis com ferramentas poderosas no mesmo contexto sem realizar uma revisão prévia. |
| Registos de auditoria | P1 | Histórico de incidentes desconhecido | Persistir o pedido do utilizador, tool call, parâmetros, resultado, decisão da política e autorização. |
| Restrições | P1 | Texto de entrada e saída inseguro | Útil, mas insuficiente para garantir autoridade à ferramenta. |
| Avaliações de equipa vermelha | P1 | Caminhos de ataque conhecidos | Testar prompt injection, envenenamento de ferramentas, extração de dados e contornos de permissões. |
O que implementar primeiro
Remova primeiro as capacidades desnecessárias. Se o agente não precisar de escrever no GitHub, não lhe atribua um token de escrita. Se ele apenas necessitar de aceder à disponibilidade do calendário, não conceda acesso total à caixa de correio. Uma permissão restrita é mais segura do que uma autorização ampla prompt.
Em seguida, verifique a política antes de cada tool call. Analise o nome da ferramenta, os argumentos, o recurso alvo, o utilizador, o ambiente e os efeitos colaterais. Um pedido que parece inofensivo pode ainda gerar uma instrução de shell perigosa.
Adicione sandboxes para execução de código, automação de navegadores, acesso a ficheiros e processamento de documentos não confiáveis. Um sandbox não torna a ação correta, mas reduz os danos causados por um tool result comprometido ou por um modelo confuso.
Utilize a aprovação humana para ações irreversíveis. Não aprove cada passo individualmente. Aprove apenas os limites críticos: implantações em produção, eliminação de dados, envio de e-mails, movimentações financeiras, alterações de permissões e decisões sujeitas a regulamentação.
Riscos específicos de MCP
MCP é útil pois permite a padronização do acesso às ferramentas. No entanto, representa um risco, uma vez que as descrições das ferramentas, os esquemas, as identidades dos servidores, os escopos OAuth e as saídas das ferramentas passam a fazer parte do contexto de decisão do modelo.
Para o MCP, manteria estas regras nas revisões de código:
- Rever as descrições e esquemas das ferramentas antes da aprovação
- Preferir credenciais restritas por servidor
- Isolar servidores não confiáveis MCP de ferramentas sensíveis
- Fazer acompanhamento das alterações nas definições das ferramentas após a instalação
- Tratar a saída das ferramentas como entrada não confiável
- Registar cada servidor, ferramenta, argumento e resultado
As regras de segurança não são suficientes
As regras de segurança podem validar as entradas e saídas. No entanto, elas não resolvem problemas relacionados com o princípio do menor privilégio, o escopo das credenciais, o isolamento em ambiente controlado, a contaminação de ferramentas ou as políticas de aprovação. Mantenha-as, mas aplique-as após a definição das capacidades e antes da exibição dos resultados ao utilizador.
Leitura aprofundada
- AI Segurança de Agentes em 2026 é o guia completo de arquitetura. AI Agente Tool Use em 2026 Explica MCP, as ferramentas, a interface de linha de comando, as competências necessárias e o processo de execução de código.
- AI Agente Runtime em 2026 Cobre os limites de runtime para agentes em execução por um longo período de tempo.