跳到主要内容

最小权限 — 别给执行者多余的一寸

这一章讲三件事: 最小权限原则的确切含义与它的microservices(微服务)学费; 为什么换成一个概率性的执行者(agent)之后,这条原则要收得更紧; 以及供应链攻击的最新变体——攻击者抢注模型幻觉(一本正经地编造不存在的东西)出来的依赖名。 读完你能回答:给 agent 权限的「刚好够用」怎么划?

1. 这一章讲什么​

02 章讲了「权限要显式验证」,这一章讲权限的总量该是多少。 答案是老原则:每个部件只拿完成任务所需的最小权限,一寸不多给。

原书这一节有个特殊地位:它是「传统理论」里第一个直接拿 AI 系统当主角来讲的—— 作者明说,这条原则对 LLM 的工具调用(agent 去操作外部能力——查库、发邮件——的每个动作)比对微服务架构还要紧1。 为什么「还要紧」,是本章的核心问题。

2. 顶层全景​

  权限给多了会发生什么(三条传导路径):

  权限超出任务所需
        │
        ├─→ 攻击面变大:多一寸权限,就多一寸可以被注入操纵后调用的能力
        ├─→ 错误谱变宽:一次普通失误,能捅出的娄子种类变多
        └─→ 提权链条变长:拿到低处权限的攻击者,能借多余权限步步往上爬

  图说:三条路径的共同点——多余权限平时看起来没有代价,
  出事的那一刻才一起兑现。这就是「爆炸半径」:一次事故能炸到的范围。

3. 核心原理​

3.1 原则本体与微服务的学费​

最小权限原则(the Principle of Least Privilege,行业缩写 POLP):系统里每个部件, 只给它完成任务必需的权限,不给更多2。

这条原则的学费,微服务架构(把一个大系统拆成一堆小服务、各管一摊的架构) 已经交过一轮:不搞 POLP 的微服务系统,攻击面(系统能被攻击的所有入口的总和)更大, 错误的种类更多,提权(攻击者从低权限爬到高权限)的路径也更通畅3。 作者引了一篇业界博客的观察:微服务世界里出现的新漏洞和 0-day (披露时连厂商都还没修复的漏洞)里,相当一部分本可以通过防御纵深、 失败安全、最小权限这些老原则把影响压住4。

这带出本节最实用的一句话:新的、未知的漏洞一定会出现—— 你挡不住它出现,但好工程能决定它出现时炸多大规模(爆炸半径)5。 最小权限就是控制爆炸半径的第一旋钮。

3.2 为什么对 LLM 执行者要更紧​

书里给的理由是一条链,链上每一环都是前面章节讲过的性质1:

  LLM 输出是概率性的(第 06 章展开)
      → 连正常执行都不可预测,还包括幻觉(一本正经地编造不存在的东西)
          → 还容易被语境操纵和注入(第 02 章的走查已经穿过一次)
              → 所以:同一个多余权限,交给确定性代码是「可能被滥用」,
                 交给 agent 是「可能被滥用 + 可能被误用 + 可能被操纵后使用」

传统程序的权限给多了,出事的前提是有人写错了代码或者有攻击者打进来; agent 的权限给多了,出事还可以没有任何人做错任何事——模型自己走偏就够了。 这是「还要紧」三个字的全部含义。

3.3 行业的学费单​

这不是理论担忧。书里列的已发生案例:研究者发现 agent 因为权限过大把用户 邮箱全部删光;还有 agent 把生产环境(线上正在服务的系统)搞挂6。 作者的原话是:这些明确属于 agent 不该有的权限——至少也该被限速、被严格管控6。

行业的回应是一批限制工具与 agent 权限的研究与框架,书里点了名:MiniScope、 AgentScope、NanoClaw——方向一致:把 agent 能动的范围框起来7。

3.4 供应链的新变体:slopsquatting​

原书这一节后半转到供应链攻击(不打你的系统本身,打你的系统依赖的东西—— 库、包、工具)。2026 年针对依赖安装的攻击在增多,其中长出了一个前所未见的新变体8:

  老把戏:typosquatting(抢注打错的名字)
    开发者手滑把 requests 敲成 reqeusts → 攻击者提前注册了 reqeusts
    → 包管理器乖乖装上了恶意包。

  新变体:slopsquatting(抢注幻觉出来的名字)
    ① 开发者让 AI 生成代码,AI 幻觉出一个不存在的依赖名(比如为演示编的 fastjsonx)
    ② 开发者没核过,直接照装 → 安装失败
    ③ 攻击者批量收集 AI 常 hallucinate 的包名,提前注册
    ④ 下一次有人照 AI 的建议装 fastjsonx → 装到攻击者的恶意包
       (fastjsonx 这个名字是为演示编的)

  差别:老把戏赌你打错字,新把戏赌模型编错名——错误率反而更高,因为幻觉是概率性的。

