Serviços de IA expostos na internet revelam falhas de autenticação, chaves em texto claro e agentes com acesso operacional

Levantamento em larga escala identificou interfaces de LLM, APIs Ollama, plataformas Flowise e instâncias n8n acessíveis sem autenticação, com risco de abuso de modelos, vazamento de conversas, exfiltração por ferramentas conectadas e execução de código em servidores mal isolados.

Componente	Serviços de IA auto-hospedados, chatbots LLM, APIs Ollama, plataformas Flowise, instâncias n8n, fluxos de agentes e integrações com ferramentas externas.
Vetor	Exposição direta à internet de instalações com autenticação ausente ou fraca, padrões inseguros em Docker, credenciais estáticas em exemplos e arquivos docker-compose, além de contas administrativas habilitadas sem controle de acesso.
Impacto	Acesso não autorizado a históricos de conversa, prompts, workflows, listas de credenciais, uso indevido de modelos pagos, abuso de infraestrutura de terceiros, alteração de fluxos, redirecionamento de tráfego e possível execução de código quando agentes têm ferramentas locais perigosas.
Prioridade	Remover exposição pública não intencional, exigir autenticação em todas as interfaces, isolar agentes em sandbox, revisar integrações com terceiros, rotacionar chaves expostas e auditar serviços de IA descobertos por inventário externo.
Artefatos	Foram observados mais de 2 milhões de hosts derivados de logs de transparência de certificados, 1 milhão de serviços expostos, mais de 5.200 servidores Ollama consultados, 31% deles respondendo a uma requisição simples, e 518 modelos associados a provedores comerciais conhecidos.
Mitigação	Aplicar autenticação obrigatória, segmentação de rede, execução sem privilégio de root, remoção de segredos de imagens e exemplos, bloqueio de funções locais sensíveis e monitoramento de chamadas a modelos, ferramentas, credenciais e conectores.

Resumo técnico

A exposição de infraestrutura de IA auto-hospedada criou uma superfície pública que combina problemas clássicos de administração de sistemas com riscos específicos de agentes e modelos de linguagem. Em uma varredura baseada em logs de transparência de certificados, mais de 2 milhões de hosts foram relacionados a cerca de 1 milhão de serviços expostos. Dentro desse conjunto apareceram chatbots, APIs de inferência, orquestradores de agentes, ferramentas de automação e painéis de workflow acessíveis pela internet. O padrão técnico mais crítico foi a ausência de autenticação em instalações recém-publicadas, permitindo que um visitante externo alcançasse funções que deveriam estar restritas a operadores internos.

O risco não se limita ao uso gratuito de capacidade computacional ou de modelos pagos. Em vários cenários, a interface pública dava acesso a histórico de conversas, configuração de bots, prompts de sistema, fluxos de automação, conectores externos e ferramentas locais ligadas ao processo do agente. Quando um chatbot está integrado a sistemas de nuvem, parsing de internet, escrita de arquivos, interpretação de código ou APIs corporativas, a fronteira de segurança deixa de ser apenas a tela de chat. O acesso ao bot passa a representar acesso indireto aos recursos que o bot consegue acionar, principalmente quando não existem autorização por escopo, sandbox forte, segregação de rede e trilhas de auditoria por usuário.

As falhas observadas seguem uma combinação perigosa: padrões de instalação permissivos, exemplos com credenciais estáticas, contêineres mal configurados, processos executando como root, ausência de autenticação inicial e pressa para colocar protótipos de IA em produção. Em ambientes de engenharia, isso amplia o impacto de uma exposição simples porque agentes frequentemente têm permissões para consultar repositórios, acionar pipelines, chamar provedores de LLM, manipular arquivos, gerar requisições HTTP e operar ferramentas administrativas. A resposta defensiva precisa tratar esses serviços como ativos de alto privilégio, não como interfaces experimentais isoladas.

Fluxo técnico

O fluxo de exposição começa na publicação direta de um serviço de IA em um endereço roteável, muitas vezes por meio de um proxy, túnel, balanceador, contêiner ou host de desenvolvimento promovido sem endurecimento. Se a aplicação não exige autenticação por padrão, o primeiro acesso externo já entrega uma sessão operacional. Em chatbots baseados em OpenUI e implementações similares, isso pode revelar histórico completo de conversas ou permitir interação com modelos vinculados ao backend. Em ambientes corporativos, conversas com LLMs frequentemente carregam descrições de arquitetura, trechos de código, nomes de sistemas, dados pessoais, hipóteses de investigação, erros de produção e instruções internas. Mesmo sem um dump de banco de dados, esse conteúdo tem valor para reconhecimento e engenharia de ataques posteriores.

