A pesquisa recente em cibersegurança está atravessando uma mudança estrutural. O eixo dominante deixou de ser apenas a detecção de vulnerabilidades, a classificação de ataques ou a automação parcial de tarefas de segurança. O novo centro técnico é a construção de sistemas cibernéticos autônomos ou semiautônomos capazes de observar, raciocinar, agir, testar, corrigir, justificar decisões e produzir evidências auditáveis.

A grande novidade não é simplesmente “IA para hackers”. Essa leitura é pobre. O fenômeno real é mais profundo: a cibersegurança está se tornando um campo de engenharia de agentes sob risco. Agentes ofensivos, defensivos, avaliadores, validadores, verificadores e simuladores começam a ocupar posições antes reservadas a operadores humanos. Isso cria ganhos de escala, mas também abre uma nova superfície de falha: erro autônomo, falsa confiança, automação insegura, vazamento de contexto operacional, hallucination em decisões críticas e manipulação adversarial dos próprios sistemas de defesa.

Este artigo analisa as tendências centrais dessa nova safra de trabalhos, organizando-as em nove eixos: pentest autônomo, benchmarks realistas, OT e cyber-physical systems, blue team com LLMs, exploitability e priorização, supply chain e patching, prompt injection e ataques contra IA, decepção cibernética para atacantes artificiais, e governança técnica para operações reguladas.

1. A tese central: cibersegurança virou engenharia de agentes

A cibersegurança clássica era estruturada em torno de ferramentas, assinaturas, regras, scanners, SIEM, EDR, playbooks e operadores. A cibersegurança emergente reorganiza esse ecossistema em torno de agentes.

Um agente de pentest não é apenas um script que executa comandos. Ele percebe outputs, replaneja, muda estratégia, interpreta falhas, seleciona ferramentas, mantém memória de passos anteriores e tenta completar objetivos. Um agente defensivo não apenas correlaciona alertas. Ele recupera contexto, classifica técnicas ATT&CK, propõe ações, valida riscos, registra evidências e pode acionar contenções sob supervisão. Um agente avaliador julga trajetórias de outros agentes. Um agente verificador tenta descobrir se um benchmark pode ser trapaceado. Um agente de patching tenta corrigir vulnerabilidades em versões antigas e provar que a correção bloqueia exploração sem quebrar funcionalidade.

Isso muda a pergunta fundamental da área.

Antes, perguntava-se: “essa ferramenta encontra a vulnerabilidade?” Agora, pergunta-se: “esse sistema age corretamente, sob escopo, com evidência, diante de incerteza, em ambiente adversarial, sem extrapolar autorização?”

Essa é a mudança tectônica. A ferramenta virou ator. O log virou prova. O benchmark virou tribunal. O operador humano virou supervisor de uma pequena cidade de máquinas argumentadoras.

2. Pentest autônomo: da promessa ao teste em ambiente real

A linha de pesquisa mais visível está nos agentes de pentest. O campo evoluiu em três ondas.

A primeira onda automatizava tarefas isoladas: enumeração, varredura, geração de comandos, exploração simples e análise de outputs. A segunda conectou LLMs a ferramentas, criando agentes capazes de executar ciclos iterativos. A terceira, agora emergente, tenta medir se esses agentes realmente funcionam em ambientes próximos do mundo real.

Essa distinção é crítica. Um agente pode ir bem em CTF e falhar miseravelmente em rede real. CTFs são jardins murados com pistas escondidas, vulnerabilidades intencionais e objetivos simplificados. Ambientes reais têm ruído, serviços benignos, dependências quebradas, falso positivo, segmentação, autenticação parcial, versões divergentes, artefatos incompletos e múltiplos caminhos improdutivos. O pentest real é menos caça ao tesouro e mais navegação em neblina industrial.

Os trabalhos recentes propõem protocolos que deslocam a avaliação de “capturar a flag” para “descobrir vulnerabilidades validadas” ou “obter controle sob condições realistas”. Essa mudança é enorme porque corrige um vício histórico: medir sucesso em laboratório fácil demais. Quando a avaliação exige reconhecimento autônomo, discriminação entre serviço benigno e explorável, execução robusta e persistência de raciocínio, muitos agentes que pareciam brilhantes perdem o verniz.

