OpenClaw 真正跑进工作流以后，最容易被忽略的问题不是“模型能不能理解”，而是“它到底被允许做什么”。只要 Agent 开始调用工具、读取资料、发送消息、操作后台，权限和凭证管理就不再是运维细节，而是系统能不能长期使用的底线。
很多新手会把凭证直接写进提示词、脚本或文档里，短期确实省事，长期却非常危险。正确做法是把敏感信息放在环境变量或受控配置里，让 Agent 只能通过受限工具间接使用，而不是在上下文里看到明文。
第一条原则：最小权限
给 Agent 配权限时，不要图省事直接给管理员账号。它只需要读知识库，就不要给写权限；只需要发送指定群消息，就不要给全量通讯录权限；只需要查询订单，就不要给退款和修改地址的权限。
最小权限听起来像老生常谈，但在 Agent 场景里尤其重要。因为模型可能理解错任务，也可能被用户输入误导。权限越大，错误执行的代价越高。
第二条原则：凭证不要进提示词
提示词、文章、README、聊天记录都不是保存密钥的地方。更稳的方式是把凭证放到环境变量、密钥管理服务或服务器受控配置中，工具运行时再读取。这样即使提示词被导出，也不会把账号密码一起带出去。
这点和本站维护规范一致：服务器连接信息、WordPress 应用密码等敏感字段只能通过环境变量读取，不能明文写进文档、脚本注释或提交记录。
第三条原则：高风险工具要白名单
不是所有工具都应该默认开放。读文件、查资料、搜索网页属于低风险；删除数据、改配置、发群通知、付款、退款、重置账号则属于高风险。OpenClaw 工具配置里应该把这些动作分层，能不用就不用，必须用就加限制。
如果你正在搭多渠道机器人，可以参考 OpenClaw 多渠道接入怎么选。渠道越多，误发消息和越权操作的风险越高，白名单越要提前设计。
第四条原则：关键动作保留人工确认
自动化不等于所有步骤都无人值守。涉及对外发送、批量修改、删除、退款、权限变更的动作，最好让 Agent 先生成操作摘要，再由人确认执行。这样既能保留效率，又能避免一次理解偏差造成实际损失。
这个思路也适合客服 Agent。比如 OpenClaw 本地知识库实战 里提到的资料整理方法，放到客服场景时就应该把解释、查询、修改分开处理。
第五条原则：日志要能复盘
权限系统如果没有日志，出了问题很难追。至少要记录谁触发了任务、Agent 理解成什么、调用了哪个工具、传了什么非敏感参数、工具返回了什么、最终有没有执行成功。
日志不是为了事后甩锅，而是为了把系统越调越稳。具体怎么复盘，可以接着看 OpenClaw 日志复盘方法。只要能还原链路，很多“AI 不靠谱”的抱怨都会变成具体可修的问题。
总结
OpenClaw 权限与凭证管理的核心不是复杂，而是边界清楚。最小权限、环境变量、工具白名单、人工确认和日志审计，这五件事先做到，Agent 才适合进入真实业务流程。否则能力越强，风险也越大。
