Antes de confiar em agentes de segurança de IA, teste-os e governe-os

A IA agêntica torna-se uma nova superfície de ataque

Um artigo recente, "Penetration Testing of Agentic AI", torna essa mudança explícita. Os autores testaram cinco modelos — Claude 3.5 Sonnet, Gemini 2.5 Flash, GPT-4o, Grok 2 e Nova Pro — em dois frameworks de agentes: AutoGen e CrewAI. O ambiente de teste foi um sistema de gestão de informações universitárias com sete agentes para aconselhamento, finanças, matrícula, serviços de carreira, suporte ao estudante e informações do campus. Os ataques incluíram injeção de prompt, SSRF, uso indevido de ferramentas, execução de código, injeção de SQL e escalação de privilégios. Em outras palavras, o estudo não testou apenas se um modelo conseguia responder com segurança no chat; testou como um agente que utiliza ferramentas se comportava quando instruções maliciosas tentavam direcionar suas ações.

Uma métrica útil no artigo é a taxa de recusa: a proporção de solicitações maliciosas que o agente recusou ou bloqueou em vez de executá-las. O AutoGen apresentou uma taxa de recusa de 52,3%, enquanto o CrewAI apresentou 30,8%; a variação de recusa ao nível do modelo foi mais estreita, indo de 46,2% do Nova Pro a 38,5% do Claude e do Grok 2. Essa comparação aponta para uma lição prática: o framework pode mudar a forma como o mesmo tipo de agente responde ao risco. Na IA agêntica, o comportamento de segurança significa mais do que a resposta final. Ele inclui se o sistema delega uma tarefa, invoca uma ferramenta, expõe dados, rejeita a solicitação, fabrica saídas, registra a tentativa ou permite que a solicitação prossiga.

Os autores também identificam a "conformidade alucinada": casos em que um agente parece seguir uma solicitação, mas fabrica o resultado em vez de recusar claramente ou realmente executar a ação solicitada. Esse comportamento é arriscado porque pode criar uma trilha de auditoria falsa. Um painel pode registrar "tarefa concluída" mesmo que nenhuma ferramenta tenha realmente produzido a saída alegada, e uma resposta em linguagem natural pode parecer plausível mesmo que não reflita o que aconteceu no ambiente. Os logs dos agentes, portanto, precisam mostrar mais do que a resposta final. Eles devem preservar prompts, chamadas de ferramentas, permissões, erros, saídas e as evidências por trás da conclusão.

Outro exemplo envolveu um agente escrevendo código e tentando executá-lo contra um endpoint de metadados na nuvem. A tentativa falhou devido ao ambiente de teste controlado, e não porque o modelo se recusou. A lição não exige detalhes operacionais: em sistemas agênticos, o contexto de implantação pode determinar se um comportamento inseguro permanece contido ou escala para um incidente. O acesso a ferramentas, permissões de rede, proteções de nuvem, limites de identidade e isolamento de tempo de execução fazem parte da postura de segurança do agente.

O paralelo com o pentesting com IA é direto. A armação define como o modelo planeja, lembra e usa as ferramentas. Na segurança de IA agêntica, o mesmo sistema circundante também define quais ferramentas são expostas, como os agentes se comunicam entre si, onde os limites de dados são desenhados e como o comportamento inseguro é bloqueado ou registrado. Os controles tradicionais de AppSec ainda se aplicam: menor privilégio, validação de parâmetros, restrições de rede, containerização, portões de aprovação e registros rastreáveis tornam-se mais valiosos quando um modelo pode agir por meio deles.

O red teaming de IA também está se tornando agêntico

Em outro artigo, "Redefining AI Red Teaming in the Agentic Era", os autores focam em como as equipes testam sistemas de IA para comportamentos inseguros, que violam políticas ou que são prejudiciais de outra forma. Eles argumentam que muitos fluxos de trabalho atuais de red team continuam centrados em bibliotecas: os operadores selecionam ataques, aplicam transformações de prompt, configuram avaliadores, inspecionam rastros e montam relatórios manualmente. O fluxo de trabalho agêntico proposto permite que os operadores descrevam o objetivo do teste em linguagem natural, e o agente seleciona os ataques, compõe as transformações, executa o fluxo de trabalho e reporta os achados.