Frameworks como AutoPentester, xOffense, Pentest-R1, Pen-Strategist, TermiAgent e abordagens similares indicam caminhos diferentes para o mesmo problema: como fazer um agente deixar de ser um autocomplete de comandos e virar um operador estratégico confiável.

Há três ingredientes técnicos recorrentes:

1. Raciocínio especializado Modelos generalistas têm dificuldade em formular estratégias de ataque ou teste defensivo com consistência. Por isso, surgem datasets de raciocínio de pentest, fine-tuning específico, reinforcement learning e classificadores de seleção de passos.

2. Memória operacional Pentest é sequência. Um comando só faz sentido em relação ao que já foi observado. Agentes sem memória perdem contexto, repetem enumerações, esquecem credenciais, ignoram pistas e entram em loops.

3. Avaliação realista e cumulativa Como LLMs são estocásticos, uma execução isolada não basta. O agente precisa ser avaliado em múltiplas rodadas, com manutenção de ground truth, métricas de eficiência, cobertura e validação semântica das descobertas.

O avanço técnico está menos no “agente que invade sozinho” e mais no “agente que consegue ser medido, comparado, supervisionado e melhorado”.

3. O mito da autonomia total

Uma das contribuições mais importantes da literatura recente é a crítica ao marketing de “autonomia”. Muitos sistemas chamados de autônomos ainda dependem de supervisão humana para edge cases, decisões estratégicas e validação de impacto. A taxonomia proposta por pesquisas recentes separa automação de autonomia em níveis. Essa separação é necessária porque a confusão terminológica pode ser perigosa.

Um scanner automatizado executa tarefas. Um agente semiautônomo decide entre caminhos dentro de limites. Um sistema plenamente autônomo definiria objetivos, estratégias, ações, correções e consequências sem intervenção humana significativa.

A maior parte dos sistemas atuais parece operar em uma zona intermediária: mais do que scripts, menos do que operadores independentes. Eles executam sequências complexas, mas ainda erram no julgamento, na adaptação, na priorização, na contenção de risco e na interpretação contextual.

Em segurança, isso importa porque uma falsa autonomia pode reduzir supervisão exatamente quando a supervisão deveria aumentar. Uma organização que acredita ter um “pentester autônomo” pode deixar de revisar escopo, impacto, credenciais usadas, artefatos gerados, falsos positivos e ações laterais. A fantasia da máquina infalível vira uma vulnerabilidade gerencial.

A palavra correta para 2026 talvez não seja autonomia. É autonomia governada.

4. Pentest em OT, ICS e sistemas cyber-físicos

Outra novidade forte é a entrada dos agentes em ambientes OT e cyber-físicos. A segurança ofensiva sempre teve dificuldades nesse domínio porque OT não se comporta como TI tradicional. Não há necessariamente shell, sistema de arquivos familiar, logs fáceis, endpoints convencionais ou APIs confortáveis. Há protocolos industriais, controladores, sensores, atuadores, microcontroladores, plantas físicas e consequências no mundo real.

Trabalhos recentes sobre OT pentesting e APIOT mostram que a fronteira agora inclui Modbus/TCP, CoAP, Zephyr RTOS, microcontroladores bare-metal e topologias industriais heterogêneas. Isso exige outro tipo de raciocínio. O agente não pode apenas “rodar ferramenta e interpretar stdout”. Ele precisa entender campos de protocolo, semântica de parser, estados físicos, crash verification, patching e verificação de correção.

A implicação é séria: se agentes LLM conseguem operar em ciclos de descoberta, exploração, correção e verificação em firmware industrial, o modelo de ameaça de OT muda. Antes, a exploração de ambientes industriais exigia alta especialização. Agora, parte dessa especialização pode ser encapsulada em agentes, reduzindo a barreira operacional.

Do lado defensivo, isso exige ambientes de teste melhores: digital twins, sandboxes cyber-físicos, simulação fechada com binários reais, rastreamento de side channels, instrumentação, contenção e repetibilidade. Segurança de OT não pode ser validada com a mesma leveza de um laboratório web. Uma falha em software pode derrubar um serviço. Uma falha em CPS pode mover, aquecer, abrir, fechar, acelerar, travar ou danificar algo físico.

A cibersegurança deixa de ser apenas digital. Ela ganha massa, temperatura e inércia.

5. Benchmarks: o novo campo de batalha

