Pentest em Sistemas de IA

Pentest em Sistemas de IA: Prompt Injection e Agentes Autônomos Mudam as Regras da Cibersegurança. Pentest em sistemas de IA precisa ir além da infraestrutura: o novo desafio é testar o comportamento

A rápida adoção de Inteligência Artificial (IA), especialmente modelos de linguagem (LLMs), sistemas com Retrieval-Augmented Generation (RAG) e agentes capazes de executar ações por meio de ferramentas e APIs, está criando uma nova superfície de ataque que desafia os modelos tradicionais de teste de intrusão.

Um estudo publicado em julho de 2026 propõe uma mudança importante nesse conceito: em sistemas habilitados por IA, um ataque bem-sucedido não precisa necessariamente resultar na invasão de um servidor, roubo de credenciais ou obtenção de privilégios administrativos. O comprometimento pode ocorrer quando um atacante consegue influenciar o comportamento da IA a ponto de fazer o sistema violar um objetivo operacional para o qual foi projetado.

Essa abordagem amplia significativamente o conceito de Penetration Testing aplicado à Inteligência Artificial.

Do comprometimento da infraestrutura à manipulação do comportamento

O Penetration Testing tradicional procura demonstrar se vulnerabilidades podem ser exploradas para produzir consequências concretas, como:

• acesso não autorizado;
• escalada de privilégios;
• movimentação lateral;
• exposição ou exfiltração de dados;
• persistência;
• interrupção de serviços;
• comprometimento de aplicações ou infraestrutura.

Esses testes continuam absolutamente necessários em ambientes de IA. Afinal, aplicações baseadas em IA continuam dependendo de APIs, identidades, serviços em nuvem, containers, bancos de dados, pipelines, repositórios de modelos, sensores e cadeias de suprimentos de software.

O problema é que os modelos de IA introduzem uma camada adicional entre infraestrutura e resultado operacional.

Uma IA pode classificar eventos, priorizar alertas, recomendar decisões, consultar informações, gerar comandos ou executar ações utilizando ferramentas externas. Consequentemente, um atacante pode comprometer o resultado produzido pelo sistema sem necessariamente comprometer tecnicamente sua infraestrutura.

É justamente essa diferença que está levando pesquisadores a propor uma nova abordagem para o Penetration Testing.

Uma nova definição para Penetration Testing em IA

O estudo “Rethinking Penetration Testing for AI-Enabled Systems: From Resource Compromise to Behavioral Objective Violation”, publicado no arXiv em 15 de julho de 2026 por Mohammad Allahbakhsh, Mohammad Hassan Bahari e Moslem Attar Raouf, propõe uma mudança importante na maneira como o Penetration Testing deve ser compreendido quando aplicado a sistemas habilitados por Inteligência Artificial. Em vez de avaliar exclusivamente se um atacante consegue comprometer recursos tecnológicos, os pesquisadores propõem considerar também se ele consegue influenciar o comportamento da IA a ponto de provocar a violação de um objetivo operacional do sistema.

No Penetration Testing tradicional, a demonstração de comprometimento normalmente está associada à exploração de uma vulnerabilidade que permite acesso não autorizado, execução de código, escalada de privilégios, movimentação lateral, exposição de informações ou comprometimento de algum recurso. Em sistemas baseados em IA, entretanto, pode existir uma forma diferente de comprometimento: o adversário não precisa necessariamente controlar o recurso tecnológico se conseguir manipular a maneira como o sistema interpreta informações, toma decisões ou executa ações.

A lógica proposta pelos pesquisadores pode ser representada pela seguinte cadeia:

Influência adversária → comportamento governado pela IA → violação de objetivo operacional

Essa perspectiva modifica a pergunta central do teste. Além de verificar “o atacante consegue comprometer algum recurso tecnológico?”, torna-se necessário avaliar “o atacante consegue controlar ou manipular alguma informação que influencia a IA e, por meio dela, induzir uma decisão ou ação contrária aos objetivos que o sistema deveria preservar?”

Essa mudança amplia significativamente a superfície considerada durante uma avaliação de segurança. Prompts fornecidos diretamente pelo usuário são apenas uma das possíveis fontes de influência. Documentos recuperados por mecanismos de Retrieval-Augmented Generation (RAG), memória de agentes, páginas web, e-mails, resultados retornados por ferramentas e APIs, dados de treinamento, sensores e outras fontes externas também podem participar da construção do contexto utilizado pelo modelo. Se um adversário puder manipular alguma dessas fontes, poderá existir um caminho indireto para influenciar o comportamento do sistema.

Em outras palavras, o ponto central deixa de ser apenas onde o atacante consegue entrar e passa a incluir também o que o atacante consegue influenciar e quais consequências essa influência pode produzir.

