🚀 本文收录于Github：AI-From-Zero 项目 —— 一个从零开始系统学习 AI 的知识库。如果觉得有帮助，欢迎 ⭐ Star 支持！

如何对OpenClaw龙虾做最小权限设计？

---

一、最小权限原则：Agent安全的基石

最小权限原则（Principle of Least Privilege）在Agent上下文里的含义是：Agent在任何时刻拥有的权限，不应超过完成当前任务所必需的最小集合。

说人话就是： 想象你雇佣了一个助理帮你处理工作。你不会给他你家所有房间的钥匙、银行账户密码和公司所有文件的访问权限。你只会给他完成当前任务所需的最小权限——比如今天只需要他查看邮件，就只给邮箱的只读权限；明天需要他发会议邀请，才临时给日历的写入权限。

这不只是安全最佳实践，也是工程设计的基本纪律——权限越少，Agent做错事的影响范围越小，无论错误来自Prompt Injection、LLM幻觉，还是Skill的bug。

对于OpenClaw这类拥有邮件和日历读写权限的Agent，最小权限设计需要在三个维度上同时发力：

1. 范围（Scope）——能访问哪些资源
2. 操作（Operation）——能做什么动作
3. 时机（Time）——什么时候才能做

把这三个维度结合起来，才能构建真正有约束力的权限模型，而不只是在文档里写"请小心使用"。

---

二、当前OpenClaw的权限现状

OpenClaw的权限粒度目前主要在Skill层面控制——一个Skill的SKILL.md说明书里会声明它需要哪些Tool（exec、web_fetch、browser等），以及需要哪些外部服务的API Key。

但这个控制是静态的、粗粒度的：一旦Gmail Skill被激活，它在整个Session里对用户邮箱的访问权限没有进一步的约束。

这意味着： 用户说"帮我读一下今天的重要邮件"，Agent理论上获得了能读取所有邮件、甚至发送邮件的权限，即使用户只想要"读"。

这种"全有或全无"的权限模型存在明显的安全风险，需要更精细化的设计。

---

三、维度一：操作权限分离（读 vs 写）

最基础的权限分离是把读操作和写操作彻底分开，默认只给读权限，写权限需要显式声明或用户确认。

OAuth Scope的最佳实践

对应到Google OAuth Scope，这个区别是明确的：

// ❌ 错误做法：申请全量邮件权限
const GMAIL_FULL_SCOPE = 'https://mail.google.com/';

// ✅ 正确做法：按需申请最小Scope
const GMAIL_READONLY = 'https://www.googleapis.com/auth/gmail.readonly';
const GMAIL_SEND = 'https://www.googleapis.com/auth/gmail.send';
const GMAIL_MODIFY = 'https://www.googleapis.com/auth/gmail.modify'; // 标记已读、移动

const CALENDAR_READONLY = 'https://www.googleapis.com/auth/calendar.readonly';
const CALENDAR_EVENTS = 'https://www.googleapis.com/auth/calendar.events'; // 创建/修改事件

Skill设计层面的分离

读邮件Skill和发邮件Skill应该是两个独立的Skill，各自持有最小必要的OAuth Token：

skills/
├── 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的邮件
// 而不是能搜索整个邮箱历史
async function fetchAgentAccessibleEmails(gmail) {
  return gmail.users.messages.list({
    userId: 'me',
    labelIds: ['INBOX', 'UNREAD'], // 明确限定标签范围
    maxResults: 20,                // 限制单次获取数量
    // 不传q参数：禁止全文搜索，防止注入攻击用搜索泄露历史数据
  });
}

日历：只读取未来N天的事件

async function fetchCalendarEvents(calendar, daysAhead = 7) {
  const now = new Date();
  const maxTime = new Date(now.getTime() + daysAhead * 24 * 60 * 60 * 1000);
  return calendar.events.list({
    calendarId: 'primary',
    timeMin: now.toISOString(),
    timeMax: maxTime.toISOString(), // 禁止读取历史事件
    maxResults: 50,
    singleEvents: true,
    orderBy: 'startTime',
  });
}

资源范围约束的核心原则

资源类型	约束策略	安全收益
邮件	标签过滤 + 数量限制	防止大规模数据泄露
日历	时间窗口限制	避免访问敏感历史事件
文件	目录白名单	防止访问系统敏感文件
网络	域名白名单	防止连接恶意服务器

---

五、维度三：时机约束（Just-in-Time权限）

最激进也最有效的设计是Just-in-Time权限：Agent平时不持有任何高权限Token，只在需要执行某个具体任务时，向用户申请一次性授权，任务完成后权限立即销毁。

信任策略平衡用户体验

这个模型的代价是用户体验摩擦——每次高危操作都要确认。可以通过"信任策略"平衡：

const TRUST_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权限的工作流程

1. 权限请求：Agent检测到需要高权限操作
2. 用户确认：显示详细的操作预览和风险说明
3. 临时授权：生成一次性Token，设置短过期时间
4. 执行操作：使用临时Token完成任务
5. 权限回收：任务完成后立即销毁Token

这种设计确保了即使Agent被攻击，攻击者也无法持久化地滥用权限。

---

六、权限设计的检查清单

好的最小权限设计，在code review或Skill审查时应该能回答这几个问题：

权限范围检查

• 这个Skill用到的OAuth Scope里，有没有比必要的更广的权限？
• 读操作和写操作是否用了分离的Scope和Token？

数据访问控制

• 单次执行能访问的数据量是否有上限（防止大规模数据泄露）？
• 是否限制了资源访问的范围（标签、时间窗口、目录等）？

用户授权机制

• 高危操作是否都有用户确认流程？
• 确认流程是否提供了足够的操作预览信息？

权限生命周期管理

• Token是否有过期时间？
• 是否在任务完成后主动销毁权限？

安全监控

• 是否记录了所有权限使用日志？
• 是否有异常权限使用的告警机制？
  

---

七、终极目标：权限与意图的严格对齐

权限设计的终极目标不是让Agent什么都不能做，而是让Agent能做的事情，和用户真正授权它做的事情，严格对齐。

这道缝隙越小，Agent被滥用（无论是被外部攻击还是被自身错误）的空间就越小。

最小权限设计的价值

• 降低攻击面：即使Prompt Injection成功，攻击者能做的也有限
• 限制错误影响：LLM幻觉导致的错误操作被权限边界限制
• 提高可审计性：每个操作都有明确的权限来源和用户授权
• 增强用户信任：用户清楚知道Agent能做什么、不能做什么

在Agent时代，最小权限原则不仅是安全要求，更是用户体验设计的核心组成部分。好的权限设计让用户既感到安全，又不会被繁琐的确认流程困扰。

正如安全专家常说的：“安全不是功能，而是基础”。对于OpenClaw这样的强大Agent，最小权限设计就是它的安全基础。