IT-ISAC AI Threat Intelligence

Nota 01 da subpasta 03 do capítulo 22 (Compartilhamento e Colaboração), dedicada à troca de inteligência sobre ameaças a sistemas de IA e com uso de IA.
Cobre a comunidade de inteligência de ameaças de IA do IT-ISAC, os tipos de intel que circula nesse domínio e a padronização emergente, com exemplo de item compartilhado.
Dialoga com o capítulo 17 (IA e automação em CTI-TH), com o MITRE ATLAS da nota 02 do capítulo 20 e com a nota 07 deste capítulo sobre objetos STIX.

1. Contexto e Posicionamento na Biblioteca

O capítulo 17 mapeou as ameaças com e contra IA do ponto de vista técnico: agentes abusados, jailbreaks, deepfakes e campanhas orquestradas com modelos generativos. Esta nota trata do lado institucional do mesmo problema: quem agrega essa inteligência, em que formato circula e como o programa de CTI passa a consumi-la. O marco é a comunidade de inteligência de ameaças de IA do IT-ISAC, que reuniu os grandes desenvolvedores de modelos, provedores de infraestrutura e empresas de segurança para trocar observações sobre abuso e ataque a sistemas de IA, e que se tornou o modelo de referência para iniciativas setoriais de IA no mundo.

A nota posiciona o tema dentro da lógica da biblioteca: uma classe nova de ativo, os modelos e agentes, cria uma classe nova de telemetria e de ameaça, e a economia do compartilhamento repete o padrão histórico dos ISACs, com uma diferença importante, a de que os produtores de IA são ao mesmo tempo as vítimas, as plataformas do adversário e as melhores fontes de telemetria, o que concentra valor e tensão comercial no mesmo grupo. O leitor que domina o compartilhamento clássico das subpastas 01 e 02 encontrará aqui o mesmo esqueleto com vocabulário novo.

2. Por que Ameaças de IA Pedem Compartilhamento Próprio

A primeira razão é a velocidade do adversário. Abusos de modelos generativos se replicam em escala quase instantânea: um jailbreak publicado em fórum vira kit de fraude em dias, e a infraestrutura de abuso, contas, chaves de API e serviços de revenda, é reutilizada entre campanhas de desinformação, engenharia social e geração de malware. A janela de defesa útil é medida em horas, e apenas a troca estruturada entre quem observa os abusos consegue operar nesse ritmo, porque nenhum provedor vê o ecossistema inteiro.

A segunda razão é a assimetria de telemetria. O provedor de modelo vê os prompts e o uso; a empresa de segurança vê os artefatos gerados e a infraestrutura; a vítima corporativa vê o impacto no ambiente; e o investigador vê o grupo de ameaça na ponta. Nenhuma dessas visões isoladas produz inteligência acionável sobre uma campanha de deepfake corporativo ou sobre uma operação de agentes abusados, e a comunidade existe para costurar as quatro. O paralelo com a frase que abre o capítulo 02 é direto: nenhum defensor vê sozinho a campanha inteira, e em IA isso é ainda mais verdadeiro porque a campanha atravessa provedores, plataformas e jurisdições.

A terceira razão é a inexistência de vocabulário consolidado. Ameaças de IA não cabem sem esforço nas taxonomias clássicas: um jailbreak não é IOC tradicional, o abuso de agente autônomo é comportamento que atravessa eventos de aplicação e uso de API, e a atribuição de deepfake é problema forense distinto. O compartilhamento próprio existe também para forçar a padronização desse vocabulário, tema da seção 5, e para que o material circule com contexto que o receptor consiga operacionalizar.

Há ainda uma razão de governança que é específica do domínio: as respostas ao abuso de IA quase sempre exigem ação coordenada entre fornecedores que competem entre si, como desligar infraestrutura compartilhada, invalidar contas e chaves ou padronizar marcação de conteúdo sintético, e essa coordenação não acontece por iniciativa unilateral porque afeta produto e margem de cada um. O fórum neutro de confiança é a única estrutura que resolve essa classe de problema com velocidade, e é exatamente o papel que a comunidade de IA do IT-ISAC desempenha no ecossistema.

