传统模型系统的错误，通常表现为“答错”。
而 Agent 系统的错误，常常表现为“做错”。
这两种错误的后果完全不同。
回答错一个知识点，也许只是降低体验。 但如果 Agent 错发消息、错触发审批、错写数据库、错执行脚本，后果就会迅速升级。
因此，一旦系统具备动作能力，安全就不再是补丁，而是主设计。
很多团队最初做 Agent 时，还会沿用聊天产品时代的惯性：先把功能做出来，最后再补内容审核、提示词约束和几条黑名单规则。但这套思路一旦遇到具备工具调用、长期状态和跨系统权限的 Agent，就会迅速失效。
因为今天的 Agent，不只是一个“会说话的界面”，而是一个被授予了执行权、读取权、连接权和持续运行权的系统组件。它会读外部网页、邮件、文档、工单和数据库，会调用 API、浏览器、脚本环境和企业工具，会把中间结果写回状态层，还可能把一次决策拆成多步自动执行。到了这个阶段，安全的对象已经变了。
过去人们主要担心的是输出内容是否有害、是否违规、是否幻觉。现在更要担心的是：
- 它会不会在错误上下文里采取正确格式但错误方向的动作
- 它会不会在拥有局部权限时拼出整体越权效果
- 它会不会把外部恶意输入当成内部指令
- 它会不会把一次中间错误写进长期状态并持续传播
- 它会不会把原本只会错一次的问题自动化、批量化和跨系统化
所以，第 26 章第一条要建立的结论是：
Agent 安全的对象，不再只是模型“说了什么”，而是系统“被允许做什么、实际上做了什么、以及出了问题后能否被阻断和追责”。只要这个判断成立，很多过去被看成“工程细节”的东西，就会立刻上升为架构问题。
第一，是动作带来的后果升级。
模型输出一段错误文本，通常还停留在认知层。 但 Agent 调一次付款接口、发送一封错误邮件、修改一次配置、触发一轮错误工单流转，影响就进入了业务层、资金层、权限层和系统层。也正因为如此，安全不再只是“控制回答”，而要控制副作用。
第二，是委托权带来的边界外移。
Agent 真正危险的地方，从来不是它“聪明”，而是它“被代表”。一旦企业把令牌、账号、工具、知识源和工作流入口交给 Agent，它就获得了一种代理执行资格。此时的风险不再是模型本身，而是模型通过工具和凭证获得的代理权。权限范围、作用域切分、最小授权、审批触发条件，都会直接决定风险上限。
第三，是状态持续性带来的时间放大。
普通对话系统出错，往往止于当前轮次；Agent 出错，可能进入 memory、task state、artifact、日志和下游系统，变成下一轮的输入事实。这样一来，安全问题就不再是瞬时错误，而是状态污染问题。一个错误标签、一条恶意摘要、一次被污染的工具返回，都可能在之后很多轮里持续生效。
第四，是外部环境接入带来的攻击面扩张。
Agent 越有用，就越要接触外部世界；而外部世界本身是不可信的。网页正文、PDF、邮件、聊天记录、第三方工具描述、其他 Agent 的消息、远程 MCP server 的元数据，这些内容既是上下文，也是潜在攻击载体。于是，安全问题第一次系统性地从“模型内部对齐”扩展成“输入通道安全、协议安全、工具安全、供应链安全”的组合问题。
第五，是自动化闭环带来的规模化风险。
传统软件的很多错误，之所以可控，是因为人仍然在回路里。Agent 一旦被设计成“读入上下文 -> 规划 -> 调工具 -> 写回状态 -> 继续执行”的闭环，错误就会被自己放大自己。它可能连续重试错误动作，可能在错误前提上继续规划，可能把一个误判扩散到多个系统。于是，安全不再是降低单次失误概率，而是限制错误链的扩散半径。
这也是为什么今天很多官方实践和系统卡会反复把注意力放在同一组机制上：approval、sandbox、least privilege、tool governance、trace、audit、kill switch。它们看起来像若干工程配件，实际上共同回答的是同一个问题：
当 Agent 具备自主执行能力时，系统如何在不完全相信模型的前提下，仍然把它放进可控的制度边界里。这意味着，安全不该只存在于上线前的检查里，而应该内嵌在这些层：
- 动作空间定义
- 权限划分
- 审批流程
- 输入隔离
- 输出结构化
- 状态写入约束
- 运行时沙箱
- 审计与追踪
这里尤其要强调一个经常被低估的问题：为什么说 Agent 安全是“系统问题”，而不是“提示词问题”？
因为提示词最多只能影响模型偏好，不能单独解决权限、身份、网络、状态、审批和追责这些系统边界。你可以在 prompt 里要求模型“不要执行危险操作”，但如果它仍然拿到了高权限 token、未隔离的文件系统、未受控的浏览器和自动通过的执行链路，那么系统的真实安全性依然很低。也就是说，prompt 可以参与防御，但不能替代防御。
因此，第 26 章第二条结论应该是：
只要 Agent 拥有长期状态、外部工具和跨系统权限，安全就已经不是模型附属能力，而是整个架构的第一性约束。理解这句话非常关键，因为它会直接改变设计顺序。
如果把安全当附属问题，团队的顺序通常是：先追求更强能力，再用规则补漏洞。 如果把安全当第一性约束，顺序就会变成：先定义可接受的自治边界，再决定给 Agent 多少能力。
两种顺序的结果完全不同。
前一种顺序会不断把系统推向“能做很多，但不知道何时该停”。 后一种顺序则会逼迫团队先想清楚：
- 哪些动作必须先审批
- 哪些数据绝不能直接外露给模型
- 哪些工具只能在隔离环境内运行
- 哪些状态可以长期保存，哪些只能短暂存在
- 哪些异常一旦发生就必须中止执行并升级到人
一旦这些问题被前置，安全就不再只是阻碍功能上线的成本项，而是定义系统可信边界的骨架。
这也是为什么越接近真实生产环境，Agent 设计越会从“做得出来”转向“能不能放心交给它做”。在高风险场景里，真正被审查的从来不只是模型分数，而是整套系统是否具备明确的权限边界、可恢复的执行控制、可追溯的证据链，以及在出错时及时降级到人的能力。
所以，本章最后要留下的判断不是“Agent 需要更重视安全”这么简单，而是：
Agent 的强大，恰恰意味着安全必须从功能外层移动到系统内核；能力越强，安全越不能后置。这也是为什么 Agent 越往生产场景走，越需要从“功能思维”进入“治理思维”。