Nas APIs Ollama, a exposição assume outro formato. Servidores com modelos conectados responderam a uma requisição simples em 31% dos mais de 5.200 alvos consultados. Como Ollama não armazena mensagens diretamente por padrão, o risco principal não é necessariamente a leitura de conversas anteriores, mas o uso não autorizado da capacidade de inferência e dos modelos acoplados. Foram identificados 518 modelos associados a provedores comerciais conhecidos, incluindo Anthropic, Deepseek, Moonshot, Google e OpenAI, encapsulados por serviços expostos. Esse desenho permite que terceiros consumam infraestrutura, façam requisições sob a conta da organização dona do servidor e tentem contornar controles de uso, custo, registro e segurança aplicados às próprias contas.

O cenário fica mais grave em plataformas de gerenciamento de agentes e workflows, como Flowise e n8n. Uma instância exposta pode revelar a lógica completa de um serviço de chatbot, incluindo nós de decisão, chamadas a APIs, ferramentas habilitadas, prompts e conexões externas. Em um caso observado, a lista de credenciais estava visível, embora os valores armazenados não fossem retornados ao visitante não autenticado. Essa proteção reduz o dano imediato, mas não elimina o risco operacional: um invasor com acesso à interface pode aproveitar conectores já autorizados para ler, enviar, transformar ou exfiltrar dados por meio dos próprios componentes do workflow. Quando a plataforma também expõe ferramentas de parsing de internet, escrita em disco ou interpretação de código, a cadeia passa de abuso de chatbot para execução de ações no servidor ou contra sistemas internos alcançáveis pela aplicação.

A presença de credenciais em texto claro apareceu em serviços específicos, incluindo bots conectados a Claude que expunham chaves de API. Chaves desse tipo devem ser tratadas como material de acesso direto a contas, limites de cobrança, logs de uso e dados transmitidos ao provedor. Se uma chave vaza em um painel público, a contenção exige revogação imediata, emissão de nova chave, revisão de uso histórico, validação de cobranças e procura por chamadas atípicas. A simples remoção da página pública não desfaz o comprometimento de um segredo já observado por terceiros.

Superfície afetada

A superfície afetada inclui qualquer ambiente que tenha publicado serviços de IA sem um inventário externo confiável. Isso envolve laboratórios de engenharia, demonstrações internas, servidores de prova de conceito, stacks em Docker, instâncias com nomes DNS emitidos em certificados públicos, painéis de automação, chatbots de atendimento, agentes com ferramentas locais e gateways que conectam modelos comerciais a aplicações próprias. Mais de 90 instâncias expostas foram observadas em setores como governo, marketing e finanças, com workflows, prompts e acessos externos abertos. A presença desses setores indica que o problema não está restrito a projetos pessoais ou ambientes de teste sem dados sensíveis.

O ponto comum é a quebra de premissa sobre alcance de rede. Muitas instalações parecem ter sido montadas como sistemas internos, mas terminaram publicadas na internet. Em uma aplicação tradicional, isso já exporia painéis administrativos; em IA, também expõe instruções de agente, memória de conversação, rotas de ferramentas e conectores que podem tocar dados de terceiros. O impacto real depende do que cada bot consegue acessar: um agente sem ferramentas causa consumo indevido e vazamento de prompts; um agente com credenciais de nuvem, automação de infraestrutura ou execução local amplia a exposição para ativos operacionais.

• Interfaces de chatbot sem autenticação podem expor conversas, prompts de sistema, modelos disponíveis e dados inseridos por usuários.
• Servidores Ollama publicados sem controle de acesso podem permitir uso externo de modelos locais ou de modelos comerciais encapsulados.
• Instâncias Flowise e n8n abertas podem revelar workflows, nós de integração, listas de credenciais, conectores e lógica de negócio.
• Stacks com Docker mal configurado, credenciais estáticas e processos como root aumentam o risco de movimentação a partir do serviço exposto.
• Agentes com escrita de arquivos, interpretação de código ou ferramentas de parsing podem transformar acesso web em execução de ações no servidor.

Hunting e telemetria

A busca deve começar por inventário externo, não apenas por CMDB interna. Logs de transparência de certificados, DNS público, registros de proxy, regras de balanceadores e exposição de portas precisam ser cruzados com nomes de aplicações de IA, endpoints de API e banners de serviços. Em seguida, os times devem validar se há autenticação antes de qualquer operação sensível, se a interface administrativa é separada da interface de usuário e se endpoints de geração, listagem de modelos, execução de workflow e gerenciamento de credenciais respondem a clientes não autenticados.

