Agentic AI para Caça Autônoma e Defesa Adaptativa

Nota central da pasta de agentes autônomos do capítulo 17.
Conceitua agentic AI aplicada à defesa, contrasta copiloto e agente autônomo, descreve a arquitetura de planejador, executor, crítico e memória e delimita os limites de autonomia com human-in-the-loop.
Dialoga com a nota de iThelma desta pasta, com o ciclo de inteligência do framework CTH e com o controle AUT.5 de orquestração de resposta.

1. Contexto e Posicionamento na Biblioteca

O termo agentic AI descreve sistemas em que um modelo de linguagem não apenas responde, mas age: decompor um objetivo em passos, invocar ferramentas, observar o resultado e decidir o próximo passo, em loop, até alcançar o objetivo ou esgotar o orçamento. Aplicado à defesa, o conceito cobre a caça autônoma documentada na nota de iThelma e vai além, propondo que o sistema participe também do ajuste das próprias defesas conforme os achados da caça, o que caracteriza a defesa adaptativa que dá título à nota.

A posição da nota é de síntese conceitual antes da aplicação ofensiva da pasta. O leitor já viu um agente executar hunting, e esta nota organiza o vocabulário e a arquitetura que permitem avaliar qualquer sistema agêntico que apareça no mercado: quem planeja, quem executa, quem critica, onde está a memória e onde está o humano. A nota de Bounty Hunter que fecha o capítulo mostra o desenho aplicado ao lado ofensivo, emulando adversários para testar essas mesmas defesas.

2. Copiloto versus Agente Autônomo

A distinção entre copiloto e agente autônomo é a distinção entre quem propõe e quem decide. O copiloto sugere a consulta, o analista edita e executa; o copiloto redige o relatório, o analista valida cada afirmação; o copiloto responde à pergunta, o analista julga a relevância. O agente autônomo executa o próprio ciclo de decisão dentro dos limites definidos, com o humano supervisionando o resultado e não cada passo. A tabela abaixo contrasta os dois desenhos nos critérios de decisão operacional.

A escolha entre os desenhos não é questão de fé tecnológica, é questão de custo de erro por tipo de tarefa. Tarefas de alta frequência e baixo custo de erro, como redigir consulta e resumir telemetria, se encaixam em copiloto com ganho imediato. Tarefas de baixa frequência e alto custo de erro, como decidir contenção, ficam fora do alcance do agente autônomo mesmo em maturidade alta, e a defesa adaptativa bem desenhada é justamente a que separa com precisão quais ajustes o sistema propõe e quais aplica.

A migração prática entre os dois desenhos segue uma escada de autonomia com estágios verificáveis, e o programa deve registrar em qual estágio cada uso opera. No primeiro estágio, o copiloto propõe e o humano executa tudo. No segundo, o agente executa passos aprovados previamente e reporta. No terceiro, o agente executa o ciclo de caça completo com supervisão assíncrona. No quarto, o agente opera continuamente em classes de ação de leitura, com revisão amostral. Cada mudança de estágio exige métrica de erro da etapa anterior acima do limiar acordado, e a tentação de pular estágios aparece sempre que um incidente cria pressa, exatamente o momento em que erro autônomo custa mais caro.

3. Arquitetura Típica: Planejador, Executor, Crítico e Memória

A arquitetura de referência distribui as funções cognitivas do sistema entre quatro componentes com responsabilidades distintas, e a separação existe para que cada função seja avaliável e substituível de forma independente. O planejador decompõe o objetivo e mantém o roteiro, o executor converte passos em chamadas de ferramenta, o crítico revisa as saídas contra evidência e o memória preserva estado entre iterações e entre execuções.

Arquitetura agêntica de referência (fluxo simplificado)
Objetivo + contexto inicial
   |
   v
[Planejador]  -> plano em passos com critério de sucesso por passo
   |
   v
[Executor]    -> invoca ferramentas (SIEM, EDR, TIP, enriquecimento)
   |             e devolve observações brutas
   v
[Crítico]     -> valida observação contra evidência, aponta lacuna
   |             e devolve correção ou aprovação do passo
   v
[Memória]     -> grava plano, passos, observações e decisões
   |             consultável pelas próximas iterações
   |
   +--- loop até: objetivo alcançado, orçamento esgotado
                ou escalonamento ao humano

[Humano]      -> define objetivo e limites, recebe escalonamentos,
                 aprova ações de efeito persistente

