Mysterium Expôs Endpoints de IA, e a Auto-hospedagem Perdeu Seu Álibi de Segurança

A Mysterium expôs endpoints de IA em uma escala que transforma um erro de configuração em um alerta para o setor. Seus pesquisadores identificaram 36.769 sistemas acessíveis, enquanto apenas 741 retornaram um desafio de autenticação HTTP.

O estudo de 10 de setembro abrangeu servidores de modelos, interfaces de chat, criadores de agentes e consoles de bancos vetoriais. Esses componentes formam a camada operacional entre um modelo de IA e as pessoas, documentos, credenciais e aplicações ao seu redor.

Isso cria um conflito desconfortável para a IA auto-hospedada. Empresas frequentemente executam modelos localmente para manter o controle sobre prompts e dados sensíveis. Ainda assim, muitas implantações parecem acessíveis sem uma barreira no nível da rede, deslocando a confiança para a segurança da aplicação, atualizações e configuração correta.

A contagem não prova que todos os 36.769 sistemas expuseram informações privadas. Algumas aplicações ainda podem exigir que os usuários façam login após o carregamento. No entanto, as conclusões mostram que milhares de serviços de IA se anunciam diretamente a scanners da internet.

Essa distinção importa. Uma página de login visível ainda é uma aplicação exposta que precisa resistir a novas vulnerabilidades, senhas roubadas, padrões fracos e sondagens automatizadas. Um serviço atrás de uma rede privada ou gateway autenticado apresenta um alvo menor.

Portanto, a comparação não é simplesmente IA local versus IA hospedada. Trata-se de controle em princípio versus controle na implantação. Os resultados da Mysterium sugerem que as organizações estão escolhendo a auto-hospedagem sem operar de forma consistente a fronteira de segurança que torna a auto-hospedagem valiosa.

Endpoints de IA Expostos pela Mysterium em Toda a Pilha Operacional de IA

A descoberta central não é um único produto vulnerável. É uma pilha de IA reconhecível que pode ser mapeada a partir da internet pública.

A Mysterium disse que seus pesquisadores usaram um índice de varredura de terceiros em vez de sondar diretamente as máquinas identificadas. O censo original buscou impressões digitais de serviços, incluindo títulos de páginas, texto de respostas e portas associadas a softwares de IA comuns.

O conjunto de dados final continha 36.769 endpoints autoidentificados. Produtos de disponibilização de modelos representavam a maior parte dessa população, liderados por 18.529 instâncias do Open WebUI. O Open WebUI oferece uma interface baseada em navegador para interagir com modelos de linguagem hospedados localmente.

Apenas um desses endpoints do Open WebUI retornou um desafio de autenticação HTTP durante o estudo. Isso não estabelece que as aplicações restantes permitiam acesso irrestrito às contas. Estabelece, porém, que quase nenhuma tinha uma barreira HTTP detectável colocada diante da aplicação.

Ollama, um serviço para baixar e executar modelos em hardware local, representou outros 6.935 endpoints confirmados. Cada um retornou anonimamente a resposta raiz do produto, segundo a Mysterium. Desse grupo, 729 retornaram um desafio de autenticação.

Os pesquisadores também identificaram 4.880 endpoints do vLLM, dos quais três retornaram um desafio. O vLLM é um servidor de inferência, o que significa que aceita solicitações e as executa por meio de um modelo de linguagem para produzir respostas.

Grupos menores incluíam 150 endpoints do LocalAI, 69 servidores llama.cpp e 63 implantações do Xinference. Esses produtos atendem a públicos diferentes, mas compartilham um objetivo operacional. Eles tornam os modelos acessíveis a aplicações ou usuários.

O conjunto de dados foi além da inferência. A Mysterium contou 5.223 endpoints associados a criadores de agentes e ferramentas de fluxo de trabalho, incluindo Flowise, RAGFlow, Dify, ComfyUI, n8n, Langflow e Open WebUI Pipelines.

Essa categoria apresenta um perfil de risco diferente. Um servidor de inferência processa prompts, mas um criador de agentes frequentemente conecta modelos a bancos de dados, sistemas de mensagens, serviços em nuvem e aplicações internas. Ele pode armazenar tokens ou invocar ferramentas com permissões reais.

O Flowise representou 1.341 endpoints acessíveis, nenhum dos quais retornou um desafio de autenticação. O estudo também contou 891 implantações do RAGFlow, 792 endpoints do Dify, 788 endpoints do ComfyUI e 675 instâncias do n8n.

