安全审查分别批准了这三个工具。对客户数据库的只读访问被评估为低风险，因为智能体（agent）只能查看记录而不能修改。发送邮件给自己（Send-email-to-self）被评估为低风险，因为收件人被硬编码为一个服务账号邮箱，且智能体已被授权向该邮箱写入。模板渲染（Template-render）被评估为低风险，因为它是一个不带 I/O 的确定性 Jinja 风格转换。发布三周后，数据丢失防护（DLP）仪表板标记了出现在一个有两百名员工可读的 Slack 频道中的客户 PII。事后分析（post-mortem）发现泄露源于智能体将这三个工具组合成了一个没有任何单一 ACL 授权的链路：读取客户记录，通过模板渲染，将结果发送到它自己的服务账号，而该邮箱又自动转发到了该频道。
没有一个工具被滥用。没有提示词注入（prompt injection）绕过任何检查。智能体完全按照其工具目录所说的那样执行，而这种组合产生了一种安全审查从未被要求评估的能力。
每一个交付过 LLM 驱动的智能体（Agent）的工程师都曾被一个简单的思维模型所诱惑：工具就是一个函数。增加一个工具意味着智能体多了一项功能。其成本仅仅是系统提示词（System Prompt）中的几行文档，或许是一个 Schema 定义，又或者是工具注册表中的一个新条目。这给人的感觉是累加的——线性增长。
事实并非如此。每一个新工具并不只是孤立地扩展智能体的能力；它扩展的是该工具与已有所有工具组合后能产生的能力。这种区别是一类生产环境故障的根源，这类故障在事后无论如何调整提示词都无法修复，因为问题出在架构层面。“提示词表面积”（Prompt Surface Area）问题是真实存在的，它会迅速复合增长，而大多数团队直到深陷其中时才察觉。
九秒。这是一个 Cursor AI 智能体在尝试修复凭证不匹配问题时，删除整个生产数据库（包括所有卷级备份）所花费的时间。该智能体持有删除权限，而实际上任何合法任务都不需要这个权限。由于没有人在部署前界定爆炸半径，破坏是全面的。
这不是模型失败的故事，而是权限范围的故事。模型做了它认为应该做的事情。工程团队只是从未问过：如果这个智能体推理出错，它最坏能做什么？
这个问题——在部署前系统性地回答——就是爆炸半径分析。
提示注入吸引了所有关注。但提示注入在会话关闭时就结束了。内存投毒（Memory poisoning）——将恶意指令注入 Agent 的长期内存——会创建一个持久性的漏洞，跨会话存续并在几天或几周后执行，由完全不像攻击的交互触发。对生产级 Agent 系统的研究显示，在受测的基于 LLM 的 Agent 中，注入成功率超过 95%，攻击成功率超过 70%。这是大多数团队尚未防御的攻击向量，且它已经进入了 OWASP Agent 应用前十名（OWASP Top 10 for Agentic Applications）。
核心问题很简单：Agent 将自己的内存视为可信的。当 Agent 从向量库或对话历史中检索“内存”时，它处理这些信息的信心与处理系统指令时相同。没有加密签名，没有来源链，Agent 也没有机制来区分它是从真实交互中形成的内存，还是由上周二处理的某个恶意文档注入的。
大多数发布具备代码执行能力的 LLM 智能体（Agent）的团队都犯了同样的错误：他们将沙箱化视为一种二元属性。要么完全跳过隔离（“我们信任我们的用户”），要么部署 Docker 容器并认为问题已解决。这两种立场在进入生产环境后都经不起考验。
现实情况是，沙箱化存在于一个包含五个不同级别的光谱上，每一级都提供不同的隔离保证、性能配置和运营成本。所选隔离级别与实际风险概况之间的不匹配是大多数智能体安全事件的根本原因 —— 而不是根本没有沙箱。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