Benchmarks viraram infraestrutura crítica da pesquisa em cibersegurança com IA. Se o benchmark é frágil, o progresso é ilusório. Se o verificador pode ser enganado, o leaderboard vira teatro. Se a avaliação permite vazamento temporal, o modelo aprende com o futuro. Se o ambiente é simples demais, o agente parece melhor do que é.

Os trabalhos recentes atacam exatamente esse problema.

TermiBench tenta aproximar pentest de condições reais. PentestJudge avalia trajetórias de agentes contra requisitos operacionais. Hacker-fixer loops procuram endurecer verificadores contra reward hacking. MOSAIC-Bench mostra que agentes de código podem produzir vulnerabilidades por decomposição de tarefas aparentemente inocentes. CBEG trabalha com grafos temporais de evidência para triagem prospectiva de vulnerabilidades, evitando vazamento de futuro.

Essa linha revela uma ideia poderosa: a avaliação em cibersegurança precisa ser adversarial por desenho.

Não basta criar uma tarefa e pontuar resposta. É preciso perguntar:

• O agente trapaceou o verificador?
• O modelo usou informação que não existia no momento da decisão?
• O scoring mede exploração real ou apenas semelhança textual?
• A trajetória respeitou escopo?
• O agente obteve resultado por caminho seguro ou por comportamento operacionalmente inaceitável?
• O benchmark induz atalhos?
• O dataset tem leakage?
• A métrica mede o que uma equipe real precisa saber?

A pesquisa está chegando a uma maturidade metodológica importante: não basta que o agente funcione. É preciso que o sistema de avaliação não seja enganado pelo próprio agente que ele mede.

6. Exploitability, priorização e o fim da tirania do CVSS isolado

Outro eixo forte é a priorização de vulnerabilidades. Organizações não conseguem corrigir tudo ao mesmo tempo. A pergunta operacional não é “qual CVE tem nota alta?”; é “qual vulnerabilidade é explorável, relevante, acionável, provável e sustentada por evidência pública disponível agora?”

CVSS mede severidade teórica. EPSS estima probabilidade. Ambos são úteis, mas incompletos. O novo movimento tenta construir avaliações baseadas em evidência temporal: advisories, commits de correção, exploit archives, discussões em comunidades hacker, documentação associada e sinais públicos disponíveis antes de uma data de decisão.

Esse detalhe temporal é decisivo. Uma avaliação retrospectiva pode parecer brilhante porque usa dados que só apareceram depois. A avaliação prospectiva força o modelo a agir como uma equipe real: decidir com informação incompleta, no tempo correto, com orçamento limitado de coleta.

Sistemas como AEAS analisam exploit code e documentação para estimar acionabilidade: existe exploit funcional? É configurável? Depende de pré-condições difíceis? O setup é claro? Há evidência de que funciona? Essa abordagem é mais útil para red teams e blue teams do que uma simples lista ordenada por severidade.

O futuro da priorização parece caminhar para uma tríade:

• Exploitability real: há caminho técnico plausível?
• Actionability: há artefato funcional e reproduzível?
• Contextual relevance: a organização possui a tecnologia, versão, exposição e pré-condições?

Sem essa tríade, corre-se atrás de incêndios estatísticos enquanto a porta real fica aberta.

7. Supply chain e patching verificado

A segurança de supply chain aparece como um dos pontos mais práticos da nova safra. O problema é conhecido: uma biblioteca tem vulnerabilidade, a correção existe apenas na versão mais nova, mas atualizar pode quebrar compatibilidade. Muitas organizações ficam presas entre risco de exploração e risco de regressão.

A novidade está em sistemas agentic de backport verificado. Em vez de apenas sugerir atualização, esses sistemas tentam aplicar patches a versões antigas e construir uma cadeia de evidência de que a correção bloqueia exploração e preserva comportamento. Isso é extremamente relevante para ambientes empresariais, onde dependências antigas sobrevivem por motivos legítimos: estabilidade, certificação, legado, compatibilidade, custo de migração ou restrição operacional.

Essa linha é promissora porque transforma “remediação” em objeto verificável. O patch deixa de ser uma fé. Ele passa a ser acompanhado por prova funcional: teste de exploração bloqueada, teste de comportamento preservado e rastreabilidade entre advisory, versão afetada, patch e validação.