A visibilidade dos bancos vetoriais foi muito menor. Os pesquisadores encontraram 914 consoles do Milvus Attu e seis endpoints do Weaviate. Um banco vetorial armazena representações numéricas de conteúdo para que uma aplicação de IA possa recuperar documentos relevantes durante uma conversa.

Esses números não devem ser interpretados como evidência de que bancos de dados vetoriais raramente são expostos. A Mysterium disse que sua fonte não examinou as portas nativas de dois produtos importantes. O censo capturou principalmente consoles web visíveis, deixando a categoria mais sensível em termos de dados pouco mensurada.

O relatório também encontrou 22.024 respostas adicionais na porta padrão do Ollama. Os pesquisadores as excluíram do total confirmado porque uma resposta de porta, por si só, oferecia evidência mais fraca do que um banner de produto reconhecível.

Essa exclusão conservadora reforça a principal conclusão. O número de 36.769 é um piso confirmado dentro de um índice de varredura, não um inventário completo da infraestrutura pública de IA.

Por Que a Segurança da IA Auto-hospedada Falha no Perímetro

A auto-hospedagem protege os dados apenas quando a organização também controla quem pode alcançar o host.

O argumento a favor de modelos locais geralmente começa pela custódia dos dados. Prompts, documentos enviados, trechos recuperados e respostas geradas podem permanecer em equipamentos controlados pela organização. Esse arranjo pode reduzir a dependência de um provedor externo de modelos.

No entanto, a localização por si só não cria confidencialidade. Um modelo executado em hardware da empresa ainda pode ser público se seu serviço escutar em um endereço voltado para a internet. Uma implantação interna pode se tornar externa por meio de uma regra de firewall, grupo de segurança na nuvem, configuração de contêiner ou túnel configurado às pressas.

Muitos produtos locais de IA escutam apenas no endereço de loopback por padrão. O loopback limita conexões a softwares executados na mesma máquina. Operadores às vezes alteram esse endereço para 0.0.0.0, o que permite que o serviço aceite conexões por todas as interfaces de rede disponíveis.

Essa alteração é útil quando um desenvolvedor precisa de acesso a partir de outro dispositivo. Ela se torna perigosa quando a rede ao redor também permite tráfego de entrada da internet.

Um proxy reverso pode fornecer uma camada de autenticação antes que as solicitações alcancem a aplicação de IA. Uma rede privada virtual pode manter o serviço fora do espaço público de endereços. Uma lista de permissões de IP pode restringir o acesso a redes aprovadas.

A Mysterium encontrou poucas evidências dessas proteções no nível HTTP. Em todo o censo, apenas 2,02 por cento dos endpoints retornaram um desafio de autenticação. Cinco consultas de produtos estavam incompletas devido a limites de taxa da fonte, portanto os pesquisadores não atribuíram contagens de desafios a esses grupos.

A interpretação restrita é importante. Um desafio HTTP não é o único controle de segurança possível. Uma aplicação pode carregar publicamente e ainda aplicar suas próprias regras de login, sessão ou autorização.

Ainda assim, depender da autenticação da aplicação altera o modelo de ameaça. A aplicação se torna continuamente acessível a scanners e invasores. Cada atualização não aplicada, erro de autorização, rota administrativa exposta e credencial padrão ganha maior relevância.

Registros recentes de vulnerabilidades mostram por que essa preocupação é concreta. Os alertas de segurança de 2026 da Tenable listaram problemas de alta gravidade que afetam o Open WebUI e vários componentes do Flowise.

Os alertas sobre o Flowise incluíram travessia de diretórios, injeção de consultas de grafo, ausência de autenticação em endpoints do NVIDIA NIM e divulgação de informações pessoais. Alertas separados abordaram exposição de credenciais, falhas de autorização e gravações arbitrárias de arquivos em outras ferramentas de IA.

Esses registros não significam que toda implantação visível na internet seja vulnerável. Versões, configurações e controles compensatórios diferem. Eles demonstram que a camada de aplicação não pode servir como substituto permanente para o isolamento de rede.

O tempo de aplicação de correções cria outro problema. Um desenvolvedor pode lançar uma prova de conceito útil em minutos e deixá-la operando por meses. O serviço pode nunca entrar no inventário de ativos usado pelas equipes de segurança e infraestrutura.

