文章总结： 本文分析了自托管AI助手运行时OpenClaw的安全风险，指出其将不受信任的代码与指令融合，导致身份滥用、内存篡改和主机入侵威胁。运行时环境成为新的安全边界，面临间接提示词注入和技能木马攻击。建议在隔离环境中运行、使用专用低权限凭证、监控状态篡改、制定重建预案。文章提供了基于微软安全产品的操作基线和狩猎查询，帮助组织降低AI助手部署风险。 综合评分： 89 文章分类： AI安全,安全建设,威胁情报,终端安全,安全运营

如何安全运行 OpenClaw：身份、隔离与运行时风险

幻泉之洲

2026年2月26日 09:16 北京

企业自托管AI助手运行时（如OpenClaw）的快速试水，带来了一系列尖锐的安全挑战。这些运行时默认内置的安全控制有限，本质上是让持有长期凭证的代码去执行不受信任的内容和第三方扩展。本文剖析了这种模式下身份滥用、内存篡改和主机入侵的核心风险，并结合微软安全产品矩阵，为无法避免部署的组织提供了一套从隔离到监控、从狩猎到响应的基线安全操作框架。

一个危险的融合：不受信任的代码与指令

像OpenClaw这样的自托管AI助手运行时，正在企业的试点项目中快速出现。它们带来了一个不容回避的现实：这些系统自带的安全控制措施相当有限。运行时可以直接消化和解析不受信任的文本输入，从外部来源下载并执行插件技能（其实就是代码片段），并使用赋予它的凭证去执行各种动作。

这实际上把代码执行的边界，从静态的应用代码本身，转移到了动态提供的内容和第三方能力上，而围绕身份、输入处理或权限范围的控制却没有同步跟上。

在一个未加防护的部署环境中，有三种风险会快速显现：

• 分配给它的凭证和它能访问的数据可能被泄露或窃取。
• AI助手的长时记忆或“状态”可以被修改，导致它在一段时间后执行攻击者提供的指令。
• 如果AI助手被诱导去检索并执行恶意代码，它所在的主机环境可能会被彻底攻陷。

说实话，因为这种特性，OpenClaw应该被视为运行着持久有效凭证的“不受信任代码”。它根本不适合在标准的个人或企业办公电脑上运行。如果一个组织认定必须评估OpenClaw，那么它就应该被部署在完全隔离的环境里，比如专用的虚拟机或单独的物理机上。运行时应该使用专门的、低权限的凭证，并且只能访问非敏感数据。持续监控和重建预案必须成为运维模型的一部分。

澄清战场：运行时与平台

为了有针对性地部署安全控制，避免在错误地方使用错误缓解措施，搞清楚“代码在哪里执行”和“指令从哪里传播”至关重要。这两个层面常被混为一谈，但它们在受攻击时的表现不同，通常也由不同的团队负责。

OpenClaw（运行时）：一个可以在工作站、虚拟机或容器中运行的自托管AI助手运行时。它能加载各种插件技能，并与本地和云资源交互。安全关键在于：它继承了宿主机的信任级别（和风险），以及它能使用的身份。在OpenClaw里安装一个技能，基本等同于安装一段有权限的代码。很多技能通过公共技能注册平台ClawHub来发现和安装。这意味着，OpenClaw只能操作用户在设备上授权给它的一切。如果它有权限访问特定应用、文件或账户，它就可能从中获取更多信息。出于隐私和安全考虑，建议仅在隔离环境中运行OpenClaw，并且不要让它访问任何非专用的、绝不能泄露的凭证或数据。

Moltbook（平台）：一个专注于AI助手的平台和身份层，AI助手通过API在此发布、读取信息并进行身份验证。其安全核心在于，它可能变成一个巨大的、可被攻击者影响的内容流，而AI助手会定时“消费”这些内容。这样一来，一条恶意帖子就可能同时抵达多个AI助手。

实践中，OpenClaw拓展了企业环境内部的代码执行边界，而Moltbook则大规模扩展了指令影响面。当这两者在没有适当防护的情况下交互时，一次恶意输入就可能导致持久的、有凭证的执行。

AI助手如何重塑安全边界

大多数安全团队对如何保护自动化流程已很熟悉。AI助手改变了风险的本质，因为“决定做什么”的实体，和“实际执行动作”的实体，不总是同一个。在运行时，AI助手加载第三方代码、读取不受信任的输入、并利用持久凭证来行动，这就使得运行时环境本身成为了新的安全边界。

这个边界包含三大块：

• 身份：

  AI助手用来干活的身份令牌（如SaaS API、代码库、邮件、云控制平面）。

