Como colocar um agente de IA em produção com segurança

O que muda quando o agente age em vez de só responder

Muda a natureza do risco: um agente que só responde expõe informação; um agente que executa ferramentas assume privilégios e pode causar dano real. Enquanto o agente apenas gera texto, o pior caso é vazar um dado que ele não deveria mostrar. No momento em que ele ganha ferramentas para agir sobre o mundo — chamar uma API, alterar um registro, enviar uma mensagem —, ele deixa de ser "conteúdo" e passa a ser um ator dentro da empresa. Essa fronteira é o que este artigo trata.

Do chatbot ao agente autônomo

A diferença entre um chatbot e um agente autônomo é a capacidade de executar ações, não apenas de conversar. Um chatbot recebe uma pergunta e devolve uma resposta em texto; ele não toca em nenhum sistema. Um agente autônomo recebe um objetivo, decide quais passos dar e usa ferramentas para cumpri-los — pode consultar um banco, abrir um ticket, mandar um e-mail ou disparar um fluxo, muitas vezes encadeando vários passos sem intervenção humana entre eles. É essa autonomia com acesso a ferramentas que cria a superfície de risco nova.

Por que o agente deve ser tratado como identidade privilegiada

Porque, a partir do momento em que age, ele opera com credenciais e permissões — exatamente como um usuário. Se um funcionário que pode alterar registros no ERP é tratado com controle de acesso, log e revisão de privilégio, um agente com o mesmo poder merece o mesmo tratamento. A diferença é que o agente atua em velocidade de máquina e pode ser manipulado por conteúdo que ele lê, o que torna o controle de identidade e de privilégio ainda mais crítico do que para uma pessoa. Colocá-lo em produção também muda a régua: um piloto tolera acesso amplo em ambiente isolado, mas produção exige escopo mínimo, identidade rastreável e um plano para o dia em que o agente se comportar de forma inesperada. A pergunta que separa os dois é direta — se este agente fizer a coisa errada agora, qual é o estrago e como eu contenho?

Prompt injection: o risco número um, de forma defensiva

Prompt injection é a manipulação de um agente por meio de instruções escondidas no conteúdo que ele processa — e é apontada de forma crescente como a principal categoria de falha de segurança em aplicações com modelos de linguagem. A causa é arquitetural: o modelo recebe as instruções do desenvolvedor e os dados do mundo (um e-mail, uma página, um documento, o resultado de uma ferramenta) pelo mesmo canal de texto, e não distingue com segurança uma coisa da outra. O projeto OWASP Top 10 for LLM Applications coloca a injeção de prompt no topo dos riscos dessa classe de aplicação^[1]. Aqui o tema é tratado para prevenir e conter — nunca para executar.

Injeção direta e injeção indireta

São duas formas do mesmo problema: a direta vem do usuário, a indireta vem do conteúdo que o agente lê. Na injeção direta, alguém que interage com o agente tenta sobrescrever suas instruções ("ignore o que mandaram antes e faça isto"). Na injeção indireta, a instrução maliciosa está embutida em um dado que o agente vai processar de forma legítima — o corpo de um e-mail que ele resume, uma página que ele consulta, um documento anexado. A indireta é mais perigosa porque o gatilho não parte de quem conversa com o agente, e sim de qualquer conteúdo que entre no seu contexto^[2].

Por que não existe "fix" único

Porque a raiz é a mistura de instrução e dado no mesmo canal, e nenhum filtro elimina isso por completo. Um modelo mais novo, um prompt de sistema mais firme ou um bloqueio de palavras reduzem a frequência, mas não zeram o risco — sempre há uma formulação nova que passa. Por isso o padrão de mercado é tratar prompt injection como risco residual permanente: não se resolve, contém-se. O prompt de sistema orienta o comportamento, mas nunca deve ser confiado como barreira de segurança.

Contenção por camadas, não por barreira única

A defesa eficaz é empilhar controles independentes, de modo que a falha de um não abra tudo. As camadas que sustentam a contenção são as mesmas que estruturam o resto deste artigo: menor privilégio de ferramentas (o agente não consegue fazer o que não tem permissão de fazer), aprovação humana para ações sensíveis (a injeção não dispara sozinha uma transferência), validação da saída antes de agir sobre ela e auditoria de cada ação (se algo passar, dá para investigar). Nenhuma camada isolada basta; juntas, transformam uma injeção bem-sucedida em um incidente contido em vez de um dano completo.

