Checklist de Segurança para AI Agents: O Que Revisar Antes de Delegar Trabalho
Checklist prático para revisar ferramentas, prompts, limites de dados, permissões, logs e aprovações antes de um AI agent agir.
Atualizado em
AI agents estão saindo do chat e entrando no trabalho real. Eles podem ler arquivos, navegar páginas, chamar ferramentas, abrir pull requests, atualizar registros e tomar decisões em várias etapas. Isso muda a pergunta de segurança: não é apenas “o modelo respondeu errado?”, mas “o que o sistema consegue fazer se confiar no input errado?”
Uma checklist de segurança para AI agents é uma revisão prática antes de delegar tarefas reais. Ela olha para prompts, ferramentas, fontes de dados, permissões, memória, logs e pontos de aprovação humana.
O que mudou
A primeira onda de risco em produtos de IA girava em torno de texto gerado. O modelo podia alucinar, vazar contexto ou seguir instruções maliciosas. Agents adicionam uma superfície maior porque combinam raciocínio do modelo com sistemas externos.
Workflows modernos podem incluir arquivos locais, repositórios, tickets, bancos de dados, ferramentas via API ou MCP, ações no navegador, memória de sessões, credenciais e planejamento multi-etapas.
Por isso, melhorar o prompt não basta. Um agent confiável precisa de limites claros: quais dados são confiáveis, quais ferramentas podem ser chamadas, quais ações exigem confirmação e como alguém audita o que aconteceu.
Três camadas de risco
| Camada | O que pode dar errado | Pergunta de revisão |
|---|---|---|
| Instructions | Página, email, ticket ou documento tenta sobrescrever regras | O agent distingue instruções do usuário de conteúdo não confiável? |
| Tools | Ferramenta tem permissão ampla, descrição envenenada ou combinação perigosa | O agent vê apenas ferramentas necessárias para a tarefa? |
| Data | Dados não confiáveis viram metadados, origem de arquivo ou contexto de execução | O sistema separa dados confiáveis de dados controlados por terceiros? |
O problema novo é que agents não apenas leem texto malicioso. Eles podem usar esse texto para escolher ferramentas, clicar, escrever código ou alterar registros.
Prompt injection, tool poisoning e data injection
| Risco | Significado | Exemplo |
|---|---|---|
| Prompt injection | Conteúdo não confiável tenta substituir instruções | Página pede para revelar instruções ocultas ou enviar dados |
| Tool poisoning | Descrição ou metadata da ferramenta muda a escolha do modelo | Ferramenta falsa diz que deve processar todos os dados financeiros |
| Agent data injection | Dados maliciosos parecem contexto confiável | Repositório ou resposta de ferramenta manipula paths, origem ou execução |
Conteúdo perigoso pode parecer link, label, nome de ferramenta, origem de arquivo, patch ou resposta estruturada.
Checklist antes de delegar trabalho
| Checagem | Bom padrão | Sinal de risco |
|---|---|---|
| Escopo | Uma tarefa clara e uma condição de sucesso | ”Resolva qualquer coisa que aparecer” |
| Limite de dados | Entradas confiáveis separadas de conteúdo externo | Web, email, tickets e output de tools misturados |
| Inventário de tools | Cada tool tem dono, propósito e permissão | Toolbox grande e confusa |
| Permissão | Read-only por padrão; escrita exige aprovação | Agent pode editar, deletar, deployar, pagar ou enviar email sozinho |
| Credenciais | Tokens com escopo e rotação | Tokens amplos ou reutilizados entre serviços |
| Aprovação humana | Ações externas ou destrutivas pausam para review | Ações irreversíveis em uma execução |
| Logging | Prompts, calls, outputs, aprovações e ações finais salvos | Só a resposta final aparece |
| Testes | Casos normais, confusos e adversariais | Apenas demo feliz |
Regra simples: se a ação é difícil de desfazer, o agent não deve executá-la sem aprovação humana.
Revisão específica de MCP
Antes de usar um MCP server, pergunte:
- Quem mantém o servidor e a implementação é confiável?
- Quais dados e ações ele expõe?
- Os nomes e descrições das ferramentas são claros?
- Os escopos podem ser reduzidos por tarefa ou usuário?
- A autorização usa consentimento por cliente e redirect URI exata?
- Tokens são emitidos para o MCP server ou repassados cegamente?
- O client bloqueia requests para endpoints internos ou metadata?
- Tool calls são registrados com detalhe suficiente?
O setup mais seguro não é o que tem mais ferramentas, mas o que mostra ao agent só o necessário.
Checklist para coding agents
| Antes de permitir | Revisar |
|---|---|
| Edição de arquivos | Limitar diretório e exigir review de patches |
| Comandos | Separar comandos read-only de install, delete, deploy ou mutação |
| Dependências | Revisar nomes de pacotes, registries, lockfile e postinstall |
| Secrets | Manter tokens fora de prompts, logs, arquivos e histórico shell |
| Pull requests | Exigir testes, diff review e provenance clara |
| Input externo | Tratar issue, README, comentários e web snippets como não confiáveis |
Coding agents podem aumentar produtividade, mas o caminho de revisão precisa continuar visível.
O que times pequenos podem fazer esta semana
- Escolha um workflow repetível, como resumir tickets ou rascunhar PR.
- Rode primeiro com acesso read-only.
- Liste todas as ferramentas que o agent pode chamar.
- Remova ferramentas que não são necessárias.
- Exija aprovação para escrita, mensagens externas, compras, deploys e deleções.
- Salve prompts, tool calls, outputs e ações finais.
- Teste um exemplo adversarial, como um ticket pedindo para ignorar regras.
Se o agent não consegue explicar quais dados confiou, quais tools usou e quais ações tomou, o workflow não está pronto para autonomia.
Registro de atualização
Jul 09 2026: Publicada a versão em português do Brasil com checklist de segurança, revisão MCP, riscos de coding agents, FAQ e referências.