Prompt Injection como vetor de influência sobre a IA

Um dos exemplos mais importantes dessa mudança é o Prompt Injection, técnica na qual entradas controladas por um adversário são estruturadas para influenciar ou alterar o comportamento esperado de um modelo de linguagem.

A dificuldade está na própria maneira como os LLMs processam informações. Em uma aplicação convencional, uma página web, um documento ou uma mensagem normalmente é tratada como dado a ser processado. Em aplicações baseadas em LLMs, entretanto, dados e instruções podem coexistir dentro do mesmo contexto apresentado ao modelo. Consequentemente, determinado conteúdo externo pode não ser interpretado apenas como informação, mas também influenciar a maneira como o modelo executa sua tarefa.

Esse problema amplia consideravelmente os possíveis vetores de ataque. Instruções adversárias podem estar presentes em páginas web, documentos, mensagens de e-mail, comentários de tickets, bases de conhecimento, registros de logs, respostas de ferramentas ou conteúdo recuperado por mecanismos RAG. O risco dependerá da arquitetura, de como essas informações são incorporadas ao contexto e, principalmente, das ações que o sistema está autorizado a realizar.

O cenário torna-se particularmente relevante no Indirect Prompt Injection. Nesse caso, o atacante não precisa interagir diretamente com o chatbot ou agente. Em vez disso, ele manipula uma fonte de informação que sabe — ou espera — que será posteriormente consultada pelo sistema de IA.

Imagine, por exemplo, um agente autorizado a pesquisar páginas web para coletar informações sobre determinado incidente. Um atacante poderia inserir conteúdo adversário em uma página sob seu controle. Quando o agente acessar essa página e incorporar seu conteúdo ao contexto do LLM, a instrução maliciosa poderá tentar interferir na tarefa original. Assim, estabelece-se uma cadeia indireta de influência:

Atacante → conteúdo externo manipulado → recuperação pela aplicação → contexto do LLM → alteração do comportamento → possível consequência operacional

O aspecto crítico é que o atacante pode influenciar a IA sem possuir acesso direto ao modelo, à aplicação ou à infraestrutura que os executa.

Um SOC baseado em IA ajuda a compreender o risco

O estudo utiliza um cenário particularmente relevante para profissionais de Segurança da Informação: um Security Operations Center (SOC) que utiliza um assistente baseado em IA para apoiar a investigação e resposta a incidentes.

Considere uma solução capaz de analisar alertas provenientes do SIEM, consultar fontes de Threat Intelligence, correlacionar informações, avaliar a severidade de incidentes, recomendar ações aos analistas e, dependendo do nível de autonomia concedido, acionar playbooks ou outras ferramentas utilizadas pelo SOC.

Nesse ambiente, um atacante externo pode não possuir qualquer acesso às credenciais dos analistas, ao SIEM, ao modelo de IA ou à infraestrutura interna. Ainda assim, pode controlar determinados artefatos que inevitavelmente serão observados durante uma investigação, como domínios, URLs, páginas web, mensagens de phishing, determinados campos de eventos ou outros conteúdos externos associados ao ataque.

É justamente nesse ponto que surge uma nova possibilidade de exploração. Se o conteúdo controlado pelo adversário for posteriormente coletado e incorporado ao contexto utilizado pelo assistente de IA, ele poderá funcionar como uma superfície de influência sobre o processo de análise.

Suponha que uma instrução adversária consiga interferir no comportamento do assistente e faça com que ele reduza indevidamente a severidade de um incidente, omita Indicadores de Comprometimento (IoCs), recomende o encerramento da investigação ou deixe de encaminhar o caso para validação humana. Nesse cenário, o atacante não precisou comprometer diretamente o SOC para interferir em seu funcionamento: ele explorou a maneira como o sistema de IA processa informações externas para tentar influenciar uma decisão operacional.

A cadeia de ataque poderia ser representada da seguinte maneira:

Conteúdo controlado pelo atacante → ingestão pelo sistema → interpretação pela IA → manipulação da análise → decisão inadequada → violação do objetivo operacional

O objetivo operacional esperado poderia ser, por exemplo, garantir que incidentes críticos sejam corretamente identificados, escalados e submetidos à análise humana. Se uma ação deliberada do atacante conseguir alterar o comportamento da IA e impedir esse resultado, existe uma consequência de segurança relevante mesmo que nenhum servidor tenha sido invadido, nenhuma credencial tenha sido roubada e nenhum privilégio administrativo tenha sido obtido.