3. A AI Threat Intelligence Community do IT-ISAC

O IT-ISAC, apresentado na nota 01 desta subpasta como o ISAC da indústria de tecnologia, estruturou uma comunidade dedicada à inteligência de ameaças de IA, reunindo os maiores desenvolvedores de modelos de fundação, provedores de nuvem e infraestrutura, empresas de segurança e membros do ecossistema de IA. A motivação declarada é compartilhar observações sobre ameaças com uso malicioso de IA e sobre ataques a sistemas de IA, de forma a elevar o custo do adversário e acelerar proteções comuns. A comunidade opera com a mecânica clássica de trust group: identidade verificada, marcação TLP, grupos de trabalho temáticos e canal de troca em tempo real para incidentes.

Três funções práticas distinguem a comunidade no ecossistema. A primeira é a troca de indicadores de abuso em escala: infraestrutura de revenda de acesso a modelos, contas e chaves comprometidas, padrões de uso automatizado malicioso e artefatos de campanhas, material que o provedor sozinho trataria como abuso de termos de serviço e que na comunidade vira inteligência de ameaça. A segunda é a coordenação de resposta a eventos transversais, como operações de desinformação que usam múltiplos provedores, em que a comunidade permite a troca de contexto sem expor clientes individuais. A terceira é a interface com governo e academia em temas emergentes, de segurança de agentes a proveniência de conteúdo, posicionando o setor antes da regulação reagir a incidente grave.

Para o programa de CTI que não é membro, o efeito prático é duplo: parte do material desagua em relatórios públicos e advisories que qualquer programa consome, e a existência da comunidade define quem o programa precisa monitorar de perto, porque os provedores de modelo passaram a publicar, cada um em seu canal, observações de abuso que antes não existiam como categoria de fonte.

4. Tipos de Inteligência que Circula em Comunidades de IA

A inteligência de ameaças de IA se organiza em famílias que o programa precisa mapear nas fontes de coleta. A tabela abaixo resume as principais, com exemplo recorrente e o receptor típico dentro da organização.

Duas observações de leitura técnica. A primeira é que grande parte dessas famílias não gera IOC clássico: um jailbreak é texto, uma voz sintética é áudio e uma rede sintética é comportamento, e por isso a comunidade compartilha padrões, hashes de artefato, assinaturas de conteúdo e heurísticas de detecção, além dos indicadores de infraestrutura que existem. A segunda é que a fronteira entre abuso de produto e ataque a organização é porosa: a mesma infraestrutura de revenda que abastece spam abastece operações de espionagem, e o corte setorial das comunidades clássicas precisa ser complementado pelo corte de ecossistema que as comunidades de IA fazem.

5. Padronização Emergente do Domínio

A padronização de ameaças de IA está em construção, e o programa deve acompanhar três frentes sem esperar consenso definitivo. A primeira é o MITRE ATLAS, que adapta a lógica do ATT&CK para ataques a sistemas de machine learning, com técnicas que vão de coleta de dados de treinamento a evasão e exfiltração de modelo, e que já opera como vocabulário de referência em relatórios e plataformas; a nota do capítulo 20 cobre suas atualizações. A segunda é a extensão do ecossistema STIX para objetos de IA, com propostas de custom objects e marcações para representar jailbreak, artefato sintético e evento de abuso, evolução que segue o caminho que STIX 2.1 percorreu para o resto do domínio e que a nota 07 deste capítulo cataloga. A terceira é a adoção de taxonomias de risco e vulnerabilidade de IA, como o catálogo de riscos de sistemas generativos de frameworks comunitários, como vocabulário de classificação no lugar de taxonomias ad hoc.

