IntelForge (Multi-Agent LLM para Enriquecimento de CTI)

Nota da pasta de LLMs do capítulo 17, dedicada à automação do ciclo de CTI.
Apresenta o IntelForge, arquitetura multi-agente que leva um indicador cru de um feed ou relato até um objeto enriquecido e pronto para o TIP.
Dialoga com a nota de CTI-LLM desta pasta, com o pipeline de coleta e enriquecimento da seção 02 do capítulo 2 e com a contextualização de indicadores da seção 03.

1. Contexto e Posicionamento na Biblioteca

O enriquecimento é a etapa em que um indicador bruto, um domínio solto em um feed, vira contexto acionável: de que infraestrutura faz parte, qual campanha o usou, qual a reputação, quais TTPs o cercam. A nota sobre enriquecimento automatizado da seção 09 do capítulo 9 mostra o caminho clássico com chamadas de API determinísticas, que funciona bem mas produz pouco contexto narrativo e não lê relatos não estruturados. O IntelForge propõe completar essa lacuna com uma arquitetura multi-agente, na qual modelos de linguagem especializados por papel colaboram para transformar matéria-prima difusa em inteligência estruturada e verificada.

A posição desta nota na pasta é intencional: o CTI-LLM concentrava várias tarefas em um modelo único, e o IntelForge divide o mesmo problema entre agentes com responsabilidades separadas, o que permite validar cada estágio de forma independente. O ganho central não é só automação, é a possibilidade de auditar o pipeline estágio por estágio, atribuindo a cada agente métricas próprias de qualidade e pontos de falha conhecidos.

2. A Arquitetura Multi-Agente e os Papéis dos Agentes

O desenho de referência organiza o trabalho em quatro papéis principais, cada um com instrução de sistema, ferramentas permitidas e formato de saída próprio. A separação de papéis segue o princípio de que um agente que extrai e o agente que verifica não podem ser o mesmo contexto de instrução, pois a verificação perde independência quando quem julga é quem produziu.

Além dos quatro papéis, implementações do tipo costumam incluir um coordenador leve, responsável por enfileirar documentos, controlar retrys e aplicar limites de custo, e por aplicar as regras de manuseio TLP do material que circula entre agentes. O coordenador não decide conteúdo, decide fluxo, e essa separação evita que a lógica de orquestração contamine o julgamento técnico dos papéis.

A escolha do modelo por papel também é decisão de arquitetura e não detalhe. O extrator exige compreensão densa de texto longo e se beneficia do modelo mais capaz disponível, enquanto o normalizador e o verificador sintático executam trabalho quase determinístico que um modelo pequeno local resolve com custo menor. Distribuir capacidade dessa forma, reservando o modelo grande para o papel que realmente precisa dele, costuma reduzir o custo total do pipeline em metade sem perda mensurável de qualidade, e permite que o papel crítico rode em modelo dedicado e versionado enquanto o resto usa instâncias compartilhadas.

3. Pipeline de Indicador Cru a Indicador Enriquecido

O pipeline completo transforma entrada difusa em saída estruturada em sete passos, cada um com dono claro e artefato verificável. A descrição abaixo serve de esqueleto para implementação, e os pontos de decisão humana ficam explícitos porque são o que sustenta a confiança no produto final.

Pipeline de enriquecimento IntelForge (visão de fluxo)
1. Coletor ingere o documento e grava {fonte, url, timestamp, tlp, hash}.
2. Extrator lê o texto e devolve candidatos em JSON, cada item com evidence.
3. Normalizador deduplica contra o TIP, aplica defang padrão e tipa os valores.
4. Verificador cruza cada candidato com a fonte original e valida sintaxe.
5. Verificador consulta enriquecimento externo: DNS passivo, WHOIS, reputação.
6. Escritor monta o objeto STIX com relações (indicator, relationship, observable).
7. Escritor grava no MISP ou OpenCTI e notifica o revisor humano da fila.

Dois detalhes do fluxo evitam os erros mais comuns de implementações apressadas. A deduplicação na etapa 3, antes da verificação, evita gastar tokens de inferência com itens já conhecidos no TIP, o que em feeds ruidosos representa a maioria. E a notificação do revisor humano na etapa 7 transforma o pipeline em fila assistida e não em gravadora automática, com o revisor podendo aprovar em lote os itens de baixo risco e inspecionar individualmente os marcados como pendentes pelo verificador.