O framework integra mais de 45 ataques adversariais, 450 transformações de prompts e 130 avaliadores. Em um estudo de caso com Llama Scout, os autores testaram 68 objetivos adversariais pela interface de terminal da Dreadnode, sem que o operador escrevesse código. Eles reportam 674 ataques, 7.727 testes, 573 achados e uma taxa de sucesso de ataque de 85%, incluindo 401 jailbreaks completos e 232 achados críticos.

Esses resultados devem ser lidos com cautela. Um único estudo de caso não deve ser generalizado a todos os modelos, implantações ou objetivos de red team, e os prompts adversários específicos usados no estudo não precisam ser reproduzidos aqui. O ponto útil é operacional: o red teaming de IA está se tornando um problema de fluxo de trabalho, e não apenas uma questão de design de prompts.

O artigo também mostra como os resultados de red team podem ser organizados para acompanhamento. As descobertas são mapeadas para frameworks de segurança e IA conhecidos, incluindo OWASP LLM Top 10, MITRE ATLAS, NIST AI RMF e Google SAIF, e o sistema pode exportar tanto relatórios executivos quanto dados estruturados para revisão técnica. A lição mais ampla é que o teste de segurança agêntico precisa de artefatos que as pessoas possam inspecionar, comparar, priorizar e agir sobre eles. Isso se aplica ao red teaming de IA, pentesting com IA, revisão de código e fluxos de trabalho de remediação.

A pesquisa de IA ofensiva precisa de governança, não de silêncio

Zhuo e colegas apresentam um argumento estratégico: os agentes de IA podem mudar a economia dos atacantes ao tornar a descoberta e a exploração de vulnerabilidades mais baratas de serem repetidas em muitos alvos. Se um atacante puder automatizar o reconhecimento, os testes e o desenvolvimento de exploits, cada alvo adicional poderá exigir menos esforço humano do que hoje.

Os autores argumentam que as salvaguardas ao nível do modelo não são suficientes por si só. A filtragem de dados, o alinhamento e as barreiras de proteção de saída podem moldar o comportamento dos modelos comerciais, mas não impedem que adversários executem modelos de pesos abertos, os modifiquem ou construam sistemas ofensivos fora de plataformas gerenciadas. A resposta proposta por eles é o desenvolvimento defensivo controlado: benchmarks que cobrem todo o ciclo de vida do ataque, agentes mais fortes para descobrir vulnerabilidades no mundo real e uma governança que mantenha os agentes ofensivos dentro de ambientes virtuais cibernéticos (cyber ranges) auditados, enquanto extrai capacidades defensivas para uso mais amplo.

O argumento é complexo, mas merece atenção. Evitar a pesquisa de IA ofensiva não impedirá que os atacantes experimentem com a IA, enquanto publicar capacidades sem salvaguardas pode aumentar o risco. O trabalho responsável nesta área exige ambientes delimitados, logs de auditoria, controles de acesso, aprovações humanas, lançamentos em etapas, divulgação responsável e limites claros sobre o que é compartilhado.

ExploitGym ilustra essa mesma tensão sob a perspectiva de medição. O benchmark testa se os agentes conseguem transformar gatilhos de vulnerabilidade em exploits funcionais em 898 instâncias, incluindo softwares de espaço de usuário, o motor JavaScript V8 do Google e tarefas do kernel do Linux. Seus resultados mostram que os agentes de fronteira conseguem demonstrar capacidade significativa de geração de exploits sob condições de pesquisa de acesso confiável, onde as salvaguardas são relaxadas para estudar os limites da capacidade, mas também que as salvaguardas em tempo de implantação podem bloquear tentativas sob prompts padrão.

Esse contraste é central para a governança. O comportamento de um agente de segurança de IA depende do modelo, das ferramentas ao redor, da política de acesso e dos controles de segurança em vigor no tempo de execução. Portanto, uma discussão séria sobre a capacidade cibernética da IA precisa especificar tanto o que o sistema pode fazer em condições de pesquisa quanto o que tem permissão para fazer em produção.