• 执行：

  它能调用的、可以改变状态的各种工具（如操作文件、执行命令行、控制基础设施、发送消息）。

• 持久化：

  它能跨运行保持变化的方式（如计划任务、配置文件、执行计划）。

总结一下，这里主要有两类安全问题：

1. 间接提示词注入：

   攻击者可以把恶意指令藏在AI助手会读取的内容里。除非用户设置了强有力的边界，否则攻击者就能引导工具的使用，或者修改AI助手的记忆，从而长期影响其行为。

2. 技能木马：

   AI助手从各种来源获取技能，本质上就是从互联网下载并运行代码。这些代码里可能包含恶意功能。

托管平台 vs. 自托管运行时

对于托管型助手和平台，安全控制通常集中在身份权限范围、连接器管理和数据边界上，因为运行时及其更新是由平台方集中管理的。而对于自托管运行时，这份责任就转移到了组织自己身上。主机系统、插件接口、本地状态都成了信任边界的一部分，而且运行时通常就在开发者那些敏感的凭证旁边运行。

用自托管运行时，你得自己为“爆炸半径”负责。主机、插件、本地状态都在信任边界之内。如果一个AI助手能够浏览外部内容并安装扩展，那么你应该假设它迟早会处理恶意输入。因此，安全控制的重心应该放在隔离和可恢复性上，而不是单纯依赖预防。

端到端攻击场景：“有毒”的技能

这个场景展示了开放AI助手生态中一个非常现实的入侵链条。它直接对应到防御者可以影响的控制点：安装了什么、运行时能访问什么、持久化是如何建立的。公开报告已经披露了在公共注册平台出现的恶意技能。有些情况下，这些技能就是直接打包成技能形态的恶意软件，连伪装都省了。

步骤1：分发

攻击者将一个恶意技能发布到ClawHub，有时伪装成实用工具，有时干脆明目张胆。然后通过社区渠道推广它。也可能是用户自己在快速迭代、低安装成本的生态中搜索并有机发现、然后安装了它。这相当于为恶意代码开辟了一条直接的供应链路径，直达运行时。

步骤2：安装

开发者或者AI助手本“人”发起了安装，因为这个技能看起来与某个任务相关。在宽松的部署中，运行时可能被允许无需人工批准就直接执行安装流程。在控制更严格的环境里，安装应该被视为一个需要明确审批的事件，等同于执行第三方代码。

步骤3：访问状态（令牌与持久指令）

攻击者的目标是访问AI助手的状态，包括令牌、缓存的凭证、配置数据和交互记录，以及能影响未来运行的持久指令渠道，比如任务文件、计划操作或AI助手配置。如果持久指令可以通过正常交互被修改，那么一次“注入”的效果就能在多次执行中持续存在。

步骤4：通过合法API进行权限复用

一旦拿到有效的身份凭据，攻击者就可以通过标准的API和工具来执行操作。只要缺乏强大的监控和日志记录，这些活动看起来就和合法的自动化流程没什么两样。

步骤5：通过配置实现持久化

持久化经常表现为持久的配置更改，比如新增OAuth授权、计划任务、修改AI助手任务，或者让某些工具获得永久批准。攻击者的目标通常不是部署传统的恶意软件，而是为了长期控制这个自动化通路。

变体：通过共享馈送进行间接提示词注入

如果多个AI助手都配置为轮询同一个共享信息源，攻击者就可以把恶意指令藏在它们“摄取”的内容里。这就是间接提示词注入：攻击载荷混在指令供应链里，嵌在外部内容中，而不是由可信的操作员直接提供。在多智能体场景下，一条恶意帖子就能一次性攻击多个AI助手。实际风险在于，可能在那个权限高、但防护弱的AI助手上，引导工具滥用或触发敏感信息泄露。

最低安全操作基线（如果你非要运行OpenClaw）

最安全的建议是，不要用你的主要工作或个人账户来安装和运行OpenClaw，也别在存有敏感数据的设备上运行它。就目前的情况看，你应该假设运行时可能被不可信输入影响，它的状态可以被篡改，主机系统可能通过它而暴露。

如果你确实有正当理由需要评估OpenClaw，下面这些防护措施应该作为底线：

1. 仅在隔离环境中运行

   ：使用一个不用于日常工作的专用虚拟机或单独的物理设备。把这个环境视为“一次性”的。

2. 使用专用凭证和非敏感数据

   ：创建仅用于AI助手目的的账号、令牌和数据集。假设它可能被攻陷，并做好定期轮换的计划。

3. 监控状态或记忆是否被篡改

   ：定期审查AI助手保存的指令和状态，看看有没有出现意料之外的持久规则、新加入的可信来源，或者跨运行的行为变化。