Memory poisoning: quando o contexto de ontem dispara a ação de amanhã

Memory poisoning é o envenenamento da memória persistente de um agente — um dado inserido hoje que altera uma decisão futura. Quando o agente guarda contexto entre sessões (preferências, fatos aprendidos, histórico), esse armazenamento vira um novo alvo: um conteúdo malicioso gravado agora pode disparar uma ação indevida horas ou dias depois, quando o agente reler a memória como se fosse verdade estabelecida. É a versão diferida da injeção de prompt — o ataque não precisa estar presente no momento da ação, basta ter sido plantado antes.

Como a memória vira vetor e como conter

A memória vira vetor quando o agente a trata como fonte confiável de instrução: se qualquer entrada — resumo de conversa, resultado de ferramenta, dado externo — é gravada sem checagem e depois relida como contexto autoritativo, uma instrução maliciosa persistida ali passa a influenciar decisões sem novo gatilho visível. A contenção tem três frentes: validar o que entra (checar e sanitizar antes de persistir, em vez de gravar cru tudo que passa), isolar por escopo (separar memória por usuário e por tarefa, para que um contexto envenenado não contamine outros) e nunca confiar na memória como comando — o que está guardado informa, mas não deve ter autoridade para acionar ações sensíveis sem passar pelas mesmas camadas de aprovação e privilégio das demais entradas.

Menor privilégio de ferramentas e dados

O agente deve receber apenas as ferramentas e os dados estritamente necessários para a tarefa — nada além. É o princípio de menor privilégio aplicado a uma identidade não-humana: sem ferramenta de escrita quando basta leitura, sem acesso ao banco inteiro quando basta uma consulta, sem alcance a sistemas que não fazem parte do caso de uso. O escopo se define por necessidade da tarefa, não por conveniência de implementação.

Escopo por caso de uso, não por conveniência

Cada agente deve ter um catálogo explícito de ferramentas ligado ao seu propósito, e nada mais. Um agente que responde dúvidas sobre pedidos precisa consultar o status do pedido — não precisa cancelar pedidos, emitir reembolsos nem acessar dados de folha de pagamento. Dar "acesso amplo para o agente funcionar" é o atalho que transforma uma injeção bem-sucedida em dano grande: quanto menor o conjunto de ações possíveis, menor o teto de estrago quando algo dá errado.

Leitura versus escrita: a fronteira que mais importa

A separação entre ler e alterar é a decisão de privilégio de maior impacto. Um agente só de leitura, mesmo comprometido, expõe informação — grave, mas contornável. Um agente com escrita pode mudar o estado do mundo: apagar, transferir, enviar, permissionar. Sempre que a tarefa admitir, mantenha o agente em leitura e sugestão, deixando a execução da ação para um passo controlado. A escrita só entra quando é indispensável, e mesmo assim cercada de aprovação e limite.

Como o privilégio se calibra por porte

Human-in-the-loop: quais ações exigem aprovação

Human-in-the-loop é a inserção de uma aprovação humana obrigatória entre a decisão do agente e a execução de ações sensíveis. A regra prática é direta: ação de leitura não exige aprovação; ação que muda o mundo, sim. O ponto não é revisar tudo o que o agente faz — isso anularia o ganho de automação —, e sim definir com clareza as classes de ação que nunca devem ser executadas sem um humano confirmando.

As classes de ação que pedem um humano

Devem exigir aprovação as ações irreversíveis ou de alto impacto. Na prática, isso inclui: o que apaga ou altera dados de forma permanente, o que gasta dinheiro ou movimenta valores, o que envia mensagem para fora da empresa (e-mail a cliente, post público), o que altera permissões ou acessos, e o que dispara um efeito difícil de desfazer. Consultar, resumir, sugerir e rascunhar são ações de baixo risco que podem seguir sem aprovação; enviar, pagar, apagar e permissionar são as que pedem confirmação. E a aprovação precisa ser informada e rastreável, não um clique automático: quem aprova deve ver o que o agente pretende fazer, com quais parâmetros e por quê, com o registro guardado junto da ação. Uma aprovação que vira carimbo por excesso de volume deixa de ser controle — por isso calibrar bem as classes que exigem humano é o que garante atenção nas que realmente importam.

Como o human-in-the-loop varia por porte

Identidade, credenciais e auditoria de cada agente