A ética deve escalar junto com a capacidade

Happe e Cito revisaram 16 artigos que cobrem 15 protótipos de segurança ofensiva baseados em LLM. A pesquisa deles aponta que 13 dos 15 protótipos revisados, ou 86,6%, mencionam considerações éticas. Também relata que 10 dos 15 artigos disponibilizaram o código-fonte ou artefatos, enquanto três dos cinco que não liberaram artefatos ainda assim incluíram exemplos de prompts.

Esses números mostram uma tensão não resolvida no campo. A pesquisa precisa de transparência suficiente para que outros possam inspecionar as alegações, reproduzir os resultados e aprender com as falhas. Mas artefatos ofensivos — códigos, prompts, conjuntos de dados, integrações de ferramentas ou rastreamentos de execução — também podem reduzir a barreira para o uso indevido, especialmente quando o sistema consegue planejar, chamar ferramentas ou gerar etapas de exploração. Os autores, portanto, defendem que as declarações de ética devem abordar a motivação, o impacto potencial, a consistência com a capacidade demonstrada, as mitigações, as orientações de monitoramento e as expectativas de divulgação responsável.

Um disclaimer genérico não é suficiente. O enquadramento ético deve corresponder à capacidade descrita. Um agente de CTF limitado, um sistema de auditoria de código-fonte, um gerador de payloads e um benchmark de desenvolvimento de exploits não carregam o mesmo nível de risco. Suas escolhas de publicação, liberações de artefatos e controles de acesso também devem diferir.

Uma revisão prática pode começar com algumas perguntas:

A mesma lógica de revisão se aplica à pesquisa, às afirmações de fornecedores e a equipes internas de segurança que constroem ferramentas agênticas. A ética não deve ser tratada como um parágrafo adicionado depois do trabalho técnico; ela deve moldar o que é testado, o que é registrado, o que é publicado e quem pode usar o sistema.

Alegações de mercado levantam perguntas de governança

As movimentações do mercado agora contextualizam essas questões de governança de forma prática. Anúncios e projetos recentes descrevem pentests autônomos, testes ofensivos contínuos, agentes conscientes de código-fonte, validação orientada a provas, orientação para remediação e testes executáveis novamente: veja exemplos de um provedor de nuvem, de um mercado de AppSec, de um repositório de pentest de IA de código aberto e de um produto de pentest de IA.

O ponto aqui não é validar essas afirmações. É que fluxos de trabalho de segurança agêntica estão passando de artigos de pesquisa para produtos, repositórios e roadmaps de fornecedores. Uma vez que isso ocorre, a governança passa a fazer parte da adoção: quem pode executar o agente, em quais sistemas ele pode tocar, quais ações exigem aprovação, como as evidências são registradas e como as descobertas são encaminhadas para a remediação.

Os modelos de acesso precisam da mesma disciplina. Equipes de AppSec internas, pentesters externos, equipes de resposta a incidentes, pesquisadores e desenvolvedores não precisam de permissões idênticas. Alguns agentes podem apenas ler código; outros podem executar scanners; outros podem executar ataques de prova de conceito em ambientes de homologação (staging); e um subconjunto menor pode tocar em ambientes semelhantes aos de produção sob um escopo explicitamente definido por escrito. Cada nível necessita de registros, aprovações e uma regra clara para interrupção.

Um modelo de acesso razoável poderia ser o seguinte:

Esse nivelamento ajuda as equipes a associar agentes a trabalhos. Um assistente de revisão de código, um agente de pentesting em staging e um benchmark de geração de exploits não devem compartilhar as mesmas permissões, pois não representam o mesmo nível de risco operacional ou legal.

O que as equipes devem perguntar antes da adoção

Antes de adotar um agente de segurança de IA, as equipes de engenharia devem entender o seu ambiente operacional. As perguntas básicas são práticas: quais dados ele pode ler, quais ferramentas pode invocar, se pode alterar o estado do sistema, se pode enviar requisições externas e se a execução é isolada (sandboxed). As equipes também devem saber se os prompts, conclusões, comandos, saídas de ferramentas e descobertas finais são registrados de forma que permita auditoria.

