个人助手的安全模型：不是信任，而是可验证的边界

一个能读文件、跑命令、接外部 API 的 AI 助手，能力越强，越需要一套”默认不越界”的安全模型。OpenClaw 的安全设计不是靠一句”请谨慎操作”的提示词，而是由工具策略、执行审批、凭据隔离、上下文边界四层机制组成的工程体系。本文逐层拆解它如何把”模型可能犯错”这一不可消除的风险，约束成可预期、可拦截的行为。

第一层：工具策略决定”能做什么”

Agent 并非默认拥有全部工具。每个 Agent 配置一个工具 profile，系统按 profile 做策略过滤——名字不在白名单内的工具，模型在当前会话里根本无法调用。这是第一道也是最硬的边界。

能力收敛的顺序：
1. 工具是否存在（profile 过滤，不可调用）
2. 工具参数是否合法（schema 校验）
3. 具体动作是否需要审批（执行策略）
4. 敏感凭据是否可访问（secrets 隔离）

设计原则是最小权限：只读型 Agent 只给 read/ls，运维型 Agent 才给 exec，能对外发送消息的工具只在确有必要的会话开放。把”删库”和”发邮件”这类高危能力从模型的工具箱里物理移除，比指望它每次都自觉可靠得多。

第二层：执行审批决定”这次能不能做”

即便工具可用，每一次具体调用仍可能需要人确认。执行策略按风险分级：只读操作默认放行，写操作、网络外发、提权操作等需要批准，破坏性操作可直接拒绝。

审批的价值在于把真实意图展示给人：批准前必须呈现完整、精确的命令或脚本，包括链式命令和多行内容，而不是一个含糊的”要执行操作，是否同意”。这样人才能在命令真正落地前发现 rm -rf $VAR/ 里变量为空、或路径写错这类致命问题。一次性授权只覆盖那一条确切命令，后续命令需要各自的决策，不存在”永久放行”。

第三层：凭据隔离，密钥不落进模型上下文

密钥、token 是最需要保护的资产。OpenClaw 的处理原则是：明文密钥既不写进配置文件，也不进入提示词，更不允许出现在进程参数里（ps 可见）。

错误做法：
  --token=abc123            # 进程列表泄露
  password = "abc123"        # 落盘 + 进上下文

正确做法：
  SecretRef / secrets 托管   # 值由系统注入，模型只见引用
  掩码式交互录入             # 人工输入，不落明文

模型通常只持有一个对密钥的”引用”，真正的值在执行时由系统在受信边界内注入。这样即使会话记录、日志或提示词被读取，泄露的也只是引用而非密钥本身。临时凭据（如登录配对码）只在私聊里发给请求者本人，用完即弃，从机制上缩小暴露面。

第四层：上下文边界，防止数据越界流动

安全不只是”能不能执行”，还包括”数据能不能流动”。OpenClaw 对会话与记忆做了明确隔离：

主会话：加载完整长期记忆（MEMORY.md）
群聊/共享会话：不加载主会话的私密记忆
跨渠道：私聊内容默认不转发到群组
记忆文件：按会话/项目范围隔离，不混用

这层边界针对的是”代理人”风险：助手在群里能看到本人的私人资料，不代表可以把它带进群聊。外发动作（邮件、推文、群消息）默认需要更谨慎的判断，内部动作（整理、检索、学习）则可以更主动。数据的可见范围与可外发范围被刻意分开。

风险无法归零，靠纵深防御收敛

必须承认：模型可能误判、可能被提示注入诱导、可能在复杂链路里犯错。没有任何单一层级能保证绝对安全，所以用纵深防御——即使模型想越权调用，工具不在；即使工具在，审批拦截；即使命令通过，密钥也拿不到明文；即使拿到局部数据，也难以越境外发。每一层都假设上一层可能失效。

给使用者的实操建议

1. 按用途建不同 Agent，给最小工具集，别全员 admin
2. 高危/外发动作保留审批，仔细核对完整命令再批准
3. 密钥一律走 secrets/SecretRef，绝不写进配置或聊天
4. 群聊机器人不挂主会话私密记忆
5. 定期复查已启用的工具、渠道与密钥元数据

小结

OpenClaw 的安全权限模型是一条四层链路：工具策略限定可用能力，执行审批拦截高风险动作，凭据托管避免明文泄露，上下文边界阻止数据越界。它的核心思想不是让模型”发誓小心”，而是用工程手段把不可消除的判断风险，限制在层层可验证的边界之内。安全不是一个开关，而是一套默认拒绝、逐层放行的纵深体系。