Habr AI revela como uma porta aberta em plataforma LLM expôs chaves de API e infraestrutura

Uma história de uma auditoria de uma grande plataforma RAG demonstra uma conclusão incômoda para o mercado de IA: os incidentes mais caros frequentemente começam não com um ataque "inteligente" ao modelo, mas com um simples erro de infraestrutura. O time gastou duas semanas procurando por vulnerabilidades complexas, mas acabou obtendo acesso a chaves e serviços internos em apenas alguns minutos.

Como Encontraram o Acesso

Os auditores testaram um serviço com dezenas de milhares de usuários e inicialmente seguiram o caminho esperado para uma pilha LLM: verificaram SSRF em combinação com LangChain, tentaram injeções de prompt, analisaram processamento HTTP e procuraram vulnerabilidades de desserialização. A lógica é compreensível: essas são exatamente as áreas geralmente discutidas quando se fala sobre segurança de RAG, agentes e aplicações LLM. Mas nenhuma das longas cadeias de ataques produziu resultados.

A descoberta crítica apareceu não na aplicação, mas no nível de infraestrutura mal protegida.

"Fizemos um curl para uma porta aberta — e conseguimos todas as chaves

em 5 minutos."

Esta frase captura bem o contraste principal. Enquanto a indústria teme ataques exóticos na orquestração de modelos, sistemas de produção real frequentemente têm interfaces abertas onde você pode ver configs, variáveis de ambiente, URLs internos e tokens para APIs externas. Se tais segredos estão ao lado de chaves funcionais, comprometer um serviço rapidamente se torna comprometer toda a plataforma.

Por Que Isso Acontece

Plataformas LLM raramente existem como um único servidor com um modelo. Tipicamente, consistem de microsserviços: gateway de API, orquestrador de cadeias, banco de dados vetorial, armazenamento de arquivos, filas, painéis de administração internos, provedores de embeddings, logging, monitoramento e faturamento. Cada novo componente adiciona redes, segredos, funções e pontos de integração. Como resultado, um time pode ter uma interface de usuário bem configurada e autorização básica, mas portas internas mal isoladas, painéis de depuração ou contêineres com acesso privilegiado.

O problema é agravado pelo fato de que startups de IA frequentemente pensam sobre ameaças no nível do modelo. Eles discutem extensivamente jailbreaks, vazamento de prompts de sistema, alucinações e proteção de contexto RAG, mas adiam a higiene clássica de DevSecOps. Porém, é precisamente essa higiene que determina se um atacante pode alcançar segredos, infraestrutura em nuvem ou chaves de API no valor de centenas de milhares de dólares. Se um serviço interno escuta a rede desnecessariamente e segredos estão disponíveis para um processo "por precaução", o LLM não é mais o problema principal — ele simplesmente aumenta o custo das consequências.

Onde Erros Ocorrem com Mais Frequência

O material é útil porque traz a conversa sobre segurança de serviços de IA de volta para questões fundamentais de disciplina de engenharia. Mesmo se a aplicação for construída em torno de uma cadeia complexa de recuperação, agentes e múltiplos modelos, um atacante quase sempre procurará o caminho mais barato. E este caminho frequentemente passa por erros antigos e familiares que qualquer time que trabalhe com infraestrutura em nuvem e contêineres conhece.

• Portas internas abertas e serviços sem ACL rigoroso
• Segredos em variáveis de ambiente, logs ou configurações acessíveis a serviços vizinhos
• Permissões excessivas para contêineres, runners e contas de serviço
• Falta de segmentação entre a camada RAG, painel de administração e infraestrutura em nuvem
• Foco em injeção de prompt enquanto se ignora higiene de rede

Para um produto, isso significa que auditorias de segurança não podem ser reduzidas a red teaming de prompts. Você precisa de um inventário de todos os componentes ao redor do modelo: quais serviços são expostos externamente, quais chaves estão disponíveis para cada contêiner, onde interfaces de depuração estão habilitadas, como o tráfego de entrada e saída é restringido, quem tem acesso a logs e snapshots de ambiente. Sem isso, até mesmo proteção de qualidade da camada de aplicação deixa a infraestrutura vulnerável, e qualquer comprometimento se transforma de um bug local em um incidente em larga escala com vazamento de dados, perda de orçamento e acesso comprometido aos provedores.

O Que Isso Significa

A conclusão principal é simples: um produto de IA deve ser protegido não como "magia LLM especial", mas como uma plataforma crítica ordinária com segredos caros e um grande raio de explosão. Se a infraestrutura básica não estiver protegida, nenhuma conversa sobre ataques complexos ao modelo ajudará — uma porta aberta se tornará mais importante do que toda sua arquitetura de IA.