A camada seguinte é a validação. As descobertas não devem depender apenas da narrativa do modelo. As equipes precisam entender como o sistema confirma a explorabilidade, lida com falsos positivos, remove duplicatas e responde quando o agente falha, entra em loop, fabrica saídas ou é influenciado por conteúdo malicioso dentro de um repositório, tíquete, página web ou documento. Essas perguntas definem o design de segurança do agente.

Os executivos não precisam inspecionar cada prompt ou loop, mas devem saber se a organização consegue governar o fluxo de trabalho. As perguntas úteis são se a ferramenta detecta vulnerabilidades válidas ou produz alertas plausíveis; se ações de grande impacto exigem aprovação; se os resultados são auditados; se a confiabilidade de execuções repetidas é medida; se a ferramenta reduz o tempo de remediação; e se há um processo de divulgação para problemas encontrados em softwares de terceiros ou de código aberto.

O teste operacional é saber se a organização tem capacidade para absorver os resultados do agente. Uma descoberta mais rápida só ajuda se a validação, a priorização e a remediação conseguirem acompanhar o ritmo. Do contrário, a IA apenas transfere o gargalo de um ponto para outro.

Um modelo de adoção responsável

Um modelo de adoção realista deve ser gradual. A primeira etapa é a assistência de apenas leitura: resumos, modelagem de ameaças, suporte à revisão de código, geração de casos de teste e redação de relatórios. Nesse nível, as principais preocupações são a exposição de dados, a qualidade das saídas e a necessidade de revisão humana.

A etapa seguinte é a execução controlada em ambientes locais ou de staging. Aqui, os agentes podem executar ferramentas, inspecionar descobertas conhecidas ou propor testes, mas devem operar em sandboxing, usar dados de teste e possuir listas de permissões de ferramentas e logs rastreáveis. Antes que as equipes comparem ferramentas ou expandam acessos, devem realizar testes repetidos e fazer validações ao nível das descobertas individuais para compreender a confiabilidade, os falsos positivos e os custos.

A prova por exploração deve vir em seguida e apenas sob autorização explícita. O ambiente deve utilizar dados descartáveis onde for possível, mecanismos de rollback, monitoramento e portões de aprovação para ações de rotina que possam afetar a disponibilidade, a integridade dos dados, os sistemas de terceiros ou os ativos de produção. Nesse nível, a organização não está mais testando apenas se o agente é utilizável; está testando se o fluxo de trabalho é passível de governança.

Para o red teaming de IA, a mesma lógica em etapas se aplica. Teste modelos e agentes sob objetivos definidos. Mantenha os prompts e as respostas adversárias de forma rastreável. Mapeie os achados para frameworks conhecidos quando isso ajudar na comunicação, mas não permita que as tags de conformidade substituam a revisão técnica. Armazene rastros estruturados para que as falhas possam ser estudadas, e não apenas contadas.

Para a pesquisa de IA ofensiva, os controles devem escalar com a capacidade demonstrada. Um artigo sobre capacidades deve explicar o ambiente, os limites, as salvaguardas, o plano de divulgação responsável e a justificativa para a liberação de artefatos. Se um sistema demonstrar capacidades de exploração mais fortes, sua seção de ética correspondente deve se tornar mais específica.

A lição que conecta tudo

A primeira postagem desta dupla argumentou que os agentes de pentest de IA tornam-se tecnicamente significativos quando os modelos são envolvidos em planejamento, memória, ferramentas e validadores. Esta publicação traz a outra metade: esses recursos criam sistemas que precisam ser guardados, testados e governados.

O futuro da IA no pentesting dependerá de mais do que a capacidade do modelo. Sistemas mais robustos produzirão evidências válidas, respeitarão o escopo delimitado, preservarão a capacidade de auditoria, conectarão descobertas à remediação e manterão os humanos como responsáveis pelas decisões de alta relevância.

Alcançar esse padrão é mais difícil do que entregar uma demonstração convincente ou uma resposta com tom de certeza, mas é o padrão de que as equipes de segurança precisam. Os sistemas agênticos devem conquistar a confiança por meio de trabalho que possa ser inspecionado, reproduzido e governado.