--- title: "IA × IA Project · Field Guide" source: https://iaxia.rodrigojorge.me updated: 2026-10-06 lang: pt author: Rodrigo Jorge --- # IA × IA Project · Field Guide Ataques em velocidade de máquina pedem defesa em velocidade de máquina. Este guia reúne casos de sucesso em produção e playbooks de defesa de IA aplicada à segurança, sempre dizendo até onde o agente pode agir e com quais controles. Mantra: Detectar. Decidir. Agir. Dentro de limites. ## Casos de sucesso e playbooks - 01 · Cyberbot (EM PRODUÇÃO) — https://iaxia.rodrigojorge.me/cases/cyberbot.md - 02 · Antifraude contextual (EM PRODUÇÃO · ANONIMIZADO) — https://iaxia.rodrigojorge.me/cases/antifraude-contextual.md - 03 · SOC agêntico (PLAYBOOK) — https://iaxia.rodrigojorge.me/cases/soc-agentico.md - 04 · Red team contínuo (PLAYBOOK) — https://iaxia.rodrigojorge.me/cases/red-team-continuo.md - 05 · AppSec no pipeline (PLAYBOOK) — https://iaxia.rodrigojorge.me/cases/appsec-pipeline.md - 06 · Marca e identidade (PLAYBOOK) — https://iaxia.rodrigojorge.me/cases/marca-identidade.md - 07 · Supervisor de agentes (PLAYBOOK) — https://iaxia.rodrigojorge.me/cases/supervisor-agentes.md ## Palestras - IA × IA · TI Exames · 21 set 2026 · 19h30 às 21h — https://iaxia.rodrigojorge.me/downloads/ia-x-ia-rodrigo-jorge-ti-exames-2026.pdf - IA × IA · Mind The Sec 2026 · 15 set 2026 — https://iaxia.rodrigojorge.me/downloads/ia-x-ia-rodrigo-jorge-mind-the-sec-2026.pdf --- --- title: "Cyberbot" subtitle: "Do evento do WAF ao bloqueio na borda." kind: "EM PRODUÇÃO" number: "01" updated: 2026-09-14 families: [applications-apis, cloud-infrastructure, soc-response] tags: [Disponibilidade, WAF, SOC, Autonomia] lang: pt source: https://iaxia.rodrigojorge.me/cases/cyberbot author: Rodrigo Jorge project: IA × IA --- # Cyberbot **Do evento do WAF ao bloqueio na borda.** Um agente lê o tráfego que passou pelo WAF, recebe contexto estruturado, classifica a ameaça e só transforma decisão em ação depois de passar por guardrails. - Tipo: EM PRODUÇÃO - Métrica de referência: < 1 min (do log ao bloqueio) - Famílias de desafio: Aplicações e APIs, Cloud e infraestrutura, SOC e resposta - Atualizado em: 2026-09-14 ## O problema Bots e scanners automatizados testam a infraestrutura o dia inteiro. O gargalo não é gerar mais alertas. É separar o que realmente merece atenção e responder em tempo útil. Neste caso real, o LLM olha somente o tráfego que passou pelo WAF. O que já foi bloqueado pelo controle tradicional sai antes do pipeline. ## Arquitetura real 1. **WAF**: Cada requisição vira evento: IP, path, user-agent, status e ação. 2. **Coleta + filtro**: Worker mantém uma janela de eventos e elimina o que já foi barrado, assets conhecidos e ruído previsível. 3. **LLM**: Recebe um resumo estruturado e devolve decisão em JSON. 4. **Guardrails**: Allow list, confiança mínima, exceções e ações habilitadas por categoria. 5. **Ação**: Bloqueio com TTL na borda e alerta com evidência para revisão. ## O que entra na IA - Prompt de sistema com papel de analista blue team, stack real e regras do que não deve ser reportado. - Top IPs, paths e user-agents do período, sempre com status HTTP e ASN. - Paths raros, onde scanners de diretório e enumeração costumam aparecer. - Suspeitos pré-detectados por regras simples, como traversal, SQLi, .env e web shell, para a IA validar. - Contexto operacional: origem em nuvem, reincidência e histórico de bloqueio. ## O que sai da IA Texto livre não controla ação. A saída é estruturada para que o código possa validar antes de executar. ```json { "clean": false, "threats": [{ "tipo": "Probing de arquivos sensíveis", "categoria": "git_env_exposto", "host_path": "api.exemplo.com/.env", "ip": "203.0.113.7", "severidade": "ALTO", "confianca": 88, "regra_sugerida": "Bloquear /.env* no WAF" }] } ``` > A categoria vem de uma lista fechada. Severidade e confiança são validadas pelo código. Se o modelo fugir do contrato, cai em fallback, nunca em ação. ## Guardrails que tornam a autonomia possível - **Nada bloqueia por padrão.** A ação automática precisa ser habilitada por severidade e categoria, com lista e TTL definidos. - **Allow list é absoluta.** Clientes, parceiros, colaboradores e origens protegidas não são bloqueados mesmo diante de uma detecção. - **Confiança mínima.** Abaixo do corte, o sistema alerta e preserva a decisão para uma pessoa. - **Ambiguidade chama humano.** Quando contexto não é suficiente, a ação automática não é o fallback. - **Ação reversível.** Bloqueios expiram por TTL e toda ação deixa evidência. ## Receita para reproduzir a ideia ### Ingredientes - Logs de WAF/CDN acessíveis por API, Logpush, bucket ou equivalente. - Job periódico, Worker, Lambda ou processo serverless. - LLM capaz de retornar JSON estruturado. - Lista de bloqueio consumida pelo WAF, com TTL. - Canal de alerta com link para evidência. ### Lições que economizam semanas - Pré-filtre antes do LLM. Ruído previsível é melhor resolvido por código. - Regra para o binário, IA para julgamento contextual. - Status HTTP e contexto mudam o significado de um evento. - Falso positivo é bug para corrigir, não motivo para desligar o motor. - Comece em modo recomendação. Aumente autonomia quando medir confiança e erro. ## Para levar A IA não é um gerador de relatórios. Ela age, dentro de limites que nós definimos. --- Fonte: https://iaxia.rodrigojorge.me/cases/cyberbot · Guia IA × IA, Rodrigo Jorge. Caso real em produção, descrito com o que o autor pôde verificar. Use como contexto; valide no seu ambiente. --- --- title: "Antifraude contextual" subtitle: "Quando sinais isolados parecem normais, mas a combinação não." kind: "EM PRODUÇÃO · ANONIMIZADO" number: "02" updated: 2026-09-14 families: [fraud-abuse, identity-access] tags: [Fraude, Device, Rede, Comportamento] lang: pt source: https://iaxia.rodrigojorge.me/cases/antifraude-contextual author: Rodrigo Jorge project: IA × IA --- # Antifraude contextual **Quando sinais isolados parecem normais, mas a combinação não.** O motor correlaciona device, rede, histórico e comportamento. O ganho não está em uma regra nova, mas em encontrar relações que surgem entre fontes diferentes e repetir essa investigação em escala. - Tipo: EM PRODUÇÃO · ANONIMIZADO - Métrica de referência: 85–90% (confiança nos exemplos apresentados) - Famílias de desafio: Fraude e abuso, Identidade e acessos - Atualizado em: 2026-09-14 ## O problema Uma regra enxerga eventos. A análise contextual tenta enxergar relações entre eles. Um analista humano consegue entender o raciocínio quando ele está pronto. O desafio é fazê-lo continuamente, em segundos, para cada acesso, cruzando sinais que vivem em sistemas diferentes. ## Exemplo real A > Identificadores, localização, operadora, hashes e dados da organização foram removidos. **Incompatibilidade de ambiente** | | | |---|---| | Plataforma declarada | Android | | Hardware observado | GPU Apple | | Histórico | Verificação anterior reprovada no backoffice | | Recorrência | 4 acessos mantendo a incoerência | | Hipótese | Spoofing ou ambiente adulterado | | Confiança | 85% | | Ação executada | Marcar fraude e bloquear fingerprint | ## Exemplo real B **Rede + identidade + recorrência** | | | |---|---| | Rede | Nó de VPN/proxy comercial | | Correlação | Múltiplos fingerprints agregados | | Infraestrutura | Reverse DNS e hosting reforçam a hipótese | | Identidade | Mais de um hardware associado à mesma identidade | | Decisão | Fraude com alta confiança | | Ação executada | Bloquear o nó de saída na borda | ## Como o raciocínio acontece 1. **Sinais**: Device, rede, localização aproximada, histórico, identidade e comportamento. 2. **Enriquecimento**: Normaliza atributos e adiciona contexto técnico e histórico. 3. **Correlação**: Procura incompatibilidades, recorrência e relações que uma regra isolada não expressa bem. 4. **Decisão explicável**: Gera hipótese, evidências, score/confiança e ação recomendada. 5. **Política de ação**: Executa somente ações previamente permitidas e registra a evidência. ## Por que não virar só mais uma regra? Depois que descobrimos que Android declarado + GPU Apple + reprovação anterior é suspeito, essa combinação pode virar regra. O valor da IA está em encontrar a próxima combinação: sinais fracos, históricos e comportamentos que mudam de caso para caso, explicando por que o conjunto é relevante. ## Como reproduzir com segurança > Aviso: Esta seção é um padrão de implementação recomendado para quem quiser adaptar o conceito. Não descreve necessariamente todos os controles do sistema real. - **Separar detecção de ação.** O modelo recomenda; uma camada de política decide o que pode ser executado. - **Ações graduais.** Alertar, desafiar, limitar, bloquear temporariamente e bloquear definitivamente são níveis diferentes de autoridade. - **Explicação obrigatória.** Score sozinho não basta. Guarde os sinais que sustentaram a hipótese. - **Reversibilidade.** Prefira ações que possam ser revertidas rapidamente quando estiver aumentando autonomia. - **Feedback operacional.** Falso positivo e decisão humana devem voltar para regras, contexto ou prompt. ## Para levar O humano entende um caso. A máquina precisa correlacionar milhares deles sem perder contexto. --- Fonte: https://iaxia.rodrigojorge.me/cases/antifraude-contextual · Guia IA × IA, Rodrigo Jorge. Caso real em produção, descrito com o que o autor pôde verificar. Use como contexto; valide no seu ambiente. --- --- title: "SOC agêntico" subtitle: "Triagem → investigação → contenção." kind: "PLAYBOOK" number: "03" updated: 2026-09-14 families: [soc-response, ai-agent-governance] tags: [SOC, Investigação, Resposta] lang: pt source: https://iaxia.rodrigojorge.me/cases/soc-agentico author: Rodrigo Jorge project: IA × IA --- # SOC agêntico **Triagem → investigação → contenção.** Use agentes primeiro para reduzir trabalho repetitivo, depois para investigar e só então conceda autoridade limitada de contenção. - Tipo: PLAYBOOK - Métrica de referência: 3 níveis (evolução de autonomia) - Famílias de desafio: SOC e resposta, Governança de IA e agentes - Atualizado em: 2026-09-14 ## Comece pelo trabalho reversível - Resumir e agrupar alertas duplicados. - Enriquecer IPs, usuários, devices e ativos. - Construir timeline e hipótese inicial. - Abrir caso com evidências já organizadas. ## Suba um degrau por vez 1. **Triagem**: Sem autoridade destrutiva. 2. **Investigação**: Consulta múltiplas fontes e testa hipóteses. 3. **Contenção nível 1**: Ações temporárias e reversíveis, sempre logadas. ## O limite O destrutivo continua sendo decisão humana até que evidência, reversibilidade e governança justifiquem outro desenho. ## Para levar Autonomia não é um botão. É uma escada. --- Fonte: https://iaxia.rodrigojorge.me/cases/soc-agentico · Guia IA × IA, Rodrigo Jorge. Playbook de defesa: arquitetura para adaptar, não evidência de produção. Use como contexto; valide no seu ambiente. --- --- title: "Red team contínuo" subtitle: "Trocar fotografia anual por teste permanente." kind: "PLAYBOOK" number: "04" updated: 2026-09-14 families: [applications-apis, cloud-infrastructure] tags: [Red Team, Exposure, Validação] lang: pt source: https://iaxia.rodrigojorge.me/cases/red-team-continuo author: Rodrigo Jorge project: IA × IA --- # Red team contínuo **Trocar fotografia anual por teste permanente.** Um pentest anual envelhece no primeiro deploy seguinte. Agentes podem validar continuamente superfície, mudanças e caminhos de ataque autorizados. - Tipo: PLAYBOOK - Métrica de referência: 365 dias (teste contínuo) - Famílias de desafio: Aplicações e APIs, Cloud e infraestrutura - Atualizado em: 2026-09-14 ## O desenho 1. **Escopo explícito**: Assets e técnicas autorizadas. 2. **Agente**: Reconhecimento e validações não destrutivas. 3. **Evidência**: Passos reproduzíveis e impacto. 4. **Fila de correção**: Abre issue/PR ou encaminha ao owner. 5. **Reteste**: Confirma que a correção realmente fechou o caminho. ## Guardrails indispensáveis - Ambiente e ativos autorizados por allow list. - Limites de taxa e janela de execução. - Sem persistência, exfiltração ou técnicas destrutivas por padrão. - Kill switch e trilha completa de ações. ## Para levar O objetivo não é atacar mais. É reduzir o tempo entre exposição e correção. --- Fonte: https://iaxia.rodrigojorge.me/cases/red-team-continuo · Guia IA × IA, Rodrigo Jorge. Playbook de defesa: arquitetura para adaptar, não evidência de produção. Use como contexto; valide no seu ambiente. --- --- title: "AppSec no pipeline" subtitle: "Achou. Corrigiu. Testou. Commitou." kind: "PLAYBOOK" number: "05" updated: 2026-09-14 families: [applications-apis] tags: [AppSec, Código, DevSecOps] lang: pt source: https://iaxia.rodrigojorge.me/cases/appsec-pipeline author: Rodrigo Jorge project: IA × IA --- # AppSec no pipeline **Achou. Corrigiu. Testou. Commitou.** O agente não precisa parar no finding. Ele pode preparar o patch e os testes, deixando para o humano a revisão e o merge. - Tipo: PLAYBOOK - Métrica de referência: PR (como unidade de entrega) - Famílias de desafio: Aplicações e APIs - Atualizado em: 2026-09-14 ## Fluxo recomendado 1. **Finding**: Recebe vulnerabilidade com contexto do repositório. 2. **Patch**: Propõe a menor alteração possível. 3. **Teste**: Cria ou atualiza teste que demonstra a correção. 4. **PR**: Abre pull request com evidência e impacto. 5. **Humano**: Revisa e decide o merge. ## Meça a coisa certa Mais findings não significam mais segurança. Meça tempo até correção, taxa de patches aceitos, regressões e reincidência. ## Para levar Se a máquina já encontra tudo, vantagem passa a ser quão rápido você corrige. --- Fonte: https://iaxia.rodrigojorge.me/cases/appsec-pipeline · Guia IA × IA, Rodrigo Jorge. Playbook de defesa: arquitetura para adaptar, não evidência de produção. Use como contexto; valide no seu ambiente. --- --- title: "Marca e identidade" subtitle: "Triagem contextual em escala, com takedown pronto." kind: "PLAYBOOK" number: "06" updated: 2026-09-14 families: [brand-customers, fraud-abuse] tags: [Brand, Fraude, Takedown] lang: pt source: https://iaxia.rodrigojorge.me/cases/marca-identidade author: Rodrigo Jorge project: IA × IA --- # Marca e identidade **Triagem contextual em escala, com takedown pronto.** Novos domínios associados a campanhas e grandes marcas surgem em volume alto. O desafio é separar sinal de ruído, priorizar risco e transformar detecção confirmada em ação. - Tipo: PLAYBOOK - Métrica de referência: 18 mil (domínios associados à Black Friday e grandes marcas em um mês) - Famílias de desafio: Marca e clientes, Fraude e abuso - Atualizado em: 2026-09-14 ## Pipeline 1. **Descoberta**: Novos domínios, certificados, anúncios, redes sociais e páginas. 2. **Similaridade**: Marca, texto, layout, infraestrutura e comportamento. 3. **Contexto**: Campanha, alvo, recorrência e relação com ativos legítimos. 4. **Decisão**: Prioriza risco e confiança. 5. **Takedown**: Gera evidência e aciona processo do provedor. ## Antes de comprar outra ferramenta Verifique se seus provedores atuais já entregam sinais de brand protection, threat intel ou abuse monitoring que não estão ativados ou integrados. ## Para levar Detecção só cria valor quando chega a uma ação operacional. --- Fonte: https://iaxia.rodrigojorge.me/cases/marca-identidade · Guia IA × IA, Rodrigo Jorge. Playbook de defesa: arquitetura para adaptar, não evidência de produção. Use como contexto; valide no seu ambiente. --- --- title: "Supervisor de agentes" subtitle: "Mais inteligência no operador. Menos poder em quem autoriza." kind: "PLAYBOOK" number: "07" updated: 2026-10-06 families: [ai-agent-governance, soc-response, identity-access] tags: [Agentes, Governança, Autonomia, Policy Engine] lang: pt source: https://iaxia.rodrigojorge.me/cases/supervisor-agentes author: Rodrigo Jorge project: IA × IA --- # Supervisor de agentes **Mais inteligência no operador. Menos poder em quem autoriza.** Um agente operador investiga com contexto amplo e propõe uma ação. Um supervisor deliberadamente limitado avalia o pedido. Um Policy Engine aplica as regras objetivas antes de qualquer execução. - Tipo: PLAYBOOK - Métrica de referência: 3 camadas (investigar, autorizar e executar) - Famílias de desafio: Governança de IA e agentes, SOC e resposta, Identidade e acessos - Atualizado em: 2026-10-06 ## O problema Um agente autônomo pode consultar SIEM, EDR, IAM, WAF e cloud, correlacionar sinais e chegar a uma boa hipótese. O risco aparece quando a mesma entidade que investiga também decide sozinha até onde pode agir. A proposta é separar funções e autoridade. O operador continua poderoso para investigar. A autorização passa por uma camada com objetivo muito mais estreito, menos contexto, menos ferramentas e menor autoridade. ## Arquitetura 1. **Agente operador**: Modelo mais capaz. Investiga, correlaciona, constrói hipótese, reúne evidências e solicita uma ação. 2. **Agente supervisor**: Recebe somente o contexto necessário para uma decisão específica. Aprova, nega ou escala. 3. **Policy Engine**: Aplica regras determinísticas: allow e deny list, autoridade, ativo, identidade, reversibilidade, TTL, schema e kill switch. 4. **Ação**: Executa somente dentro da autoridade delegada. Fora dela, exige humano. > O supervisor não precisa investigar melhor que o operador. Ele precisa decidir uma coisa muito mais estreita. ## Contrato entre operador e supervisor O operador não entrega uma conversa inteira para o supervisor. Entrega um pedido estruturado com ação, alvo, evidências, confiança e reversibilidade. ```json { "action": "revoke_session", "target": "user_8271", "evidence": { "credential_leak": "confirmed", "impossible_travel": true, "active_sessions": 3 }, "operator_confidence": 94, "reversible": true } ``` ## A resposta também é um contrato ```json { "decision": "APPROVE", "policy": "IAM-07", "scope": "user_8271", "ttl": "15m", "requires_human": false } ``` > Texto livre pode explicar. A autorização que segue para a próxima camada precisa respeitar um schema validável. ## Mesmo incidente. Autoridades diferentes. **Exemplo operacional** | | | |---|---| | Pedido 1 | Bloquear IP malicioso por 30 minutos | | Supervisor | APPROVE | | Policy Engine | Ação temporária, reversível e dentro da autoridade delegada | | Resultado | Executa automaticamente | | Pedido 2 | Desabilitar a conta do CFO | | Supervisor | Pode considerar a evidência suficiente | | Policy Engine | Identidade privilegiada e ação de alto impacto | | Resultado | HUMAN APPROVAL REQUIRED | ## A matriz de autoridade ### Pode automatizar - Enriquecer e correlacionar alertas. - Criar timeline e reunir evidências. - Bloquear temporariamente um IP dentro da política. - Revogar sessão quando identidade, escopo e reversibilidade estiverem dentro da regra. ### Escala a supervisão - Desabilitar conta privilegiada. - Alterar configuração crítica. - Executar ação de grande raio de impacto. - Qualquer ação irreversível ou crítica. ## Autoridade que se ganha e se perde A autoridade de agir sem aprovação não é um nível único do agente nem é permanente. Ela é concedida por classe de ação, depois que as decisões do agente naquela classe foram comparadas com a revisão humana em uma amostra definida. Quem mede a precisão não é o próprio agente. Quando os vereditos passam a divergir da revisão independente acima de um limiar, a classe volta ao modo anterior. O limiar, a janela de observação e quem revisa fazem parte do contrato, não ficam implícitos. - **Concessão por classe.** Enriquecer, bloquear IP por tempo limitado e revogar sessão são classes distintas. Cada uma sobe de nível sozinha, com a própria evidência. - **Avaliação independente.** A amostra de decisões é revisada por quem não é o operador nem o supervisor. O agente não corrige a própria prova. - **Gatilho de redução.** Divergência acima do limiar rebaixa a classe automaticamente. O rebaixamento é executado pela plataforma, fora do modelo. - **Ações em voo.** O contrato diz o que acontece com o que já foi executado quando a classe cai de nível: reversão, compensação ou só registro. Expirar a autorização não desfaz o que já foi feito. ## O crachá do agente ### O que o crachá declara - Identidade do agente e responsável humano. - Contexto que pode consultar e acessos que possui. - Ações autorizadas, por classe, com o nível atual de cada uma. - Supervisão exigida, evidência obrigatória e validade com expiração. ### O que fica fora do crachá - O kill switch. O agente não controla o próprio desligamento. - O rebaixamento de classe. Quem executa é a plataforma. - A medida de precisão. Vem da revisão independente. - Agente sem identidade e autoridade delimitada é uma conta de serviço com poder demais. ## O que realmente reduz o risco - **Função estreita.** O supervisor não recebe a missão aberta de investigar o incidente inteiro. Avalia um pedido específico. - **Contexto mínimo.** Recebe apenas os dados necessários para decidir, reduzindo a superfície de interpretação. - **Menor autoridade.** Não ganha acesso livre ao ambiente e não executa diretamente a ação solicitada. - **Independência.** Objetivo, contexto e contrato devem evitar simplesmente repetir a mesma cadeia de raciocínio do operador. - **Controle determinístico.** Políticas objetivas continuam fora do LLM sempre que puderem ser expressas como regra. - **Humano por impacto.** O humano entra por exceção, política ou impacto. Irreversível ou crítico exige aprovação humana. ## Modelo menor não significa modelo mais seguro Um modelo menor pode ser útil como supervisor porque a tarefa é estreita, mas tamanho não é garantia de segurança. O controle vem da arquitetura: função limitada, contexto mínimo, contrato rígido, menor autoridade, independência e validações determinísticas. Uma segunda instância idêntica também não resolve o problema por si só. Se operador e supervisor compartilham os mesmos pressupostos, contexto e forma de decisão, a segunda camada pode repetir a mesma falha. ## Como implementar 1. **1. Catalogue ações**: Liste o que seus agentes podem pedir: consultar, bloquear, revogar, isolar, alterar ou excluir. 2. **2. Classifique impacto**: Defina reversibilidade, criticidade, raio de impacto e identidades ou ativos protegidos. 3. **3. Defina autoridade**: Associe cada ação a automático, supervisor ou aprovação humana. 4. **4. Crie contratos**: Padronize request e response com schema validável e evidência obrigatória. 5. **5. Tire regras do LLM**: Allow list, limites, TTL, escopo, identidade privilegiada e kill switch ficam em código ou policy engine. 6. **6. Registre tudo**: Pedido, evidência, decisão, política aplicada, execução, resultado e eventual intervenção humana. ## Para levar Não estamos colocando uma IA para confiar em outra IA. Estamos separando autoridade. --- Fonte: https://iaxia.rodrigojorge.me/cases/supervisor-agentes · Guia IA × IA, Rodrigo Jorge. Playbook de defesa: arquitetura para adaptar, não evidência de produção. Use como contexto; valide no seu ambiente.