A tabela abaixo resume as frentes de padronização, o que cada uma resolve e o estágio realista de adoção.

A consequência prática para quem compartilha hoje é disciplinar a saída mesmo sem padrão fechado. A recomendação operacional é: classificar todo material com referência ATLAS quando houver técnica mapeável, marcar o tipo de artefato sintético quando aplicável, incluir metadados de modelo e versão quando a observação for específica de versão, e manter a marcação TLP como em qualquer troca. Essa higiene custa pouco e garante que o material continue utilizável quando a padronização assentar, além de facilitar a intersecção com relatórios públicos que já adotam ATLAS.

6. Exemplo de Item de Inteligência de IA Compartilhado

O item abaixo reproduz a estrutura típica de um registro de troca em comunidade de IA, em formato híbrido de boletim e objeto estruturado, com os campos que permitem operacionalização pelo receptor.

TIPO: Abuso de agentes autônomos para operação de fraude em escala
ID: AIC-2026-0402-11   TLP:AMBER   ATLAS: AML.T0043 (bypass via agente)
RESUMO: Operação coordenada usa agentes com acesso a modelo de razão
        para gerar e responder mensagens de fraude em plataformas de
        recrutamento, com persona sintética e voz gerada em calls.
OBSERVAÇÕES DE TELEMETRIA: padrão de uso com janelas de alta paralela,
        prompts reutilizáveis com marca de kit, contas em cascata.
INDICADORES: 2 hashes de prompt-kit, infraestrutura de revenda (3
        domínios), padrão de fingerprint de agente (user-agent e
        cadência de chamada).
DETECÇÃO SUGERIDA: limites e anomalia de cadência por conta; detecção
        de prompts com marca de kit no gateway de IA; verificação de
        voz com desafio dinâmico em calls de alto risco.
AÇÃO: revisar gateway de IA contra o kit; compartilhar de volta se
        observado no ambiente.

A leitura operacional do item mostra o que muda em relação à troca clássica. O campo ATLAS substitui o mapeamento ATT&CK como âncora técnica, e permite ao receptor classificar a ameaça na linguagem emergente do domínio. Os indicadores misturam artefato e comportamento, e a detecção sugerida opera em camadas, do gateway de IA até o processo humano de verificação de voz, reconhecendo que a defesa contra abuso de IA é sistêmica. E a ação final de compartilhar de volta materializa a reciprocidade que sustenta a comunidade.

A conversão do item em objetos do TIP segue o caminho da nota 07 deste capítulo: indicadores de infraestrutura como objetos Indicator padrão, o kit como objeto Malware com propriedade de descrição, a observação de uso como relatório anexado e a marcação ATLAS como referência externa, de modo que o material entre no mesmo grafo analítico do resto do programa.

Para o receptor que opera TIP com suporte a custom objects, o esqueleto abaixo ilustra a representação do kit de prompts como objeto STIX 2.1 com referência ATLAS, no formato que comunidades de IA começam a adotar para material sem IOC clássico.

{
  "type": "malware",
  "spec_version": "2.1",
  "id": "malware--a1b2c3d4-0000-4000-8000-kitprompts01",
  "created": "2026-04-02T11:20:00.000Z",
  "modified": "2026-04-02T11:20:00.000Z",
  "name": "Prompt-kit de fraude em plataformas de recrutamento",
  "is_family": false,
  "malware_types": ["kit"],
  "description": "Conjunto de prompts reutilizáveis para agentes\n    usados em fraude com persona sintética e voz gerada",
  "external_references": [
    {
      "source_name": "mitre-atlas",
      "external_id": "AML.T0043"
    }
  ],
  "labels": ["tlp:amber", "ai-abuse", "fraude"]
}

7. Erros Comuns e Pontos de Atenção