Esse exemplo ajuda a compreender a principal contribuição da abordagem proposta pelos pesquisadores: em sistemas habilitados por IA, proteger os recursos computacionais continua sendo necessário, mas pode não ser suficiente. Também é preciso avaliar quais informações podem influenciar o comportamento da IA, quem consegue controlar essas informações e se essa influência pode ser convertida em decisões ou ações contrárias aos objetivos de segurança e de negócio da organização.

Nem todo erro da IA representa uma vulnerabilidade

Um aspecto importante na avaliação de segurança de sistemas baseados em Inteligência Artificial é diferenciar uma falha natural do modelo de um comportamento efetivamente provocado por uma ação adversária. LLMs podem apresentar alucinações, interpretar incorretamente determinadas informações, produzir classificações inadequadas ou gerar respostas inconsistentes sem que exista qualquer interferência de um atacante. Por esse motivo, encontrar uma resposta errada durante um teste não significa, por si só, que uma vulnerabilidade tenha sido explorada ou que o Penetration Testing tenha sido bem-sucedido.

Para que o comportamento observado seja considerado relevante sob a perspectiva de um teste de intrusão, é necessário demonstrar uma relação causal entre a atuação do adversário e o resultado produzido pelo sistema. No modelo proposto pelos pesquisadores, essa relação pode ser representada pela sequência ação adversária → influência sobre a IA → alteração de comportamento → violação de um objetivo operacional. Em outras palavras, o teste precisa demonstrar que o atacante, dentro das condições estabelecidas, conseguiu deliberadamente influenciar o sistema de maneira capaz de produzir um resultado contrário aos objetivos que deveriam ser preservados.

Essa análise também depende da definição prévia de um Threat Model (modelo de ameaças) que estabeleça claramente quem é o adversário considerado, quais recursos ou informações ele pode controlar, quais acessos possui, quais técnicas estão dentro do escopo e quais são suas limitações. Sem essas premissas, torna-se difícil determinar se determinado resultado representa uma exploração plausível ou apenas um comportamento inesperado do próprio modelo.

A distinção é fundamental para a qualidade dos testes de segurança em IA. Caso qualquer alucinação, erro de classificação ou resposta inadequada seja registrada automaticamente como vulnerabilidade, o resultado tende a se transformar em uma coleção de falhas do modelo, e não em uma avaliação efetiva de segurança. Um AI Penetration Testing deve ir além de identificar respostas incorretas: precisa demonstrar, de forma reproduzível, como um adversário pode provocar determinado comportamento, quais objetivos de segurança ou de negócio podem ser violados e qual impacto real essa manipulação pode produzir no ambiente avaliado.

As novas superfícies de ataque

A abordagem amplia consideravelmente aquilo que precisa ser considerado durante um Penetration Testing.

Entre as superfícies relevantes estão:

• Prompt Injection: manipulação direta das instruções recebidas pelo modelo.
• Indirect Prompt Injection: instruções maliciosas inseridas em conteúdo que posteriormente será recuperado pela IA.
• Retrieval Poisoning: manipulação de documentos, páginas ou bases utilizadas por mecanismos RAG.
• Memory Manipulation: inserção de informações ou instruções maliciosas na memória persistente de agentes.
• Data Poisoning: manipulação de dados utilizados no treinamento ou adaptação do modelo.
• Tool Misuse: indução do agente para utilizar APIs, comandos ou ferramentas legítimas de maneira indevida.
• Sensor Manipulation: alteração de imagens, áudio ou outros sinais utilizados por sistemas multimodais ou físicos.
• Human-AI Interaction Manipulation: utilização das respostas da IA para influenciar decisões humanas de maneira adversária.

Agentes autônomos ampliam a superfície de ataque

O risco torna-se ainda mais relevante com o avanço da Agentic AI, especialmente porque esses sistemas deixam de atuar apenas como mecanismos de geração de conteúdo e passam a participar ativamente da execução de processos. Enquanto um chatbot convencional normalmente recebe uma solicitação e produz uma resposta, um agente de IA pode interpretar um objetivo, planejar etapas, consultar diferentes fontes de informação, utilizar ferramentas e executar ações para alcançar o resultado esperado, muitas vezes com níveis significativos de autonomia.

Dependendo da arquitetura e das permissões concedidas, esses agentes podem consultar sistemas corporativos, acessar bancos de dados, interagir com APIs, analisar informações de um SIEM, abrir ou atualizar tickets, executar scripts, iniciar workflows e até realizar alterações em configurações de sistemas. Essa capacidade cria uma diferença fundamental do ponto de vista da Segurança da Informação: uma manipulação bem-sucedida do comportamento do modelo pode deixar de produzir apenas uma resposta incorreta e passar a resultar em uma ação concreta sobre o ambiente tecnológico ou sobre um processo de negócio.

