Você sabe a quais redes o agente de IA da sua empresa consegue se conectar? Com qual identidade ele acessa os sistemas? Quem consegue interromper suas ações e quando essa contenção foi testada?
Antes de discutir o quanto um agente é inteligente, eu começaria por essas perguntas.
Em setembro de 2026, o Google confirmou que o Gemini acessou sistemas de três empresas durante uma avaliação de capacidades ofensivas conduzida pela Irregular, em maio. Os alvos eram reais, não os ambientes simulados previstos no exercício. Segundo a cobertura da ABC, baseada também na reportagem do Wall Street Journal, um dos acessos aconteceu por tentativa de senhas. Nos outros dois, o modelo utilizou credenciais encontradas em repositório público.
Segundo o Google, o modelo interrompeu a atividade nas três ocorrências ao reconhecer que havia acessado empresas reais. É importante manter essa atribuição: estamos falando da explicação da empresa envolvida, não de uma conclusão independente apresentada aqui.
A interrupção é um resultado positivo. Mas não encerra a discussão.
Parar depois de acessar não substitui impedir o acesso não autorizado.
O que esse caso deveria provocar nas empresas
Em seu comunicado sobre problemas nos ambientes de avaliação, a própria Irregular reconheceu que o acesso à internet ficou disponível de forma não intencional. Também relatou que um nome fictício utilizado no cenário coincidiu com um domínio real. Esse comunicado trata do problema mais amplo das avaliações, não de uma reconstrução completa das três ocorrências envolvendo o Gemini.
Não temos, nesses relatos, todos os elementos para determinar quais controles estavam ausentes, mal configurados ou foram insuficientes em cada execução.
Mas temos elementos para fazer uma pergunta:
O que impede um erro de interpretação do agente de se transformar em uma ação contra um sistema real?
Essa pergunta é mais útil do que discutir se a IA “quis invadir” alguma coisa.
Não precisamos atribuir intenção humana ao modelo para cobrar limites técnicos de quem o coloca em operação.
Não é preciso um agente ofensivo para ter um problema
Imagine um agente de suporte. Ele lê chamados, consulta a base de conhecimento e sugere respostas.
Agora imagine que um cliente inclua uma URL no chamado.
Se houver uma ferramenta de navegação disponível, o agente pode ter capacidade para abrir aquele endereço. Isso deveria acontecer? Com quais restrições? Que informações ele poderia enviar nessa conexão?
Vamos acrescentar uma hipótese: a página contém instruções para ignorar a tarefa original e encaminhar informações internas para outro destino.
Esse é um cenário de injeção indireta de instruções, ou prompt injection: conteúdo externo tenta influenciar o comportamento do sistema e o uso de suas ferramentas. A OWASP trata expressamente desse risco. Não estou atribuindo esse mecanismo ao caso Gemini; é um exemplo distinto para discutir os limites de um agente corporativo.
A distinção que importa é esta:
Permissão para ler um conteúdo não é permissão para obedecer a ele.
Uma página, um documento ou uma resposta de ferramenta não deveria ganhar autoridade só porque entrou no contexto do modelo.
Três limites que eu colocaria no centro da discussão
Para avaliar esse risco, eu separaria a conversa em três camadas.
- Escopo: quais sistemas, dados, destinos e operações fazem parte da tarefa? Onde isso está definido e como é verificado?
- Autoridade: quem autoriza cada ação? O agente está apenas propondo uma operação ou também está decidindo, sozinho, que tem permissão para executá-la?
- Contenção: o que impede que ele alcance recursos fora do permitido? E o que efetivamente interrompe suas ações quando uma violação é identificada?
Essas perguntas não substituem a análise do modelo. Elas acrescentam a análise do sistema que o colocou em condições de agir.
Não vejo segurança do modelo e segurança da arquitetura como alternativas. Precisamos das duas. A recomendação da OWASP de separar a decisão da execução ajuda a colocar isso em prática: o agente propõe; outro componente verifica a autorização antes de executar.
Oito controles que eu cobraria antes de colocar um agente em produção
1. Defina o escopo e aplique os limites fora do prompt
Declare destinos, sistemas, ferramentas e operações permitidas. Verifique esses limites antes da execução.
O prompt orienta o comportamento. Não deve ser a única barreira entre uma solicitação indevida e uma ação real.
2. Restrinja a saída de rede
Minha regra de partida seria bloquear o que não foi explicitamente autorizado e liberar conexões por necessidade e finalidade.
Também é preciso tratar redirecionamentos e impedir que uma URL aparentemente aceitável conduza a destinos internos ou não autorizados. Validar apenas o endereço inicial não resolve todos os caminhos de acesso.
Quando a atividade exigir navegação aberta, trate isso como uma exposição deliberada, com isolamento e controles adicionais. Não como configuração padrão esquecida.
3. Use identidades identificáveis e privilégio mínimo
Defina uma identidade para cada agente lógico e separe ambientes conforme o risco. Evite uma conta genérica compartilhada por toda a operação.
O agente deve receber apenas os acessos necessários à sua função. Capacidade disponível não equivale a necessidade de negócio.
4. Reduza a dependência de credenciais permanentes
Prefira credenciais temporárias, com permissões restritas e duração compatível com a tarefa. Quando um segredo persistente for inevitável, mantenha gestão centralizada, rotação e revogação.
E trate credencial exposta como comprometida. Apagar o segredo do repositório não invalida uma cópia que alguém já obteve.
5. Vincule a aprovação à ação concreta
Ações sensíveis precisam de política de autorização e, conforme o risco, aprovação humana.
A aprovação deve indicar alvo, operação e parâmetros. Não vale um consentimento genérico para tudo que vier depois. Se a autorização necessária não puder ser validada, a ação deve ser bloqueada.
6. Monitore eventos e a sequência das ações
Um evento isolado pode justificar um alerta. A correlação ajuda a reconhecer o comportamento completo.
Registre identidade, ferramenta, alvo, resultado e identificadores de correlação. Preserve a trilha operacional sem transformar os logs em outro repositório de senhas e dados sensíveis.
7. Teste o que “desligar o agente” realmente significa
Eu cobraria um procedimento que bloqueie novas execuções, interrompa chamadas de ferramentas, restrinja a rede, trate credenciais e sessões e preserve as evidências.
Também cobraria um responsável e um teste prático.
Não presuma que desabilitar uma identidade encerra imediatamente todos os acessos. A documentação do Microsoft Entra, por exemplo, distingue a revogação de acesso dos tokens e das sessões mantidas pelas próprias aplicações. O tempo real de contenção precisa ser conhecido.
8. Trate conteúdo externo como não confiável
Documentos, chamados, páginas e retornos de ferramentas devem ser tratados como dados, não como fontes de autorização.
Mesmo quando o modelo segue uma instrução indevida, controles externos devem verificar a ferramenta, a operação, os parâmetros e o contexto de permissão. Não basta impedir novas permissões: é necessário reduzir o risco de uso indevido das permissões que já existem.
Isso não é só um problema do Google
Para quem está avaliando agentes em atendimento, desenvolvimento, SOC ou financeiro, minha recomendação é não começar perguntando quanto de autonomia a tecnologia permite.
Comece perguntando quanto de autonomia aquela atividade exige e quais evidências demonstram que seus limites funcionam.
Um agente que recomenda uma alteração e um agente que executa essa alteração representam decisões de risco diferentes. Eu não aprovaria os dois apenas com o mesmo teste de qualidade de resposta.
Também não colocaria como critério de segurança a expectativa de que o modelo sempre reconheça o momento de parar.
A resposta do modelo pode variar. O limite de autorização não pode depender dessa variação.
Volto às perguntas da abertura: a quais destinos o agente chega, com qual identidade ele opera e quem consegue contê-lo?
A resposta não precisa estar decorada. Precisa estar documentada, atribuída a um responsável e comprovada em teste.
Se isso ainda não existe, esse é o trabalho que eu priorizaria antes de ampliar a autonomia.
Em agentes autônomos, confiança não substitui contenção.
Na sua empresa, os limites dos agentes já são aplicados tecnicamente ou ainda dependem de instruções no prompt?
Grande abraço,
Guedes