• Tratar inteligência de IA como novidade de briefing e não como fonte operacional; efeito: material que define onde olhar não chega ao SOC nem ao gateway de IA; correção: incluir as fontes de IA no pipeline e rotear itens com SLA de triagem.
• Esperar IOC clássico e descartar o resto; efeito: a organização perde exatamente o material de maior valor, que é comportamento e artefato sintético; correção: ampliar a definição de acionamento para heurísticas, padrões e assinaturas de conteúdo.
• Ignorar a dimensão de abuso e focar só em ataque; efeito: a organização defende o modelo e continua sendo vítima de fraude gerada por IA; correção: mapear as duas direções, ataque a IA e ataque com IA, no mesmo quadro de ameaça.
• Não monitorar os canais públicos dos provedores de modelo; efeito: a comunidade publica por seus membros e o programa não vê; correção: tratar os provedores como categoria de fonte com coleta dedicada.
• Compartilhar observações de abuso sem revisão jurídica; efeito: material com dado de cliente ou de uso interno vaza com a marca da organização; correção: aplicar o mesmo fluxo de curadoria de saída das subpastas anteriores, com atenção redobrada a dado pessoal em prompts.
• Substituir ATLAS por taxonomia improvisada na saída; efeito: material sem âncora comum não se cruza com relatórios nem com a comunidade; correção: padronizar referência ATLAS e tipo de artefato na fila de contribuição.
• Avaliar provedores de modelo apenas como fornecedor de tecnologia; efeito: a organização perde a visão de que o mesmo provedor é fonte primária de telemetria de abuso e parte do ecossistema de resposta; correção: incluir provedores no mapa de fontes de inteligência com canal de advisory e canal de abuso tratados separadamente.
• Medir fontes de IA com métricas de feed clássico; efeito: taxa de acionamento despenca porque o material é contexto e padrão, e a fonte é cortada injustamente; correção: medir também casos de antecipação de campanha e detecção de fraude, nas métricas da subpasta 04.
• Deixar os prompts e logs de uso de IA fora do inventário de telemetria; efeito: quando o item da comunidade chega, a organização não tem como verificar se o padrão ocorreu no próprio ambiente; correção: coletar metadados de uso de IA com privacidade adequada, conforme o capítulo 02.

8. Integração com o Restante da Biblioteca

A nota conecta a inteligência de ameaças de IA ao resto da biblioteca em três direções. A técnica fica no capítulo 17, que detalha as ameaças com e contra IA, e no ATLAS do capítulo 20, que fornece o vocabulário de classificação; a institucional fica nas subpastas anteriores deste capítulo, porque a mecânica de comunidade, TLP e reciprocidade é a mesma; e a mensuração fica na subpasta 04, que mede volume, acionamento e sobreposição das fontes de IA como de qualquer outra fonte.

A nota 02 desta subpasta completa o quadro com a dimensão público-privada, cobrindo grupos de trabalho governamentais e modelos de alerta rápido para incidentes de IA. Para o programa de CTI, o ponto de partida prático é modesto e imediato: mapear as fontes públicas de abuso dos provedores, adotar ATLAS como vocabulário de saída e incluir um item de ameaça de IA por semana no briefing interno, transformando a participação futura em comunidade em decisão de dados e não de moda.

Um fechamento operacional ajuda a internalizar a diferença do domínio: nas comunidades clássicas, o indicador é a moeda da troca e o contexto é o diferencial; nas comunidades de IA, o contexto costuma ser a moeda inteira, porque o indicador isolado quase não existe. O programa que internalizar essa inversão desde o desenho do seu pipeline, tratando texto, áudio e comportamento como observáveis de primeira classe ao lado de IP e hash, estará pronto para consumir e contribuir no domínio de IA sem retrabalho de arquitetura. Essa preparação também reduz o custo de entrada na próxima onda de comunidades, porque o vocabulário de artefato sintético e a referência ATLAS já estarão presentes nos objetos internos quando a federação de IA pedir interoperabilidade.