Segurança de Agentes de IA: Uma Lista de Verificação Prática de Controle

A segurança de agentes de IA é o sistema de controle em torno de um modelo que pode ler o contexto, escolher ferramentas e agir em diferentes etapas. Um design seguro pressupõe que a saída do modelo, o conteúdo recuperado e os resultados das ferramentas podem estar incorretos ou serem maliciosos. Ele limita o acesso, valida cada ação, torna a incerteza visível e responsabiliza uma pessoa por alterações consequentes.

Ottermind aplica essa mesma abordagem de prioridade aos limites ao trabalho conectado: o contexto de origem e os entregáveis ​​permanecem revisáveis, enquanto as ações consequentes permanecem sujeitas a permissões e aprovação humana. É uma opção de espaço de trabalho, não um substituto para a revisão de segurança da organização.

Pesquisa e divulgação: A lista de verificação baseia-se nos documentos NIST Estrutura de Gestão de Riscos de IA, OWASP Top 10 para Candidaturas de Mestrado em Direito (LLM) e Guia de segurança do agente Anthropic, revisados ​​em 3 de setembro de 2026.

Os cinco limites de segurança

A segurança é distribuída por todo o fluxo de trabalho. Um aviso final pedindo a um agente para "ter cuidado" não é um controle de segurança.

Modelo de ameaças antes do projeto de recursos

Anote o que o agente pode observar, o que ele pode alterar e quem poderia se beneficiar de um erro. Considere um usuário curioso, um conector comprometido, texto malicioso em um documento recuperado, uma ferramenta que retorna dados inesperados e uma interrupção de serviço durante uma gravação. Para cada ameaça, nomeie um controle de prevenção, um sinal de detecção e uma ação de recuperação. Este modelo de ameaças simplificado geralmente revela que o recurso mais arriscado é um conector excessivamente abrangente, e não o próprio modelo.

Isolamento de identidade e locatário

Autentique a pessoa antes de iniciar a execução e autorize cada recuperação e chamada de ferramenta com base nessa identidade. Não assuma que um ID de projeto visível no modelo seja confiável. Verifique as permissões de locatário, projeto, função e nível de registro no serviço que detém os dados. Para espaços de trabalho multiusuário, teste explicitamente uma solicitação entre locatários e verifique se os logs não expõem nomes de arquivos, trechos ou argumentos de ferramentas proibidos.

Integridade da recuperação

Sistemas de recuperação podem vazar dados, retornar registros obsoletos ou expor instruções incorporadas em documentos. Armazene a proveniência com cada bloco: identificador da fonte, proprietário, data de vigência e decisão de permissão. Prefira registros atuais como fonte de verdade e exponha conflitos. Trate HTML, PDFs, e-mails e comentários de problemas como dados, não como instruções. Um modelo nunca deve ser capaz de conceder a si mesmo acesso porque um parágrafo recuperado diz que deveria.

Isolamento de ferramentas e tempo de execução

Use ferramentas específicas que expressem a intenção de negócio em vez de um shell genérico ou um cliente HTTP irrestrito. Valide argumentos, imponha cotas, defina tempos limite e torne as gravações idempotentes. Execute código ou ações do navegador em um ambiente isolado (sandbox) com um sistema de arquivos descartável e saída restrita. Separe as credenciais de desenvolvimento das credenciais de produção e rotacione os tokens de curta duração após a execução.

Design com aprovação humana

A aprovação deve mostrar a ação proposta, o alvo, as evidências de origem, os efeitos colaterais e as alternativas. "Aprovar" não deve ocultar um lote de gravações não relacionadas. Exija uma revisão mais rigorosa para comunicação externa, exclusão, pagamento, alterações de acesso e atualizações de políticas. Armazene o aprovador, o carimbo de data/hora, a decisão e quaisquer edições para que uma nova tentativa não possa ignorar silenciosamente o ponto de verificação.

Casos de teste de equipe vermelha

Crie um pequeno conjunto de regressão que inclua injeção de prompt em um documento, um usuário sem acesso, uma ferramenta retornando JSON malformado, uma credencial expirada, um esquema alterado, uma nova tentativa duplicada e uma solicitação para enviar ou excluir. O resultado esperado nem sempre é uma tarefa concluída; recusa segura, escalonamento e um erro útil são resultados válidos. Execute o conjunto sempre que prompts, ferramentas, conectores ou versões do modelo forem alterados.

Lista de verificação de operações de segurança