O desenho do pipeline também define o contrato de dados entre estágios, e essa definição vale tanto quanto os prompts. Cada artefato que circula carrega um envelope com identificadores do documento de origem, versão do modelo e do prompt usados, carimbo de tempo e etiqueta TLP herdada, e qualquer estágio que produza saída precisa escrever esse envelope antes de enfileirar. Sem o envelope, a depuração de um item rejeitado exige reexecução manual de todo o caminho, e com ele a triagem de incidente de pipeline vira consulta a três campos. Times que implementam o envelope desde o primeiro dia instrumentam o painel de métricas da seção 5 sem esforço adicional, porque cada métrica é um agregado sobre campos do envelope.

4. Exemplo de Fluxo Completo com Resultado

O exemplo abaixo acompanha um indicador do ingest ao registro final, mostrando o que cada agente produz. O material é sintético e serve de gabarito para teste de regressão do pipeline, exercício que todo time deve rodar a cada mudança de prompt ou de modelo.

Entrada (post de blog de pesquisa, trecho):
"... a infraestrutura da campanha reutiliza o domínio cdn-stats[.]top,
que resolve para 203.0.113.77 e serve o loader assinado com o hash
9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08.
A persistência é feita via tarefa agendada criada no primeiro boot."

Extrator (JSON):
{"iocs":[{"type":"domain","value":"cdn-stats[.]top",
          "evidence":"a infraestrutura da campanha reutiliza o domínio"},
         {"type":"ip","value":"203.0.113.77",
          "evidence":"que resolve para 203.0.113.77"},
         {"type":"sha256","value":"9f86d081...0f00a08",
          "evidence":"loader assinado com o hash"}],
 "techniques":[{"attck_id":"T1053.005","name":"Scheduled Task",
          "evidence":"persistência via tarefa agendada"}]}

Verificador (resumo):
- domínio cdn-stats[.]top: sintaxe válida, evidence ok, TLD .top marcado
  de risco, DNS passivo mostra 4 subdomínios históricos -> ACEITO
- ip 203.0.113.77: pertence à faixa de documentação RFC 5737 -> REJEITADO
  (falso IOC de exemplo, típico de material didático)
- sha256: formato válido e hash não visto no TIP -> ACEITO

Escritor (registro final, resumido):
{"type":"indicator","pattern":"[domain-name:value = 'cdn-stats[.]top']",
 "labels":["loader","campanha-cdn"],"tlp":"amber",
 "confidence":70,"valid_until":"<data +90d>",
 "relationship":"indicates T1053.005 Scheduled Task"}

O resultado ilustra o valor do verificador em ação: o IP de faixa de documentação, presente no texto de origem, seria um falso IOC permanente se o pipeline gravasse tudo que o extrator recorta. A rejeição com justificativa registrada também serve de rótulo de treino para melhorar o extrator no próximo ciclo, fechando o laço de melhoria contínua descrito na seção seguinte.

5. Avaliação de Qualidade do Produto

Avaliar um pipeline multi-agente exige medir cada estágio e o produto final, e não apenas a impressão de que está funcionando. As métricas abaixo formam o painel mínimo de qualidade, com responsável indicado e cadência sugerida de revisão semanal e mensal conforme o indicador.

A taxa de rejeição é a métrica mais diagnóstica das sete. Rejeição próxima de zero normalmente significa que o verificador está aprovando tudo, e não que o extrator ficou perfeito, sintoma clássico de prompt de verificação fraco. Rejeição acima de 15% sugere que o extrator alucina ou que a fonte está degradada, e a investigação começa pela amostra de rejeitados, que deve ser lida por humano toda semana com anotação da causa.

O painel só tem valor quando comparado a um baseline manual medido antes da automação, e esse é o ponto que os projetos costumam pular. Antes de ligar o pipeline, o time deve medir por uma semana quantos indicadores o processo manual extrai por hora de analista, com qual taxa de erro revisada e com qual custo de enriquecimento externo por item. As mesmas amostras passam pelo pipeline e os dois conjuntos de números entram no mesmo slide para a liderança, o que transforma a discussão de adoção em decisão sobre dados e não sobre entusiasmo com a tecnologia.

6. Risco de Alucinação e Mitigações

A alucinação em enriquecimento tem formatos específicos e é diferente do erro comum de digitação. O modelo pode inventar um subdomínio plausível que não existe no texto, atribuir a campanha errada por similaridade de nomes, gerar um hash que parece válido ou descrever uma infraestrutura agregando fatos de relatos diferentes sem marcar a fusão. Cada formato exige mitigação própria, e a tabela abaixo consolida as defesas que provaram funcionar em operação.

