Violação da Fireworks AI: checklist de riscos de provedores de inferência após o incidente de LLMjacking

A violação da Fireworks AI é um dos casos recentes mais claros de risco que passa por um provedor de inferência hospedada e chega aos seus clientes. Em outubro de 2026, a Fireworks AI divulgou um incidente de segurança. Uma atualização posterior descreveu uma segunda invasão e um impacto mais amplo.

A seguir está o que a Fireworks de fato publicou, seguido de um plano de resposta que chamamos de playbook Segredos, Dados, Gastos. Depois vem um checklist de due diligence para futuras avaliações de fornecedores.

O que a Fireworks divulgou: duas invasões, em ordem

A Fireworks publicou um boletim de segurança inicial e uma atualização posterior. Lidos lado a lado, eles descrevem duas invasões distintas.

O primeiro incidente, identificado em 6 de outubro, envolveu o uso não autorizado de credenciais internas da Fireworks. Segundo o boletim inicial, um terceiro não autorizado acessou variáveis de ambiente usadas em jobs de avaliação em um número limitado de contas de clientes.

O segundo entrou por meio de um fornecedor. Um provedor de nuvem terceirizado que hospedava máquinas de P&D da Fireworks sofreu um incidente de segurança em 23 de outubro. Um dia depois, em 24 de outubro, o invasor usou esse acesso para chegar às máquinas de desenvolvimento da Fireworks e executar uma carga de trabalho não autorizada, o que gerou impacto adicional sobre dados de clientes.

A atualização também mudou o quadro do que foi levado. Quando o primeiro boletim saiu, só se sabia do acesso a segredos armazenados na Fireworks. Investigações posteriores encontraram impactos em informações de conta e de faturamento e, para um conjunto limitado de contas, impactos em segredos, datasets e modelos incompletos.

Sobre a autoria, a empresa cita evidências que ligam a atividade a um grupo cibercriminoso com motivação financeira que vende tokens obtidos com acesso não autorizado a LLMs para gateways de roteamento ilícitos, prática que ela chama de "LLMJacking".

Ainda há uma lacuna no registro. Segundo o The Register, a atualização não informou quantos clientes cada ataque afetou. Até que a Fireworks diga mais, confirme sua própria exposição diretamente com o fornecedor.

O que foi exposto, o que não foi e o que a Fireworks mudou

No primeiro incidente, a Fireworks acredita que variáveis de ambiente, incluindo chaves de API e tokens armazenados como segredos, foram capturadas em determinadas contas afetadas. Um segredo no ambiente de um job raramente é interessante por si só; seu valor está no que ele desbloqueia em outros lugares.

As informações de faturamento expostas incluíam endereços de cobrança e de entrega, histórico de faturas e pagamentos, saldo da conta e uso de créditos. Os números de cartão de pagamento são outra história: a empresa afirma que não os armazena e que eles não foram afetados.

Sobre os pesos dos modelos, Lin Qiao, CEO da empresa, disse ao The Register que os invasores não pareciam estar atrás dos pesos e que a maioria dos downloads foi parcial e interrompida. Trate isso como uma avaliação do próprio fornecedor, não como uma constatação independente.

O impacto também se propaga adiante. A Notion, cliente da Fireworks, informou aos usuários afetados que seus workspaces estavam entre os menos de 1 por cento dos workspaces da Notion que podem ter sido afetados pelo incidente da Fireworks.

O produto mudou em resposta. Os uploads e downloads self-service de datasets usados pelo Batch Inference e pelo treinamento baseado em datasets foram desativados durante a investigação. A documentação de fine-tuning agora informa que avaliadores e jobs de avaliação foram removidos. Trata-se do mesmo recurso cujas variáveis de ambiente foram expostas no primeiro incidente.

Por que o LLMjacking transforma uma chave vazada em uma conta alta

LLMjacking é o roubo e a revenda de acesso à inferência de modelos.

O Google Threat Intelligence Group relata que, em várias investigações do que chama de "LLMJacking", o vetor de acesso inicial predominante foram tokens de identidade de nuvem expostos ou roubados. Isso inclui credenciais de IAM, chaves de contas de serviço, tokens de acesso pessoal do GitHub e tokens de sessão ativos. Repare como essa lista é muito mais ampla do que chaves de API de modelos. Para quem defende, esse é o ponto principal.

O Google descreve os "LLM Mixers" como gateways de roteamento ilícitos que fazem proxy, agregam e revendem acesso não autorizado a LLMs para assinantes clandestinos. Um desses serviços, o Jet Night, oferece um plano de tokens ilimitados por cerca de $60 por mês com suposto acesso a modelos de fronteira, enquanto esse nível de serviço ao consumidor normalmente custaria entre $100 e $250 por mês.

Alguém paga a diferença, e é a vítima. Nos incidentes descritos pelo Google, as cobranças fraudulentas passaram de $100,000 em um único dia, e as cobranças acumuladas em algumas organizações chegaram a $1 milhão antes que o acesso fosse revogado. Em um caso, um agente de ameaça fez mais de 500,000 chamadas de API de LLM em menos de oito horas, usando chaves de API de terceiros roubadas para alimentar o Jet Night, e o serviço repassou quase $1 milhão em custos de tokens à organização vítima.