• Mantenha um inventário de modelos, ferramentas, conectores e armazenamentos de dados.
• Revise os escopos dos conectores e as funções privilegiadas periodicamente.
• Gerencie o volume incomum de ferramentas, a recuperação entre projetos e as ações bloqueadas.
• Mantenha os rastreamentos por tempo suficiente para investigar incidentes sem armazenar segredos desnecessários.
• Documente como revogar o acesso, interromper uma execução e restaurar o registro de origem.
• Forneça aos usuários uma maneira clara de relatar uma sugestão insegura ou um contexto vazado.

Mapeamento de controles para estágios do agente

As revisões de segurança são mais fáceis quando seguem o ciclo do agente. Na entrada, verifique a identidade, a finalidade e os dados permitidos. Durante a recuperação, aplique as permissões e associe a proveniência. Durante o raciocínio, restrinja o esquema de saída e marque a incerteza. Antes de uma chamada de ferramenta, valide os argumentos e os efeitos colaterais. Após a chamada, verifique o resultado e registre a transição. Antes da conclusão, solicite o revisor apropriado e persista o status final. Esse mapeamento estágio por estágio impede que as equipes tratem a segurança como um único ponto de entrada em torno de um agente que, de outra forma, seria irrestrito.

Risco da cadeia de suprimentos e do conector

A capacidade efetiva de um agente inclui seu SDK, plugins, servidores MCP, extensões de navegador, modelos de prompt e escopos de conector. Inventarie essas dependências e revise as atualizações antes que cheguem à produção. Fixe as versões sempre que possível, assine ou verifique os pacotes e mantenha as credenciais de teste separadas dos dados do cliente. Um conector capaz de ler uma unidade inteira pode criar mais vulnerabilidades do que o próprio fabricante do modelo, mesmo quando o modelo em si está configurado corretamente.

O que uma análise de segurança útil contém?

Registre o fluxo de trabalho pretendido, a classificação de dados, as identidades, as ferramentas, as versões do modelo e do SDK, os cenários de ameaça, os controles, os casos de teste, os riscos não resolvidos e o responsável. Inclua um exemplo de uma ação bloqueada e um exemplo de uma escalação segura. Reavalie a análise quando um novo conector, ferramenta, modelo ou nível de autonomia for introduzido; a aprovação anterior não deve encobrir silenciosamente uma superfície de ação materialmente diferente.

Privilégio mínimo na prática

Forneça a um agente apenas as fontes e ferramentas necessárias para a tarefa atual. Separe as credenciais de leitura e gravação. Defina o escopo dos arquivos por projeto e identidade, restrinja os destinos de rede e expire o acesso temporário. Teste o limite de permissão com um usuário que não deve ter acesso à fonte.

Contrato de chamada de ferramenta

{
  "tool": "create_draft_task",
  "arguments": {"title": "...", "owner": "...", "due_date": "..."},
  "requires_approval": true,
  "idempotency_key": "project-123:brief-v2"
}

Valide os tipos, os valores permitidos, a identidade e os efeitos colaterais no código do aplicativo. Exija confirmação para envio, exclusão, compra, alteração de acesso ou publicação. Garanta a segurança das novas tentativas com chaves de idempotência.

Recuperação e injeção de prompts

Trate documentos, páginas da web, e-mails e resultados de ferramentas como dados não confiáveis. Delimite-os das instruções do sistema, preserve os identificadores de origem e impeça que o texto recuperado altere as permissões ou a política da ferramenta. Quando as fontes entrarem em conflito ou a recuperação estiver vazia, retorne um estado de escalonamento em vez de tentar adivinhar.

Avaliação e resposta a incidentes

Teste casos normais, incompletos, adversários, entre locatários, sensíveis e de falha de ferramentas. Monitore ações bloqueadas, sugestões inseguras, tentativas de exposição de dados, erros de ferramentas e correções de revisores. Mantenha um caminho de reversão e um responsável que receba os incidentes.

Perguntas frequentes

Um agente de IA pode ser totalmente autônomo?

Autonomia é uma configuração de produto limitada, não uma propriedade de segurança. Quanto mais consequente a ação, mais fortes devem ser os controles de aprovação, monitoramento e reversão.

Um modelo privado resolve a segurança do agente?

Não. Um modelo privado pode alterar o risco do fluxo de dados, mas a identidade, a recuperação, as permissões das ferramentas, o isolamento em tempo de execução, o registro em log e a revisão humana ainda são importantes.

O que as equipes devem proteger primeiro?

Comece com a identidade, as permissões de recuperação e os limites de gravação das ferramentas. Um fluxo de trabalho somente leitura com rastros claros é uma implementação inicial mais segura do que um amplo acesso autônomo.

Para obter informações sobre a estrutura do sistema, consulte Arquitetura do agente de IA; para obter detalhes de implementação, compare com Guia Claude Agent SDK.