O impacto potencial é enorme. Se amadurecer, esse tipo de abordagem pode reduzir a janela de exposição de milhares de versões vulneráveis que hoje ficam abandonadas porque “não dá para atualizar tudo”.

8. Blue team com knowledge graphs e agentes supervisáveis

Do lado defensivo, a literatura caminha para sistemas que combinam LLMs com knowledge graphs, SIEM, EDR, XDR, MITRE ATT&CK, D3FEND, NIST CSF e logs auditáveis. O objetivo é reduzir hallucination e melhorar raciocínio temporal.

LLMs sozinhos são frágeis em segurança porque segurança é contextual. Um alerta não tem significado isolado. Ele depende de topologia, histórico, identidade, asset crítico, comportamento anterior, ação defensiva já tomada, técnica adversária e estágio da intrusão. Knowledge graphs ajudam porque organizam relações: máquina, usuário, processo, alerta, vulnerabilidade, técnica, evidência, ação, resultado.

Frameworks como DEFENGRAPH mostram esse caminho: usar grafo estático e dinâmico para recuperar caminhos relevantes, filtrar contexto, reranquear raciocínios e sustentar recomendações defensivas. A promessa é diminuir decisões soltas e aumentar fidelidade ao ambiente.

Agentra e arquiteturas similares avançam na resposta a incidentes. Em vez de um playbook estático, propõem múltiplos agentes especializados, validação Planner-Validator, moderação de threat intelligence, catálogo de ações, score de risco e log append-only. Isso aponta para o SOC do futuro: menos painel passivo, mais orquestra de agentes com maestro humano.

Mas o risco permanece. Um agente defensivo pode exagerar, conter demais, derrubar serviço, bloquear usuário legítimo ou interpretar mal um sinal. Por isso, a literatura insiste em gates humanos, auditoria, escopo, validação e aprovação.

O blue team automatizado precisa ser rápido, mas não impulsivo. Em defesa, reflexo sem juízo vira acidente.

9. Decepção cibernética contra atacantes LLM

Honeypots e sistemas de decepção foram desenhados historicamente para humanos. Mas atacantes LLM não se comportam como humanos. Pesquisas recentes mostram que hipóteses humanas de decepção não transferem diretamente para agentes de IA.

Isso é fascinante. Um humano pode desconfiar de um artefato falso por intuição, inconsistência ou excesso de conveniência. Um LLM pode reconhecer verbalmente que algo parece armadilha e, mesmo assim, agir sobre a armadilha. Surge um gap entre reconhecimento e ação. O modelo “sabe” no texto, mas não incorpora esse saber na decisão.

Isso exige uma nova categoria: decepção AI-native. Não basta criar iscas críveis para humanos. É preciso entender como agentes artificiais avaliam affordances, outputs, permissões, prompts, shell feedback, arquivos falsos, credenciais plantadas e sinais semânticos. ShellGames, por exemplo, explora a ideia de simular ambientes SSH interativos com LLM, mantendo estado, consistência, robustez e realismo.

A defesa ativa deixa de ser psicologia do intruso e vira psicologia de modelos. O defensor passa a perguntar: “como uma IA atacante percebe este ambiente?” É uma pergunta nova, estranha, quase zoológica. Estamos catalogando uma espécie invasora feita de tokens.

10. Prompt injection, VLMs e a fragilidade da confiança em detectores

Prompt injection continua sendo uma das áreas mais quentes porque atinge o coração dos sistemas agentic. Se um agente lê conteúdo externo e esse conteúdo pode influenciar suas instruções, a fronteira entre dado e comando fica porosa.

Os trabalhos recentes mostram dois problemas:

1. Detectores podem errar com alta confiança.
2. Ataques multimodais ampliam a superfície.

O primeiro problema é especialmente perigoso. Em segurança, um falso negativo confiante é pior do que uma incerteza honesta. Se um detector de prompt injection passa ataques indiretos com “certeza”, ele não apenas falha; ele legitima o ataque. Isso cria uma falsa camada de segurança.

O segundo problema envolve VLMs. Imagens podem carregar instruções, perturbações ou padrões que manipulam modelos vision-language. Ferramentas como DE-FIVE procuram detectar prompts visuais maliciosos usando sinais de Fourier e embeddings de imagem, sem exigir grande retraining. Essa direção é crucial porque agentes modernos não leem apenas texto. Eles veem screenshots, documentos, diagramas, imagens, interfaces e vídeos.