作者把这类纯 AI 生成的代码叫 slopcode(「泔水代码」),slopsquatting 就是 typosquatting + slop 的合成词9。

对策没有新东西,还是供应链的老三样,而且书里强调「比以往任何时候都更需要」10: 审软件物料清单(SBOM,software bill of materials——你的系统到底用了哪些依赖 的一张清单);用自动扫描器盯依赖更新与已知漏洞;对代码库跑已知弱点检查。 最后一句值得原文照录其意:AI 编码助手嵌进开发流程越深,它的错误就越是攻击面的一部分10。

3.5 主走查:给邮件 agent 逐项开权限​

拿一个具体需求走一遍:「让 agent 每天读收件箱,把重要邮件整理成摘要发给我」。 权限从零开始,逐项开(每一项的后果分析是我们的工程推演,事件背景来自书里案例):

  需求拆解:读邮件 → 判断重要性 → 写摘要 → 发出

  最小权限集(第 1 轮):
    ① 读取收件箱(只读)      —— 够读
    ② 调用一个「发摘要」接口  —— 够发,且只能发到一个写死的地址

  对照书里的反面案例:agent 删光邮件[^6]
    → 最小集里根本不存在「删除」这个动作。删不掉,这类事故在结构上不可能发生。

  第 2 轮:用户嫌不够,想让它「顺手归档已处理的邮件」
    ③ 增加:移动邮件(可逆操作,损失有限)—— 可以给,但注意:
       「移动到已删除」和「移动到归档」是同一个接口权限,给的时候要清楚这一寸宽在哪。

  第 3 轮:用户想让它「直接回复报价邮件」
    ④ 增加:对外发送任意邮件 —— 这是质变:② 只能发到一个写死地址,
       ④ 是对外任意发。外发通道一旦有了,它同时是「数据外泄通道」
       (第 12 章的致命三件套会回来收这笔账)。给之前必须配:
       发送前的 preview-and-confirm(人先看一眼再放行),或者至少限速 + 收件人白名单。

  结论:从 ①② 到 ④,权限面宽了三倍,风险不是线性涨——
  ④ 是台阶式跳变。开权限这件事的功夫全在「认出台阶」上。

4. 作者的判断与证据​

  • 有证据的:agent 删邮件、打挂生产是书里引述的行业已发生事件6; slopsquatting 是书里明确命名的新攻击类别9;
  • 作者的判断:POLP「对 LLM 工具比对微服务更紧」——这条推理(从前提走到结论的过程)成立,但「更紧」到什么 程度没有量化标准,属经验判断1;
  • MiniScope / AgentScope / NanoClaw 书里只点了名,没有展开任何一个的机制7。

5. 边界与局限​

  • 「最小」怎么算,书里没给操作规程:实践中「任务所需」的边界本身就是威胁建模 (第 11 章)的产出,不是拍脑袋;
  • 书里没有讨论权限的时效:要不要过期、要不要按会话收敛——这些是真实系统里 必答的题;
  • slopsquatting 的规模数据(多少包名被抢注)书里没给;
  • 0-day、SBOM 这些词书里默认读者认识,我们在此处已就地补讲。

6. 可带走的​

  1. 每个部件只拿完成任务所需的最小权限——这条对 agent 比对微服务更紧;
  2. 理由是三连:概率性输出、连正常执行都不确定、易被注入操纵;
  3. 多余权限的代价平时看不见,出事那一刻兑现(攻击面/错误谱/提权三条路径);
  4. 新漏洞一定会出现;工程的目标是缩小爆炸半径,不是消灭漏洞;
  5. 「删除」「外发」这类不可逆、出边界的权限是台阶,给之前要配人工确认或白名单;
  6. slopsquatting:AI 幻觉的依赖名会被抢注——照 AI 的建议装包之前,先核这个名字真的存在且是官方的;
  7. SBOM + 自动扫描 + 弱点检查,供应链老三样在 AI 时代只增不减;
  8. AI 助手的错误本身就是攻击面的一部分。

7. 原文地图​