Esse ciclo de vida produz IA sombra, sistemas adotados ou desenvolvidos sem supervisão organizacional normal. O projeto continua visível para seu criador, mas invisível para as equipes responsáveis por revisões de acesso, atualizações, logs e resposta a incidentes.

O resultado é uma fronteira de segurança construída com suposições. O cientista de dados presume que o firewall da nuvem bloqueia o tráfego. A equipe de infraestrutura presume que a aplicação exige autenticação. O responsável pela aplicação presume que a implantação é temporária.

Um scanner da internet testa essas suposições sem precisar de contexto organizacional. Se o produto responde, se identifica e apresenta uma superfície de aplicação, ele já cruzou uma fronteira que a auto-hospedagem deveria preservar.

Criadores de Agentes Transformam a Exposição em Risco de Cadeia de Suprimentos

Os endpoints de IA expostos mais graves fazem mais do que responder perguntas, porque podem agir por meio de credenciais e sistemas conectados.

Uma cadeia de suprimentos de IA inclui o modelo, pacotes de software, infraestrutura de disponibilização, bancos de dados de recuperação, plugins, ferramentas e serviços externos usados para produzir um resultado. Uma fraqueza em qualquer componente conectado pode influenciar o sistema ou ampliar o acesso de um invasor.

Cadeias de suprimentos de software tradicionais já carregam riscos herdados. As aplicações dependem de pacotes mantidos por desenvolvedores externos, imagens de contêiner criadas em outros lugares e fluxos de trabalho automatizados que mantêm credenciais de implantação.

As aplicações de IA adicionam prompts, arquivos de modelos, conteúdo de recuperação, instruções de agentes e definições de ferramentas a essa cadeia. Alguns desses artefatos parecem dados, embora possam alterar o que um agente faz.

A Fortinet descreveu as habilidades de agentes como uma nova camada de dependência para assistentes de programação. Sua análise de habilidades observou que uma habilidade pode usar instruções em linguagem natural para dizer a um agente que acesse arquivos, execute comandos de shell ou transmita informações.

Esse comportamento nem sempre exige uma falha de software convencional. Uma instrução maliciosa pode se tornar operacional quando um agente confia nela e tem permissão para usar a ferramenta solicitada.

Um criador de fluxos de trabalho exposto à internet combina esses riscos. Ele pode revelar quais integrações uma organização utiliza, aceitar entradas não confiáveis ou expor rotas que interagem com credenciais armazenadas. Um fluxo de trabalho comprometido poderia então alcançar sistemas muito além do servidor de IA original.

Considere um assistente de recuperação usado por uma equipe de engenharia. A aplicação pode se conectar a um repositório de código-fonte, um armazenamento de documentação, um rastreador de problemas e um endpoint de modelo. Seu banco de dados vetorial pode conter fragmentos de documentos internos.

Se a interface pública tiver uma falha de autorização, o prêmio do invasor não se limita à inferência gratuita do modelo. Dependendo do produto e da configuração, o invasor poderia acessar conteúdo recuperado, definições de fluxo de trabalho, metadados de conexão ou tokens.

Um agente de suporte ao cliente apresenta um caminho semelhante. Ele pode se conectar a e-mails, registros de pedidos, ferramentas de mensagens e um banco de dados de clientes. Mesmo uma credencial com escopo restrito se torna valiosa quando o fluxo de trabalho pode combinar informações entre serviços.

É por isso que os 5.223 endpoints de criadores de agentes merecem atenção separada dos servidores de modelos. A população menor pode carregar um raio de impacto operacional maior.

O relatório de risco em nuvem da Tenable, de fevereiro, oferece contexto empresarial. Sua telemetria mostrou que 70 por cento das organizações analisadas haviam integrado ao menos um pacote de IA ou Model Context Protocol de terceiros.

Model Context Protocol, ou MCP, é um padrão que permite que aplicações de IA se conectem a ferramentas e fontes de dados. Sua utilidade vem de conceder aos modelos acesso estruturado a recursos externos.

A Tenable também relatou que 18 por cento das organizações haviam concedido a serviços de IA permissões administrativas que raramente eram auditadas. A empresa constatou que identidades não humanas, incluindo agentes e contas de serviço, apresentavam risco mensurado maior do que usuários humanos.

Essas conclusões vêm da telemetria de clientes e de nuvem da Tenable, não do censo de internet da Mysterium. Os conjuntos de dados não devem ser combinados em uma única estimativa de prevalência. Juntos, eles mostram dois lados do mesmo problema operacional.