O crítico é o componente que mais diferencia implementações sérias. Sem crítico, o sistema confere a própria saída no mesmo contexto e a autoconfirmação prevalece, o mesmo problema documentado na nota de IntelForge para o papel de verificador. Com crítico em contexto separado, recebendo o passo, a observação e a evidência bruta, a taxa de conclusão sem suporte cai de forma mensurável, e a arquitetura ganha um ponto natural de instrumentação para medir a qualidade de cada etapa.

O produto do planejador merece formato exemplar, porque é o artefato que o supervisor avalia antes de liberar a execução. O roteiro abaixo mostra a decomposição de um objetivo em passos com critério de sucesso, e a regra de qualidade é que cada critério precisa ser verificável pelos dados, e não por impressão do executor.

Plano gerado pelo planejador (resumido)
Objetivo: avaliar indício de movimento lateral para servidores de arquivo
Passo 1: inventariar contas com logon tipo 3 nos servidores-alvo em 7 dias
         critério: lista de pares conta-servidor com contagens
Passo 2: comparar com baseline de administradores aprovados
         critério: conjunto de contas fora do baseline
Passo 3: para cada conta fora do baseline, recuperar processo pai da
         sessão na EDR
         critério: árvore de processo por conta suspeita
Passo 4: correlacionar horário com autenticação de origem
         critério: tabela final com conta, origem, horário e processo
Orçamento: 12 iterações, 4 consultas SIEM, 4 consultas EDR
Escalonamento: achado em servidor de arquivo crítico interrompe o plano

A memória tem duas camadas com propósitos distintos e confundi-las é erro de projeto comum. A memória de execução guarda o estado da caça corrente, plano, passos e observações, e vive só enquanto a execução vive. A memória de conhecimento guarda o que sobrevive às execuções, baselines do ambiente, consultas que funcionaram, falsos positivos conhecidos e lições das caças anteriores, e é ela que faz o sistema melhorar com o uso. Sem a camada de conhecimento, cada caça recomeça do zero e a promessa de adaptação não se realiza.

A tabela abaixo contrasta as duas camadas da memória com os critérios de projeto que cada uma exige. A observação prática é que a camada de conhecimento é um ativo de dados do programa, com dono, esquema e ciclo de revisão, e não um detalhe de implementação do agente.

A observabilidade do sistema agêntico se apoia na mesma infraestrutura de registro do iThelma, elevada a padrão de plataforma: todo passo grava objetivo, plano vigente, ferramenta invocada, parâmetros, observação, veredito do crítico e decisão tomada. Esse registro único serve a três consumidores ao mesmo tempo, o depurador de engenharia, o auditor de conformidade e o analista que precisa entender por que o sistema propôs um ajuste, e desenhar o registro para um dos três sem os outros dois é a dívida que cobra juros no primeiro incidente.

4. Defesa Adaptativa: Ajustar Detecções Conforme os Achados

A defesa adaptativa fecha o circuito entre descoberta e melhoria: o que a caça aprende retroalimenta o catálogo de detecções, os baselines e as prioridades de coleta. O ciclo adaptativo de referência tem quatro movimentos, executados com proporção humana definida por classe de mudança: caçar e descobrir, propor ajuste, validar o ajuste e implantar com monitoramento. O exemplo abaixo descreve o ciclo em etapas para um achado real de hunting.

Ciclo de defesa adaptativa (exemplo em etapas)
1. Caça autônoma encontra uso de RMM não homologado com nome alterado
   em 2 hosts, achado confirmado por revisão humana.
2. Propostas geradas pelo sistema:
   a. regra de detecção: processo assinado por editor RMM com Image
      fora de caminho padrão, janela de 24 horas;
   b. ajuste de prioridade de coleta: registrar diretórios de conteúdo
      de usuário no inventário de execução de script;
   c. item de inteligência: editor RMM acrescentado ao perfil de
      técnicas de acesso do ambiente.
3. Validação humana: regra testada contra 30 dias de histórico,
   3 disparos legítimos de administração, exceção registrada por host
   de administração aprovado.
4. Implantação: regra entra no catálogo com dono e data, item de
   inteligência entra no TIP e o ciclo seguinte de caça usa a nova
   cobertura como base para formular hipóteses complementares.

O exemplo mostra a fronteira correta de autonomia: o sistema propõe com evidência, o humano valida contra dados reais e implanta com governança, e o ciclo volta a rodar com o ambiente modificado. Adaptativo não significa autorregulado; significa que o intervalo entre descoberta e melhoria de detecção encurta de semanas para dias, com a qualidade garantida pelos mesmos controles do catálogo e do pipeline de inteligência que já governam as mudanças manuais.

