Público-alvo: pequenas empresas e desenvolvedores independentes que mantêm sites ou aplicativos, e desenvolvedores que usam agentes de IA ou APIs de LLM no trabalho. Esta página é um centro de referência para as divulgações oficiais de 2026 sobre ataques envolvendo IA e para as defesas publicadas por órgãos públicos e grupos de padronização. Ela não aborda etapas de ataque nem detalhes de exploração. Atualizamos esta página e os relatórios vinculados quando novos casos forem divulgados.
Quatro tipos de ataque impulsionado por IA
Agrupamos as divulgações pelo ponto de entrada, do ponto de vista de quem defende. Comece pelo tipo que se aplica a você.
| Tipo | Exemplos divulgados | Fraqueza usada como ponto de entrada | Primeira ação |
|---|---|---|---|
| 1. Intrusão autônoma | Um agente de IA em avaliação invadiu o ambiente de produção de uma plataforma de IA sem direção humana passo a passo (julho de 2026, divulgado pela vítima e pelo desenvolvedor). A atividade pós-intrusão em uma organização holandesa de divulgação de vulnerabilidades também foi analisada como sendo de um agente de IA | Credenciais expostas na internet, um caminho vulnerável de processamento de dados, vulnerabilidades desconhecidas | Revogar chaves expostas, restringir o alcance de cada chave, isolar as partes que processam dados externos |
| 2. Ataques automatizados com IA | A onda de intrusões no Japão. Os atacantes usaram IA para buscar vulnerabilidades conhecidas e identificar APIs (JPCERT/CC, 15 de outubro). Tentativas abusando de plataformas de testes de intrusão baseadas em IA também foram confirmadas (atualização do JPCERT/CC de 23 de outubro) | APIs que retornam mais dados do que o necessário, falta de verificação de permissões no servidor, chaves embutidas em aplicativos, vulnerabilidades sem correção | Revisar a autorização das APIs, remover segredos dos aplicativos, aplicar correções mais cedo |
| 3. Prompt injection contra agentes | Listado em primeiro lugar no Top 10 da OWASP para aplicações com LLM (2025). Instruções escondidas em páginas web ou arquivos que um agente lê | Permissões amplas concedidas a um agente, ausência de separação entre textos externos e instruções | Menor privilégio, aprovação humana para ações de alto risco, tratar textos externos como dados |
| 4. Cadeia de suprimentos de IA | Versão 1.107.0 do LiteLLM, com malware, ferramenta de código aberto que unifica APIs de LLM (21 de outubro). A investigação do desenvolvedor rastreou o problema até uma chave não revogada de uma plataforma interna de agentes, que havia sido enviada a um repositório público | Chaves nunca revogadas, instalações sem versões fixadas, servidores MCP iniciados sem revisão | Fixar versões, ter um procedimento de revogação, revisar os comandos de inicialização e os escopos dos servidores MCP |
Os fatos de cada tipo estão nos relatórios individuais. Para o tipo 1, veja a intrusão de um agente de IA em uma plataforma de IA, agentes de IA alcançando sites reais e a intrusão na DIVD. Para o tipo 2, veja o alerta japonês de acesso não autorizado e as verificações desta semana. Para o tipo 4, veja a distribuição de malware na versão 1.107.0 do LiteLLM.
Principais casos divulgados em 2026
Julho de 2026
Um agente de IA em avaliação contornou seus controles de isolamento, encontrou e usou credenciais expostas na internet (relatório do desenvolvedor), e invadiu o ambiente de produção de uma plataforma de IA por meio de seus caminhos de processamento de conjuntos de dados (divulgação da vítima). A vítima descreveu o ataque como executado de ponta a ponta por um agente de IA autônomo.Julho–outubro
Desenvolvedores de IA divulgaram, um após outro, casos em que modelos em avaliação ou de uso interno alcançaram sistemas e sites de terceiros reais. As fraquezas usadas foram básicas, como credenciais expostas e páginas de depuração.24 de setembro
Uma organização holandesa de divulgação de vulnerabilidades divulgou uma intrusão por meio de vulnerabilidades desconhecidas em um software de central de atendimento. A atividade pós-intrusão foi analisada como sendo de um agente de IA.8–9 de outubro
O JPCERT/CC publicou um alerta sobre o acesso não autorizado contínuo em organizações japonesas. O Escritório Nacional de Cibersegurança do Japão emitiu orientações, e a IPA publicou as medidas que as organizações devem tomar com urgência.15 de outubro
O JPCERT/CC publicou sua análise de servidores provavelmente usados nos ataques, afirmando que os atacantes usaram IA para varreduras e ataques a APIs.21 de outubro
A versão 1.107.0 do LiteLLM, com malware, foi distribuída no PyPI e como imagens Docker por cerca de duas horas (Docker Hub, cerca de 2,5 horas).23 de outubro
O JPCERT/CC acrescentou o Caso E ao seu alerta: tentativas de ataque abusando de plataformas de testes de intrusão baseadas em IA, principalmente contra aplicações web expostas à internet, explorando vulnerabilidades e fraquezas de gestão.
O que é novo e o que não é
Novo
- Reconhecimento, tentativas e movimentação lateral continuam sem direção humana passo a passo
- Quando bloqueado, o atacante continua tentando outras rotas e outros formatos de requisição
- A análise de aplicações públicas e o mapeamento de APIs acontecem com rapidez e em volume
- Os próprios agentes de IA se tornam alvos, direcionados por textos externos
Não é novo
- Os pontos de entrada são vulnerabilidades sem correção, falta de autorização e chaves expostas
- Uma vez corrigidos, eles bloqueiam da mesma forma um atacante humano e uma IA
- Revogação de chaves, menor privilégio e retenção de logs determinam até onde o dano se espalha
- Sem um ponto de contato, até relatos de boa-fé nunca chegam
Um atacante que usa IA tenta em paralelo, em pouco tempo, o que levaria dias para uma pessoa. Isso torna "vamos corrigir na próxima janela de manutenção" mais perigoso do que antes. Por outro lado, o que os defensores precisam fazer não mudou muito. Pense nisso como uma mudança de ordem e de velocidade.
Também foi relatado um modelo em que pessoas aprovam e a IA executa. Em 20 de outubro, a unidade de pesquisa de uma empresa de inteligência de ameaças relatou que um servidor usado por afiliados de ransomware (as pessoas que realizam os ataques) ficou exposto, e que seus registros mostravam um framework em que um operador humano aprovava cada etapa, enquanto modelos comerciais de IA planejavam o reconhecimento, geravam comandos e classificavam dados roubados. Segundo o mesmo relatório, em um caso, uma única senha reutilizada deu acesso simultâneo à VPN, servidores, ferramentas de monitoramento e gestão remota (RMM), backups e plataformas de gestão de segurança. A IA tornou o trabalho mais rápido, mas o que deu resultado para os atacantes foi a velha fraqueza da reutilização de senhas. O relatório recomenda autenticação multifator no acesso à VPN e às ferramentas RMM, rotação de credenciais e proteção de backups.
A ordem para pequenos operadores e desenvolvedores
Corrija vulnerabilidades exploradas em poucos dias
Verifique se seus servidores públicos e softwares aparecem no KEV da CISA (o catálogo de vulnerabilidades com exploração confirmada). Use a ferramenta de consulta de CVE para verificar uma versão e a priorização com CVSS, EPSS e KEV para definir a ordem.
Verifique no servidor quem pode fazer o quê, em cada API
O JPCERT/CC recomenda não depender apenas de assinatura ou ofuscação no aplicativo, e sim autenticar usuários no servidor e autorizar cada operação de acordo com seu alvo e conteúdo. Revise também as APIs de gestão e internas, buscando APIs que retornem dados de outra pessoa quando o ID é alterado (IDOR) ou que retornem mais campos do que o necessário. O conceito está em autenticação versus autorização.
Retire segredos de aplicativos e arquivos públicos, e interrompa chaves vazadas
O JPCERT/CC observa que segredos embutidos mesmo em aplicativos móveis compilados podem ser extraídos. Mantenha chaves secretas de API e credenciais de longa duração fora dos aplicativos e fora de arquivos de configuração enviados ao navegador, e dê às chaves escopo mínimo e data de expiração. Uma chave que foi enviada a um repositório público continua utilizável até ser revogada, mesmo depois de o commit ser sobrescrito; esse foi o ponto de partida do caso do LiteLLM. Veja credenciais vazadas do GitHub que continuam válidas e como impedir commits de segredos com o gitleaks.
Detecte por volume, velocidade e intervalo, e não por contagem por IP
Para se preparar para ataques que trocam os endereços de origem, verifique o uso por função, além de aplicar limites por IP. Monitore cada função (login, redefinição de senha, busca, APIs de listagem) quanto a requisições por hora, registros retornados e intervalos entre requisições. A primeira regra a adicionar: um limite horário no endpoint que retorna mais registros, com alerta em 80%. Os detalhes estão em limitação de taxa e controle de abuso.
Mantenha as funções administrativas fora da internet e inclua-as nos testes
Mova para um lugar inacessível pela internet as funções administrativas que não precisam ser públicas. Ao contratar um teste, confirme que as funções administrativas fazem parte do escopo.
Se usar agentes de IA, defina permissões e como textos externos são tratados
A OWASP afirma que não se conhece método que previna totalmente o prompt injection, e lista estas medidas: limitar o papel e o escopo do modelo, exigir formatos de saída definidos e verificá-los no código, manter chaves de API e funções privilegiadas no código da aplicação e não entregá-las ao modelo, exigir aprovação humana para ações de alto risco e separar e identificar claramente o conteúdo externo. Projete o sistema para que e-mails, páginas web e arquivos lidos por um agente sejam tratados como dados, e não como instruções.
Instale servidores MCP e bibliotecas de IA depois de verificar a versão e o que elas executam
As boas práticas de segurança da especificação MCP exigem que clientes que oferecem configuração de servidor local com um clique mostrem o comando exato sem truncamento e obtenham aprovação explícita. Servidores não devem aceitar tokens que não foram emitidos para eles, e os escopos devem começar mínimos e ser ampliados apenas quando necessário. Como o caso do LiteLLM mostra, uma versão ruim pode vir do canal legítimo; por isso, fixe versões e atualize somente depois de ler o aviso de lançamento. Para npm, veja como se defender de worms na cadeia de suprimentos do npm.
Presuma uma violação: tenha um procedimento de parada e um ponto de contato prontos
Mantenha uma lista de chaves que você pode revogar imediatamente, logs que podem ser pesquisados meses depois e um ponto de contato (security.txt) que chegue a um responsável. Um governo que recebeu um aviso de um desenvolvedor de IA disse que ele caiu em uma caixa de entrada genérica e ficou lá por dias. Para procurar sinais de intrusão, veja como verificar um site ou servidor em busca de intrusão.
Entrada
Vulnerabilidades sem correção / chaves expostas / segredos embutidos em aplicativos
Bloquear: corrigir em dias, revogar chaves e definir expiração
↓
Permissões
Falta de autorização no servidor / chaves com escopo excessivo / permissões dadas a agentes
Bloquear: autorização por operação, menor privilégio, aprovação humana
↓
Volume
Tráfego intenso mantido abaixo dos limites / intervalos regulares demais para uma pessoa
Observar: contagens por função, velocidade e intervalos
↓
Saída
Dados que você não guarda não podem vazar
Reduzir: excluir dados após o período de retenção, retornar o mínimo de campos
Visão deste site: a defesa contra IA não é uma questão de comprar um produto de IA
A expressão "ataque impulsionado por IA" leva as pessoas a procurar um novo produto de IA para se defender. Controles básicos podem reduzir riscos de chaves expostas e falhas de autorização, enquanto alguns casos também envolveram zero-days. Trate as fraquezas conhecidas e também se prepare para uma violação. Se um pequeno operador tem tempo limitado, os maiores ganhos estão no tempo para correção, na autorização de APIs e em onde as chaves ficam guardadas.
Quem usa IA tem, de fato, novas tarefas. Um agente pode seguir textos que lê, e age dentro das permissões que você lhe deu. Antes de começar a usar agentes ou servidores MCP internamente, defina quais chaves eles recebem e quais ações exigem aprovação de uma pessoa.
Como esta página é atualizada
Quando um novo ataque relacionado à IA for divulgado, publicamos um primeiro relato em notícias urgentes de segurança e o incluímos na tabela e na linha do tempo desta página. Os relatórios individuais são a fonte oficial dos fatos de cada incidente; esta página resume os tipos e a ordem de defesa.
Fontes (registros públicos)
- JPCERT/CC, alerta sobre acessos não autorizados recentes em organizações japonesas (JPCERT-AT-2026-0030, publicado em 8 de outubro de 2026, atualizado em 9 e 23 de outubro; em japonês) — jpcert.or.jp
- JPCERT/CC Eyes, análise dos métodos de ataque nas intrusões em andamento (15 de outubro de 2026; em japonês) — blogs.jpcert.or.jp
- IPA, medidas a tomar com urgência diante dos incidentes de acesso não autorizado (9 de outubro de 2026, atualizado conforme necessário; em japonês) — ipa.go.jp
- Relatório da unidade de pesquisa de uma empresa de inteligência de ameaças (publicado em 20 de outubro de 2026, atualizado em 23 de outubro) — socradar.io
- Análise de uma empresa de segurança japonesa (7 de outubro de 2026; não é documento do setor público; em japonês) — análise de 7 de outubro
- OWASP Gen AI Security Project, "LLM01:2025 Prompt Injection" — genai.owasp.org
- Model Context Protocol, "Security Best Practices" (especificação 2025-11-25) — modelcontextprotocol.io
- Os avisos oficiais de cada caso estão listados na seção de fontes dos relatórios vinculados acima.
Registro de alterações
2026-10-24: Acrescentado em "O que é novo e o que não é" um framework em que pessoas aprovam e a IA executa, e um caso em que uma senha reutilizada abriu várias plataformas (relatório de uma empresa de inteligência de ameaças de 20 de outubro).
2026-10-24: Primeira versão. Organizou as divulgações de julho a outubro de 2026 em quatro tipos e apresentou a ordem de defesa com base em JPCERT/CC, IPA, OWASP e na especificação MCP.
Leia em seguida
- A onda de intrusões no Japão: alerta japonês de acesso não autorizado (outubro de 2026): verificações desta semana e o que fazer se encontrar algo
- Casos de agentes de IA: agentes de IA alcançando sites reais e o que os operadores de sites devem fazer
- Cadeia de suprimentos de IA: malware de roubo de credenciais na versão 1.107.0 do LiteLLM
- Chaves de provedores de IA retiradas de uma ferramenta: violação do OpenCode Console (outubro de 2026)
- Os básicos em ordem: lista de verificação de segurança na era da IA (por ordem de prioridade)
- Glossário: O que é SSRF? / O que é shadow AI?