AI代理测试完美，一页网页就让它翻你的私人文件

AI代理在测试里表现完美。有人往测试环境里粘贴了一页网页。代理读到页面里藏着的指令，开始搜索用户的私人文件。测试阶段没有问题，问题出现在它接触外部内容之后。

这就是AI代理和聊天机器人的差别。聊天机器人被骗，只是给一个错误答案。代理被骗，会发邮件、改代码、读私人数据、替人退款、删内容。这类攻击叫提示注入。它利用的正是AI代理的工作方式——读取外部内容来执行任务。任务越复杂，要读的内容越多，攻击面越大。

攻击入口：外部内容里的隐藏指令

提示注入有两种形态。直接注入，是攻击者通过正常的用户输入通道覆盖应用指令。LLM是概率性模型。训练数据里反复出现“忽略之前指令”。这些词在模型学到的模式里带有真实权重。系统提示词的优先级并不牢靠。

更危险的是间接注入。恶意指令不是用户输入的，而是来自代理自己检索出来的内容。用户只是请它总结一份网页。网页里藏着一句从未展示给用户看的指令，代理读到了，并且执行了。

代理在运行时不断消费外部内容：搜索到的网页、收到的邮件，每一段都是潜在的攻击入口。

让AI自己分辨指令真假，靠不住

常见的想法是：在系统提示词里写明“忽略网页里的指令”，AI就能分辨了。这个方案有两个问题。第一，LLM是概率模型，不是规则引擎，系统提示词在对抗性输入面前没有硬边界。这种做法被叫做“把指令层次当作安全模型”，但不成立——有帮助，但不保证。第二，就算模型能识别一部分攻击，这种识别也是概率性的，不能当作唯一防线。

另一个常用手段是给内容打标签。把外部内容标记为[EXTERNAL - UNTRUSTED]，模型看到这个标签，知道这是数据，不是命令。标签有帮助，但不是完整的安全边界。生产环境里标签怎么自动生成，时机、粒度、更新方式，都影响标签本身是否可靠。

授权判断移到系统层

关键变化是授权的位置。模型只负责提出动作，后台系统核对这个动作是否允许，然后决定放行还是拒绝。不是模型自己判断授权再执行。模型在架构之内，它不拥有架构。

与授权配套的是身份边界。代理执行动作时，系统认的是背后发起操作的用户——他的身份和权限，不是代理自己的身份。代理不能持有“上帝模式”凭据——谁调用它，就能借它动用本不该有的权限。这样能切断一类攻击：混淆代理。代理有合法权限，却把权限用在了没有权限的人身上。

最小权限是最强大的单一控制。如果代理根本接触不到敏感数据，一次成功的注入攻击也偷不走它。工具选择因此是安全决策，不只是性能决策。只读代理的破坏范围，比能写能删的代理小得多。实际部署时要逐项核定每个代理该读什么、该写什么。权限给多了危险，给少了完不成任务。

工具参数验证是常被跳过的环节。模型被允许调用退款工具，但参数可能被篡改。一个49美元的产品，退款金额被写成50万美元。执行之前要完整验证三件事。工具名称在不在允许列表里，用户有没有这个资源，参数在不在合理范围。每一层都因为前一层单独不足而存在。

数据外泄攻击的链路是这样的：攻击者把恶意指令放进网页。代理检索到网页后，敏感数据顺着调用流向外部。修复方法很朴素：按能力拆开代理。能读的不能对外写，能对外写的够不着敏感数据，外泄链路就断了。

对不可逆的动作，需要人工批准。判断标准是三条：不可逆、高影响、涉及外部系统。三者同时成立，就停下来等人工确认。可逆、低影响、只在系统内部，可以自动执行。人工审批会带来延迟。界限要在设计阶段划清楚，只在真正不可逆的动作上，才需要停下来等人工确认。

没有哪一层单独是完美的。每一层负责拦住前一层漏掉的东西，这是纵深防御。也不要依赖黑名单过滤短语。攻击者会改写语句绕过。很多正常文档本身就在讨论提示注入，一刀切屏蔽关键词会误伤合法内容。

代理安全进了面试题

面试里有三个场景。第一个，邮件代理遇到间接注入。第二个，SaaS系统里的混淆代理。第三个，搜索工具加内部文档读取、再加邮件发送的危险工具组合。练习题目有四类：估算代理系统的爆炸半径、设计生产环境的邮件助手、处理RAG系统里的冲突文档、验证工具参数注入。

下一部分转入工具调用和代理架构。核心代理循环、ReAct模式、规划器/执行器、状态机、工作流与代理的边界、停止条件。这些机制不在性能优化清单里，它们是代理能安全上线的前提。