Nesse contexto, ataques como Prompt Injection e Indirect Prompt Injection assumem uma dimensão mais crítica. Se um atacante conseguir inserir instruções maliciosas em um conteúdo posteriormente processado pelo agente — como uma página web, documento, e-mail, ticket, registro de log ou informação recuperada por um mecanismo RAG — existe o risco de que essas instruções sejam interpretadas como parte legítima da tarefa. Caso o agente também possua acesso a ferramentas ou sistemas externos, a manipulação poderá, dependendo dos controles existentes, influenciar chamadas de APIs, consultas, alterações ou outras ações realizadas em nome do usuário ou da própria aplicação.

A segurança de agentes de IA, portanto, não deve se limitar à proteção do modelo ou à filtragem de prompts. É necessário controlar também quais recursos o agente pode acessar, quais ferramentas pode utilizar, quais ações está autorizado a executar e em quais situações uma decisão humana deve ser obrigatória. Princípios consolidados de Segurança da Informação, como privilégio mínimo (Least Privilege), segregação de funções, validação de entradas e saídas, controle de acesso às ferramentas, registro e rastreabilidade das ações, monitoramento contínuo e aprovação humana para operações críticas tornam-se componentes fundamentais da arquitetura de segurança.

Em outras palavras, quanto maior a autonomia concedida ao agente, maior deve ser a preocupação com os limites dessa autonomia. O objetivo não é apenas impedir que a IA produza uma resposta inadequada, mas evitar que uma manipulação de seu contexto ou processo decisório seja convertida em uma ação não autorizada, um incidente de segurança ou um impacto efetivo para o negócio.

Como deve funcionar um Penetration Testing de IA

Uma das principais mudanças propostas para o Penetration Testing de sistemas baseados em Inteligência Artificial está no ponto de partida da avaliação. Em vez de iniciar exclusivamente pela identificação de ativos, serviços, vulnerabilidades e possíveis caminhos de exploração, o framework propõe começar pelos objetivos operacionais que o sistema de IA deve preservar e, a partir deles, identificar como um adversário poderia influenciar seu comportamento para produzir um resultado contrário ao esperado.

Na prática, isso aproxima o teste de uma abordagem orientada a risco e impacto. A questão deixa de ser apenas “quais vulnerabilidades existem neste sistema?” e passa a incluir “quais decisões ou ações da IA poderiam ser manipuladas por um adversário e quais seriam as consequências para a organização?”. Dessa forma, o teste conecta a técnica utilizada pelo atacante ao comportamento da IA e, finalmente, ao impacto operacional ou de negócio.

Um processo simplificado pode ser estruturado nas seguintes etapas:

1. Definir os objetivos operacionais que precisam ser preservados

O primeiro passo é estabelecer claramente quais resultados, restrições e condições de segurança devem permanecer válidos durante a operação do sistema. Esses objetivos precisam ser suficientemente específicos para permitir determinar posteriormente se houve ou não uma violação.

Em um SOC que utiliza IA para apoiar a análise de incidentes, por exemplo, um objetivo operacional poderia estabelecer que um incidente classificado como crítico não pode ser encerrado ou ter sua severidade reduzida sem validação humana. Em outros contextos, os objetivos podem envolver impedir divulgação de informações confidenciais, execução de operações sem autorização ou utilização de ferramentas fora do escopo permitido.

2. Mapear os comportamentos controlados ou influenciados pela IA

Depois de definir o que precisa ser protegido, é necessário identificar quais decisões e ações dependem direta ou indiretamente do modelo. Isso inclui classificações, recomendações, geração de conteúdo, priorização de eventos, seleção de ferramentas, chamadas de APIs, execução de workflows e outras ações realizadas por agentes.

Essa etapa é especialmente importante porque nem toda saída produzida pela IA possui o mesmo impacto. Uma resposta incorreta em um chatbot informativo pode representar um risco limitado, enquanto uma decisão equivocada de um agente com permissão para alterar configurações, aprovar transações ou executar comandos pode produzir consequências significativamente maiores.

3. Identificar as superfícies que podem influenciar o comportamento

O próximo passo consiste em mapear todas as fontes de informação capazes de modificar o contexto utilizado pela IA. A análise não deve se limitar ao prompt fornecido diretamente pelo usuário. Documentos, páginas web, e-mails, bases de conhecimento, mecanismos RAG, memória do agente, resultados de APIs, ferramentas externas, sensores e outras fontes de dados também podem participar da construção do contexto utilizado pelo modelo.

A pergunta central nesta etapa é: quais dessas fontes podem ser direta ou indiretamente controladas ou manipuladas por um adversário?

Esse mapeamento permite identificar caminhos nos quais uma informação aparentemente legítima pode funcionar como vetor para Prompt Injection, Indirect Prompt Injection, Retrieval Poisoning, Memory Manipulation ou outras formas de influência adversária.

