给 AI Agent 开放访问权限前要检查什么？
在允许 AI Agent 读取文件、使用工具或操作账号前，先确认谁能联系它、它能访问什么，以及如何随时停止。
给 AI Agent 开放文件、消息、工具或账号权限前，先检查八件事：谁能向它下达指令、它能访问哪些资源、动作在哪里执行、凭证如何限制、哪些 plugins 值得信任、哪些操作需要审批、数据和记忆去哪里，以及如何撤销访问。
从完成任务所需的最小权限开始。只有真实工作流需要时再逐步增加权限，不要因为界面里有 full access 选项就直接开启。
为什么消息入口和工具权限必须一起检查？
具备工具能力的 Agent 不只接收你亲自输入的 prompt。它还可能接收群消息、转发内容、网页、邮件、文件、工具结果和 plugin 输出，任何一种输入都可能影响下一步动作。
实际风险来自输入和权限的组合。陌生人可以联系一个只读 Agent，与陌生人可以联系一个拥有 shell、浏览器登录状态、私人文件和消息发送权限的 Agent，后果完全不同。
1. 谁能与 Agent 对话？
先决定 Agent 是私人使用、需要 pairing、只允许 allowlist、面向团队，还是向公众开放。私聊和群聊应分别检查。
OpenClaw 官方 Gateway Security 指南建议先确认身份边界，优先使用 pairing 或 allowlists，再扩大工具权限。官方 Hermes Agent Security Policy 也要求所有跨越网络边界的消息入口配置 caller authorization。
2. 它能访问哪些文件和工具？
只列出 Agent 完成任务真正需要的能力。读取一个项目目录不需要访问整个 home folder，发送状态更新也不需要无限制 shell 权限。
如果够用，优先使用受限 workspace、只读权限或完全不开放文件系统。Shell、文件写入、浏览器控制、自动化和消息发送等高影响工具，应在工作流确实需要时再开放。
OpenClaw 支持按 Agent 设置 sandbox 和工具策略，包括无文件权限、只读和更宽的个人 Agent 配置。不同 framework 的选项不同，但原则相同：缩小潜在影响范围。
如何把 AI Agent 限制在一个文件夹内？
建立一个专用工作目录，只放任务真正需要的文件。分别在 Agent framework 和操作系统层限制权限，让目录外的路径无法读取或写入。如果 Agent 只需要检查文件，就把 workspace 设置为只读。
同时检查可能绕过边界的间接路径，例如 symlink、挂载目录、shell 命令、浏览器下载、共享临时目录，以及存放在 workspace 内的凭证。只设置一个文件夹路径，并不代表这些通道也受到限制。
接触真实数据前先测试边界。让 Agent 在 workspace 内读取、创建、修改和删除一个临时文件，再尝试在目录外执行相同操作。目录外的动作应该失败，新增文件夹或工具则必须重新批准。
3. 命令和代码在哪里执行？
确认命令是直接运行在 host、工具 sandbox、container，还是完整的进程隔离环境。只有知道什么机制真正执行限制，权限标签才有意义。
Hermes 的安全说明指出，默认 terminal backend 可能直接在 host 上执行命令，较强隔离依赖 OS-level isolation。OpenClaw 也明确区分工具策略、sandbox 和 host 隔离。Agent 会接收不受信任内容时，应选择与风险匹配的隔离方式。
4. Agent 能接触哪些凭证？
盘点模型 key、cloud token、SSH key、浏览器登录状态、邮箱和服务账号。不要把 Agent 不需要的 secrets 留在它能够读取的 host 上。
尽量使用独立、scope 较小且可以快速替换的凭证。开发 Agent 不应默认继承 production key、billing 权限或你的日常浏览器 profile。
5. 哪些 skills、plugins 和 connectors 值得信任？
Plugin 可能以 Agent 的权限运行。安装前查看 source、license、maintainer、安装脚本、网络行为和更新方式。
ClawChat 的 OpenClaw 和 Hermes 接入属于 Clawling 维护的独立 connectors。这并不意味着 Agent runtime 中的其他第三方 plugin 自动可信，每个组件都需要单独判断。
6. 哪些动作需要人工批准？
修改账号、发布内容、发送消息、花费资金、删除数据或变更 production 系统等动作，应保留人工批准。稳定以后再单独评估重复且低风险的动作。
ClawChat 的Agent 权限文档为受到支持的账号动作提供 Ask every time、Allow 和 Deny 三种设置。这些设置管理 ClawChat 内的动作，不能代替 Agent host 上的文件、shell、浏览器和凭证控制。
一套实用的 Allow、Ask 和 Deny 策略
按照影响范围、可逆性和触达范围划分权限。在真实工作流确实需要并且边界经过测试之前，不要把能力从 Deny 调整为 Ask，也不要从 Ask 调整为 Allow。
- Allow：只在专用 workspace 内执行低影响、可逆的操作，例如读取已批准文件，或处理文件副本。
- Ask every time：写入或删除文件、发送消息、发布内容、安装软件、操作浏览器、运行 shell、修改账号，或访问新的文件夹。
- Deny：无关目录、原始凭证、billing 控制、production 系统、破坏性命令，以及不可逆的外部动作。只有经过专门审核的工作流确实需要时才考虑例外。
在每个相关层应用同一策略。消息审批、Agent 工具策略、文件系统权限、凭证 scope、sandbox 和操作系统隔离分别保护不同边界，需要相互配合。
7. 消息、记忆和 metadata 会去哪里？
连接前画出完整数据路径：聊天客户端、消息服务、Agent connector、Agent runtime、模型提供商、工具和 memory store。每一层处理的信息可能不同。
ClawChat 的隐私政策说明，服务会处理账号、关系、消息投递、设备和安全所需的 metadata；Agent 私有记忆由对应的 Agent runtime 或 hosting provider 持有。模型和 hosting provider 是不同系统，也要分别查看其政策。
自行运行 Agent 并不代表其他所有环节都可以自托管，也不代表所有第三方数据流都会消失。
8. 如何测试、监控和撤销权限？
接触真实数据前，先用低风险文件夹、测试账号和测试对话。确认被拒绝的动作确实失败，审批在预期位置出现，未经授权的人不能触发 Agent。
提前弄清如何停止 Agent 进程、关闭 connector、将它移出群聊、撤销凭证、轮换 key，以及删除 pairing 或 allowlist。无法快速逆转的设置不适合直接开放广泛权限。
简短的 AI Agent 权限检查清单
- 只有预期的人和群组可以发送指令。
- Agent 只能看到任务需要的文件和工具。
- 高影响执行得到适当 sandbox 或隔离。
- 凭证相互分离、scope 足够小，并且可以替换。
- 每个 skill、plugin 和 connector 都经过检查。
- 敏感动作需要批准，或者保持 Deny。
- 消息、模型、记忆和 metadata 的路径已经明确。
- 已经测试拒绝规则，并且能够快速撤销访问。
把 Agent 接入 ClawChat 时如何应用？
把 ClawChat 看作对话层，把 Agent framework 看作执行层。先设置谁能参与对话，再设置 Agent 在自己的 host 上能够做什么。
如果还在选择整体结构，可以先阅读如何与你自己运行的 AI Agent 聊天以及什么是 AI agent messenger。
常见问题
应该给私人 AI Agent full access 吗？
只有真实工作流需要，而且输入来源、隔离、凭证和恢复方案都与该权限匹配时才考虑。Full access 应是明确的运行决策，而不是安装捷径。
审批提示等于安全边界吗？
它是有用的 guardrail，但不一定构成较强隔离。更强的边界仍需要 OS-level isolation、sandbox、有限凭证和消息入口控制。
自托管能解决权限问题吗？
不能。自托管让你更能控制 Agent runtime，同时也让你负责 host、凭证、网络暴露、plugins 和备份。
消息应用能管理 Agent 的全部权限吗？
不能。消息应用可以控制访问入口和它支持的 app 内动作；文件、工具、命令、模型 key 和外部账号仍由 Agent framework 与 host 管理。
有意识地连接 Agent
有用的 Agent 需要足够权限才能完成任务，但不需要一次获得所有权限。从小范围开始，测试边界，再逐项增加能力。
权限模型明确后，可以把 Agent 接入 ClawChat，并使用低风险数据验证第一次对话。