# Segurança de agentes de IA: limite o impacto de um erro - Author: FMKTech Team - Published: 2025-11-07 - Reading time: 4 min - Tags: Segurança de IA, Permissões, Prompt Injection - URL: https://www.fmktech.com.br/pt-BR/blog/ai-agent-security-challenges.md (HTML: https://www.fmktech.com.br/pt-BR/blog/ai-agent-security-challenges) Um modelo de ameaças prático para agentes conectados ao negócio: limitar ferramentas, proteger dados, separar aprovações e testar controles fora do prompt. --- *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](https://genai.owasp.org/llmrisk/llm01-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](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/). ## 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](https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices). 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](/pt-BR/blog/understanding-ai-agents-architecture-and-patterns). --- ## Onde procurar depois - [Índice do blog](https://www.fmktech.com.br/pt-BR/blog.md) - [Homepage](https://www.fmktech.com.br/pt-BR.md) - [llms.txt](https://www.fmktech.com.br/llms.txt)