4. Definir critérios objetivos de falha

Antes de executar os ataques, é necessário determinar quais resultados serão considerados uma violação de segurança. Isso evita que qualquer resposta inesperada, alucinação ou erro do modelo seja automaticamente classificado como vulnerabilidade.

Retomando o exemplo do SOC, o simples fato de o modelo interpretar incorretamente um indicador pode representar uma falha de qualidade. Entretanto, se um conteúdo deliberadamente manipulado pelo atacante fizer o sistema reduzir a severidade de um incidente crítico, impedir sua escalada ou recomendar seu encerramento, poderá existir uma violação do objetivo operacional previamente estabelecido.

O critério de sucesso do ataque deve, portanto, estar associado a um comportamento adversarialmente induzido e a uma consequência claramente definida.

5. Executar cenários adversários controlados

Com os objetivos, comportamentos, superfícies de influência e critérios de falha definidos, inicia-se a execução dos testes. O avaliador procura construir cenários realistas nos quais um adversário, respeitando as capacidades e limitações estabelecidas no Threat Model, tenta influenciar o comportamento do sistema.

Esses cenários podem envolver manipulação direta de prompts, inserção de instruções em documentos recuperados pelo RAG, contaminação de informações utilizadas pelo agente, exploração da memória persistente ou tentativa de induzir chamadas inadequadas de ferramentas e APIs.

O objetivo não é simplesmente fazer o modelo produzir uma resposta estranha ou incorreta, mas demonstrar se uma ação adversária plausível consegue alterar o comportamento do sistema de maneira suficiente para violar um objetivo operacional.

6. Produzir evidências reproduzíveis e mensurar o impacto

Por fim, cada cenário relevante deve gerar evidências que permitam compreender e, quando possível, reproduzir o comportamento observado. Isso inclui registrar o modelo e sua versão, configurações, prompts, contexto utilizado, documentos recuperados, permissões disponíveis, ferramentas acionadas, resultados obtidos e condições em que o ataque ocorreu.

Como sistemas baseados em LLMs apresentam comportamento probabilístico, também pode ser necessário repetir o mesmo cenário diversas vezes para determinar a frequência com que a manipulação é bem-sucedida, em vez de concluir a avaliação com base em uma única execução.

O resultado final deve permitir construir uma cadeia de evidências clara:

Objetivo operacional → superfície de influência → ação adversária → comportamento da IA → ação ou decisão resultante → violação do objetivo → impacto

Essa abordagem torna o Penetration Testing de IA mais próximo de uma avaliação orientada ao risco real. Em vez de produzir apenas uma relação de prompts que conseguiram contornar determinado mecanismo de proteção, o teste passa a demonstrar como um adversário pode influenciar a IA, quais controles falharam, que comportamento foi alterado e qual consequência essa manipulação pode produzir para a organização.

Um pentest probabilístico: quando um único teste não é suficiente

Uma das diferenças mais relevantes entre o Penetration Testing tradicional e os testes de segurança aplicados a sistemas de Inteligência Artificial está na previsibilidade dos resultados. Em muitos cenários convencionais, uma vulnerabilidade pode ser reproduzida de maneira relativamente determinística: mantidas as mesmas condições técnicas, uma exploração tende a produzir resultados semelhantes. Em sistemas baseados em Large Language Models (LLMs), entretanto, essa previsibilidade é significativamente menor, pois o comportamento do modelo possui natureza probabilística e pode variar entre diferentes execuções.

Isso significa que um mesmo ataque de Prompt Injection, utilizando exatamente a mesma entrada e aparentemente nas mesmas condições, pode conseguir manipular o comportamento do modelo em uma execução e falhar em outra. Pequenas variações no contexto, no histórico da interação, nos parâmetros do modelo, nas informações recuperadas por um mecanismo RAG ou até na sequência das mensagens podem influenciar o resultado. Dessa forma, avaliar a segurança de um sistema de IA com base em uma única tentativa pode produzir conclusões pouco representativas sobre sua resistência real a ataques.

Por esse motivo, um AI Penetration Testing precisa incorporar uma abordagem mais sistemática e repetível. Os mesmos cenários adversários devem ser executados diversas vezes, sob condições controladas, permitindo avaliar não apenas se determinada técnica funciona, mas também com que frequência ela funciona e em quais circunstâncias o comportamento inseguro ocorre. Uma técnica de ataque que obtenha sucesso em apenas parte das execuções não deve ser automaticamente descartada, principalmente quando o resultado possível envolver acesso indevido a informações, execução de ações não autorizadas ou comprometimento de um processo crítico.