Em endpoint e servidor, a telemetria relevante inclui criação de processos por serviços de IA, execução de interpretadores, escrita em diretórios incomuns, chamadas de rede originadas pelo processo do agente e leitura de arquivos fora do diretório esperado da aplicação. Em plataformas de workflow, o foco deve estar em alterações de fluxos, criação de novos nós, chamadas para domínios não reconhecidos, exportação de configurações, teste de conectores e uso de credenciais já cadastradas. Em provedores de LLM, os sinais incluem aumento de volume, prompts fora do padrão do produto, chamadas originadas de IPs incomuns e uso de modelos que não fazem parte do desenho aprovado.

A detecção também deve considerar abuso sem exploração de vulnerabilidade. Um visitante que usa uma API aberta exatamente como projetada ainda está realizando acesso não autorizado se o serviço foi exposto por erro. Por isso, a ausência de falha de software identificada não deve encerrar a investigação. Registros de acesso HTTP, cabeçalhos, endereços IP de origem, horários de primeira interação, parâmetros de modelo, tamanho de prompt, resposta de autenticação e status de execução de ferramentas são elementos suficientes para reconstruir parte da atividade.

• Requisições não autenticadas para endpoints de geração, listagem de modelos, workflows, credenciais, histórico de chat ou execução de ferramentas.
• Aumento de chamadas a provedores de LLM, principalmente quando associado a modelos comerciais encapsulados por servidores internos.
• Alterações em workflows de Flowise ou n8n, criação de nós novos, mudanças em prompts e conexões para destinos externos não previstos.
• Processos filhos, interpretação de código, escrita de arquivos ou chamadas HTTP iniciadas pelo serviço de IA fora do comportamento normal.
• Uso de chaves de API após exposição pública, incluindo chamadas de IPs desconhecidos, horários atípicos e consumo acima da linha de base.

Mitigação

A contenção inicial deve remover da internet todos os serviços de IA que não precisam de acesso público e colocar os demais atrás de autenticação forte, autorização por função e controles de origem. A autenticação precisa existir no primeiro acesso, não apenas em telas administrativas secundárias. Serviços de desenvolvimento, protótipos e laboratórios devem ficar em rede privada, VPN, bastion ou ambiente temporário com expiração. Para APIs de inferência, endpoints de listagem de modelos e geração devem exigir credenciais, limites de taxa, registro por identidade e segregação por aplicação consumidora.

Depois da contenção de rede, a revisão deve alcançar segredos e permissões. Chaves de API, tokens de provedores de LLM, credenciais de bancos, conectores de nuvem e credenciais de automação vistas por aplicações expostas devem ser rotacionadas. Não basta trocar segredos que apareceram em texto claro; também é necessário revisar credenciais cadastradas em workflows acessíveis, pois um invasor pode ter usado a própria plataforma para acionar sistemas conectados sem visualizar o valor secreto. Logs de provedores, custos, chamadas e alterações administrativas devem ser preservados antes de limpeza ou reconstrução.

O endurecimento estrutural exige tratar agentes como código com privilégio. Contêineres devem rodar sem root, com filesystem restrito, capacidades mínimas, rede limitada e segredos injetados por mecanismo seguro, não por exemplos copiados para docker-compose. Ferramentas de escrita, execução e interpretação precisam de sandbox, allowlist de comandos, diretórios temporários e política explícita para acesso à rede. Workflows devem ter revisão por mudança, exportação versionada, separação entre criação e execução, além de escopos reduzidos para cada conector. A validação final deve repetir a visão de um atacante externo: resolução DNS, portas abertas, resposta sem autenticação, banners, endpoints sensíveis e chamadas capazes de gerar ação real.

• Inventariar domínios, certificados, portas e serviços de IA visíveis externamente, incluindo ambientes de teste e protótipos.
• Exigir autenticação e autorização em Ollama, chatbots, Flowise, n8n, APIs de modelo e painéis de gerenciamento antes de qualquer função sensível.
• Rotacionar chaves de API e credenciais associadas a instâncias expostas, revisando uso histórico e cobranças dos provedores.
• Executar contêineres sem privilégio de root, remover credenciais estáticas de exemplos e bloquear segredos em imagens, repositórios e arquivos docker-compose.
• Isolar agentes em sandbox, restringir ferramentas locais, limitar saída de rede e registrar execução de workflows, chamadas de modelo e uso de conectores.