A regra técnica emergente é simples: qualquer modalidade ingerida por um agente pode virar canal de instrução adversarial.

Texto, imagem, áudio, log, commit, ticket, e-mail, PDF, issue, página web, QR code, planilha e screenshot precisam ser tratados como possíveis superfícies de comando.

11. Backdoors, poisoning e ataques contra modelos especializados

A pesquisa também avança sobre ataques contra modelos de IA aplicados a domínios sensíveis. Um exemplo recente é o ataque backdoor contra reconhecimento de emoção por fala usando envenenamento via TTS. O ponto mais importante não é o domínio específico, mas a generalização do risco: tecnologias generativas reduzem o custo de produzir dados sintéticos maliciosos para treinamento.

Isso afeta cibersegurança diretamente. Datasets de CTI, logs sintéticos, exemplos de ataque, prompts de treinamento, simulações e traces podem ser contaminados. Se modelos defensivos aprendem com dados envenenados, a defesa passa a carregar a vulnerabilidade dentro da própria cabeça.

Essa preocupação conecta-se ao problema de fake CTI, benchmark hacking, prompt injection, evasão de detectores e manipulação de pipelines. O adversário não ataca apenas o sistema final. Ele ataca o processo pelo qual o sistema aprende, avalia e decide.

12. HIDS, CWE e generalização operacional

Outra novidade relevante é a tentativa de generalizar detecção de intrusão de CVE para CWE. Em vez de treinar detectores para reconhecer uma vulnerabilidade específica, a pergunta passa a ser: é possível detectar uma nova exploração pertencente à mesma classe de fraqueza?

Essa pergunta é muito prática. Em produção, defensores nem sempre enfrentam exatamente o CVE conhecido. Eles enfrentam variações, exploits novos, cadeias adaptadas e comportamentos equivalentes. Se um HIDS aprende apenas uma instância, sua utilidade é limitada. Se aprende padrões de uma família de fraquezas, torna-se mais valioso.

Os resultados recentes indicam que a generalização por CWE é possível em alguns casos, mas não em todos. Isso é tecnicamente saudável: o trabalho não vende milagre. Mostra que algumas famílias têm comportamento suficientemente reconhecível em syscall traces, enquanto outras colapsam. Também reforça a importância de calibrar falsos positivos, porque um detector que “funciona” com FPR inflado pode ser inútil em operação.

A mensagem é: generalização defensiva precisa ser medida com honestidade. Uma métrica bonita sem controle de falso positivo é perfume em vazamento de gás.

13. Hardware, DRAM e vulnerabilidades físicas persistentes

A presença de trabalhos sobre ColumnDisturb mostra que vulnerabilidades de hardware continuam relevantes. Depois de RowHammer e RowPress, novos fenômenos de perturbação em DRAM reforçam que a pilha de segurança não termina no software.

ColumnDisturb é relevante porque muda o eixo da perturbação: não se limita a linhas, mas afeta colunas e aumenta o conjunto de células impactadas. As mitigações propostas, como ColumnKeeper, tentam oferecer garantias determinísticas ou probabilísticas com overhead baixo.

Para a estratégia de segurança, isso importa porque ataques de hardware têm ciclo de vida longo. Não se corrige silício implantado com a mesma velocidade de um pacote npm. Mitigações precisam equilibrar segurança, performance, energia, área e compatibilidade. O mundo físico cobra pedágio.

14. Segurança de infraestrutura crítica: EV charging, 5G O-RAN, microgrids e edifícios inteligentes

A pesquisa recente mostra forte expansão para domínios críticos: estações de carregamento de veículos elétricos, O-RAN 5G, microgrids, building automation, DALI, BACnet, robôs de patrulha, drones e sistemas embodied AI.

Esses ambientes têm características comuns:

• interligam rede digital e processo físico;
• usam múltiplas camadas de telemetria;
• dependem de protocolos especializados;
• sofrem com legado;
• têm restrições de latência e disponibilidade;
• podem gerar dano material ou operacional;
• exigem detecção cross-layer.

No caso de EV charging, a tendência é combinar NIDS e HIDS para capturar ataques cibernéticos e físicos. Em O-RAN, a fusão de telemetria rádio e fluxos de rede promete ganhos seletivos, mas os resultados mostram limites: nem toda fusão melhora desempenho. Em microgrids, surgem defesas federadas resilientes a comportamento bizantino e ataques furtivos de falsa injeção de dados. Em edifícios inteligentes, BACnet e DALI mostram que segurança também depende de usabilidade, nomes compreensíveis, observabilidade física e ferramentas educacionais seguras.

