O Arquivo de Incidentes de IA da Orca: 354 Incidentes Reais de Agentes de IA, Cada um com um Recibo

Uma equipe de segurança consegue dizer com precisão o quão bem um modelo resiste a injeção de prompt dentro de um ambiente de testes. O que quase ninguém consegue dizer é quantas organizações foram de fato comprometidas por um agente no mês passado, quais dessas violações tiveram uma vítima confirmada e quais dos números citados no relatório vieram do fornecedor em vez de um órgão regulador. Essa lacuna — entre o que os modelos podem fazer e o que já aconteceu — é a lacuna quea href="https://www.orcarouter.ai/incident-archive">Orca AI Incident Archive/a> foi criado para fechar. Ele entrou no ar em 23 de setembro de 2026 e, conforme o corte de dados de 22 de setembro, contém 354 registros extraídos de 593 fontes únicas.

Nota de precisão: todos os números abaixo são lidos do próprio code>dist/stats.json/code> publicado pelo arquivo na versão 2026-09-22 e da página em tempo real. O anúncio de lançamento em 23 de setembro citou 340 registros, 548 fontes e 126 com dano confirmado; esses eram os números no momento da publicação, e o arquivo é atualizado continuamente, de modo que os dois conjuntos diferem em cerca de um dia de ingestão. Onde o README do arquivo e sua página em tempo real divergiram quanto ao número de um selo durante o desenvolvimento, a página em tempo real e a exportação JSON são as fontes em que se deve confiar.

O que o arquivo realmente contém

Não é um feed de notícias e não é uma lista de CVEs. Cada entrada é um único arquivo Markdown com frontmatter estruturado, arquivada sob o mês em que o evento aconteceu, e cada entrada contém pelo menos uma fonte. O conjunto de dados é publicado sob a licença CC BY 4.0 e espelhado em um repositório público, então o conjunto todo pode ser clonado, comparado por diff e citado, em vez de capturado em uma captura de tela.

A janela de cobertura abrange 22 meses, de um precursor de dezembro de 2024 até 22 de setembro de 2026, e a distribuição é a parte interessante. A severidade divide-se em 45 críticas, 139 altas, 77 médias, 8 baixas e 85 informativas. A confiança da fonte divide-se em 302 de grau A, 47 de grau B, 2 de grau C e 3 de grau D. Dano real confirmado no mundo real está registrado para 127 registros, explicitamente descartado para 142 e deixado nulo para 85.

Esses últimos três números são o motivo pelo qual vale a pena ler o arquivo com cuidado, em vez de apenas passar os olhos por ele. Uma contagem de 354 registros não é uma contagem de 354 incidentes. Apenas 138 deles são de fato classificados como incidente; o restante são divulgações de vulnerabilidades, demonstrações de pesquisa, relatórios de ameaças e movimentos de política. Contar todos os cinco juntos é exatamente como um número de manchete dá errado, e é por isso que o arquivo os mantém separados e permite que você filtre.

Por que "um jailbreak não é um incidente" é o cerne da questão

A maioria das coleções de eventos de segurança de IA elimina uma distinção: um agente que realmente causou dano não é a mesma coisa que um pesquisador demonstrando que poderia. É essa única confusão que transforma uma demonstração de conferência em manchete de violação, e é isso que o arquivo foi construído para recusar.

Três campos carregam esse peso. code>real_harm/code> registra se uma vítima foi confirmada. code>ai_involvement/code> registra se uma fonte primária — o fornecedor, a vítima, as autoridades policiais ou um relatório oficial — confirmou o papel da IA, com atribuições disputadas mantidas no conjunto de dados, mas rotuladas. code>kind/code> registra que tipo de documento é a entrada. Um registro sem fonte não entra. Um registro com evidências conflitantes é marcado como disputado em vez de resolvido na direção que parecer melhor. Quando novas evidências chegam, o registro é atualizado e a alteração é escrita em seu histórico de revisões, em vez de ser sobrescrita silenciosamente.

O arquivo aplicou essa regra a si mesmo. Durante as suas próprias rodadas de verificação, ele excluiu duas entradas que não puderam ser comprovadas, corrigiu uma alegação amplamente repetida sobre a rapidez com que uma intrusão progrediu e rebaixou o grau de confiança de uma terceira entrada quando as evidências subjacentes se revelaram de segunda mão. Um banco de dados de incidentes que nunca removeu nada é um banco de dados que não foi verificado.

As doze superfícies de ataque pelas quais ele classifica

Cada registro é marcado com um ou mais de doze tipos, e cada tipo tem sua própria contagem mês a mês. Governança e política é o maior grupo, com 65 registros, mas apenas um deles tem dano confirmado — o que é o formato correto para atividade regulatória e um dado enganoso de se citar como contagem de incidentes. Abuso de credenciais vem em seguida, com 55 registros e 40 vítimas confirmadas, a maior densidade de dano do conjunto. Agente como arma está em 51, com 28 confirmados. Injeção indireta de prompt tem 45 registros, mas apenas 5 com dano confirmado, o que é a ilustração mais clara da divisão entre capacidade e consequência em todo o conjunto de dados: é a classe de ataque mais estudada e uma das menos produtivas no mundo real. Envenenamento da cadeia de suprimentos, com 36 registros, tem 27 vítimas confirmadas — a pior proporção do quadro.