Pesquisas anteriores apontam na mesma direção. A análise original de 2024 da Sysdig estimou que um ataque não descoberto poderia custar a uma vítima mais de $46,000 por dia em consumo de LLM. Pesquisas posteriores da Sysdig indicaram que esse valor quase triplicou, passando de $100,000 por dia com modelos de primeira linha como o Claude 3 Opus.

O playbook Segredos, Dados, Gastos para clientes de inferência hospedada

Estas sete etapas valem para este incidente e para o próximo semelhante, seja qual for o provedor.

Segredos: o que você entregou

Etapa 1: Inventarie todos os segredos armazenados. Liste cada segredo armazenado no provedor, com atenção especial às variáveis de ambiente associadas a jobs de avaliação, batch ou treinamento. Como chaves de API e tokens armazenados como segredos foram capturados em determinadas contas afetadas, trate qualquer segredo dentro do escopo como comprometido até prova em contrário.

Etapa 2: Faça a rotação na origem. Revogue e emita novamente cada credencial de terceiros junto ao provedor que a emitiu. O fornecedor é explícito: remover apenas um segredo armazenado não invalida a credencial subjacente, e credenciais de terceiros exigem ação junto aos provedores emissores. No longo prazo, mantenha chaves brutas totalmente fora dos runtimes de jobs. As equipes podem considerar um proxy de credenciais para isso; veja nosso guia sobre proxies de credenciais para agentes de IA.

Etapa 3: Delimite o raio de impacto. Para cada chave rotacionada, anote o que ela podia alcançar (contas de nuvem, repositórios, bancos de dados, outras APIs de modelos) e revise os logs desses sistemas em busca de atividade após a janela de exposição. Dê aos tokens de identidade de nuvem e aos tokens do GitHub a mesma prioridade das chaves de modelos; nas investigações do Google, eles foram a porta de entrada mais comum.

Dados: o que você enviou

Etapa 4: Revise datasets e modelos. Descubra quais datasets, jobs de fine-tuning e modelos incompletos estavam na plataforma. Depois, decida se algum desses dados exige notificação a clientes, contratual ou regulatória. Envolva a assessoria jurídica desde cedo.

Etapa 5: Ajuste os fluxos de trabalho afetados. Planeje-se em torno dos recursos de datasets pausados para Batch Inference e treinamento baseado em datasets. Decida se você vai reenviar os dados quando os recursos voltarem ou mantê-los no seu próprio ambiente daqui em diante.

Gastos: o que você monitora

Etapa 6: Informe o financeiro sobre a exposição de faturamento. Endereços, histórico de faturas e saldos vazados dão a um fraudador detalhes úteis para um e-mail de phishing convincente ou uma fatura falsa. Peça às equipes de financeiro e de contas a pagar que confirmem qualquer solicitação de pagamento inesperada ou alteração bancária por um canal em que já confiam.

Etapa 7: Defina limites e alertas para cada chave restante. Configure alertas de gasto por chave e limites rígidos, tanto no provedor quanto no faturamento da sua própria nuvem. Encaminhe-os para um canal de plantão, não para uma caixa de entrada compartilhada que ninguém lê à noite. A seção de monitoramento abaixo mostra quais sinais observar.

Qualquer que seja o grupo, registre cada decisão com data, hora e um responsável.

Quem é responsável por cada etapa

Use isto como padrão inicial. Em uma equipe pequena, uma pessoa pode cobrir vários papéis. O que importa é que cada etapa tenha um responsável nomeado.

Onde a retenção zero de dados se aplica e onde não se aplica

De acordo com a documentação de tratamento de dados da Fireworks, a empresa adota retenção zero de dados (ZDR) por padrão, o que significa que não registra nem armazena dados de prompts ou de gerações de nenhum modelo aberto sem opt-in explícito do usuário. Sua página de política de ZDR acrescenta uma ressalva: alguns recursos armazenam conteúdo de clientes, como respostas armazenadas, jobs em batch e treinamento.

Veja o que a violação de fato atingiu: conteúdo armazenado, na forma de datasets e modelos incompletos, além de segredos, que a ZDR nunca teve a intenção de cobrir. Um padrão de ZDR vale a pena para inferência em tempo real. Não é uma promessa sobre tudo o que você envia. Sugerimos verificar as configurações de retenção de cada provedor que você usa, em vez de presumir que são iguais; nosso guia sobre armazenamento de requisições da API Gemini é uma leitura relacionada.

Na prática, rotule cada carga de trabalho como somente inferência ou como conteúdo armazenado. Para uploads de batch ou fine-tuning, remova os campos de que o modelo não precisa, oculte dados pessoais quando possível e mantenha a cópia mestre no seu próprio ambiente.