主题原书章原文位置
POLP 的 CrowdStrike 定义Principle of Least Privilegetext/09-fm-principle-of-least-privilege.txt:3(搜「CrowdStrike」)
原则本体:最小权限、不多给Principle of Least Privilegetext/09-fm-principle-of-least-privilege.txt:7(搜「minimum permissions necessary」)
微服务:攻击面/错误谱/提权Principle of Least Privilegetext/09-fm-principle-of-least-privilege.txt:9(搜「privilege escalation」)
业界博客、老原则压影响Principle of Least Privilegetext/09-fm-principle-of-least-privilege.txt:11(搜「failing securely」)
爆炸半径、新漏洞一定出现Principle of Least Privilegetext/09-fm-principle-of-least-privilege.txt:13(搜「blast radius」)
对 LLM 工具更紧 + 三条性质Principle of Least Privilegetext/09-fm-principle-of-least-privilege.txt:15(搜「LLM tool use」)
删邮件、打挂生产、限速管控Principle of Least Privilegetext/09-fm-principle-of-least-privilege.txt:23(搜「delete all their emails」)
MiniScope/AgentScope/NanoClawPrinciple of Least Privilegetext/09-fm-principle-of-least-privilege.txt:25(搜「MiniScope」)
2026 供应链攻击增多Principle of Least Privilegetext/09-fm-principle-of-least-privilege.txt:29(搜「dependency installations」)
slopsquatting 命名与机制Principle of Least Privilegetext/09-fm-principle-of-least-privilege.txt:31(搜「Slopsquatting」)
SBOM、自动扫描、AI 错误即攻击面Principle of Least Privilegetext/09-fm-principle-of-least-privilege.txt:33(搜「software bill of materials」)

Footnotes​

  1. 出处:「Principle of Least Privilege」第 15 段(text/09-fm-principle-of-least-privilege.txt:15,搜「LLM tool use」)。原文明确:这条对 LLM 工具调用比对微服务架构更适用;随后列出三条性质(概率性、不可预测含幻觉、易受语境操纵与独有注入类)。 ↩ ↩2 ↩3

  2. 出处:「Principle of Least Privilege」第 3 段(text/09-fm-principle-of-least-privilege.txt:3,搜「CrowdStrike」)与第 7 段(text/09-fm-principle-of-least-privilege.txt:7,搜「minimum permissions necessary」)。CrowdStrike 定义:只给完成任务必需的访问权;作者提炼:每个部件拿最小必要权限,一寸不多。 ↩

  3. 出处:「Principle of Least Privilege」第 9 段(text/09-fm-principle-of-least-privilege.txt:9,搜「privilege escalation」)。不搞 PoLP 的微服务:攻击面增大、错误谱变宽、提权被助长。 ↩

  4. 出处:「Principle of Least Privilege」第 11 段(text/09-fm-principle-of-least-privilege.txt:11,搜「failing securely」)。Shahzad Bhatti 的博客文章盘点微服务常见漏洞与近期 0-day;其中最佳实践与本节原则重叠(纵深防御、失败安全、最小权限)。 ↩

  5. 出处:「Principle of Least Privilege」第 13 段(text/09-fm-principle-of-least-privilege.txt:13,搜「blast radius」)。原文:新而未知的漏洞会随时间出现;好工程仍能通过影响范围(爆炸半径)压低事故代价。 ↩

  6. 出处:「Principle of Least Privilege」第 23 段(text/09-fm-principle-of-least-privilege.txt:23,搜「delete all their emails」)。研究者遭遇过 agent 因权限过大删光其全部邮件;agent 也有打挂生产环境的案例;这类权限至少应限速并严控。 ↩ ↩2 ↩3

  7. 出处:「Principle of Least Privilege」第 25 段(text/09-fm-principle-of-least-privilege.txt:25,搜「MiniScope」)。业界注意到工具与 agent 权限的棘轮式上涨,开始建框架限制:MiniScope、AgentScope、NanoClaw。 ↩ ↩2

  8. 出处:「Principle of Least Privilege」第 29 段(text/09-fm-principle-of-least-privilege.txt:29,搜「dependency installations」)。2026 年针对依赖安装与软件供应链的攻击增多,多起为针对大型软件仓库维护者的定向攻击。 ↩

  9. 出处:「Principle of Least Privilege」第 31 段(text/09-fm-principle-of-least-privilege.txt:31,搜「Slopsquatting」)。模型幻觉依赖名的兴起,催生了针对「AI 幻觉出的软件」的 typosquatting,被命名为 slopsquatting;传统 typosquatting 赌开发者打错字,新变体武器化幻觉依赖;slopcode 是对纯 AI 生成代码的谑称。 ↩ ↩2

  10. 出处:「Principle of Least Privilege」第 33 段(text/09-fm-principle-of-least-privilege.txt:33,搜「software bill of materials」)。审 SBOM(依赖与 API 调用)仍是关键步骤;自动扫描器更新包、盯新漏洞、查已知弱点;AI 编码助手嵌得越深,其错误越是攻击面的一部分。 ↩ ↩2