A Mysterium mediu serviços acessíveis. A Tenable mediu permissões, pacotes de terceiros e condições de identidade dentro de ambientes empresariais. A exposição pública se torna mais relevante quando o serviço acessível também controla uma identidade não humana privilegiada.

A pressão recai tanto sobre desenvolvedores quanto sobre equipes de segurança. Os desenvolvedores precisam de acesso rápido a modelos e integrações. As equipes de segurança precisam de inventário, responsabilidade clara, privilégios limitados e evidências de que cada serviço público tem uma razão deliberada para existir.

Nenhum dos dois objetivos pode ser alcançado apenas por meio de políticas de modelo. Um modelo que recusa um prompt prejudicial não corrige um console administrativo público. As salvaguardas do provedor não rotacionam um token vazado nem removem um contêiner abandonado.

Organizações que usam IA para trabalhar com conhecimento interno também precisam classificar o que entra em sistemas de recuperação. Uma base de conhecimento pesquisável pode melhorar o acesso a material técnico, mas seu armazenamento e conectores herdam a sensibilidade desse material.

A questão de segurança, portanto, avança para etapas anteriores. Antes que um agente receba um prompt, alguém deve decidir quais dados ele pode recuperar, quais ferramentas pode invocar e qual rede pode alcançá-lo.

O que o número 36.769 não prova

O censo demonstra acessibilidade pública, mas não estabelece 36.769 comprometimentos bem-sucedidos ou vazamentos de dados.

A medição da internet pode produzir um número impactante sem responder a todas as questões de segurança. As assinaturas de produtos identificam serviços, enquanto uma resposta HTTP revela algo sobre seu perímetro. Nenhuma delas revela automaticamente o estado interno de autorização da aplicação.

Alguns endpoints no conjunto de dados provavelmente exibiam uma página de login. Outros poderiam ter restringido funções importantes após o carregamento da interface. Alguns poderiam ser sistemas de pesquisa, honeypots, demonstrações intencionalmente públicas ou instalações de teste vazias.

A Mysterium reconheceu esse limite. O relatório não afirmou que cada aplicação visível permitia acesso anônimo a recursos privados. Ele descreveu a ausência de uma barreira de rede ou HTTP como a exposição comum.

Essa limitação impede um cálculo direto de registros violados, organizações vulneráveis ou usuários afetados. Os pesquisadores não publicaram uma lista dos proprietários dos alvos, e fazê-lo poderia criar riscos adicionais.

A medição de autenticação também varia por produto. Apenas 12 das 17 categorias de produtos tinham contagens de desafios resolvidas. Um traço no conjunto de dados indicava uma consulta incompleta, não a ausência confirmada de autenticação.

A análise geográfica também foi limitada. A Mysterium relatou atribuição por país para apenas um subconjunto das respostas do Ollama em sua porta padrão. Qualquer afirmação ampla sobre quais países ou setores estão mais expostos iria além das evidências.

A contagem de endpoints também pode incluir vários serviços operados por uma única organização. Por outro lado, um endpoint pode estar diante de um ambiente compartilhado maior. O número de endereços acessíveis não é o número de empresas afetadas.

A cobertura do scanner apresenta outra incerteza. Um índice, cronograma de consultas ou assinatura diferente pode retornar uma população diferente. Os serviços ficam online e offline, alteram banners, passam por proxies ou recebem correções.

Essas limitações não anulam a descoberta. Elas mudam a conclusão de “36.769 sistemas comprometidos” para algo mais preciso: milhares de serviços de IA reconhecíveis estavam acessíveis por meio de um índice público de varredura.

Essa condição é valiosa para invasores antes mesmo do início da exploração. A identificação do produto ajuda a automatizar a correspondência de vulnerabilidades. Um scanner pode buscar uma interface conhecida, estimar sua versão e testar rotas aplicáveis em escala.

A diferença entre exposição e comprometimento se assemelha a uma porta destrancada voltada para a rua. Ver a porta não prova que alguém entrou. Mas mostra que a propriedade depende mais fortemente de todos os controles internos restantes.

O número de 2,02 por cento do relatório também exige cautela. A autenticação HTTP básica não é inerentemente melhor do que a autenticação moderna de aplicações em todas as arquiteturas. Um proxy mal gerenciado pode introduzir suas próprias fraquezas.