Essa característica introduz uma dimensão estatística ao Penetration Testing de sistemas de IA. Além de registrar a vulnerabilidade e seu impacto, o relatório pode precisar documentar a quantidade de tentativas realizadas, a frequência de sucesso, as condições em que a manipulação ocorreu e a consistência das salvaguardas existentes. Assim, a pergunta deixa de ser apenas “o ataque funcionou?” e passa também a considerar “qual é a probabilidade de o ataque funcionar quando repetido em condições semelhantes?”.

Um relatório de Penetration Testing de IA deveria registrar, entre outros elementos:

• modelo e versão utilizados;
• configuração da aplicação;
• Threat Model;
• prompt ou artefato adversário;
• estado do mecanismo RAG;
• conteúdo da memória;
• permissões das ferramentas;
• quantidade de execuções;
• quantidade de ataques bem-sucedidos;
• taxa de sucesso;
• comportamento observado;
• objetivo operacional afetado;
• consequência para o negócio.

Isso transforma a reprodutibilidade em um elemento ainda mais importante na avaliação de segurança de IA.

IA também está transformando a execução do Penetration Testing

Enquanto pesquisadores desenvolvem novas técnicas para avaliar a segurança de sistemas baseados em Inteligência Artificial, outro movimento ocorre em paralelo: a própria IA começa a ser utilizada para executar atividades de Penetration Testing. Modelos de linguagem e agentes autônomos já demonstram capacidade para interpretar informações sobre um ambiente, selecionar ferramentas, executar comandos, analisar resultados e utilizar essas informações para decidir quais etapas devem ser realizadas em seguida.

Essa evolução representa uma mudança importante em relação à automação tradicional de segurança. Ferramentas convencionais automatizam tarefas previamente definidas, como descoberta de ativos, varredura de portas ou identificação de vulnerabilidades. Um agente baseado em IA pode, em princípio, utilizar os resultados obtidos durante o teste para adaptar sua estratégia, selecionar novas ações e construir progressivamente um caminho de ataque, aproximando-se de algumas atividades normalmente executadas por um profissional de Offensive Security.

Uma pesquisa publicada em junho de 2026 ilustra essa evolução ao avaliar 19 LLMs proprietários e open-weight em um framework composto por 300 servidores-alvo. Dependendo do modelo analisado, os pesquisadores observaram taxas de sucesso de penetração autônoma entre 10,7% e 69,3%, indicando diferenças significativas entre as capacidades dos modelos para executar tarefas ofensivas de forma autônoma.

Outro estudo publicado em 2026 explorou especificamente a utilização de LLMs em cenários de Assumed Breach envolvendo ambientes Microsoft Active Directory. Nesse tipo de avaliação, parte-se da premissa de que o atacante já obteve algum nível inicial de acesso, e o objetivo passa a ser identificar caminhos que permitam ampliar esse comprometimento. O estudo demonstra como agentes podem participar da investigação do ambiente, interpretar informações coletadas e construir possíveis caminhos de ataque.

A evolução também alcança técnicas de Reinforcement Learning (RL). Uma revisão científica publicada em março de 2026 analisou pesquisas sobre sua aplicação ao planejamento de caminhos de ataque e ao Penetration Testing autônomo, demonstrando como mecanismos de aprendizado podem ser utilizados para selecionar ações sucessivas a partir do estado observado do ambiente.

Estamos, portanto, diante de duas transformações que ocorrem simultaneamente. De um lado, temos a IA como alvo, exigindo novas metodologias para avaliar Prompt Injection, manipulação de contexto, RAG, memória, ferramentas e comportamento de agentes. Do outro, temos a IA como instrumento de Offensive Security, capaz de automatizar progressivamente etapas de descoberta, análise, exploração e construção de caminhos de ataque.

Essa segunda transformação, entretanto, introduz um problema adicional: quanto maior a autonomia concedida ao agente durante um Penetration Testing, maior também precisa ser o controle sobre o que ele pode testar, quais ferramentas pode utilizar, quais ações pode executar e até onde pode avançar sem autorização humana.

Pentests autônomos também exigem novos padrões de governança

A utilização de agentes capazes de tomar decisões e executar ações ofensivas torna insuficiente simplesmente aplicar, sem adaptações, os mesmos mecanismos utilizados para ferramentas convencionais de automação. Um agente pode encadear ações, interpretar resultados intermediários e modificar sua estratégia durante a execução, o que amplia a necessidade de estabelecer limites técnicos e operacionais claros.

É nesse contexto que surge o OWASP Autonomous Penetration Testing Standard (APTS), iniciativa destinada a estabelecer requisitos específicos para sistemas de Penetration Testing com diferentes níveis de autonomia. A proposta reconhece que metodologias consolidadas, como PTES, OWASP WSTG e OSSTMM, continuam relevantes, mas não foram originalmente concebidas para responder a todas as questões introduzidas por agentes autônomos.