Checklist de due diligence de fornecedores: perguntas para qualquer provedor de inferência

Leve estas perguntas para avaliações de compras, renovações e questionários de segurança. Cada uma vem da linha do tempo da Fireworks ou do padrão mais amplo de LLMjacking.

• [ ] Tratamento de segredos: Onde os segredos dos clientes são armazenados, quem pode lê-los e os runtimes de jobs os recebem como variáveis de ambiente em texto simples?
• [ ] Cadeia de suprimentos: Quais nuvens de terceiros hospedam máquinas de P&D ou de desenvolvimento, e como elas são isoladas dos dados de clientes?
• [ ] Mapa de retenção: Quais recursos armazenam conteúdo de clientes? Como mostra a seção acima, isso varia de recurso para recurso, então obtenha a resposta por escrito.
• [ ] Comunicação de incidentes: O provedor vai divulgar quantos clientes foram afetados, e como as atualizações chegarão até você?
• [ ] Ciclo de vida de recursos: Quando um recurso é descontinuado, como aconteceu aqui com avaliadores e jobs de avaliação, como seus segredos e dados são eliminados?
• [ ] Controles de faturamento: É possível definir limites de gasto, cotas por chave e alertas de anomalia que cheguem a um canal de plantão?
• [ ] Escopo de credenciais: As chaves podem ser limitadas a modelos, projetos ou ambientes específicos, e rotacionadas sem indisponibilidade?
• [ ] Acesso a logs: É possível ver quem leu seus segredos e quando?

Boas respostas não fazem o risco desaparecer. Equipes que roteiam tráfego entre vários provedores também podem querer controles de roteamento e de orçamento na camada de gateway; veja nosso playbook de AI gateway.

Monitoramento de LLMjacking: sinais que podem aparecer antes da fatura

O LLMjacking costuma ser barulhento. Seus sinais muitas vezes aparecem nos dados de uso bem antes de a conta chegar, desde que alguém esteja olhando.

• Picos de volume. A Sysdig detectou mais de 85,000 requisições à API do Bedrock em uma campanha, e 61,000 delas chegaram em uma janela de três horas em 11 de julho de 2024. Um pico assim deve acionar alguém.
• Anomalias de taxa. O caso do Jet Night, com mais de 500,000 chamadas em menos de oito horas, provavelmente está muito acima de qualquer coisa que suas chaves fazem normalmente. Crie alertas para grandes desvios da taxa habitual de cada chave. O tracing de GenAI com OpenTelemetry é uma forma de coletar os dados de uso necessários para essa linha de base.
• Limites de gasto. Os limites por hora ou por dia da Etapa 7 restringem o dano na escala diária relatada pelo Google. Uma revisão mensal não consegue fazer isso.
• Padrões incomuns. Fique atento a chamadas para modelos que você normalmente não usa, novas regiões, endereços IP de origem desconhecidos e atividade em horários estranhos.
• Identidade, não apenas chaves. Trate qualquer token de identidade de nuvem roubado como um possível ponto de entrada para LLMjacking.

Essa tendência não começou com a Fireworks. A Sysdig relatou um aumento de 10x nas requisições de LLMjacking em julho de 2024, e o dobro de endereços IP únicos envolvidos nesses ataques ao longo do primeiro semestre de 2024.

Erros comuns que as equipes cometem após a violação de um provedor de inferência

• Tratar exclusão como revogação. Apagar um segredo de um painel é organização. Não é rotação (veja a Etapa 2).
• Interpretar demais um selo de ZDR. Consulte a tabela de retenção antes de presumir que uma carga de trabalho nunca foi armazenada.
• Rotacionar apenas a chave óbvia. Chaves de IAM, chaves de contas de serviço e tokens do GitHub armazenados junto com a chave do modelo importam tanto quanto ela. Nas investigações do Google, os tokens de identidade de nuvem foram o ponto de entrada mais comum.
• Tratar o primeiro boletim como definitivo. Aqui o escopo cresceu de segredos armazenados para informações de faturamento, datasets e modelos incompletos. Reavalie sua exposição a cada atualização.
• Esperar a fatura mensal. Com as taxas de perda diárias descritas acima, uma fatura chega tarde demais para ajudar.

Ressalvas: o que ainda é desconhecido e como interpretar os números

• A Fireworks não divulgou quantos clientes foram afetados.
• A afirmação de que os invasores não estavam atrás dos pesos dos modelos vem de Lin Qiao, CEO da Fireworks, e não foi verificada de forma independente.
• Os números de custo de LLMjacking vêm de investigações do Google Threat Intelligence Group e da Sysdig sobre outras vítimas, não deste incidente. Eles mostram o que é possível, não o que os clientes da Fireworks perderam.
• Os números da Sysdig são de 2024 e refletem os preços de modelos e os volumes de ataque daquele período.
• O número de menos de 1 por cento da Notion se aplica apenas aos workspaces da Notion.
• As obrigações de notificação dependem da sua jurisdição e dos seus contratos, então busque orientação jurídica quando elas se aplicarem.