O princípio mais forte é a defesa em profundidade. Um serviço de IA sensível não deve depender de um único login de aplicação quando redes privadas, gateways autenticados, proxies com reconhecimento de identidade e regras limitadas de entrada estão disponíveis.

Também há um incentivo comercial por trás de parte dos comentários mais amplos sobre exposição à IA. Fornecedores de segurança se beneficiam quando organizações compram produtos de descoberta, varredura, identidade e monitoramento. Suas recomendações devem ser avaliadas com base em evidências técnicas.

A própria Mysterium é uma empresa de VPN, o que torna a privacidade de rede relevante para seus negócios. Isso não invalida seu conjunto de dados. Torna métodos transparentes, assinaturas reproduzíveis e confirmação independente mais importantes.

O estudo publicou suas assinaturas e explicou resultados excluídos, lacunas causadas por limites de taxa e categorias subcontadas. Essas escolhas tornam a medição central mais fácil de testar do que uma alegação baseada apenas em telemetria privada.

A próxima etapa útil da pesquisa é a validação controlada. Equipes independentes devem repetir as consultas, amostrar o comportamento dos endpoints sem acessar conteúdo sensível e acompanhar como a população muda após a divulgação.

Uma contagem em queda sugeriria que operadores ou mantenedores de software responderam. Uma contagem estável indicaria que a implantação insegura é estrutural, e não temporária.

A verdadeira troca é velocidade de implantação versus controle verificável

O estudo da Mysterium sobre endpoints de IA expostos desafia a ideia de que a hospedagem própria proporciona privacidade automaticamente.

A IA hospedada concentra a confiança em um provedor. Os clientes dependem de contratos, isolamento de serviços, controles de retenção, políticas de acesso e do programa de segurança do provedor.

A hospedagem própria redistribui essa confiança. A organização controla o hardware e a implantação, mas também herda a aplicação de patches, a gestão de identidades, o desenho de rede, o registro de logs, backups e a resposta a incidentes.

Essa pode ser a escolha certa para informações regulamentadas ou cargas de trabalho especializadas. Não é a escolha mais fácil por padrão. O servidor local deve ser operado como infraestrutura sensível, e não como um experimento de desktop que acabou sendo compartilhado.

A velocidade cria a tensão central. Frameworks de IA são projetados para reduzir a distância entre uma ideia e uma aplicação funcional. Um pesquisador pode iniciar uma interface, anexar um modelo, conectar documentos e compartilhar o resultado rapidamente.

Cada conveniência pode ocultar uma decisão operacional. Expor uma porta facilita a colaboração. Armazenar um token em um fluxo de trabalho torna a integração mais rápida. Conceder permissões amplas evita erros repetidos de autorização.

Essas decisões se acumulam em um ambiente que funciona antes que alguém tenha definido seu limite de segurança. A aplicação se torna útil, atrai usuários e se aproxima da produção enquanto mantém seus controles experimentais.

Processos tradicionais de segurança também podem contribuir para a lacuna. Se obter um ambiente aprovado leva semanas, os funcionários criarão soluções contornando o processo. Bloquear todos os serviços de IA sem fornecer um caminho utilizável incentiva alternativas não gerenciadas.

As organizações precisam de uma rota de implantação rápida o suficiente para competir com infraestrutura paralela. Essa rota deve fornecer redes privadas, identidade gerenciada, armazenamento de segredos, logs, responsabilidade pela aplicação de patches e datas de expiração por padrão.

Experimentos de curta duração merecem datas de expiração porque sistemas temporários raramente se removem sozinhos. Uma instância de nuvem criada para uma demonstração pode permanecer online depois que seu proprietário muda de função ou esquece o projeto.

O inventário deve incluir toda a cadeia operacional. Encontrar um servidor de modelo sem seu armazenamento vetorial, mecanismo de fluxo de trabalho, host de contêineres e contas de serviço deixa os defensores com uma visão fragmentada.

A identidade merece atenção equivalente. Um agente deve receber as permissões mais restritas necessárias para sua tarefa. Credenciais administrativas não devem se tornar a resposta padrão quando uma integração falha.

Credenciais armazenadas em fluxos de trabalho públicos ou previamente expostos devem ser rotacionadas. Remover o acesso à internet fecha um caminho, mas não invalida um token que um invasor talvez já possua.

Os logs devem cobrir ações, não apenas conversas. As equipes precisam saber qual ferramenta um agente invocou, qual identidade utilizou, qual recurso acessou e se a ação correspondeu a um fluxo de trabalho aprovado.

