高权限 Agent 如何限制事故波及范围

给 AI Agent 配上 root、云账号和一整套工具，效率可能上去了，误操作和提示注入的影响范围也跟着扩大。原文的核心主张是：先设计 Agent 出问题后最多能破坏什么，再讨论它能自主完成多少任务。

作者把防线拆成身份权限、沙箱、工具审批和运行监控。对正在接入 AI 编程或自动化运维的团队，这篇短文最有用的提醒是：模型是否听话，不能成为系统安全的最后保障。

为什么不能指望模型识破恶意指令

原文引用了一项覆盖 33,000 条 Agent 执行轨迹的审计：多数未成功的注入攻击，是被模型忽略了，而非被明确拒绝。两者有区别：一次没有执行恶意指令，不等于建立了稳定的拒绝规则。

另一组结果更直接：模型权重相同，只替换 system prompt，攻击成功率就从 0.2% 变成了 43%。作者借此强调，提示词能影响行为，但不适合独自承担安全边界。

安全措施要在模型决定调用工具之后，仍然能够阻止危险操作。

不过，这些数字是作者引用的审计结果，并非文中展示的团队实测。所给原文没有交代模型、任务分布、攻击样本和评估方法，不能直接拿来估算自己项目的中招概率。

独立身份和沙箱，分别限制什么

作者首先要求 Agent 使用自己的身份，避免复用人的账号，也不要长期持有管理员角色。这样，即使 Agent 被控制，攻击者拿到的也只是这个任务被允许使用的权限。

在 AWS 场景中，原文建议使用任务范围内的 IAM role，配合 15–30 分钟的 STS 临时凭证；反面例子是在 CI 中放一个拥有 AdministratorAccess、持续 12 小时且无人监控的会话。

短期凭证缩短可利用时间，任务权限限制可执行动作，两者解决的问题不同。

沙箱则负责约束执行环境。原文列出 microVM、gVisor container 和一次性环境，要求根据代码的不可信程度选择隔离边界，把可写文件系统限制在一个工作区，并为出站网络设置白名单。

但沙箱内部依然有工作文件、凭证，以及被允许访问的目标。Agent 即使没有逃出沙箱，也可能把工作区里的内容发往允许访问的地址。

因此，不能把「放进容器」当成完成了安全设计。隔离限制它能接触什么，权限限制它接触之后能做什么。

审批和停止按钮，要真正管住工具

工具决定 Agent 能把哪些想法变成行动。不需要发邮件，就不提供邮件工具；剩下的工具，也要按后果决定是否审批。

原文建议把审批集中在不可逆操作、对外操作、资金支出和批量变更上。每一步都弹确认，容易让人机械放行；完全不设审批，又可能让外部内容直接驱动危险动作。

作者列出了 LangGraph 的 interrupt、HumanInTheLoopMiddleware 和 OpenAI Agents SDK 的 approval flow。关键要求是：审批必须发生在调用之前，绑定明确动作，并设置有效期。一次批准不该变成后续操作的通行证。

原文还提到一个 Semantic Kernel 案例：间接提示注入把攻击脚本写进了 Windows Startup 文件夹。但没有提供复现过程，无法进一步判断具体失守条件。

运行期间，则要记录每次模型调用、工具调用和决策，对新网络目标、批量删除、凭证访问设置告警。

真正的停止按钮必须撤销会话及其凭证。

只给 Agent 发一句「停止」，仍然是在依赖它服从指令，无法保证已有凭证随之失效。

我的判断

这套思路成立的地方，是把安全责任分给模型之外的执行机制。相比只补一段 system prompt，独立身份、权限校验和调用前审批，更容易形成可检查的边界。

但具体配置仍是经验建议。原文没有证明 15–30 分钟适合所有任务，也没有提供 microVM 与 gVisor 的隔离成本、兼容性或性能对照。长任务如何续期、审批如何避免动作被替换、凭证如何立即撤销，都没说清。

文末提到了 CamoLeak、ForcedLeak，以及完整文章里的沙箱比较和审批代码，但当前材料没有展开。不能仅凭案例名称，就替作者补出攻击原理或认定方案已经验证有效。

对一般团队，最值得照搬的是分层约束的原则；具体技术选型，需要结合现有身份系统、任务时长和工具能力决定。

能拿来做什么

• 给 AI 编程任务单独配置身份和凭证，先列清它需要读写的仓库、目录和云资源，再授予对应权限。
• 让执行 Node 脚本或项目代码的 Agent 只写指定工作区，并检查出站白名单是否仍允许它传走敏感内容。
• 对删除资源、批量修改和对外发送等工具调用设置执行前审批，让审批内容包含明确目标和参数，并限制有效期。
• 把停止能力做进运行平台，验证停止后会话和凭证确实失效，同时保留模型及工具调用记录供排查。