IA
A segurança de IA vai além da prevenção de roubo de dados, da restrição de agentes de IA maliciosos ou de impedir que assistentes forneçam conselhos prejudiciais. Uma ameaça relativamente simples, mas de rápida expansão, surgiu: tentativas de sequestrar poder computacional e explorar a rede neural de outra pessoa para ganho pessoal. Isso é conhecido como LLMjacking. Como se prevê que os custos de computação com IA vão aumentar drasticamente, o número de invasores motivados por esses interesses também deve crescer. É por isso que, ao implementar servidores de IA proprietários e seus ecossistemas de suporte, como RAG ou MCP, é essencial adotar medidas de segurança rigorosas desde o início.
Estatísticas de um honeypot
A velocidade e a escala dessas tentativas de sequestro de recursos são melhor ilustradas por um experimento documentado em detalhes em abril de 2026. Um pesquisador configurou um Raspberry Pi para se passar por um servidor de IA privado de alto desempenho e o tornou acessível na Internet. Quando consultado, este servidor relatou a disponibilidade dos servidores Ollama, LM Studio, AutoGPT, LangServe e text-gen-webui, que são ferramentas bastante usadas como wrappers para modelos de IA hospedados localmente. O servidor também parecia apto a aceitar solicitações de API no formato OpenAI, que se tornou o padrão do setor.
Tudo indica que esses serviços eram executados por uma instância local do Qwen3-Coder 30B Heretic (um dos modelos de código aberto mais poderosos), cujo alinhamento de segurança foi removido. Para tornar a armadilha mais atraente, o honeypot relatou a presença de vários bancos de dados RAG e de um servidor MCP com recursos tentadores, como get_credentials .
Na realidade, o Raspberry Pi estava simplesmente hospedando 500 respostas pré-salvas de um modelo Qwen3 real, com um script leve que selecionava a resposta mais relevante para cada consulta recebida. Essa configuração foi suficiente para passar em uma verificação superficial, permitindo ao pesquisador investigar as intenções dos invasores.
De acordo com o autor, o Shodan, um serviço de verificação popular da Internet, descobriu o servidor em menos de três horas após sua ativação. Apenas uma hora depois, começaram a chegar solicitações semelhantes a sondagens de capacidades. Durante o mês seguinte, o servidor recebeu mais de 113 mil solicitações de milhares de IPs exclusivos, sendo que 23% desse tráfego foi direcionado à descoberta de recursos de IA e à exploração de LLMs locais e agentes de IA.
As solicitações para endpoints como /api/tags e /v1/models permitem que os invasores identifiquem quais modelos estão hospedados em um servidor, enquanto a verificação de /.cursor/rules geralmente precede uma tentativa de explorar um agente de IA. Da mesma forma, a verificação de /.well-known/mcp.json serve como um inventário dos servidores MCP da vítima. Embora o autor não mencione o número total de ataques que foram além de verificações simples, houve 175 tentativas ativas de sequestrar o LLM somente na última semana do experimento.
O que os invasores querem?
Com base nas observações do pesquisador, nenhum dos invasores do servidor isca tentou executar código arbitrário ou obter acesso raiz. (Nota editorial: isso é surpreendente e pode ter ocorrido devido a lacunas no registro.) Quase todos os ataques visavam desviar recursos. As seguintes atividades foram registradas durante o experimento:
- Uma tentativa bem estruturada de analisar a documentação técnica de um microprocessador
- Um prompt para escrever um romance erótico
- Solicitações para analisar e estruturar dados de texto de mídia social em relação a novas vulnerabilidades
- Uma tentativa de chamar modelos da Anthropic usando o servidor comprometido como um proxy de API
É importante notar que o reconhecimento de recursos de IA é feito por meio de ferramentas padronizadas e de rápida evolução. As solicitações de um aplicativo chamado LLM-Scanner partiram da infraestrutura de sete provedores de nuvem diferentes em oito países, sugerindo que os invasores já adotaram metodologias consolidadas, além de plataformas especializadas para compartilhamento de técnicas. Na terceira semana do experimento, o scanner foi atualizado com uma verificação adicional: agora ele usava perguntas abstratas simples para determinar se estava interagindo com a IA ao vivo ou se estava lidando com um honeypot configurado para fornecer respostas prontas.
Entre os ataques não específicos, o experimento registrou várias tentativas de extrair credenciais do arquivo .env. Os invasores caçavam esse arquivo de forma sistemática em todos os diretórios concebíveis no servidor. Deixar um arquivo .env acessível ao público é um dos erros mais básicos ao implementar projetos no Laravel, no Node.js e em outros frameworks. Porém, isso continua sendo um descuido comum, especialmente entre iniciantes e vibe coders. Isso acaba por aumentar as chances de que os esforços dos invasores deem resultado.
Conclusões e dicas de defesa
Não é novidade que invasores verificam servidores acessíveis ao público e tentam explorá-los. Mas a ascensão dos LLMs oferece aos invasores outra forma de monetizar seus esforços, o que é muito lucrativo para eles e devastador para as vítimas. Para entender a enorme escala a que esses ataques podem chegar, basta analisar a sua contraparte mais próxima: o mercado de cryptojacking, onde os criminosos mineram criptomoedas usando recursos computacionais roubados. Esse mercado cresceu 20% em 2025. À medida que as soluções alimentadas por IA se proliferam e os principais provedores aumentam os custos de assinatura, enquanto os chips locais de IA continuam escassos, devemos esperar que o LLMjacking se torne um fenômeno em escala industrial.
Principais medidas defensivas para infraestruturas de IA privadas
- Para sistemas de IA executados localmente em uma única máquina, os servidores como LM Studio, Ollama ou similares devem estar configurados para aceitar conexões somente na interface local (localhost), e não em todas as interfaces de rede disponíveis. Isso restringe o acesso do LLM à própria máquina host e evita que a IA seja acessível pela Internet.
- Para servidores que recebem solicitações remotas, implemente autenticação e autorização robustas em vez de depender apenas da validação da chave de API, ainda que o servidor opere somente dentro de uma rede corporativa local. As soluções baseadas em OIDC ou OAuth2 com tokens de curta duração são as mais eficazes. Isso não apenas protege contra o LLMjacking, mas também evita o abuso das chaves de API e permite um monitoramento mais detalhado da atividade do usuário. Além disso, as chaves devem ser protegidas não apenas contra invasores externos, já que o uso indevido pelos próprios agentes de IA é um risco crescente. Isso se aplica às interfaces LLM, bem como ao MCP, RAG e outros.
- Use segmentação de rede e listas de permissão de IP para conceder acesso ao servidor de IA somente aos departamentos, funcionários e serviços que precisem dele.
- Todas as conexões entre cliente e servidor devem estar protegidas por uma versão atual do TLS.
- Aplique o princípio do privilégio mínimo separando o acesso a serviços específicos. Por exemplo, os componentes MCP e LLM devem ter seus próprios tokens de acesso distintos.
- Instale um Agente de segurança EDR em todas as estações de trabalho e servidores, incluindo aqueles que hospedam modelos de IA.
- Monitore o consumo dos recursos de IA, estabeleça cotas de uso conforme a função dos funcionários e configure alertas para picos de atividade incomuns.
- Mantenha registros detalhados das respostas do LLM e das solicitações feitas ao modelo e às suas ferramentas de suporte. Integre essas fontes de dados ao seu SIEM. Proteja os registros contra adulteração ou exclusão.