Entre essas questões estão o controle rigoroso de escopo, execução segura das atividades, supervisão humana, limitação da autonomia, auditabilidade das decisões, resistência à manipulação e governança da cadeia de suprimentos utilizada pelo agente. Segundo a documentação atual do projeto, o APTS estrutura 173 requisitos distribuídos por oito domínios de governança, buscando estabelecer mecanismos para que a autonomia não elimine os controles necessários a uma operação ofensiva autorizada.

Essa preocupação é particularmente importante porque, em um Penetration Testing tradicional, o profissional trabalha dentro de um escopo formalmente autorizado. Um agente autônomo precisa estar sujeito às mesmas restrições — e possivelmente a salvaguardas adicionais — para impedir que uma decisão automatizada ultrapasse os limites técnicos, contratuais ou operacionais estabelecidos para o teste.

O que muda para as organizações

Para as organizações, essas transformações indicam que a segurança da IA não deve ser tratada apenas como mais uma atividade dentro da gestão convencional de vulnerabilidades. Sistemas que utilizam LLMs, RAG ou agentes autônomos introduzem componentes e relações que precisam ser incorporados ao modelo de avaliação de segurança.

Uma forma de visualizar essa nova superfície é considerar toda a cadeia envolvida no funcionamento da aplicação:

Infraestrutura → Dados → RAG e contexto → Modelo → Agente → Ferramentas e APIs → Ações → Objetivo operacional

Cada camada pode introduzir riscos próprios e, principalmente, criar relações de confiança com as demais. Um documento recuperado por um mecanismo RAG, por exemplo, pode influenciar o modelo; o modelo pode orientar um agente; o agente pode utilizar uma ferramenta; e essa ferramenta pode executar uma ação sobre um sistema corporativo. Portanto, uma manipulação iniciada na camada de informação pode percorrer toda a cadeia até produzir uma consequência operacional.

É por essa razão que proteger apenas o endpoint do modelo ou implementar filtros contra determinados prompts não é suficiente. Os controles precisam acompanhar toda a cadeia de decisão, estabelecendo quais informações podem influenciar o agente, quais ferramentas podem ser acionadas, quais privilégios essas ferramentas possuem, quais ações precisam ser registradas e quais decisões não podem ser executadas autonomamente.

Nesse cenário, práticas de AI Security Testing e AI Red Teaming tendem a complementar o Penetration Testing tradicional. O objetivo passa a ser avaliar não apenas vulnerabilidades técnicas da infraestrutura, mas também a capacidade de um adversário manipular o comportamento do sistema e transformar essa influência em consequências reais.

Para aplicações de maior criticidade, mecanismos de Human-in-the-Loop (HITL) podem representar uma salvaguarda relevante. Operações potencialmente destrutivas, movimentações financeiras, alterações de configurações, concessões de privilégios ou decisões críticas de segurança podem exigir autorização humana antes da execução. O princípio é simples: quanto maior o impacto potencial de uma ação e maior a autonomia do agente, mais rigorosos devem ser os controles que delimitam essa autonomia.

Essa mudança amplia o próprio conceito de segurança aplicado à Inteligência Artificial. Não basta perguntar se o modelo está protegido contra ataques. É necessário avaliar quem pode influenciá-lo, quais decisões ele pode tomar, quais recursos consegue acessar, quais ações pode executar e quais consequências essas ações podem produzir para a organização.

Governança também passa a fazer parte do Penetration Testing

A discussão não é exclusivamente técnica.

Agentes autônomos levantam questões relacionadas a:

• definição formal de escopo;
• autorização para exploração;
• limites de autonomia;
• segregação de funções;
• registro completo das ações;
• responsabilização;
• cadeia de suprimentos dos modelos;
• comportamento não determinístico;
• supervisão humana;
• interrupção segura das operações.

Pesquisa recente sobre a ética de agentes autônomos utilizados em Offensive Security também chama atenção para a combinação entre comportamento não determinístico, impactos potencialmente abertos e redução da barreira técnica necessária para utilização dessas ferramentas.

Isso significa que organizações precisarão combinar Cybersecurity, AI Governance, Risk Management e controles técnicos para utilizar essas tecnologias de maneira segura.

Conclusão

A incorporação da Inteligência Artificial aos processos corporativos está ampliando o próprio conceito de Penetration Testing. Durante décadas, grande parte das avaliações de segurança esteve concentrada em responder a uma pergunta essencial: “um atacante consegue obter acesso indevido ao sistema?”. Essa questão continua sendo fundamental, mas sistemas baseados em IA acrescentam uma segunda dimensão: “mesmo sem comprometer diretamente a infraestrutura, um atacante consegue influenciar o sistema a ponto de fazê-lo agir contra os objetivos da organização?”

