本文收录于GithubAI-From-Zero 项目 —— 一个从零开始系统学习 AI 的知识库。如果觉得有帮助欢迎 ⭐ Star 支持如何对OpenClaw龙虾做最小权限设计一、最小权限原则Agent安全的基石最小权限原则Principle of Least Privilege在Agent上下文里的含义是Agent在任何时刻拥有的权限不应超过完成当前任务所必需的最小集合。说人话就是想象你雇佣了一个助理帮你处理工作。你不会给他你家所有房间的钥匙、银行账户密码和公司所有文件的访问权限。你只会给他完成当前任务所需的最小权限——比如今天只需要他查看邮件就只给邮箱的只读权限明天需要他发会议邀请才临时给日历的写入权限。这不只是安全最佳实践也是工程设计的基本纪律——权限越少Agent做错事的影响范围越小无论错误来自Prompt Injection、LLM幻觉还是Skill的bug。对于OpenClaw这类拥有邮件和日历读写权限的Agent最小权限设计需要在三个维度上同时发力范围Scope——能访问哪些资源操作Operation——能做什么动作时机Time——什么时候才能做把这三个维度结合起来才能构建真正有约束力的权限模型而不只是在文档里写请小心使用。二、当前OpenClaw的权限现状OpenClaw的权限粒度目前主要在Skill层面控制——一个Skill的SKILL.md说明书里会声明它需要哪些Toolexec、web_fetch、browser等以及需要哪些外部服务的API Key。但这个控制是静态的、粗粒度的一旦Gmail Skill被激活它在整个Session里对用户邮箱的访问权限没有进一步的约束。这意味着用户说帮我读一下今天的重要邮件Agent理论上获得了能读取所有邮件、甚至发送邮件的权限即使用户只想要读。这种全有或全无的权限模型存在明显的安全风险需要更精细化的设计。三、维度一操作权限分离读 vs 写最基础的权限分离是把读操作和写操作彻底分开默认只给读权限写权限需要显式声明或用户确认。OAuth Scope的最佳实践对应到Google OAuth Scope这个区别是明确的// ❌ 错误做法申请全量邮件权限constGMAIL_FULL_SCOPEhttps://mail.google.com/;// ✅ 正确做法按需申请最小ScopeconstGMAIL_READONLYhttps://www.googleapis.com/auth/gmail.readonly;constGMAIL_SENDhttps://www.googleapis.com/auth/gmail.send;constGMAIL_MODIFYhttps://www.googleapis.com/auth/gmail.modify;// 标记已读、移动constCALENDAR_READONLYhttps://www.googleapis.com/auth/calendar.readonly;constCALENDAR_EVENTShttps://www.googleapis.com/auth/calendar.events;// 创建/修改事件Skill设计层面的分离读邮件Skill和发邮件Skill应该是两个独立的Skill各自持有最小必要的OAuth Tokenskills/ ├── gmail-read/ │ ├── SKILL.md # 声明只需要 gmail.readonly scope │ └── config.json # { scope: gmail.readonly } ├── gmail-send/ │ ├── SKILL.md # 声明需要 gmail.send scope高危操作需确认 │ └── config.json # { scope: gmail.send, requireConfirm: true } └── calendar-read/ └── SKILL.md # 声明只需要 calendar.readonly scope这种设计确保了读操作默认安全不需要用户确认写操作显式授权高危操作必须用户确认权限边界清晰每个Skill的职责单一明确四、维度二资源范围约束即使在同一类操作内也应该限制能访问的资源范围避免Agent获得过大的数据访问权限。邮件标签过滤而非全量访问// 只允许Agent读取INBOX中被标记为IMPORTANT或UNREAD的邮件// 而不是能搜索整个邮箱历史asyncfunctionfetchAgentAccessibleEmails(gmail){returngmail.users.messages.list({userId:me,labelIds:[INBOX,UNREAD],// 明确限定标签范围maxResults:20,// 限制单次获取数量// 不传q参数禁止全文搜索防止注入攻击用搜索泄露历史数据});}日历只读取未来N天的事件asyncfunctionfetchCalendarEvents(calendar,daysAhead7){constnownewDate();constmaxTimenewDate(now.getTime()daysAhead*24*60*60*1000);returncalendar.events.list({calendarId:primary,timeMin:now.toISOString(),timeMax:maxTime.toISOString(),// 禁止读取历史事件maxResults:50,singleEvents:true,orderBy:startTime,});}资源范围约束的核心原则资源类型约束策略安全收益邮件标签过滤 数量限制防止大规模数据泄露日历时间窗口限制避免访问敏感历史事件文件目录白名单防止访问系统敏感文件网络域名白名单防止连接恶意服务器五、维度三时机约束Just-in-Time权限最激进也最有效的设计是Just-in-Time权限Agent平时不持有任何高权限Token只在需要执行某个具体任务时向用户申请一次性授权任务完成后权限立即销毁。信任策略平衡用户体验这个模型的代价是用户体验摩擦——每次高危操作都要确认。可以通过信任策略平衡constTRUST_POLICY{// 低风险静默执行calendar.readonly:{confirm:false},gmail.readonly:{confirm:false},// 中风险首次确认24小时内记住选择calendar.events:{confirm:first-time,rememberFor:86400},// 高风险每次确认且显示操作详情gmail.send:{confirm:always,showPreview:true},exec:{confirm:always,showCommand:true},};Just-in-Time权限的工作流程权限请求Agent检测到需要高权限操作用户确认显示详细的操作预览和风险说明临时授权生成一次性Token设置短过期时间执行操作使用临时Token完成任务权限回收任务完成后立即销毁Token这种设计确保了即使Agent被攻击攻击者也无法持久化地滥用权限。六、权限设计的检查清单好的最小权限设计在code review或Skill审查时应该能回答这几个问题权限范围检查这个Skill用到的OAuth Scope里有没有比必要的更广的权限读操作和写操作是否用了分离的Scope和Token数据访问控制单次执行能访问的数据量是否有上限防止大规模数据泄露是否限制了资源访问的范围标签、时间窗口、目录等用户授权机制高危操作是否都有用户确认流程确认流程是否提供了足够的操作预览信息权限生命周期管理Token是否有过期时间是否在任务完成后主动销毁权限安全监控是否记录了所有权限使用日志是否有异常权限使用的告警机制七、终极目标权限与意图的严格对齐权限设计的终极目标不是让Agent什么都不能做而是让Agent能做的事情和用户真正授权它做的事情严格对齐。这道缝隙越小Agent被滥用无论是被外部攻击还是被自身错误的空间就越小。最小权限设计的价值降低攻击面即使Prompt Injection成功攻击者能做的也有限限制错误影响LLM幻觉导致的错误操作被权限边界限制提高可审计性每个操作都有明确的权限来源和用户授权增强用户信任用户清楚知道Agent能做什么、不能做什么在Agent时代最小权限原则不仅是安全要求更是用户体验设计的核心组成部分。好的权限设计让用户既感到安全又不会被繁琐的确认流程困扰。正如安全专家常说的“安全不是功能而是基础”。对于OpenClaw这样的强大Agent最小权限设计就是它的安全基础。