关键判断
- prompt injection 本身不是终点，真正的风险来自它能否驱动写入、发送、执行等有副作用的工具。
- 审批弹窗不是安全边界，只是最后一道提示；真正的边界是最小权限、隔离和策略约束。
- 工具描述、资源内容、提示模板都应被视为潜在不可信输入，而不是天然可信的系统部件。
- 读、写、联网能力默认不该被放进同一个高自治会话里。
- 一个成熟的 agent 系统，不仅要拦动作，还要让操作者看清楚“模型想做什么”与“系统实际允许了什么”。
这段时间大家聊 AI 安全时，很容易把问题压缩成一句话：小心 prompt injection。这个提醒当然没错，但如果只停在这里，工程判断反而会失焦。因为 prompt injection 更像一个入口条件，它说明模型可能被误导；真正决定风险上限的，是模型被误导之后，系统到底给了它什么工具、这些工具之间有没有被切开、以及副作用动作有没有被单独约束。
今天最强的信号，不是某一条耸动新闻，而是几条材料反复在说同一件事：当 agent 开始接入文件、Shell、浏览器、内部 API、消息发送和自动化流程后，风险已经不再是“模型说错一句话”，而是“不可信内容能不能驱动有副作用的能力”。如果一个系统默认把读取、写入、联网、执行放进同一个高自治会话里，那 prompt injection 就很容易从语义层问题，升级成真正的系统动作问题。
这也是为什么我越来越不认同“多弹几个确认框就安全了”这种思路。审批当然有价值，但它更像最后一道提示，不是根边界。真正有用的边界，是把能力先切薄：读取工具单独开放，写入工具默认更难触发，网络发送单独受限，执行类能力再额外加一道约束。再往前一步，文件系统和网络本身也应该被隔离。这样即便模型被恶意文档、工具描述或提示模板带偏，它能造成的真实后果仍然被压在一个小范围里。
另一个常被低估的问题是，很多团队会天然相信工具描述和资源文本，仿佛只要它们属于“系统的一部分”，就默认可信。但现实里，工具说明、资源内容、甚至 prompt 模板本身都可能成为注入面。模型不会天然分清“这是系统边界定义”还是“这是外来误导文本”，所以工程上必须先帮它做这个区分。换句话说，不可信输入不该只指用户消息，也包括那些会影响工具选择和参数生成的外围文本。
如果把今天的判断压成一个更实用的最小模型，我会给做 agent 平台的团队五条默认规则：第一，读写联网分离；第二，副作用工具比读取工具更难触发；第三，把工具描述和资源内容当成潜在不可信输入；第四，写入和发送动作要有结果回读，而不是只看“是否同意”；第五，日志里要区分模型想做什么、系统又实际允许了什么。AI agent 的风险从来不只是提示词本身，真正拉开系统安全差距的，始终是工具边界切得够不够干净。