OpenClaw 深度解析：Codex常驻智能体的安全控制平面实践

10 组 Q&A（工程师视角）

1. Q：常驻 Agent 和普通 Codex 会话最大安全差异是什么？ A：普通会话目标固定、人工引导；常驻 Agent 24/7 自主行动、可生成修改代码，风险是 Agent 自身行为失齐（内生风险），不只是外部攻击。
2. Q：可信 / 不可信边界怎么划分？ A：可信：网关、身份、网络代理、沙箱控制逻辑（静态确定代码）；不可信：Agent 大模型运行时、Agent 写出的代码、Agent 工作环境。
3. Q：Codex 沙箱两大配置文件分工？ A：requirements.toml：管理员强制锁死可选能力；config.toml：定义权限集、文件 / 网络 / 环境变量策略。
4. Q：网络安全管控手段有哪些？ A：托管代理、域名白名单、显式黑名单（云元地址、pastebin 等）、禁止自行扩白名单。
5. Q：密钥如何保护，不让 Agent 直接读取？ A：使用密钥代理（credential broker），密钥不暴露给 Agent 运行环境。
6. Q：auto-review 自动审核解决什么痛点？ A：避免全量人工审核带来的审核疲劳；LLM 初审过滤常规动作，人工只处理高风险事项。
7. Q：Agent 身份和服务账号是一回事吗？ A：不是。Agent 身份用来标识行为主体、审计区分 Agent / 用户操作；服务账号配套它，用来访问第三方资源。
8. Q：文件权限最小化怎么做？ A：仅开放工作目录写权限，运行环境只读，SSH 密钥目录等敏感路径直接 deny。
9. Q：可观测日志记录哪些内容？权限策略？ A：控制平面配置变更、Agent 每一轮交互；日志含敏感信息，仅安全小范围人员可访问。
10. Q：OCE（OpenClaw Enterprise）价值？ A：开源厂商中立 Agent 控制平面，内置这套安全预设，降低企业自建持久 Agent 安全底座成本。

OpenAI 如何结合可信控制平面服务、Codex 沙箱、自动审核、智能体身份与可观测性体系，落地常驻智能体作者：Kevin S Lin

近一年前 OpenClaw 发布时，它向业界展示了常驻智能体的能力。普通 Codex 会话有着固定目标，并且由人引导；而常驻智能体可以 24/7 持续运行，工作范围宽泛，无需用户输入就能主动执行动作。

常驻智能体能力极强，但到目前为止，它们在真实业务中的落地规模仍然有限。和传统软件相比，这类部署面临大量全新挑战。传统软件依赖配置与代码的确定性，威胁大多来自外部攻击者；但常驻智能体可以自行修改配置、编写任意代码来达成目标。风险会从内部产生：智能体做出和预期对齐的行为发生偏移，形成 “内生攻击”。

目前 OpenAI 内部已经大规模部署常驻智能体，其中包含数百个 OpenClaw 智能体。本文介绍我们为落地 OpenClaw 所采用的一系列安全管控方案。

一、隔离可信执行与不可信执行

要保护常驻智能体，必须把可信、确定的业务逻辑和不可信的大模型执行环境隔离开。可信逻辑包含网络、身份、沙箱等核心组件，属于静态代码；只要没有软件漏洞，行为就和配置保持一致。而智能体本身、它的运行环境、以及它动态写出的代码，全部归为不可信部分：智能体可以按需生成代码，行为没有强确定性保证。

为支撑这套架构，OpenClaw 开源项目实现了网关与执行 harness（远程运行基座）分离方案。这使得 OpenClaw 网关组件和智能体运行基座可以跑在不同容器，在我们内部更是部署在独立集群。

借助这种拆分，我们把负责调度配置智能体的网关视作可信确定性代码，只需要重点对智能体负载做沙箱隔离，当作不可信代码管控。

二、设置刚性安全边界

智能体负载的安全边界依靠沙箱机制强制落地，限制智能体可执行的动作。OpenClaw 内部部署采用的沙箱管控维度：

• 网络：管控智能体可访问的端点。使用企业级白名单，对受限端点显式拦截
• 工作区：管控可读写文件。仅允许向智能体专属工作目录写入
• 进程：管控可访问进程。依托 Codex Linux 沙箱做进程隔离
• 密钥：管控密钥访问权限。通过密钥代理服务托管密钥，智能体本身无法直接读取密钥

我们直接复用 Codex 基座自带沙箱，配置分为两类：

1. requirements.toml
   ：管理员强制约束，限定 Codex 配置里可选的能力项
2. config.toml
   ：Codex 实际运行权限配置

同时额外启用安全策略：关闭人工审批交互模式，网页检索流量全部走 OpenAI 自研检索索引。

requirements.toml