Essa mudança altera significativamente a maneira como a superfície de ataque precisa ser compreendida. Técnicas como Prompt Injection, Indirect Prompt Injection, Retrieval Poisoning, Memory Manipulation e Tool Misuse demonstram que um adversário pode explorar não apenas vulnerabilidades de software, configurações inadequadas ou credenciais comprometidas, mas também as informações, instruções e contextos utilizados pela IA para interpretar uma situação e tomar decisões.

O risco torna-se ainda mais relevante quando o modelo deixa de apenas produzir respostas e passa a integrar agentes capazes de utilizar ferramentas, consultar sistemas corporativos e executar ações. Nesse cenário, uma manipulação inicialmente limitada ao contexto da IA pode percorrer diferentes camadas da arquitetura e resultar em uma consequência concreta: influência adversária → alteração do comportamento → execução de uma ação → violação de um objetivo operacional. Assim, o comportamento do sistema passa a integrar efetivamente sua superfície de ataque.

Isso não significa que o Penetration Testing tradicional esteja se tornando obsoleto. Infraestrutura, aplicações, APIs, identidades, privilégios, configurações e vulnerabilidades continuarão sendo componentes essenciais de qualquer avaliação de segurança. O que muda é a necessidade de ampliar o escopo para incluir também modelos, prompts, dados, mecanismos RAG, memória, contexto, agentes, ferramentas e as relações de confiança existentes entre esses componentes.

O resultado tende a ser uma abordagem mais integrada, na qual Penetration Testing, AI Security Testing e AI Red Teaming se complementam para avaliar não apenas se um ambiente pode ser tecnicamente comprometido, mas também se a Inteligência Artificial pode ser manipulada para produzir comportamentos contrários às políticas, controles e objetivos da organização.

Para gestores de Segurança da Informação, essa talvez seja a principal mensagem: proteger a infraestrutura que executa a IA já não é suficiente; é necessário proteger também as decisões e ações que a IA é capaz de influenciar ou executar. Quanto maior for a autonomia concedida a esses sistemas e maior sua participação em processos críticos, mais importante será estabelecer limites de atuação, privilégio mínimo, segregação de funções, monitoramento, rastreabilidade e intervenção humana para decisões de maior impacto.

O Penetration Testing de sistemas de IA, portanto, não deve terminar quando se comprova que o atacante não conseguiu “entrar” no ambiente. Em determinadas arquiteturas, a questão mais importante pode ser justamente outra: até onde um adversário consegue chegar simplesmente fazendo o sistema confiar, decidir ou agir da maneira errada?

Por Kleber Melo - CEO Mindsec e Editor Chefe Blog Minuto da Segurança 
Com auxilio de busca e pesquisa da IA Mindsec

Referências técnicas

Artigo-base – GBHackers
New Framework Redefines AI Penetration Testing Around Prompt Injection and Behavioral Objective Violations

Allahbakhsh, Bahari e Attar Raouf – Rethinking Penetration Testing for AI-Enabled Systems
Pesquisa original no arXiv

Elsevier – Autonomous Pentesting Using Artificial Intelligence: From the Cybersecurity Point-of-View
Estudo científico sobre pentest autônomo com IA

Elsevier – Autonomous Penetration Testing Using Reinforcement Learning: A Review and Perspectives
Revisão sobre Reinforcement Learning aplicado ao pentest autônomo

ACM – Can LLMs Hack Enterprise Networks?
Pesquisa sobre LLMs e Penetration Testing autônomo em Active Directory

OWASP – Autonomous Penetration Testing Standard (APTS)
OWASP Autonomous Penetration Testing Standard

Clique e fale com representante oficial Netwrix Endpoint Protector

Veja também:

• Ransomware em 2026: número de vítimas bate recorde
• Top 10 Malware usados por Hackers
• O resgate não é o custo do ransomware
• Microsoft Defender pode ser transformado em arma contra EDR e antivírus
• Shadow AI: 47% do uso corporativo de IA ocorre em contas pessoais
• Cibersegurança: 95% das equipes enfrentam lacunas de habilidades
• Credenciais móveis avançam como pilar da segurança bancária
• Ransomware mira backups em 96% dos ataques
• Criminosos criam marketplace de dados pessoais para aplicar golpes na internet
• Violações de dados mais que dobram com avanço dos agentes de IA
• CertiK Intel3D – A Era das PSAVs e o Novo Padrão de Segurança do Brasil
• América Latina é a segunda região mais exposta a ciberameaças industriais