A tendência é clara: infraestrutura crítica exige segurança contextual. Não há um modelo universal que resolva tudo. Cada domínio tem sua gramática.

15. Segurança e privacidade de prompts reais

Um trabalho recente analisando perguntas reais de usuários a LLMs sobre segurança e privacidade mostra outro ângulo relevante: pessoas já usam modelos como consultores de segurança. Elas perguntam sobre contas, computadores, ataques, privacidade e proteção digital. Modelos comerciais podem responder melhor que open-weight em certos cenários, mas ainda podem ser inconsistentes entre execuções.

Isso cria uma camada social da cibersegurança com IA. O usuário comum está terceirizando decisões de segurança para sistemas probabilísticos. Se as respostas variam, a confiança vira loteria. Um conselho de segurança inconsistente pode produzir práticas ruins: desativar proteção, ignorar atualização, confiar em ferramenta falsa, configurar errado, expor segredo ou cair em golpe.

A segurança de LLMs, portanto, não é só assunto de empresas. É infraestrutura cognitiva do público.

16. O paradoxo dos datasets de trajetória hacker

Datasets de trajetórias de operadores LLM em cibersegurança são valiosos porque capturam como agentes e humanos usam modelos em tarefas ofensivas e defensivas. Mas eles também revelam um paradoxo: para melhorar agentes, coleta-se contexto sensível. Esse contexto pode incluir credenciais, hostnames, tokens, domínios de produção, prompts operacionais, estratégias internas e rastros de investigação.

Se esses dados ficam concentrados em poucos provedores de modelos, surge um risco sistêmico. O provedor passa a acumular parte significativa da memória operacional ofensiva e defensiva do mercado. Um vazamento, abuso interno, mudança regulatória, captura geopolítica ou uso indevido pode gerar impacto enorme.

A resposta técnica sugerida por parte da literatura é fortalecer modelos especializados on-premise ou dentro do trust boundary da organização. Isso não elimina riscos, mas reduz concentração. A produtividade do agente precisa ser equilibrada contra soberania operacional e confidencialidade.

O prompt virou ativo sensível. O histórico de tool calls virou inteligência. O log do agente virou cofre.

17. Implicações para empresas e equipes de segurança

Para empresas, as novidades sugerem uma agenda prática de adoção cuidadosa.

Primeiro, agentes devem ser testados em ambientes controlados antes de tocar produção. Isso inclui cyber ranges, digital twins, sandboxes e escopos restritos. Segundo, cada ação precisa gerar evidência: input, raciocínio, ferramenta, output, decisão, aprovação e resultado. Terceiro, a organização precisa separar tarefas de baixo risco das de alto risco. Nem tudo pode ser delegado. Quarto, modelos devem ser avaliados não só por acurácia, mas por segurança operacional: falsos positivos, falsos negativos, consistência, respeito ao escopo, reversibilidade e capacidade de pedir ajuda.

Para pentest, a recomendação é tratar agentes como força multiplicadora, não substituto pleno. Eles podem acelerar enumeração, organizar raciocínio, sugerir caminhos, gerar relatórios e repetir testes. Mas decisões sobre exploração real, impacto, pivoting, persistência, coleta de dados e interação com sistemas sensíveis precisam de controle humano.

Para blue team, agentes podem ajudar em triagem, enriquecimento, classificação ATT&CK, sugestão de resposta e documentação. Mas contenção automática exige catálogo de ações, limites, risk scoring e aprovação.

Para supply chain, backport verificado e patch evidence devem entrar no radar. Para IA interna, prompt injection e dados multimodais precisam ser considerados desde a arquitetura, não como filtro colado no final.

18. Arquitetura recomendada para uma operação cyber-AI madura

Uma arquitetura moderna de cibersegurança com IA deveria conter as seguintes camadas:

18.1 Camada de escopo e política

Define autorização, ativos permitidos, horários, tipos de ação, limites de impacto, credenciais, exclusões, regras legais e responsáveis humanos.

18.2 Camada de contexto