A mitigação estrutural mais eficaz é o desenho da verificação como papel independente com contexto limitado: o verificador recebe o item candidato, a evidence e o trecho original, e o prompt exige julgamento de suporte textual antes de qualquer consulta externa. Quando o mesmo modelo e o mesmo prompt fazem extração e verificação em sequência dentro de um único contexto, a taxa de autoconfirmação sobe e a verificação vira formalidade, o que é pior do que não verificar porque cria falsa sensação de controle.

O gabarito de prompt do verificador abaixo mostra as três perguntas que toda verificação responde em ordem fixa, com decisão terminológica padronizada para que as métricas da seção 5 sejam comparáveis ao longo do tempo.

Sistema (verificador): para cada candidato, responda em ordem:
1. SINTAXE: o valor é sintaticamente válido para o tipo declarado?
2. SUPORTE: a evidence citada existe no trecho original e sustenta o item?
3. VEREDITO: ACEITO (suporte pleno), PENDENTE (suporte parcial ou
   ambiguidade) ou REJEITADO (sem suporte ou malformado).
Devolva JSON {"value","type","syntax","support","verdict","reason"}.
Regras: não consulte conhecimento externo antes do item 2; nunca
reescreva o valor; REJEITADO exige reason com a frase exata do original
que deveria sustentar o item e não sustenta.

7. Erros Comuns e Pontos de Atenção

• Automatizar a gravação sem fila humana: o produto enriquecido precisa de revisão proporcional ao risco do uso, e feed automático direto no bloco de firewall replica erro de extração em escala.
• Orquestrar com prompts entrelaçados: agente que herda o contexto completo do anterior deixa de ser independente; cada papel deve receber apenas o necessário ao seu julgamento.
• Ignorar TLP no fluxo: material de fórum pode ser verde e o enriquecimento com fontes comerciais pode restringir redistribuição; a etiqueta acompanha o item de ponta a ponta.
• Medir custo só em tokens: o custo real inclui chamadas de API de reputação, retenção de logs e horas de revisão; orçamento por documento evita surpresa no fim do mês.
• Deixar o verificador se autoaprovar: prompts de verificação precisam de teste adversarial periódico, com candidatos envenenados de propósito no ambiente de teste.
• Esquecer a expiração: todo indicador entra com valid_until, porque enriquecimento sem ciclo de vida vira acúmulo de falsos positivos antigos, problema já tratado na nota de ciclo de vida da seção 03.
• Rodar verificação e extração no mesmo serviço sem isolamento: falha de fila ou reinício derruba os dois papéis ao mesmo tempo, e a fila de revisão fica cega exatamente quando há volume anômalo, o cenário em que o pipeline mais importa.
• Revisar em lote sem amostragem: aprovar tudo de baixo risco de uma vez só é aceitável quando há auditoria amostral posterior; sem a amostra semanal auditada, o lote vira ponto cego permanente do controle de qualidade.
• Atualizar modelo sem rodar o gabarito do exemplo da seção 4: qualquer troca de versão precisa do teste de regressão completo, pois a nova versão pode passar no agregado e falhar exatamente nos casos de rejeição que sustentam o controle.
• Consultar enriquecimento externo sem cache: reputação de hash e WHOIS não mudam em minutos, e repetir a chamada por cada tentativa multiplica custo e latência sem ganho de qualidade.
• Usar o mesmo limite de contexto para todos os papéis: o extrator precisa de janela grande para o relato inteiro, e o verificador trabalha melhor com trecho curto, item e evidence, janela grande demais dilui a atenção da verificação.
• Tratar o revisor humano como gargalo a eliminar: a fila assistida é o controle de qualidade do produto, e a meta de projeto é reduzir o custo por revisão com boa marcação de pendências, nunca reduzir a revisão a zero.

8. Integração com o Restante da Biblioteca

O registro final do IntelForge entra no TIP pelo mesmo caminho do pipeline clássico da seção 08 do capítulo 2, com a diferença de chegar já classificado, relacionado e com evidência auditável, o que melhora a pontuação de qualidade discutida na nota de scoring de IOCs. As TTPs extraídas alimentam o controle CTI.6 do grupo ANA do framework CTH e as hipóteses de hunt do grupo HNT, e as relações montadas no grafo dão matéria-prima direta para o agrupamento de campanhas da seção 01 do capítulo 5.

Nas notas seguintes da pasta, o foco estreita da inteligência estruturada para a detecção: LLMCloudHunter converte relatos cloud em consultas de hunting nos logs de AWS, Azure e GCP, e a nota de Sigma generaliza a geração de regras com validação automatizada. A sequência deliberada é do dado ao julgamento, do indicador à detecção, e o IntelForge é o estágio que garante que as etapas seguintes partam de inteligência verificada e não de texto cru.