4. 备份状态，以便快速重建

   ：

• 备份.openclaw/workspace/目录可以捕获AI助手的工作状态，但不包含凭证。
• 备份整个.openclaw/目录也能捕获令牌和凭证。虽然这简化了恢复过程，但也增加了备份的敏感性，如果怀疑凭证已泄露，这么做可能就不合适。

1. 把重建视为一项常规控制措施

   ：定期重装，一旦发现异常行为就立即重建。持久化攻击可能看起来只是细微的配置更改，而不是明显的恶意软件部署。

| 需要做什么 | 如何通过微软控制实现 | | — | — | | 身份 | 为AI助手使用专用身份。最小化权限。优先使用短期令牌。对高权限使用受控的授权流程。Microsoft Entra ID：强制执行最小权限、条件访问和管理员批准流程。Microsoft Defender for Cloud Apps (应用治理)：盘点OAuth应用、监控授权漂移、对可疑发布者或权限级别告警。 | | 终端与主机 | 将AI助手主机视为特权设备。将试点与生产环境隔离。制定快速隔离和令牌吊销计划。Microsoft Defender for Endpoint：加入AI助手主机，并使用设备组应用更严格策略。Microsoft Defender XDR：关联终端活动与身份、云事件，以便快速调查和遏制。 | | 供应链（技能、扩展、插件） | 尽可能限制安装来源和发布者。固定已批准能力的版本。审查更新。Microsoft Defender for Endpoint：利用遥测和调查发现可疑扩展安装和远程访问工具。终端管理和应用控制：在可行的地方限制未经批准的安装路径和发布者。 | | 网络与出口 | 限制AI助手主机和工作负载的出站访问，只允许访问业务所需的目标地址。除非有充分理由，否则应阻止或隔离高风险的外部内容源。Defender for Endpoint 网页内容过滤：对AI助手设备组限制访问类别和网站。Azure网络控制和Defender for Cloud：在Azure中应用网络控制，并通过集中日志监控出站行为。 | | 数据保护 | 降低敏感数据被AI助手提示词摄取的风险。降低敏感数据被AI助手工具泄露的风险。Microsoft Purview：使用敏感度标签和终端DLP来审计或阻止AI助手进程以及向外部目的地移动带标签的数据。 | | 监控与响应 | 记录AI助手动作，并将异常的工具使用视为事件信号。为AI助手身份泄露准备响应预案。Microsoft Defender XDR：使用狩猎和事件关联分析。Microsoft Sentinel：当需要更长的数据保留、更丰富的关联和自动化时使用它。建立围绕隔离、凭证轮换、授权审查和工作空间取证的运行手册。 |

狩猎查询与排查指引（Microsoft Defender XDR）

这些狩猎查询旨在快速发现环境中AI助手运行时在哪里运行，并帮助你区分那些作为高权限自动化运行的部署与正常的用户驱动行为，从而加快范围确定、优先级排序和响应速度。

狩猎1：发现AI助手运行时及相关工具

用来盘点AI助手运行时的存在位置，以及它们运行时使用的身份和命令行。

DeviceProcessEvents| where Timestamp > ago(30d)| where ProcessCommandLine has_any ("openclaw","moltbot","clawdbot")or FileName has_any ("openclaw","moltbot","clawdbot")| project Timestamp, DeviceName, AccountName=InitiatingProcessAccountName, FileName, FolderPath, ProcessCommandLine| order by Timestamp desc

排查：确认设备是已批准的试点一部分，验证任何控制接口的暴露面是否受限，如果运行时出现在意外位置，审查最近的安装记录。

狩猎1b: 云工作负载变体 (CloudProcessEvents)

当AI助手运行时可能运行在通过Defender for Cloud加入的多云容器环境中，且进程遥测数据记录到CloudProcessEvents表时，使用此查询来扩展盘点范围。

CloudProcessEvents| where Timestamp > ago(30d)| where ProcessCommandLine has_any ("openclaw","moltbot","clawdbot")or ProcessName has_any ("openclaw","moltbot","clawdbot")or FileName has_any ("openclaw","moltbot","clawdbot")| extend WorkloadId = coalesce(AzureResourceId, AwsResourceName, GcpFullResourceName)| project Timestamp,WorkloadId,KubernetesNamespace,KubernetesPodName,ContainerName,AccountName,ProcessName,Filenames,FolderPath,ProcessCommandLine| order by Timestamp desc

排查：验证工作负载和命名空间是否映射到已批准的试点，确认容器镜像来源，核查该服务预期的进程和命令行是什么。

狩猎1c：ClawHub技能安装与罕见技能识别