Setembro de 2026 é o mês que comprova a tese

Só em setembro de 2026, cinquenta e um registros foram contabilizados, mais que o dobro de qualquer mês anterior na janela. Isso não é um colapso súbito da segurança. É um mês em que a manutenção de registros finalmente alcançou um ano de eventos acumulados, e a composição é o que importa: entradas críticas para um code>.git/config malicioso que executa código do atacante em sete agentes de programação antes mesmo de o modelo ser contatado, para uma falha do Langflow explorada no mundo real, para uma campanha de enxame de agentes de IA em um fornecedor de gestão de impressão e para um worm de npm que entra na cadeia a montante. Ao lado delas, figuram entradas informativas sobre o OWASP Agent Control Standard, um discurso do Estado da União da UE que citou fugas de agentes e um briefing de um painel das Nações Unidas que tratou um incidente como alerta de perda de controle.

As entradas coreanas, e o que um campo de região não significa

O campo code>region/code> do arquivo marca onde um evento de fato ocorreu, não onde o fornecedor está sediado — divulgações de fornecedores transfronteiriças são sempre registradas como globais, e é por isso que 291 dos 354 registros não trazem nenhuma tag de país único. Dois registros carregam a tag KR, ambos entradas de política com fontes de grau A e nenhum dano confirmado: a remoção do DeepSeek das lojas de aplicativos domésticas da Coreia do Sul em abril de 2025, e a proibição do OpenClaw em toda a empresa, adotada pela Naver, Kakao e Karrot em fevereiro de 2026.

Essa contenção é deliberada. Uma contagem de dois para uma região não é uma afirmação de que a Coreia teve dois eventos de segurança de IA. É uma afirmação de que dois eventos na janela ocorreram na Coreia com uma fonte primária forte o suficiente para registro — e o arquivo prefere publicar um número pequeno e honesto a inflar a página de um país com eventos que aconteceram aos clientes de uma empresa coreana em outro lugar.

Como interpretar as classificações de confiança antes de citar uma

A confiança diz respeito à qualidade da fonte, não à gravidade, e uma nota D não significa falso — significa que as partes discordam e que você não deve citar apenas um lado. A nota A significa uma fonte primária: o fornecedor, a vítima, as autoridades policiais ou um relatório oficial. A nota B significa um laboratório de pesquisa ou um grande veículo de comunicação com detalhes verificáveis. A nota C significa apenas informação de segunda mão. A nota D significa que os fatos ou a atribuição estão em disputa. Em 302 de 354 registros, a nota A representa 85% do conjunto de dados, o que é excepcionalmente alto para relatos de incidentes e é o resultado direto da regra “sem fonte, sem entrada”.

Vale a pena declarar claramente as ressalvas honestas, porque o arquivo as declara. Dois registros permanecem com grau C e três com grau D. Oitenta e cinco registros têm severidade informativa porque são entradas de política ou de relatório de ameaça mantidas para continuidade da linha do tempo, e não incidentes. O repositório tem três semanas e não tem estrelas, nem releases, nem auditoria externa de sua própria metodologia — é um conjunto de dados publicado abertamente, não um estudo revisado por pares.

Por que isso importa mais do que outro benchmark

À medida que os agentes adquirem navegadores, shells, credenciais, execução de código e acesso à produção, a questão de segurança deixa de ser o que um modelo é capaz de fazer e passa a ser o que já foi feito com um. Os benchmarks respondem bem à primeira pergunta e não respondem de modo algum à segunda. Um arquivo de incidentes, classificado pela qualidade da fonte e filtrado por se alguém foi realmente prejudicado, é o único tipo de instrumento que responde à segunda — e só funciona se os registros forem rastreáveis, corrigíveis e livres para reutilização.

Isso é o que está agora aberto. O conjunto de dados está em a href="https://www.orcarouter.ai/incident-archive">orcarouter.ai/incident-archive/a>, o Markdown bruto, as exportações JSON e CSV e o esquema estão no a href="https://github.com/Continuum-AI-Corp/Orca-AI-Incident-Archive">repositório público/a>, e as correções passam pelo histórico de revisões do registro. Se você conhece um evento que pertence a ele, o caminho de contribuição é um arquivo Markdown e pelo menos uma fonte. Sem fonte, sem entrada.

A OrcaRouter, que publica o arquivo, opera um único endpoint compatível com OpenAI em mais de 200 modelos, sem markup sobre os preços dos provedores e com failover automático entre eles — a mesma camada de roteamento que torna possível direcionar um agente para um modelo mais barato nas chamadas fáceis e um mais forte nas difíceis, que é exatamente a arquitetura em que a maioria dos incidentes acima foi encontrada.