超22万OpenClaw实例暴露公网,AI Agent面临大规模“裸奔”风险

超22万OpenClaw实例暴露公网,AI Agent“裸奔”!数据泄露、权限滥用风险高悬,安全治理亟待加强。

原文标题:超22万OpenClaw部署实例暴露公网,Agent在大规模“裸奔”

原文作者:AI前线

冷月清谈:

AI前线报道,监控页面显示超22万个OpenClaw实例暴露在公网,覆盖多个国家和地区。大量实例未启用访问认证,且存在凭证泄露风险,托管在包括腾讯、甲骨文、百度、阿里、华为等多家云服务商平台。OpenClaw作为一种可执行“自主智能体”的运行环境,未经授权的公网暴露可能导致数据泄露、权限滥用等严重后果。文章指出,Agent正在快速进入生产环境,但安全治理能力尚未成熟,开发者需加强安全意识,及时启用身份验证、移除公网暴露并打补丁。此次事件凸显了AI Agent大规模部署带来的安全挑战和安全防护的紧迫性

怜星夜思:

1、OpenClaw大规模暴露事件,除了文章中提到的安全风险,你觉得还可能带来哪些潜在威胁?
2、文章提到开发者安全意识不足,本地测试成功后直接上云。你认为除了加强安全培训,还有什么方法可以有效防止类似事件再次发生?
3、面对日益普及的AI Agent,企业应该如何构建更完善的安全防护体系,才能避免重蹈覆辙?除了文中的建议,大家还有什么好的建议吗?

原文内容

左右滑动查看更多图片

近日,一个名为“OpenClaw Exposure Watchboard”的公开监控页面引发行业关注。

网页上,列出了超22万个暴露在公网的 OpenClaw 实例,覆盖美国、新加坡、中国大陆等多个地区。作者明确提示:如果这是你的部署,应立即启用身份验证、移除公网暴露并打补丁。

页面显示,每条记录包含公网 IP 与端口(多数为 18789 端口)、是否启用认证(Auth Required)、是否在线(Is Active)、是否存在凭证泄露(Has Leaked Creds)、以及所属运营商 ASN 信息等字段。

值得注意的是,大量实例的“Auth Required”字段为空,意味着未启用访问认证。同时,“Has Leaked Creds”一栏中有不少被标记为“Leaked”(红色),表明可能检测到明文凭证或 API Key 暴露风险。这意味着,部分运行中的 AI Agent 服务不仅对外开放,而且可能存在敏感信息泄露隐患。

从 ASN 信息来看,这些实例托管在包括腾讯、甲骨文、百度、阿里、华为
Hostinger、BedHosting等云基础设施或数据中心网络中,显示出部署主体可能并非个人开发者设备,更多或涉及企业或生产环境。

OpenClaw 作为一类可执行“自主智能体”的运行环境,与传统 Web 服务存在本质差异。智能体通常具备调用外部工具、访问数据库、执行代码或与第三方 API 交互的能力。一旦未经鉴权暴露在公网,其潜在风险远高于普通网站端口开放,可能导致数据泄露、权限滥用甚至业务系统被远程操控。

通过该网站可以看出,一方面,Agent 正在快速进入真实生产环境,并且部署量已经爆炸;另一方面,Agent 在被大量“裸奔部署”,很多开发者本地测试成功后直接上云,开公网端口、没加鉴权等,配套安全治理能力尚未完全成熟。

整理:褚杏娟

细思极恐!如果这些Agent被恶意操控,会不会被用于传播虚假信息,甚至影响舆论走向?这可比传统的水军可怕多了。

除了技术手段,法律法规也要跟上。明确AI Agent的责任边界,谁部署谁负责,这样才能倒逼企业重视安全。

除了数据泄露和权限滥用,我觉得还可能被用于DDoS攻击,或者被黑客利用进行恶意挖矿,消耗大量计算资源。

从安全的角度来看,我认为最大的威胁是供应链攻击。如果攻击者控制了这些Agent,就可以悄无声息地注入恶意代码,感染整个系统。

有没有可能开发一种“Agent沙箱”?让Agent在隔离的环境中运行,即使被攻破,也不会影响到整个系统。

我觉得可以引入更严格的自动化安全审查机制,比如在代码提交前进行安全扫描,强制执行安全策略。有点像汽车的年检,不合格就不能上路。

建立完善的Agent资产管理系统非常重要,就像管理服务器一样管理Agent,清楚地知道哪些Agent在运行,部署在哪里,权限是什么。这样才能更好地监控和防护。

话说回来,开发者也有苦衷啊!赶进度、堆KPI,哪有时间搞安全那些“虚头巴脑”的东西?也许应该从考核机制上做些改变,把安全纳入考量。

采用零信任安全模型,不要默认信任任何Agent,对Agent之间的通信进行严格的身份验证和授权。可以有效防止横向渗透。