用来识别ClawHub技能安装事件，并发现环境中出现的罕见技能。

DeviceProcessEvents| where Timestamp > ago(30d)| where ProcessCommandLine has "clawhub install"| extend SkillSlug = extract(@"\bclawhub\s+install\s+([^\s]+)", 1, ProcessCommandLine)| where isnotempty(SkillSlug)| summarize InstallEvents=count(), Devices=dcount(DeviceName), Accounts=dcount(InitiatingProcessAccountName) by SkillSlug| order by Devices asc, InstallEvents desc

排查：确认该技能是否为试点所批准，然后审查已安装技能文件夹的内容，并与后续活动（如新启动的Shell、下载工具或出站连接）进行关联。将该技能名称与批准的列表对比，以捕获试图模仿的命名。

狩猎2：开发者终端上的扩展安装与频繁变更

用来检测开发者终端上扩展的频繁变动，这通常是可疑执行的前兆。

DeviceFileEvents| where Timestamp > ago(30d)| where FolderPath has_any (@"\.vscode\extensions\", @"/.vscode/extensions/")| where ActionType in ("FileCreated","FileModified","FolderCreated")| summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp), FileCount=count()by DeviceName, InitiatingProcessAccountName, FolderPath| order by LastSeen desc

排查：重点关注新创建的扩展文件夹和意料之外的修改高峰。验证发布者和安装来源，然后检查该扩展启动了哪些进程。

狩猎3：高权限OAuth应用与授权漂移（App Governance）

用来发现与AI助手集成相关的、新的或已变更的高权限OAuth应用（需要启用App Governance）。

OAuthAppInfo| where Timestamp > ago(30d)| where PrivilegeLevel =~ "High"| project Timestamp, AppName, VerifiedPublisher, AppOrigin, IsAdminConsented, ConsentedUsersCount, AppStatus, Permissions| order by Timestamp desc

排查：验证商业上是否需要如此高权限的应用，确认发布者身份，并调查权限或授权范围的突然变化。

狩猎4：AI助手进程创建意外监听服务

用来检测由AI助手进程打开的监听端口，这可能表明控制面暴露或无意中开启了服务。

DeviceNetworkEvents| where Timestamp > ago(30d)| where ActionType == "ListeningConnectionCreated"| where InitiatingProcessCommandLine has_any ("openclaw","moltbot","clawdbot")or InitiatingProcessFileName has_any ("openclaw","moltbot","clawdbot")| summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp), Ports=make_set(LocalPort)by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, LocalIP| order by Timestamp desc

排查：验证监听是否是必须的，以及是否进行了访问限制。如果访问范围超出了预期边界，则隔离主机并轮换该AI助手使用的所有身份。

狩猎5：AI助手运行时启动意外Shell或下载工具

用来标记在AI助手运行中不常见的、启动Shell或下载工具的行为。

DeviceProcessEvents| where Timestamp > ago(30d)| where InitiatingProcessFileName has_any ("openclaw","moltbot","clawdbot")or InitiatingProcessCommandLine has_any ("openclaw","moltbot","clawdbot")| where FileName in ("cmd.exe","powershell.exe","pwsh.exe","bash","sh","curl","wget")| project Timestamp, DeviceName, AccountName=InitiatingProcessAccountName,Parent=InitiatingProcessFileName, FileName, ProcessCommandLine| order by Timestamp desc

排查：区分预期的自动化与机会型执行。对于那些子进程触及凭证存储、安装新软件包或向异常目的地建立网络连接的案例，应给予更高优先级。

自托管AI助手的安全意涵

自托管AI助手把不受信任的代码和不受信任的指令，融合到了使用有效凭证执行的单一运行循环中。这就是核心风险。

运行OpenClaw不仅仅是一个配置选项。它是一个关于你准备将哪台机器、哪些身份、哪些数据暴露给处理不可信输入的AI助手的信任决策。

对大多数环境来说，恰当的决定可能就是不部署它。如果有团队非要上，那么唯一站得住脚的姿态是假设它随时可能被攻陷：隔离运行时、限制其访问范围、持续监控、并准备好随时进行无延迟的重建。

有三件事应该立即去做：盘点运行时在哪里部署、验证它使用哪些身份以及相关权限、识别哪些输入能影响工具执行。然后相应地收紧控制，并端到端监控活动。前面提供的狩猎查询可以作为起点，把每一个发现都当作在攻击发生前缩小“爆炸半径”的机会。

参考资料

[1] https://www.microsoft.com/en-us/security/blog/2026/02/19/running-openclaw-safely-identity-isolation-runtime-risk/

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《如何安全运行 OpenClaw：身份、隔离与运行时风险》