Segurança de agentes de IA: limite o impacto de um erro

Revisado em 4 de setembro de 2026.

Um agente que apenas prepara texto tem um perfil de risco diferente de outro que envia e-mails, altera pedidos ou executa código. Segurança começa nessa diferença, não em uma instrução mais enfática para o modelo se comportar.

Projete considerando que o modelo pode interpretar mal um pedido ou ser influenciado por conteúdo não confiável. O sistema ainda deve restringir o que acontece em seguida.

Desenhe os limites de confiança

Para cada processo, identifique o usuário, o ambiente do agente, as ferramentas, os serviços conectados e os dados que circulam entre eles. Depois, pergunte:

• Qual identidade é usada quando uma ferramenta executa?
• Quais registros essa identidade pode consultar ou alterar?
• Por onde texto externo entra no contexto?
• Quais ações afetam outra pessoa ou sistema?
• Que evidência permitiria reconstruir uma falha?

Use as respostas para definir controles. Um assistente que lê mensagens recebidas e pode enviar e-mails tem uma exposição diferente de uma busca interna somente para consulta.

Conteúdo consultado não é autorização

Prompt injection pode chegar pela entrada do usuário ou por documentos, sites e resultados de ferramentas. RAG e fine-tuning não eliminam esse risco. A OWASP recomenda medidas em camadas, incluindo privilégios limitados e aprovação para operações de alto risco. Veja a orientação da OWASP sobre prompt injection.

Como teste ilustrativo, coloque em um documento de teste uma instrução inofensiva pedindo ao assistente uma ação fora de sua tarefa. O resultado esperado não é só uma recusa educada. Verifique que a ferramenta conectada negaria a ação mesmo se o modelo tentasse executá-la.

Instruções e filtros de conteúdo podem orientar o comportamento. Não substituem verificações de acesso em código executável.

Restrinja as ações disponíveis

Dê a um agente de relatórios acesso ao conjunto de dados necessário, não uma credencial de administrador. Separe ferramentas de consulta das de escrita e use autorização distinta para publicar, excluir ou enviar.

Confira, no momento da execução, o acesso do usuário autenticado ao alvo específico. Não confie em um identificador de cliente, papel ou sinalizador de aprovação só porque aparece nos argumentos gerados pelo modelo.

A OWASP aponta excesso de funcionalidades, permissões e autonomia como fatores de agência excessiva. Suas orientações incluem limitar as operações disponíveis e aplicar autorização nos sistemas de destino. Veja a orientação sobre agência excessiva.

Faça a aprovação ter significado

Para uma ação com consequências, mostre ao revisor o alvo real e a mudança proposta. “Permitir que o agente continue” é mais fraco do que “Enviar esta mensagem a estes destinatários”.

Vincule a aprovação àquela ação. Se destinatário, valor, conteúdo ou escopo mudar, exija nova decisão. Uma aprovação anterior não deve virar permissão irrestrita para o restante da conversa.

Confira também se as condições continuam válidas. O estado de um pedido pode mudar entre a proposta e a execução. O serviço deve rejeitar uma ação cujas premissas já não sejam verdadeiras.

Proteja execução e observação

Mantenha segredos fora dos prompts, das respostas de ferramentas e dos logs comuns. Restrinja acesso a arquivos e saídas de rede conforme a tarefa. Se houver execução de código, revise o isolamento real em vez de assumir que a palavra “sandbox” comprova a proteção.

Em integrações MCP remotas, valide credenciais para o serviço correto e siga seus requisitos de autorização. A orientação de segurança do MCP alerta contra aceitar e encaminhar tokens sem validar adequadamente o destinatário. Leia a orientação de segurança do MCP.

Registros de auditoria devem mostrar quem solicitou uma ação, o que foi autorizado e o que aconteceu. Oculte conteúdo sensível, restrinja acesso à auditoria e defina por quanto tempo os registros serão mantidos.

Teste falhas, não apenas o caminho ideal

Antes de habilitar uma ação, exercite ao menos estes casos em um ambiente controlado:

1. Uma solicitação válida aponta para o registro de outro cliente.
2. Um documento consultado pede uma ação não autorizada.
3. Uma aprovação é reutilizada com outro alvo.
4. Ocorre um timeout depois de o serviço aceitar a mudança.
5. Uma repetição pode duplicar um efeito externo.
6. Uma nova chamada acontece depois da revogação de permissão.

Verifique o estado do serviço e a auditoria, não apenas a explicação do agente.

Por fim, defina como interromper uma execução, revogar acesso, identificar registros afetados e recuperar o que for possível. Aumente a autonomia com base em controles demonstrados e nas consequências de uma falha — não só porque o piloto passou algumas semanas sem incidentes aparentes.

Para as escolhas de arquitetura ao redor desses controles, leia nosso guia de arquitetura de agentes.