Habr AI detalha como uma única porta aberta em uma plataforma de LLM leva a chaves e infraestrutura

Uma história de auditoria de uma grande plataforma RAG traz uma conclusão incômoda para o mercado de IA: os incidentes mais caros muitas vezes começam não com um ataque «inteligente» ao modelo, mas com um erro banal de infraestrutura. A equipe passou duas semanas procurando vulnerabilidades sofisticadas, mas no fim obteve acesso a chaves e serviços internos literalmente em poucos minutos.

Como o acesso foi encontrado

Os auditores testaram um serviço com dezenas de milhares de usuários. Primeiro seguiram o caminho esperado para uma stack de LLM: verificaram SSRF combinado com LangChain, tentaram injeções de prompt, analisaram o tratamento de HTTP e procuraram vulnerabilidades de desserialização. A lógica é clara: são esses os temas que costumam ser discutidos quando o assunto é segurança de RAG, agentes e aplicações com LLM. Mas nenhuma das cadeias longas produziu resultado funcional. A descoberta crítica apareceu não na aplicação, mas em uma infraestrutura mal protegida.

«Fizemos um único curl em uma porta aberta e pegamos todas as chaves

em 5 minutos».

Essa frase resume bem o principal contraste do material. Enquanto a indústria teme ataques exóticos à orquestração de modelos, ambientes de produção reais muitas vezes mantêm interfaces abertas pelas quais é possível ver configurações, variáveis de ambiente de serviço, URLs internas e tokens de APIs externas. Se esses segredos ficam ao lado das chaves de produção, o comprometimento de um serviço rapidamente vira o comprometimento de toda a plataforma.

Por que isso acontece

Plataformas de LLM raramente rodam como um servidor com um modelo. Normalmente são um conjunto de microsserviços: gateway de API, orquestrador de cadeias, banco vetorial, armazenamento de arquivos, filas, painéis administrativos internos, provedores de embeddings, logging, monitoramento e cobrança. Cada novo componente adiciona rede, segredos, papéis e pontos de integração. Com isso, a equipe pode ter a interface de usuário e a autorização básica bem configuradas, mas portas internas, painéis de depuração ou contêineres com acesso privilegiado mal isolados.

O problema se agrava porque startups de IA costumam pensar em ameaças no nível do modelo. Falam muito de jailbreak, vazamento do prompt de sistema, alucinações e proteção do contexto RAG, mas adiam a higiene clássica de DevSecOps. No entanto, é ela que determina se um invasor conseguirá chegar a segredos, à infraestrutura de nuvem ou a chaves pagas que valem centenas de milhares de dólares. Se um serviço interno escuta a rede sem necessidade e os segredos ficam disponíveis a um processo «por precaução», o LLM deixa de ser o problema principal: ele apenas aumenta o custo das consequências.

Onde mais se erra

O material é útil porque leva a conversa sobre segurança de serviços de IA de volta ao básico da disciplina de engenharia. Mesmo que a aplicação seja construída em torno de uma cadeia complexa de recuperação, agentes e vários modelos, o atacante quase sempre procura o caminho mais barato. E esse caminho muitas vezes passa por erros antigos e conhecidos de qualquer equipe que já trabalhou com infraestrutura de nuvem e contêineres.

• Portas e serviços internos abertos sem ACL rigorosa
• Segredos em variáveis de ambiente, logs ou configuração acessíveis a serviços vizinhos
• Permissões excessivas em contêineres, runners e contas de serviço
• Falta de segmentação entre a camada RAG, o painel administrativo e a infraestrutura de nuvem
• Foco em prompt injection e descaso com a higiene de rede

Para o produto, isso significa que uma auditoria de segurança não pode se resumir a red teaming de prompts. É preciso inventariar todos os componentes em torno do modelo: quais serviços ficam expostos externamente, quais chaves cada contêiner enxerga, onde há interfaces de depuração ativas, como o tráfego de saída e de entrada é limitado e quem tem acesso a logs e snapshots do ambiente. Sem isso, mesmo uma boa proteção da camada de aplicação deixa a infraestrutura vulnerável, e qualquer comprometimento deixa de ser um bug local e vira um incidente em larga escala, com vazamento de dados, de orçamento e de acesso a provedores.

O que isso significa

A conclusão principal é simples: um produto de IA deve ser protegido não como «mágica especial com LLM», mas como uma plataforma crítica comum, com segredos caros e grande raio de impacto. Se a infraestrutura básica não está fechada, nenhuma conversa sobre ataques sofisticados ao modelo vai salvar: uma porta aberta acaba importando mais que toda a sua arquitetura de IA.