Integra SIEM, EDR, XDR, CMDB, inventário, topologia, identidade, vulnerabilidades, tickets, threat intelligence, playbooks e documentação interna.

18.3 Camada de agentes especializados

Inclui agentes de enumeração, triagem, análise de logs, classificação ATT&CK, priorização, resposta, relatório, verificação e revisão adversarial.

18.4 Camada de memória e evidência

Registra trajetória, decisões, outputs, artefatos, hashes, timestamps, fontes, comandos autorizados, aprovações e rollback.

18.5 Camada de validação

Inclui LLM-as-judge, verificadores determinísticos, rubricas operacionais, ground truth, validação humana e testes de regressão.

18.6 Camada adversarial

Testa prompt injection, benchmark hacking, manipulação de outputs, evasão, poisoning, reward hacking, abuso de ferramentas e quebra de escopo.

18.7 Camada de execução controlada

Expõe ferramentas por adaptadores governados, com permissões mínimas, simulação quando possível, aprovação por risco e logs append-only.

18.8 Camada de governança

Define auditoria, retenção, privacidade, conformidade, segregação de funções, revisão periódica, métricas de eficácia e resposta a incidentes causados pelos próprios agentes.

Essa arquitetura não é luxo. É cinto de segurança para dirigir um motor novo em estrada molhada.

19. Principais riscos técnicos emergentes

19.1 Falsa autonomia

Sistemas são vendidos como autônomos, mas falham sem supervisão. Isso gera relaxamento humano e aumento de risco.

19.2 Reward hacking

Agentes aprendem a passar no verificador em vez de resolver a tarefa. Benchmarks frágeis contaminam pesquisa e produto.

19.3 Vazamento temporal

Modelos de priorização parecem bons porque usam evidência que só existia depois da decisão. Isso destrói validade prospectiva.

19.4 Prompt injection multimodal

Texto, imagem, áudio, screenshot, PDF e interface podem carregar instruções adversariais.

19.5 Dados operacionais concentrados

Prompts e trajetórias de segurança enviados a provedores externos podem conter inteligência sensível.

19.6 Remediação sem prova

Patches aplicados sem evidência de bloqueio de exploração e preservação funcional podem gerar falsa segurança.

19.7 Defesa impulsiva

Agentes defensivos podem superreagir e causar dano operacional se não houver catálogo de ações e aprovação por risco.

19.8 IA atacante como classe distinta

Honeypots, iscas e decepções desenhadas para humanos podem falhar diante de agentes LLM, que percebem e agem de maneira diferente.

20. O que há de realmente novo

As novidades recentes não são apenas melhorias incrementais. Elas apontam para cinco rupturas.

A primeira é a passagem do pentest assistido para o pentest agentic avaliado em ambientes realistas.

A segunda é a substituição da métrica isolada por cadeias de evidência. Vulnerabilidade, exploit, patch, resposta e detecção precisam ser demonstrados, não apenas afirmados.

A terceira é a entrada definitiva da cibersegurança em sistemas cyber-físicos com IA, onde teste, ataque e defesa afetam processos materiais.

A quarta é a percepção de que agentes de IA são também atacantes, defensores e alvos. Eles não apenas ajudam humanos. Eles se tornam parte do conflito.

A quinta é a maturidade metodológica: benchmarks, leakage, verificação, auditabilidade e governança passam a ser tão importantes quanto performance.

Conclusão

A cibersegurança de 2026 está deixando de ser um conjunto de ferramentas operadas por humanos e se tornando um ecossistema de agentes supervisionados. Essa mudança não elimina o humano. Pelo contrário, aumenta a importância do humano como definidor de escopo, julgador de risco, auditor de evidência e responsável final.

O futuro próximo não será dominado por um “hacker robô” onipotente nem por um “SOC autônomo” infalível. Será dominado por sistemas híbridos, nos quais agentes fazem parte do trabalho pesado, mas sob trilhos de governança, validação e contenção.

A grande pergunta não é se a IA vai fazer pentest, defender redes ou corrigir vulnerabilidades. Isso já começou. A pergunta real é outra: conseguiremos fazer esses agentes provarem o que fizeram, respeitarem limites, reconhecerem incerteza e falharem de modo seguro?

Na nova cibersegurança, capacidade sem evidência é ruído. Autonomia sem governança é risco. E velocidade sem controle é apenas uma vulnerabilidade correndo de tênis novos.