# AI Agent 安全：关键在于控制其"爆炸半径"

- 来源：ginobefun (@hongming731)
- 发布时间：2026-05-28 15:25
- AIHOT 分数：62
- AIHOT 链接：https://aihot.virxact.com/items/cmpp6mnzd0cdeslv4etmsx9fk
- 原文链接：https://x.com/hongming731/status/2059898858881077474

## AI 摘要

Anthropic 在文章中指出，保障日益强大的 AI Agent 安全，不能仅依赖模型自身的防错能力，更需通过设计环境边界来控制其错误发生后的“爆炸半径”。例如，Claude Code 早期因用户疲劳导致93%的权限提示被批准，防线失效；针对通过伪造指令窃取 AWS 凭据的风险，则需依靠文件访问控制、网络出口限制等环境层措施进行硬性阻断。文章强调，授予 Agent 接入 GitHub、Slack 或 MCP 等权限，实质是赋予其一整组能力，必须在架构层面谨慎设计。

## 正文

如果一个 AI Agent 越来越能干，能读文件、跑代码、调工具、连外部服务，产品应该怎么保证它不会闯祸？

Anthropic 这篇文章给了一个很清醒的答案：不要只盯着模型会不会犯错，更要设计清楚它即使犯错，最多能造成多大影响。

这就是文中反复提到的「blast radius」，可以理解为失控半径。Agent 的价值来自更强的能力和更大的权限，但风险也来自这里。模型安全、Prompt 约束、内容审核都有用，但它们都是概率性的。真正兜底的，还是环境层的边界，比如沙箱、虚拟机、文件访问范围、网络出口控制、只读权限、短期 token 和审计日志。

文章里几个案例很有启发。Claude Code 早期依赖用户审批，但用户会疲劳，93% 的权限提示都会被批准。安全如果变成反复弹窗，最后往往只是训练用户点「允许」。另一个案例更典型，攻击者通过一段看似正常的 prompt，让 Claude 读取本地 AWS 凭据并发到外部地址。因为这是用户亲手粘贴的指令，模型层很难判断异常。能真正挡住它的，是文件不可访问、网络不能外发。

还有一个容易忽略的点：白名单不是简单的「允许访问某个域名」，而是在授予这个域名背后一整组能力。允许访问 http://api.anthropic.com，就可能允许上传文件到某个账号。允许接入 GitHub、Notion、Slack、MCP，也不只是接入一个工具，而是接入一组读、写、上传、分享、删除的能力。