O LLMjacking transforma uma credencial de nuvem ou chave de API roubada em acesso a modelos de inteligência artificial pagos pela vítima. O efeito pode aparecer primeiro na fatura, mas o problema é de segurança: identidade comprometida, consumo não autorizado e possibilidade de ampliar o ataque dentro do ambiente cloud.
O uso corporativo de modelos de linguagem criou um ativo novo e caro dentro da infraestrutura de tecnologia. APIs de IA, serviços gerenciados em nuvem e modelos hospedados são consumidos sob demanda e, em muitos casos, faturados por volume de requisições, tokens processados ou capacidade computacional. Quando a credencial que autoriza esse consumo é roubada, o atacante não precisa instalar nada na empresa para gerar prejuízo: basta usar o acesso que já existe.
Esse tipo de abuso ficou conhecido como LLMjacking. O termo foi cunhado pela Sysdig em 2024 ao descrever ataques em que credenciais de nuvem comprometidas eram testadas contra diferentes serviços de inteligência artificial. A pesquisa identificou ferramentas capazes de verificar acesso a dez provedores e modelos, consultar quotas e descobrir quais credenciais poderiam ser aproveitadas. Em uma das cadeias observadas, pesquisadores encontraram indícios de uso de reverse proxies para repassar o acesso a terceiros enquanto a conta comprometida arcava com o consumo.
O ataque começa na identidade, não no modelo
LLMjacking não depende de uma vulnerabilidade no modelo de IA. O ponto decisivo é a autorização. Chaves de API, access keys de nuvem, tokens, contas de serviço e identidades de workload funcionam como a ponte entre uma aplicação e o serviço de IA. Se esse material é exposto em código, repositórios, buckets, arquivos de configuração, pipelines ou sistemas vulneráveis, ele pode ser reutilizado por outra pessoa.
A pesquisa original da Sysdig partiu de um ambiente comprometido por uma versão vulnerável do Laravel. Depois do acesso inicial, as credenciais cloud foram exfiltradas e testadas contra serviços de IA. O atacante não precisava conhecer a senha de um usuário final nem comprometer o modelo: precisava apenas encontrar uma identidade com autorização suficiente para invocá-lo.
Do ponto de vista do provedor, muitas dessas chamadas chegam com uma credencial válida. Por isso, a diferença entre uso legítimo e abuso depende de contexto: origem da requisição, horário, região, modelo utilizado, volume de tokens, frequência, comportamento histórico e alterações recentes de permissões.
A fatura é apenas uma parte do impacto
O efeito mais visível é financeiro. Em 2024, a Sysdig estimou que determinadas combinações de modelo e volume poderiam ultrapassar US$ 46 mil por dia. Meses depois, ao analisar a evolução da técnica e modelos mais caros, a empresa estimou cenários acima de US$ 100 mil por dia. Esses números representam cenários de consumo potencial calculados pelos pesquisadores, e não uma fatura universal: o impacto real depende de quotas, modelo, preço, limites da conta e tempo até a detecção.
O risco, porém, não termina no custo. A mesma credencial pode oferecer visibilidade sobre serviços, regiões, permissões e recursos relacionados. Se estiver associada a privilégios mais amplos, o LLMjacking pode ocorrer dentro de uma intrusão maior, com coleta de segredos, movimentação lateral e escalada de privilégios.
Foi o que apareceu em uma investigação divulgada pela Sysdig em fevereiro de 2026. O grupo analisado obteve credenciais expostas em buckets S3, alcançou privilégios administrativos em menos de dez minutos e, entre outras ações, abusou do Amazon Bedrock para LLMjacking. O caso mostra que o consumo indevido de IA pode ser uma etapa de uma operação cloud mais extensa, e não um incidente isolado de cobrança.
Outra evolução observada em 2026 foi o uso não autorizado de infraestrutura de IA como componente de ferramentas ofensivas. Em junho, pesquisadores encontraram um servidor Ollama mal configurado sendo utilizado como motor de raciocínio de uma ferramenta automatizada de exploração. Esse caso não é idêntico ao LLMjacking clássico baseado em credencial roubada, mas revela o mesmo incentivo econômico: usar capacidade de IA de terceiros para reduzir custo e acelerar operações próprias.
Quando custo vira sinal de segurança
Tradicionalmente, alertas de orçamento e consumo ficam sob responsabilidade de FinOps, cloud operations ou financeiro. O LLMjacking mostra que essa separação pode atrasar a resposta. Um aumento abrupto no número de invocações, no consumo de tokens ou no uso de um modelo nunca utilizado antes pode ser um evento financeiro e um indicador de comprometimento ao mesmo tempo.
Por isso, telemetria de IA deve ser correlacionada com logs de identidade e de nuvem. Um pico de custo acompanhado de chamadas vindas de nova região, alteração de role, criação de chave, mudança de política ou atividade fora do padrão histórico merece tratamento de incidente, não apenas revisão de orçamento.
Como reduzir a exposição ao LLMjacking
A proteção começa pela mesma disciplina aplicada a qualquer identidade de nuvem de alto valor: reduzir a quantidade de credenciais permanentes, limitar privilégios e tornar o abuso visível. Chaves estáticas devem ser substituídas, sempre que a arquitetura permitir, por identidades de workload e credenciais temporárias. Em AWS, Azure e Google Cloud, mecanismos nativos permitem reduzir a dependência de segredos de longa duração.
Segredos não devem viver no código. Repositórios, arquivos .env, imagens de contêiner, buckets públicos, notebooks, logs e pipelines são fontes recorrentes de exposição. Secret scanning deve existir tanto na cadeia de desenvolvimento quanto no ambiente em produção. Quando uma chave é encontrada publicamente, removê-la do arquivo não basta: ela precisa ser revogada ou rotacionada.
Menor privilégio precisa chegar aos serviços de IA. Uma identidade que apenas executa uma função específica não deveria conseguir habilitar novos modelos, alterar logging, criar outras credenciais ou acessar recursos sem relação com a aplicação. O controle deve considerar modelo, região, ação permitida e escopo da identidade.
Quotas e budgets são contenção, não autenticação. Limites de gasto e alertas reduzem impacto e ajudam na detecção, mas não corrigem uma credencial comprometida. A resposta deve combinar bloqueio financeiro com revogação de chaves, análise dos logs e verificação de outras ações executadas pela mesma identidade.
O SOC precisa enxergar a telemetria de IA. Logs de invocação de modelos, trilhas de auditoria cloud, eventos de IAM e dados de custo devem alimentar regras de detecção e investigações. O objetivo é reconhecer desvios de comportamento antes que o evento apareça apenas no fechamento da fatura.
Inventário também é controle. A empresa precisa saber quais equipes usam IA, quais modelos estão autorizados, quais identidades fazem as chamadas, onde os segredos são armazenados e qual centro de custo responde pelo consumo. Sem esse mapa, uma anomalia pode parecer apenas crescimento de uso.
O problema de governança por trás da técnica
LLMjacking expõe uma fronteira que muitas organizações ainda administram de forma fragmentada. Segurança olha credenciais; cloud operations olha serviços; FinOps olha custos; áreas de negócio olham modelos e produtividade. O atacante, por outro lado, enxerga tudo como a mesma cadeia.
Quanto mais a IA passa a operar dentro de aplicações, automações e agentes, mais importante se torna tratar acesso ao modelo como uma relação de confiança auditável. Isso inclui owner da identidade, finalidade, privilégios, duração da credencial, origem esperada das chamadas, logs e mecanismo de revogação.
A conta inesperada pode ser o primeiro alerta
O LLMjacking mostra que a economia do uso de IA também se tornou parte da superfície de ataque. Uma credencial roubada pode ser convertida diretamente em capacidade computacional, e o prejuízo pode aparecer no painel de custos antes de gerar um alerta tradicional de malware ou exploração.
Para as empresas, a resposta mais eficaz é conectar identidade, segurança de nuvem, observabilidade e FinOps. Quando uma chamada de IA depende de uma credencial e tem custo mensurável, consumo fora do padrão não é apenas um problema de orçamento: pode ser evidência de comprometimento.
Referências
- ZDNET — LLMjacking
- Sysdig — LLMjacking: Stolen Cloud Credentials Used in New AI Attack
- Sysdig — The Growing Dangers of LLMjacking: Evolving Tactics and Evading Sanctions
- Sysdig — AI-assisted cloud intrusion achieves admin access in 8 minutes
- Sysdig — LLMjacking evolved: Attackers are using stolen AI compute to build offensive agentic tools
Be the first to comment