Isso é especialmente importante quando instruções de agentes vêm de terceiros. Um modelo, plugin ou skill importado pode alterar o comportamento sem se parecer com código executável. As revisões devem examinar tanto pacotes convencionais quanto arquivos de controle em linguagem natural.

Os mantenedores de software também enfrentam pressão. Padrões seguros devem dificultar a exposição acidental. Os produtos podem alertar quando serviços se vinculam a interfaces públicas, exigir credenciais na primeira execução e separar rotas administrativas de endpoints voltados ao usuário.

A documentação importa porque tutoriais frequentemente se tornam arquitetura de produção. Um guia de início rápido que expõe um serviço sem explicar as consequências para a rede pode propagar o mesmo erro em milhares de instalações.

Provedores de nuvem e de modelos continuam fazendo parte da comparação. Plataformas gerenciadas podem reduzir o trabalho de configuração, mas introduzem riscos de concentração no provedor e de permissões de conta. A resposta não é que um modelo de hospedagem sempre vence.

A escolha defensável é aquela cujos controles podem ser verificados. Uma organização deve saber onde o modelo é executado, quem pode alcançá-lo, quais dados ele processa, quais identidades utiliza e com que rapidez o acesso pode ser revogado.

Três sinais mostrarão se a exposição diminui

O próximo teste é se mantenedores e operadores transformarão um censo amplamente divulgado em correção mensurável.

O primeiro sinal é uma nova varredura da internet usando as mesmas assinaturas. As medidas mais reveladoras serão o total de endpoints confirmados e a parcela protegida por autenticação no nível de rede.

Uma contagem menor de endpoints sugeriria que os operadores removeram acessos públicos desnecessários. Uma taxa maior de autenticação mostraria que os serviços permaneceram úteis enquanto ganhavam um perímetro.

Nenhuma mudança isolada é suficiente. Um endpoint pode desaparecer de uma assinatura porque seu banner mudou, enquanto permanece acessível. Portanto, os pesquisadores devem documentar alterações nas consultas e preservar medições comparáveis.

O segundo sinal é a ação dos principais mantenedores. Open WebUI merece atenção particular porque representava 18.529 endpoints, aproximadamente metade da população confirmada pela Mysterium.

Avisos sobre vinculação pública, credenciais iniciais obrigatórias, modelos de implantação mais seguros e orientações mais claras sobre proxy reverso fortaleceriam a argumentação mais ampla do relatório. O silêncio ou mudanças cosméticas em banners deixariam o problema operacional em grande parte intacto.

Os criadores de agentes devem receber uma análise ainda mais rigorosa. Flowise, RAGFlow, Dify, n8n, Langflow e ferramentas semelhantes precisam de padrões seguros que reconheçam seu acesso a segredos e sistemas externos.

O terceiro sinal é a evidência de vulnerabilidades e incidentes. Novos avisos envolvendo autorização, exposição de credenciais, execução remota ou acesso de agentes a ferramentas mostrariam como a exposição pública pode se tornar uma via de ataque.

A exploração confirmada reforçaria a urgência, mas os defensores não devem esperar por ela. A ausência de incidentes divulgados não comprova segurança quando os proprietários dos ativos podem não ter logs ou visibilidade.

As organizações podem agir antes que esses sinais surjam. Elas devem inventariar os serviços de IA, testar quais interfaces estão publicamente acessíveis e identificar as pessoas responsáveis por cada implantação.

Tudo o que não exige acesso público deve ser vinculado a uma interface privada. Os serviços que precisam permanecer acessíveis devem ficar atrás de gateways autenticados, com identidades limitadas e patches atualizados.

Os criadores de agentes precisam de tratamento adicional como infraestrutura de segredos. As equipes devem revisar integrações armazenadas, rotacionar credenciais expostas, inspecionar fluxos de trabalho importados e registrar as ações dos agentes nos sistemas conectados.

A contagem de endpoints de IA expostos da Mysterium acabará ficando desatualizada. Isso é esperado. A questão importante é se a próxima contagem refletirá controles melhores ou apenas uma coleção maior de serviços negligenciados.

Para desenvolvedores, compradores corporativos e usuários de IA, o teste prático é simples: a organização consegue mostrar quem pode acessar cada sistema e o que esse sistema pode fazer? Se a resposta depender de suposições, a implantação não está fornecendo o controle que a auto-hospedagem prometia.