Agent权限策略为何必须禁止自身修改

能改自己权限配置的 AI Agent，权限边界就可能形同虚设。这篇文章讨论的不是怎样把安全提示词写得更严，而是怎样让 Agent 只能读取授权，不能替操作者创造授权。

作者提出三种可以组合的设计：操作者签名的权限范围、会话级授权凭据、只暴露引用的密钥句柄。它们面向会接触真实凭证、同时拥有文件和 shell 工具的 Agent。对正在接入内部环境或开发凭证的团队，最值得检查的问题是：授权配置究竟掌握在谁手里？

配置文件为什么撑不起权限边界

不少框架会规定「凭证只能发送到指定主机」「不能把密钥拼进 shell 命令」。但规则往往保存在 settings、环境变量或项目配置里，而 Agent 恰好也能修改这些地方。

此时，恶意网页、被污染的 README、恶意依赖不必直接突破校验。它们只要诱导 Agent 把攻击者的主机加入允许列表，后续操作就可能看起来完全合规。

授权声明的可信度，取决于 Agent 能否改写它。

作者的威胁模型有明确前提：Agent 拥有文件和 shell 工具，会处理不可信内容；攻击者控制网页、issue 评论或依赖行为等输入，希望窃取凭证或触发特权操作。防守方还要保留正常流程，例如连接 staging、输入开发凭证。

因此，问题不是取消灵活性，而是让外部内容无法获得与操作者相同的授权能力。

稳定环境靠签名，临时需求靠短授权

第一种设计是由操作者签署权限范围，例如允许向 staging.internal、*.corp.example 提交凭证。Agent 和工具可以读取、验证这份声明，但无法生成新的有效声明。

这里有两个关键条件。

一是签名密钥必须位于 Agent 的文件与 shell 能力之外。作者列举了硬件支持的密钥存储、CI secret、操作者的密码管理器；这些位置是否安全，仍取决于 Agent 实际能否访问。把密钥放进它能读取的文件，整个方案就退回了可改配置。

二是签名要覆盖完整范围，而非单独覆盖每个条目。这样，增加一个主机也会让原签名失效。

这种方式适合已知主机、已知集群等稳定设施。代价是调整不够灵活，撤销也需要新的签名。作者建议有效期按天计算，而非按月，让到期失效承担常见的权限回收工作。

第二种设计处理临时需求：操作者只为当前会话授权，并生成一份结构化凭据。授权内容包含 {principal, capability, scope, expiry, nonce}：谁批准、允许什么操作、作用范围、何时失效，以及防止跨会话重放的随机标识。

其中，capability 应当窄到 enter-credential，而非 do-anything；有效期控制在几分钟到几小时。

授权记录只能追加，Agent 可以读取，不能改写历史，也不能自行签发。作者提出用哈希链连接记录，并可定期签署链头，向外部锚定。每条记录承诺前一条记录的内容，便于发现篡改或顺序变化。

交互式开发更适合这种方式：开发者每天早上批准一次 staging 主机，授权有明确期限，页面里的注入指令无法自行延长它。

密钥不进入上下文，还要限制它能被用到哪里

第三种设计是让操作者在会话开始时直接输入一次密钥，此后 Agent 只接触句柄，也就是密钥的引用。

例如，Agent 上下文中出现的是 DB_PASSWORD_REF=vault://ci/db-password，而非 DB_PASSWORD=hunter2。工具需要凭证时，由工具服务端解析引用、取得真实值。

关键是解析发生在哪里。如果 Agent 的 shell 展开引用后，把真实密钥送回上下文，这层隔离就失效了。工具后端也不能把解析结果写进日志，否则只是换了一个泄露出口。

句柄还必须绑定有效授权。作者用一个很直观的分工解释两者：句柄标识「用什么」，授权限定「何时、向哪里使用」。没有匹配授权的句柄，应当无法触发密钥使用。

三种设计组合后，签名范围定义稳定环境，会话授权处理临时变化，句柄负责隔离密钥内容。每次特权操作执行前，都要检查这些条件；检查不通过或无法确认，就拒绝执行，也就是 fail-closed。

作者还希望允许与拒绝都形成可签名、可检查的记录。排查「为什么 Agent 拒绝输入密码」时，团队可以直接查看授权证据。

我的判断

我认同文章把焦点放在「谁能写授权」上。对于能操作文件和 shell 的 Agent，仅靠提示词或同权限下的配置，很难承担真正的隔离职责。签名提供了一种验证授权来源的办法。

但这是一篇设计分析，没有提供实现代码、攻击测试结果或对照数据。三种方案的效果、接入成本与使用体验，目前都不能当作实测结论。

哈希链尤其需要补一个条件：能检测篡改，不等于能阻止 Agent 伪造授权。 如果 Agent 能重建整条链，单靠哈希关系无法证明记录来自操作者；如果没有可信的最新链头，也不能仅凭一段自洽的链判断尾部是否被截掉。独立进程、写入权限和外部签名锚点，才让这些记录具备可信来源。

原文也没有说清会话授权如何与稳定范围组合：临时授权能扩展哪些权限、冲突时谁优先，都需要实现时补齐。

句柄同样不是完整防线。Agent 即使读不到密钥，仍可能诱导工具拿密钥执行错误操作，所以接收方与操作范围的校验不能省。

作者列出的失败路径也很实际：操作者密钥失窃、授权检查与使用之间发生变化，即 TOCTOU，以及工具日志泄露解析结果。相比单纯维护允许列表，这套设计能留下更明确的授权证据；但它没有消除权限系统的工程难题，而是要求团队把执行边界做扎实。

能拿来做什么

• 给 AI 编程工具接入 staging 前，先检查允许列表、环境配置和签名密钥是否都在 Agent 可读写范围内，优先移走决定授权的那部分能力。
• 为需要临时输入凭证的调试流程设计会话授权，明确接收主机、具体操作和到期时间，用短授权减少反复关闭安全限制的需求。
• 在 Node 工具服务中解析密钥引用，让 Agent 只传句柄，并检查工具输出、异常信息和日志是否会带回真实密钥。
• 排查授权问题时同时保留批准与拒绝记录，并核对实际执行时使用的授权，避免只检查一份已经过时的缓存。