Mysterium 暴露 AI 端点，自托管失去了安全借口
Mysterium 暴露的 AI 端点规模之大，已让一次配置失误演变为整个行业的警示。其研究人员识别出 36,769 个可访问系统，其中仅 741 个返回了 HTTP 身份验证质询。
这项于 9 月 10 日发布的研究涵盖模型服务器、聊天界面、智能体构建器和向量存储控制台。这些组件构成了 AI 模型与其周围人员、文档、凭据和应用程序之间的运行层。
这为自托管 AI 带来了令人不安的矛盾。企业通常在本地运行模型，以保留对提示词和敏感数据的控制权。然而，许多部署似乎无需网络层面的访问门槛即可被访问，这使信任转而依赖于应用安全、及时修补和正确配置。
这一数量并不能证明全部 36,769 个系统都暴露了私密信息。部分应用在加载后仍可能要求用户登录。不过，这些发现表明，数以千计的 AI 服务直接向互联网扫描器暴露了自身。
这一区别至关重要。可见的登录页面仍是暴露在外的应用，必须抵御新漏洞、被盗密码、薄弱默认设置和自动化探测。位于私有网络或经身份验证网关保护后的服务，攻击面则更小。
因此，比较的重点并不只是本地 AI 与托管 AI 之争，而是原则上的控制与实际部署中的控制之别。Mysterium 的结果表明，组织正在选择自托管，却未能始终如一地维护让自托管具有价值的安全边界。
Mysterium 暴露 AI 端点遍布实际运行的 AI 技术栈
核心发现并非某一款脆弱产品，而是一套可从公共互联网映射出来、具有清晰特征的 AI 技术栈。
Mysterium 表示，其研究人员使用了第三方扫描索引，而非直接探测所识别的机器。原始普查 搜索了服务指纹，包括与常见 AI 软件相关的页面标题、响应文本和端口。
最终数据集包含 36,769 个可自我识别的端点。模型服务产品占据了其中大多数，领先的是 18,529 个 Open WebUI 实例。Open WebUI 提供基于浏览器的界面，用于与本地托管的语言模型交互。
研究期间，这些 Open WebUI 端点中仅一个返回了 HTTP 身份验证质询。这并不能证明其余应用允许不受限制的账户访问，但足以说明，几乎没有应用在前端部署可检测到的 HTTP 访问门槛。
Ollama 是一项用于在本地硬件上下载和运行模型的服务，另有 6,935 个确认端点。据 Mysterium 称，它们均以匿名方式返回该产品的根响应。其中 729 个返回了身份验证质询。
研究人员还识别出 4,880 个 vLLM 端点，其中三个返回了质询。vLLM 是一种推理服务器，即接收请求并通过语言模型运行以生成响应。
规模较小的群体包括 150 个 LocalAI 端点、69 台 llama.cpp 服务器和 63 个 Xinference 部署。这些产品面向不同用户群体，但拥有共同的运行目标：让应用或用户能够访问模型。
该数据集不止涵盖推理服务。Mysterium 统计到 5,223 个与智能体构建器和工作流工具相关的端点，包括 Flowise、RAGFlow、Dify、ComfyUI、n8n、Langflow 和 Open WebUI Pipelines。
这一类别具有不同的风险特征。推理服务器处理提示词，而智能体构建器通常会将模型连接到数据库、消息系统、云服务和内部应用。它可能存储令牌，或调用拥有实际权限的工具。
Flowise 占据了 1,341 个可访问端点，且没有一个返回身份验证质询。该研究还统计到 891 个 RAGFlow 部署、792 个 Dify 端点、788 个 ComfyUI 端点和 675 个 n8n 实例。
向量存储的可见度则低得多。研究人员发现 914 个 Milvus Attu 控制台和六个 Weaviate 端点。向量存储保存内容的数值表示，使 AI 应用能够在对话中检索相关文档。
这些数字不应被解读为向量数据库很少暴露在外的证据。Mysterium 表示，其数据源并未扫描两款主要产品的原生端口。这次普查主要捕获了可见的 Web 控制台，因此对数据敏感性最高的类别测量并不充分。
报告还在 Ollama 的默认端口上发现了 22,024 个额外响应。研究人员将其排除在确认总数之外，因为仅凭端口响应提供的证据弱于可识别的产品横幅。
这一保守的排除方式强化了主要结论。36,769 这一数字只是某个扫描索引中的确认下限，并非公共 AI 基础设施的完整清单。
自托管 AI 安全为何在边界处失效
只有当组织同样控制谁能够访问主机时，自托管才能保护数据。
本地模型的价值通常始于数据保管权。提示词、上传文档、检索段落和生成回答都可以留在由组织控制的设备上。这种安排可降低对外部模型提供商的依赖。
然而，仅靠位置并不能产生保密性。运行在公司硬件上的模型，如果服务监听面向互联网的地址，仍然可能是公开的。内部部署可因防火墙规则、云安全组、容器设置或仓促配置的隧道而变成外部服务。
许多本地 AI 产品默认只监听回环地址。回环地址将连接限制为同一台机器上运行的软件。运营人员有时会将其改为 0.0.0.0，使服务能够通过所有可用网络接口接受连接。
当开发者需要从另一台设备访问时，这一改变很有用；但如果周边网络同时允许来自互联网的入站流量，它就会变得危险。
反向代理可在请求抵达 AI 应用之前提供身份验证层。虚拟专用网络可将服务置于公共地址空间之外。IP 允许列表则可将访问限制在获批网络中。
Mysterium 几乎没有发现这类 HTTP 层保护措施的证据。在完整普查中，仅 2.02% 的端点返回了身份验证质询。由于数据源速率限制，五项产品查询并不完整，因此研究人员未向这些群组分配质询数量。
狭义解读十分重要。HTTP 质询并非唯一可能的安全控制。应用可以公开加载，但仍在自身内部执行登录、会话或授权规则。
但依赖应用身份验证会改变威胁模型。应用将持续可被扫描器和攻击者访问。每一次漏打补丁、授权错误、暴露的管理路由和默认凭据，都会带来更严重的后果。
近期漏洞记录表明，这种担忧并非抽象问题。Tenable 在其 2026 年安全公告中列出了影响 Open WebUI 和多个 Flowise 组件的高严重性问题。
Flowise 的公告包括路径遍历、图查询注入、NVIDIA NIM 端点缺少身份验证，以及个人信息泄露。其他 AI 工具的独立公告还涵盖凭据暴露、授权失效和任意文件写入问题。
这些记录并不意味着每个互联网可见部署都存在漏洞。版本、配置和补偿性控制各不相同。它们证明，应用层无法永久替代网络隔离。
补丁时机又带来另一个问题。开发者可以在数分钟内推出有用的概念验证项目，随后任其运行数月。该服务可能永远不会进入安全与基础设施团队使用的资产清单。
这种生命周期会产生影子 AI，即未经正常组织监管便被采用或构建的系统。项目对创建者仍然可见，却对负责访问审查、更新、日志和事件响应的团队不可见。
结果是由假设构成的安全边界。数据科学家假定云防火墙会拦截流量；基础设施团队假定应用需要身份验证；应用所有者则假定部署只是临时性的。
互联网扫描器无需理解组织背景，就能检验这些假设。如果产品会响应、能识别自身并呈现应用攻击面，那么它就已经越过了自托管本应保留的一道边界。
智能体构建器将暴露转化为供应链风险
最严重的暴露 AI 端点不只是回答问题，因为它们能够通过凭据和连接的系统执行操作。
AI 供应链包括模型、软件包、服务基础设施、检索数据库、插件、工具，以及用于产出结果的外部服务。任何已连接组件中的薄弱环节，都可能影响系统或扩大攻击者的访问范围。
传统软件供应链本已承载继承性风险。应用依赖外部开发者维护的软件包、由其他地方构建的容器镜像，以及持有部署凭据的自动化工作流。
AI 应用则将提示词、模型文件、检索内容、智能体指令和工具定义加入这条链中。其中一些工件看似只是数据，实际上却可能改变智能体的行为。
Fortinet 将智能体技能描述为编程助手的新型依赖层。其技能分析指出，技能可以利用自然语言指令，让智能体访问文件、运行 shell 命令或传输信息。
这种行为并不总需要传统的软件漏洞。当智能体信任恶意指令，且拥有使用所请求工具的权限时，恶意指令就可能转化为实际操作。
暴露在互联网中的工作流构建器会将这些风险结合起来。它可能泄露组织所使用的集成服务、接受不可信输入，或暴露与已存储凭据交互的路由。遭入侵的工作流随后可能访问远超原始 AI 服务器范围的系统。
以工程团队使用的检索助手为例。该应用可能连接到源代码仓库、文档存储、问题跟踪器和模型端点。其向量数据库可能包含内部文档片段。
如果公共接口存在授权漏洞，攻击者的收获就不止是免费模型推理。根据产品和配置不同，攻击者可能访问检索内容、工作流定义、连接元数据或令牌。
客户支持智能体也存在类似路径。它可能连接电子邮件、订单记录、消息工具和客户数据库。即便是权限范围有限的凭据，只要工作流能够整合多个服务的信息，也会变得极具价值。
这正是为何 5,223 个智能体构建器端点值得与模型服务器分开关注。规模较小的群体，可能拥有更大的运营爆炸半径。
Tenable 于 2 月发布的云风险报告提供了企业环境方面的背景。其遥测数据显示，在被分析的组织中，70% 已集成至少一个第三方 AI 或 Model Context Protocol 软件包。
Model Context Protocol，即 MCP，是一项让 AI 应用连接工具和数据源的标准。它的价值在于赋予模型对外部能力的结构化访问权限。
Tenable 还报告称，18% 的组织向 AI 服务授予了极少审计的管理权限。该公司发现，包括智能体和服务账户在内的非人类身份，其测得的风险高于人类用户。
这些发现来自 Tenable 的客户与云端遥测数据，而非 Mysterium 的互联网普查。两类数据集不应合并为单一的普遍性估算。结合来看，它们展现了同一运营问题的两个侧面。
Mysterium 测量的是可被访问的服务。Tenable 测量的是企业环境内部的权限、第三方软件包和身份状况。当可访问服务同时控制着具有高权限的非人类身份时，公开暴露的后果会更加严重。
压力同时落在开发者与安全团队身上。开发者需要快速访问模型和集成能力。安全团队则需要资产清单、明确的责任归属、受限权限，以及证明每项公开服务均有明确存在理由的证据。
单靠模型策略无法实现任一目标。模型拒绝有害提示词，并不能修复公开的管理控制台。提供商的防护机制也不会轮换已泄露的令牌，或移除被遗弃的容器。
使用 AI 处理内部知识的组织，还需对进入检索系统的内容进行分类。可搜索的知识库能够改善技术资料的访问体验，但其存储和连接器也会继承这些资料的敏感性。
因此，安全问题需要前移。在智能体接收提示词之前，必须有人决定它可以检索哪些数据、调用哪些工具，以及哪些网络能够访问它。
36,769 这一数字无法证明什么
这项普查证明了服务可从公网访问，但并未证明发生了 36,769 起成功入侵或数据泄露。
互联网测量可以得出醒目的数字，却无法回答所有安全问题。产品指纹能够识别服务，而 HTTP 响应可以揭示其外围暴露情况。两者都无法自动反映应用内部的授权状态。
数据集中的某些端点可能仅显示登录页面。另一些端点也许在界面加载后限制了重要功能。有些可能是研究系统、蜜罐、刻意公开的演示，或空的测试安装。
Mysterium 承认了这一界限。该报告并未声称每个可见应用都允许匿名访问私有功能。它描述的是缺乏网络或 HTTP 层访问门槛这一共同暴露状况。
这一限制意味着，无法直接计算被泄露的记录、易受攻击的组织或受影响的用户。研究人员没有公布目标所有者名单，因为这样做可能带来额外风险。
身份验证测量也因产品而异。17 个产品类别中，只有 12 个得出了已解析的验证拦截数量。数据集中的短横线表示查询未完成，而非确认不存在身份验证。
地理分析同样有限。Mysterium 仅报告了默认端口上部分 Ollama 响应的国家归属。任何关于哪些国家或行业暴露最严重的宽泛说法，都会超出证据范围。
端点数量还可能包括同一组织运营的多个服务。反过来，一个端点也可能位于更大的共享环境之前。可访问地址的数量并不等于受影响公司的数量。
扫描器覆盖范围带来了另一项不确定性。不同的索引、查询计划或指纹可能返回不同的总体。服务会上线和下线、变更标识信息、迁移至代理后方，或获得补丁。
这些限制并不会抹去这一发现。它们将结论从“36,769 个已被攻陷的系统”调整为更准确的表述：数以千计的可识别 AI 服务可通过一个公开扫描索引访问。
在攻击开始利用漏洞之前，这种状况就已对攻击者具有价值。产品识别有助于自动化漏洞匹配。扫描器可以寻找已知界面、估算其版本，并大规模测试适用路由。
暴露与入侵之间的区别，类似于一扇面向街道且未上锁的门。看到这扇门并不能证明有人已经进入。但它确实表明，该场所更依赖其余所有内部控制措施。
报告中的 2.02% 数字同样需要谨慎解读。在任何架构中，Basic HTTP authentication 并不必然优于现代应用身份验证。管理不善的代理也可能引入自身的弱点。
更强的原则是纵深防御。敏感的 AI 服务不应在可使用私有网络、经身份验证的网关、身份感知代理和受限入站规则时，仍仅依赖单一应用登录机制。
围绕 AI 暴露的一些更广泛评论背后，也存在商业激励。安全厂商会从组织购买发现、扫描、身份和监控产品中获益。其建议应根据技术证据进行评估。
Mysterium 本身是一家 VPN 公司，因此网络隐私与其业务相关。这并不意味着其数据集无效，而是使透明的方法、可复现的指纹和独立验证变得更加重要。
该研究公布了其指纹，并说明了被排除的结果、速率限制造成的缺口，以及被低估的类别。这些选择使其核心测量结果比仅基于私有遥测的主张更易于检验。
下一步有价值的研究是开展受控验证。独立团队应重复查询，在不访问敏感内容的情况下抽样检查端点行为，并追踪披露后总体数量的变化。
数量下降将表明运营者或软件维护者作出了响应。数量保持稳定则说明，不安全部署是结构性问题，而非暂时现象。
真正的权衡是部署速度与可验证控制之间的取舍
Mysterium 关于暴露 AI 端点的研究挑战了这样一种观点：自托管天然就能带来隐私。
托管式 AI 将信任集中于提供商。客户依赖合同、服务隔离、保留控制、访问策略以及提供商的安全计划。
自托管则重新分配了这种信任。组织控制硬件和部署，但也承担补丁管理、身份管理、网络设计、日志记录、备份和事件响应的责任。
对于受监管信息或专用工作负载而言，这可能是正确选择。但它默认并不是更轻松的选择。本地服务器必须被当作敏感基础设施运营，而不是一个碰巧被共享的桌面实验。
速度构成了核心张力。AI 框架旨在缩短从想法到可运行应用的距离。研究人员可以快速启动界面、连接模型、接入文档并分享成果。
每一项便利都可能掩盖一项运营决策。暴露端口会让协作更容易。将令牌存入工作流可加快集成。授予广泛权限则可避免反复出现授权错误。
这些决策会不断累积，形成一个在尚未定义安全边界前便已可运行的环境。应用变得有用、吸引用户，并在保留实验性控制措施的同时逐渐接近生产环境。
传统安全流程也可能扩大这一缺口。如果获取获批环境需要数周，员工就会绕过流程自行搭建。在未提供可用替代路径的情况下阻止所有 AI 服务，会鼓励不受管理的替代方案。
组织需要一条足够快、能够与影子基础设施竞争的部署路径。这条路径应默认提供私有网络、托管身份、密钥存储、日志记录、补丁责任归属和到期日期。
短期实验应设置到期日期，因为临时系统很少会自行消失。为演示创建的云实例，可能在其所有者换岗或忘记项目后仍持续在线。
资产清单必须覆盖完整的运营链条。若只发现模型服务器，却没有发现其向量数据库、工作流引擎、容器主机和服务账户，防御者得到的仍是一幅碎片化图景。
身份同样值得重视。智能体应仅获得完成任务所需的最小权限。当集成失败时，管理凭据不应成为标准答案。
存储在公开或曾经暴露的工作流中的凭据应被轮换。移除互联网访问关闭了一条路径，但并不会使攻击者可能已持有的令牌失效。
日志必须覆盖操作，而不只是对话。团队需要知道智能体调用了哪个工具、使用了哪个身份、访问了什么资源，以及该操作是否符合已批准的工作流。
当智能体指令来自第三方时，这一点尤为重要。导入的模板、插件或技能可以改变行为，却未必看起来像可执行代码。审查必须同时检查传统软件包和自然语言控制文件。
软件维护者同样面临压力。安全默认设置应让意外暴露更难发生。产品可以在服务绑定公共接口时发出警告、要求首次运行时设置凭据，并将管理路由与面向用户的端点分离。
文档同样重要，因为教程往往会成为生产架构。若快速入门指南在暴露服务时未解释网络层面的后果，就可能将同样的错误传播至数千个安装实例。
云服务和模型提供商仍是比较的一部分。托管平台可以减少配置工作，但也会引入提供商集中化和账户权限风险。答案并不是某一种托管模式总能胜出。
可辩护的选择是其控制措施能够被验证的选择。组织应知道模型在哪里运行、谁能够访问它、它处理哪些数据、使用哪些身份，以及多快能够撤销访问权限。
三项信号将显示暴露是否收缩
下一项检验是，维护者和运营者是否能将被广泛报道的普查转化为可衡量的修复行动。
第一个信号是使用相同指纹重新进行互联网扫描。最有揭示意义的指标将是确认端点总数，以及受到网络层身份验证保护的端点占比。
较低的端点数量表明运营者移除了不必要的公网访问。更高的身份验证率则表明服务在保持可用的同时增加了外围保护。
仅有任何一种变化都不足够。端点可能因其标识信息变化而从指纹中消失，却仍然可访问。因此，研究人员应记录查询变更，并保留可比较的测量方法。
第二个信号是主要维护者的行动。Open WebUI 尤其值得关注，因为它占据了 18,529 个端点，约为 Mysterium 确认总体的一半。
针对公网绑定、强制初始凭证、更安全的部署模板以及更清晰的反向代理指引发出警告，将有助于强化报告的整体论点。沉默不作为或仅调整表面横幅，都会让实际运营问题基本得不到解决。
智能体构建工具应接受更严格的审视。Flowise、RAGFlow、Dify、n8n、Langflow 及类似工具需要采用安全默认设置，并充分认识到它们能够访问密钥和外部系统。
第三个信号来自漏洞与事件证据。涉及授权、凭证泄露、远程执行或智能体工具访问的新安全公告，将表明公网暴露如何演变为攻击路径。
已确认的在野利用会进一步凸显紧迫性，但防御方不应等到那一步才行动。当资产所有者可能缺乏日志或可见性时，没有披露的安全事件并不能证明系统安全。
组织可以在这些信号出现之前采取行动。他们应盘点 AI 服务，测试哪些接口可从公网访问，并明确每项部署的责任人。
任何不需要公网访问的服务，都应绑定到私有接口。必须保持可访问的服务，应部署在具备身份认证的网关之后，并限制可访问身份、及时安装补丁。
智能体构建工具还需要被作为密钥基础设施加以额外管理。团队应审查已存储的集成配置、轮换已暴露的凭证、检查导入的工作流，并记录智能体对已连接系统执行的操作。
Mysterium 统计的暴露 AI 端点数量终将过时。这很正常。真正重要的问题是，下一次统计反映的是更完善的控制措施，还是仅仅意味着被忽视服务的数量更多。
对于开发者、企业采购方和 AI 用户而言，实际检验标准很简单：组织能否说明谁可以访问每个系统，以及该系统能够执行什么操作？如果答案依赖于假设，那么该部署就没有提供自托管原本承诺的控制能力。