# 禁止无限制的 danger-full-access 高危沙箱模式allowed_sandbox_modes = [”read-only”, ”workspace-write”]# 允许缓存检索，禁止实时在线检索allowed_web_search_modes = [”cached”]# 启用实验性托管网络代理experimental_network.enabled = true# 用户侧配置不能自行扩充域名白名单experimental_network.managed_allowed_domains_only = true# 仅放行以下目标域名，按需替换为业务所需地址experimental_network.allowed_domains = [  ”github.com”,  ”api.github.com”,  ”codeload.github.com”,]# 显式拦截目标，包含云元数据地址experimental_network.denied_domains = [  ”pastebin.com”,  ”*.pastebin.com”,  ”webhook.site”,  ”metadata.google.internal”,  ”169.254.169.254”,]

config.toml

# 选用下方定义的权限集default_permissions = ”openclaw”# 使用缓存检索模式web_search = ”cached” [permissions.openclaw.filesystem]# 最小运行环境只读权限”:minimal” = ”read”# 智能体工作目录读写”/home/dev-user/openclaw-workspaces” = ”write”# 只读资产目录”/home/dev-user/read-only” = ”read”# 禁止访问 SSH 密钥”/home/dev-user/.ssh” = ”deny” [permissions.openclaw.network]# 强制走管理员托管代理enabled = true# 不继承上游代理allow_upstream_proxy = false# 开启代理本地/私有地址防护allow_local_binding = false# 关闭 SOCKS5 监听enable_socks5 = false# 关闭 SOCKS5 UDPenable_socks5_udp = false# 禁止在非回环地址启动代理监听dangerously_allow_non_loopback_proxy = false# 禁止无限制访问 Unix socketdangerously_allow_all_unix_sockets = false [shell_environment_policy]# 保留敏感环境变量默认过滤规则ignore_default_excludes = false# 从智能体命令环境中剔除 GitHub 凭证（不会隐藏文件内存储的凭证）exclude = [  ”GH_TOKEN”,  ”GITHUB_TOKEN”,  ”OPENCLAW_GITHUB_BASIC_AUTH”,  ”OPENCLAW_GITHUB_READONLY_BASIC_AUTH”,] [apps._default]# 默认关闭所有应用，按需单独开启enabled = false# 默认禁用高风险销毁类操作destructive_enabled = false# 默认禁用开放互联网类操作open_world_enabled = false

三、增加基于大模型的安全防护

前面所有管控都属于静态防护：依靠传统确定性代码阻止智能体越界。随着模型能力持续变强，我们需要可以随算力同步扩容的防护手段 —— 也就是用另一个大模型做防护。

OpenAI 的 auto-review（自动审核）系统，使用二级智能体监控、审批主智能体的动作。如果全部依赖人工审核，人会产生审核疲劳，习惯性放行所有权限弹窗。把 LLM 审核器作为前置过滤层，人工只需要处理高风险审批项。该能力原生内置于 OpenClaw 和 Codex。在 OpenClaw 内部部署中，所有智能体动作强制经过自动审核。

四、智能体身份与用户身份解耦

智能体执行动作时，我们需要审计行为、分配资源权限，并且区分动作发起方是智能体还是人类用户 —— 智能体身份就是用来实现这件事的。目前业界正在形成相关标准：一部分规范让智能体拥有独立资源访问权限；另一部分基于 OAuth 委托，让智能体代表用户行事。

⚠️ 智能体身份 ≠ 服务账号：服务账号是给机器人独立 API 访问身份，二者需要搭配使用。典型做法：智能体持有自身独立身份，再通过绑定该身份的服务账号访问第三方服务。

OpenClaw 内部部署方案：每个智能体拥有唯一身份，绑定企业服务账号。好处：

• 推理凭证独立于用户账号
• 团队可以给智能体挂载自定义插件
• 完整审计智能体行为，必要时直接关停推理权限

五、全链路可观测

完备的可观测能力，让运维团队掌握智能体完整生命周期：从配置变更，到每一步执行动作。对于常驻智能体来说，这套能力是溯源、识别异常对齐偏移行为的基础。

OpenClaw 内部全量日志采集：控制平面上每一次配置变更、智能体每一轮交互（turn）全部落日志。因为交互日志可能包含敏感信息，日志做严格权限锁定，仅安全团队少数人员可访问。

结语

常驻智能体还处在落地早期，行业缺少成熟最佳实践，这也是很多企业不敢大规模采用的原因。

OpenAI 内部 OpenClaw 试点上线后，技术与非技术团队的生产力和使用率都显著提升。目前已有 500+ 智能体在后台持续自主工作：收到产品反馈自动提交代码 PR、持续针对新功能跑数据实验等。

在 OpenAI DevDay，我们发布了开源、厂商中立的智能体控制平面 OpenClaw Enterprise（OCE）。使用 OCE 配套的标准 Codex 预设，开箱即可启用本文提到的多项安全能力。项目当前仍处于试点阶段，计划在今年年底发布 1.0 正式版。

我们相信产业界 AI 最大增量会来自常驻智能体。我们把内部实践对外公开、开源 OCE，目标是让所有人都能更安全地部署这类智能体。