5. Avaliação de Sistemas Agênticos em Produção

Avaliar um sistema agêntico exige medir o sistema inteiro, e não só a qualidade das respostas do modelo. As métricas cobrem quatro dimensões, eficácia do objetivo, qualidade dos passos, segurança operacional e custo, e o painel abaixo consolida o conjunto mínimo para um sistema que executa caça com proposta de ajuste de detecção.

Duas métricas do quadro são específicas de sistemas agênticos e merecem explicação. O escalonamento indevido mede o contrário do erro perigoso: passos que o agente manda para o humano por falta de confiança, e taxa alta indica que o desenho de limites está mal calibrado e transforma supervisão em filtro de ruído, o que leva o supervisor a aprovar sem ler, o pior dos mundos. A violação de guardrail, por sua vez, deve ser zero absoluto, e qualquer tentativa, mesmo bloqueada, indica que o planejador entende mal o contrato de ferramentas e precisa de correção antes de continuar operando.

6. Limites de Autonomia e Human-in-the-Loop

Os limites de autonomia são decisão de política e não de capacidade técnica, e a tabela abaixo organiza as classes de ação pelo nível de supervisão exigido. A regra orientadora é proporcionalidade: quanto mais reversível e barato o erro, mais autonomia se justifica; quanto mais persistente o efeito, mais humana é a decisão obrigatória.

O human-in-the-loop bem implantado tem formato verificável, e não é apenas intenção declarada em documento. Cada ponto de decisão humana aparece no transcript como passo de aprovação com carimbo, o escalonamento tem SLA definido para não travar o ciclo sem necessidade, e a revisão amostral dos passos autônomos alimenta a avaliação de qualidade do sistema. Quando o fluxo de aprovação se torna gargalo real, a resposta correta é classificar melhor as ações para reduzir aprovações desnecessárias, e nunca desligar a aprovação das classes de alto efeito.

7. Erros Comuns e Pontos de Atenção

• Confundir orquestração com agência: playbook de SOAR executa sequência desenhada, agente decide a sequência, e chamar de autônomo um workflow encadeado infla a expectativa e descredita o programa quando o resultado não vem.
• Deixar o crítico no mesmo contexto do executor: autoconfirmação estrutural, e o remédio é contexto separado com acesso à evidência bruta, não prompt mais severo no mesmo agente.
• Crescer a autonomia sem medir primeiro: cada nova classe de ação autônoma precisa de métrica de erro própria medida em supervisão antes da liberação, e a liberação sem métrica é aporte de risco sem contrato.
• Memória de conhecimento sem curadoria: lições erradas de caças mal conduzidas se acumulam como fato, e a memória precisa de revisão periódica com direito a correção e expiração.
• Adaptar detecção sem governança de catálogo: regra proposta pela máquina entra pelo mesmo processo do AUT.3, com dono, data e revisão, e catálogo paralelo sem dono é dívida técnica instantânea.
• Achados que só a máquina interpreta: todo achado adaptativo deve ser inteligível por outro analista via transcript, porque dependência de interpretação opaca quebra a auditoria e trava a confiança do time.
• Orçamento de custo sem teto por objetivo: loop agêntico sem limite consome tokens e janelas de busca até falhar, e o teto por execução com encerramento documentado é o guardrail mínimo.

8. Integração com o Restante da Biblioteca

A arquitetura descrita consome e alimenta os grupos do framework CTH de forma explícita: o planejador usa o inventário do TH.1 e as baselines do TH.2, o executor opera sobre a coleta do grupo DAT e o catálogo do AUT.3, o crítico aplica o padrão de evidência da análise do grupo ANA e as propostas de detecção seguem o fluxo de métricas do grupo MET para provar o efeito. A integração com o AUT.5 merece atenção especial, porque a orquestração de resposta é o limite natural onde a proposta agêntica vira ação com efeito real sobre produção.

No arco do capítulo, esta nota fecha o lado defensivo da autonomia e prepara a leitura da emulação ofensiva: a nota de Bounty Hunter aplica a mesma arquitetura de agentes ao lado adversário, com perfis de ator competindo contra as detecções implantadas, e o leitor pode avaliar os dois lados com o mesmo vocabulário de planejador, executor, crítico e memória. A pergunta de projeto que permanece aberta em toda implementação, defensiva ou ofensiva, é a mesma que abre esta nota: qual classe de decisão está autorizada a rolar sem humano na sala, e como essa autorização é auditada depois.