Cada agente precisa de identidade própria, credencial de curta duração e trilha de auditoria de cada ação — os três alicerces que tornam um agente contível e rastreável. Sem identidade própria, não dá para saber quem fez o quê. Sem credencial efêmera, um vazamento vira acesso permanente. Sem auditoria, não há investigação possível depois de um incidente. Esses controles são também os que mais sobrevivem à troca de modelo: independem de qual ferramenta de IA está em uso.

Identidade de máquina por agente, nunca credencial de pessoa

Cada agente deve ter seu próprio service account, com credencial dedicada e de curta duração — jamais a credencial de um funcionário nem uma chave estática compartilhada entre vários. Reaproveitar a credencial de uma pessoa mistura as ações do agente com as dela e destrói a rastreabilidade; uma chave estática compartilhada faz de qualquer vazamento um problema de todos os agentes de uma vez. A prática de gerir agentes como identidades não-humanas, com credenciais efêmeras e menor privilégio, é o que permite conter e rastrear um agente comprometido. Vale tratar isso como problema de IAM desde o primeiro agente em produção: a gestão de identidade de máquina para agentes é reconhecida de forma crescente como um ponto fraco, e pesquisa da Strata sobre identidade agêntica aponta uma lacuna de governança — as organizações adotam agentes mais rápido do que estruturam a identidade e o controle de acesso deles, e uma parcela relevante não confia que seu IAM atual lida com identidades de agentes^[3].

Logar cada ação: quem, o quê, quando e com qual credencial

A auditoria útil registra a ação inteira, não só o resultado. Para cada passo do agente, o log deve guardar a entrada recebida, a decisão tomada, a ferramenta chamada, os parâmetros e o resultado — associados ao agente específico (qual identidade), ao momento e à credencial usada. É esse registro que permite reconstruir o que aconteceu quando algo dá errado. Em ambientes maiores, a trilha ganha imutabilidade e correlação com o SIEM, com retenção e alerta; em ambientes menores, o log do próprio SaaS já é o ponto de partida — desde que exista e seja consultável.

Kill switch: desligar o agente na hora

Todo agente em produção precisa de um modo de ser desligado imediatamente. Se um agente começa a se comportar de forma anômala — encadeando ações estranhas, respondendo a uma injeção, agindo fora do escopo —, tem que existir um botão que corte seu acesso e pare a execução na hora, sem depender de reimplantar nada. A ausência de kill switch é um erro comum e caro: sem ele, conter um agente comprometido vira uma operação lenta justamente quando a velocidade importa.

Testar antes de produção e a cada mudança

Antes de liberar um agente, rode contra ele os casos de abuso conhecidos — e repita a cada troca de modelo ou de prompt, porque o comportamento muda. Testar um agente não é só verificar se ele cumpre a tarefa feliz; é verificar como ele reage quando alguém tenta manipulá-lo. E como o comportamento de um agente depende do modelo e do prompt, qualquer alteração nesses dois exige repetir o teste: o que estava contido pode deixar de estar.

Que casos de abuso testar

Os cenários mínimos a exercitar são injeção direta, injeção indireta, tentativa de escalar privilégio e exfiltração via ferramenta. Isso significa: tentar sobrescrever as instruções pelo canal do usuário; esconder instruções em um conteúdo que o agente vai ler; verificar se o agente consegue acessar algo além do seu escopo; e checar se dá para fazê-lo vazar dados usando as ferramentas que tem. O objetivo é defensivo — mapear onde a contenção falha para reforçá-la, nunca produzir um roteiro de ataque. E como a segurança de um agente não é fixa (depende do modelo e do prompt em uso), cada troca de modelo ou de prompt deve disparar novo teste: um modelo novo pode responder de forma diferente a uma injeção que o anterior resistia, e um ajuste no prompt pode abrir uma brecha — retestar é o que evita que uma atualização de rotina reintroduza um risco já resolvido.

Erros comuns que anulam todo o resto

Alguns erros recorrentes derrubam a segurança mesmo quando os controles existem no papel. Os principais: dar acesso amplo "para o agente funcionar", reaproveitar credencial humana em vez de dar identidade própria, confiar no prompt de sistema como se fosse barreira de segurança, não ter kill switch para desligar o agente e tratar a saída do agente como confiável sem validar antes de agir sobre ela. Cada um deles transforma uma falha contida em um incidente completo — e todos são evitáveis com os controles descritos aqui.