Openclaw 一旦拥有邮件、日历读写权限，如何做最小权限设计？

精炼回答

最小权限原则（Principle of Least Privilege）在 Agent 上下文里的含义是：Agent 在任何时刻拥有的权限，不应超过完成当前任务所必需的最小集合。 这不只是安全最佳实践，也是工程设计的基本纪律------权限越少，Agent 做错事的影响范围越小，无论错误来自 Prompt Injection、LLM 幻觉，还是 Skill 的 bug。

对于 OpenClaw 这类拥有邮件和日历读写权限的 Agent，最小权限设计需要在三个维度上同时发力：范围（Scope）------能访问哪些资源 、操作（Operation）------能做什么动作 、时机（Time）------什么时候才能做。把这三个维度结合起来，才能构建真正有约束力的权限模型，而不只是在文档里写"请小心使用"。

扩展分析

当前 OpenClaw 的权限现状

OpenClaw 的权限粒度目前主要在 Skill 层面控制------一个 Skill 的 SKILL.md 说明书里会声明它需要哪些 Tool（exec、web_fetch、browser 等），以及需要哪些外部服务的 API Key。但这个控制是静态的、粗粒度的：一旦 Gmail Skill 被激活，它在整个 Session 里对用户邮箱的访问权限没有进一步的约束。

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

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

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

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

javascript 复制代码

// ❌ 错误做法：申请全量邮件权限
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：

arduino 复制代码

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

维度二：资源范围约束

即使在同一类操作内，也应该限制能访问的资源范围。

邮件：标签过滤而非全量访问

javascript 复制代码

// 只允许 Agent 读取 INBOX 中被标记为 IMPORTANT 或 UNREAD 的邮件
// 而不是能搜索整个邮箱历史
async function fetchAgentAccessibleEmails(gmail) {
  return gmail.users.messages.list({
    userId: 'me',
    labelIds: ['INBOX', 'UNREAD'],  // 明确限定标签范围
    maxResults: 20,                 // 限制单次获取数量
    // 不传 q 参数：禁止全文搜索，防止注入攻击用搜索泄露历史数据
  });
}

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

javascript 复制代码

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，只在需要执行某个具体任务时，向用户申请一次性授权，任务完成后权限立即销毁。

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

javascript 复制代码

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 },
};

权限设计的检查清单

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

这个 Skill 用到的 OAuth Scope 里，有没有比必要的更广的权限？读操作和写操作是否用了分离的 Scope 和 Token？单次执行能访问的数据量是否有上限（防止大规模数据泄露）？高危操作是否都有用户确认流程？Token 是否有过期时间，是否在任务完成后主动销毁？

权限设计的终极目标不是让 Openclaw 什么都不能做，而是让 Openclaw 能做的事情，和用户真正授权它做的事情，严格对齐。 这道缝隙越小，Openclaw 被滥用（无论是被外部攻击还是被自身错误）的空间就越小。