精炼回答
最小权限原则（Principle of Least Privilege，简称 PoLP）放在 Agent 的语境中，核心要义其实很简单：Agent 在任何时刻所拥有的权限，都不应超过完成当前任务所需的最小集合。这不仅仅是安全领域的经典准则，更是工程设计中一条必须严格遵守的纪律——权限越少，即使 Agent 因 Prompt Injection、LLM 幻觉或 Skill 自身的 Bug 而出错，其可能造成的危害范围也会越小。
以 OpenClaw 这种能够读写邮件和日历的 Agent 为例，要实现最小权限设计，必须从三个维度同步推进：范围（可访问哪些资源）、操作（可执行哪些动作）、时机（在什么情况下才能执行）。只有将这三个维度紧密整合，才能构建出真正具有约束力的权限模型，而不只是停留在文档中写一句“请谨慎使用”。
扩展分析
当前 OpenClaw 的权限现状
目前 OpenClaw 的权限粒度基本停留在 Skill 层面——一个 Skill 的 SKILL.md 会声明它需要哪些 Tool（如 exec、web_fetch、browser 等）以及哪些外部服务的 API Key。但这种控制是静态且粗粒度的：一旦 Gmail Skill 被激活，在整个 Session 生命周期内，它对用户邮箱的访问权限就再也没有进一步的约束了。
这意味着什么？当用户说“帮我读一下今天的重要邮件”时，Agent 理论上就获得了读取所有邮件甚至发送邮件的权限——而用户最初只想要一个“读取”功能。
维度一：操作权限分离（读 vs 写）
最基础的一步是彻底分离读操作与写操作。默认仅授予读权限，写权限必须显式声明或经过用户确认。
对应到 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
维度二：资源范围约束
即使在同类操作内部，也必须限制可访问的资源范围。
邮件：使用标签过滤而非全量访问
// 只允许 Agent 读取 INBOX 中标记为 IMPORTANT 或 UNREAD 的邮件
// 避免 Agent 能够搜索整个邮箱历史，降低数据泄露风险
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 },
};
权限设计的检查清单
一个好的最小权限设计，在 Code Review 或 Skill 审查时，应能明确回答以下几个关键问题：
- 该 Skill 使用的 OAuth Scope 中，是否存在超出实际必要范围的权限？
- 读操作与写操作是否使用了彼此独立的 Scope 和 Token？
- 单次执行可访问的数据量是否有明确上限（防止大规模数据泄露）？
- 所有高危操作是否都配备了用户确认流程？
- Token 是否设置了过期时间，并在任务完成后主动销毁？
权限设计的终极目标，并非让 OpenClaw 什么都不能做，而是让 OpenClaw 实际能做的事情，与用户真正授权它做的事情严格对齐。这道缝隙越小，OpenClaw 被滥用（无论是因外部攻击还是自身错误）的空间就越小。
