安全讨论的重心，正在从模型移到运行时
企业安全团队对智能体的态度，在 2026 年出现了明显转折。前两年，讨论多集中在「该不该允许员工用某个大模型」；而现在，随着智能体被直接接上文件系统、API、邮箱与数据库，问题变成了另一个：这些系统会自己规划、自己调用工具、自己记住东西，而它们的行为并不像传统软件那样确定。
一份名为《State of Agentic AI Security 2026》的报告把这种转变落到了数字上。报告的判断是：企业安全的主流方法把「应用安全」的思路套在了智能体上，而这些系统的行为方式并不像应用。应用安全的前提是「你审查、测试、部署的代码，就是运行时的代码」，修好代码就修好了风险；但智能体可以在运行时被一份它自己检索到的文档、一封邮件或一次 API 返回的内容改变行为，这些风险不在代码里，而在运行路径上。
先说明边界：这是一份由安全厂商发布的年度报告，其商业利益与「智能体需要专门安全产品」这一结论方向一致；报告中的部分数字引自其他机构的研究，口径并不完全统一，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。因此下文在引用数字时会同时标注来源，供读者自行判断权重。
四个数字，以及它们的口径
报告被引用最多的是 48%：在企业生产环境中运行的智能体里，有 48% 处于缺少「有效安全控制」的状态。这个口径值得留意——它统计的不是「没有安全政策的公司占比」，而是「实际在跑、在处理真实数据、在调用真实 API 的智能体个体占比」。报告作者特意强调这一区别，因为前者容易被解读成一个管理问题，后者则直接指向暴露面。
另外三组数字来自报告引用的其他研究，口径各不相同：88% 的企业表示，在部署智能体之后至少经历过一次已确认或疑似相关的安全事件；34% 的已部署企业智能体受到过提示注入类攻击的影响；单次与智能体相关的数据泄露，平均成本约 470 万美元。第三组数字的原始出处是通用数据泄露成本研究，属于整体口径向智能体场景的迁移估算，把它当作精确值并不合适，更合理的用法是理解量级。
报告还给出了一组时间维度的对照：2025 年 12 月到 2026 年 4 月之间，企业环境中的智能体数量翻了一倍，而监控覆盖率基本持平，维持在约 52% 左右。这组对照解释了为什么 48% 这个比例会显得刺眼——部署在加速，可见性却没有同步扩张，缺口自然变大。
四类基础威胁，都不在代码里
报告从十个威胁类别中挑出四类作为基础，它们的共同点是都发生在运行时。
提示注入及其变体排在前面。攻击者把对抗性指令嵌入文档、邮件或 API 响应中，试图改变智能体的行为。其中更棘手的是间接注入：恶意载荷不是来自用户输入，而是来自智能体自己检索回来的内容。静态分析很难拦住它，因为从「内容」的角度看，被检索到的文本本身是合法的。
第二类是工具与权限滥用。报告用了一个直接的比喻：一个被攻陷的智能体，等于一个被攻陷的内部人。如果这个智能体有邮箱、文件存储或客户数据库的访问权，那么能够操纵它行为的人，就获得了它所能触及的一切。攻击面不在代码里，而在凭证里。
第三类是记忆与上下文投毒。跨会话保留记忆的智能体引入了一条新的攻击路径：能够影响记忆存储的人，就影响了此后每一次会话。而且这种污染是持久的，可能对常规监控不可见——一次注入，长期生效。
第四类是多智能体之间的信任传播。在编排系统中，智能体之间会互相通信与委派任务，一个注入点可以沿着调用链级联放大；一个继承了父级高权限的子智能体，能够以单个攻击者原本不可能获得的权限行事。
报告还单独提示了「影子智能体」问题：多数企业生产环境中的智能体数量，明显多于安全团队所知道的。一个产品经理发现某个效率机会，让工程师周末做了个原型，三周后这个原型已经在处理真实用户请求——而安全评审从未发生，因为在所有人的印象里它「只是个原型」。这个描述之所以成立，是因为它不需要任何技术漏洞，只需要组织惯性。
为什么防线要往前挪到运行时
报告反复强调的一点是：预部署控制依然必要，但不够。代码审查、对系统提示词做红队测试、审计工具权限，这些工作在发布前都必须做；而且由于攻击手法会独立演化，定期重跑红队也仍然有价值。但它们都无法阻止一个正在执行任务的智能体，在处理一份来自共享目录的文档时被改变目标。
这带来一个工程上的推论：真正决定权限与动作的检查，应当放在模型推理循环之外，用确定性机制执行，而不能只依赖提示词里的约束。把「模型看起来理解了规则」当作授权的最后一关，本身就是设计缺陷。
报告援引的一个观点值得记录：代码可以审查，系统提示词可以红队，工具权限可以审计，但智能体仍然可能在运行时被它检索到的一份文档攻陷。这句话的重点不在悲观，而在于指出防线位置的迁移——从「发布前的一次性检查」，转向「运行中的持续判定」。
中立思辨
需要辩证看待几件事。其一，报告由安全厂商发布，「智能体需要专门的安全产品」这一结论与发布方的商业利益方向一致，48% 这类数字在传播中容易被当作行业共识，读者应回到原始口径去理解它。其二，「有效安全控制」本身缺乏统一定义，不同厂商对「有效」的门槛差异很大，因此这个比例在不同报告之间可能差异显著，跨报告比较需要谨慎。其三，报告把多个来源的数字并列呈现，强化了问题的严重感，但这些数字的时间点、样本与统计对象并不一致，叠加使用会高估确定性。其四，报告主张把控制放到推理循环之外，方向是对的，但确定性检查也会带来新的代价：它需要维护一份准确的策略清单，而策略清单本身会随业务变化而失效，且过度严格的运行时拦截可能让智能体退回「每步都要人批」的低效状态。其五，记忆投毒这类威胁目前公开的真实案例仍然有限，其实际发生率与影响范围难以估计，把它当作已证实的高频风险可能为时过早。其六，报告对企业安全团队的建议偏向技术控制，但影子智能体的成因是组织问题——跨部门的影子系统需要的是流程与授权机制，而不只是监控工具。
趋势研判
短期看，最可能被普遍采纳的是运行时行为审计与工具调用的策略网关，因为它们能与既有的身份与日志体系对接，且不改变智能体本身的实现；中期看，记忆与上下文层会成为独立的防护对象，类似今天对数据库的权限管理，因为持久化的记忆一旦被污染，修复成本远高于拦截成本；长期看，随着多智能体协作成为常态，「智能体之间的信任如何建立与撤销」会从研究问题变成工程标准问题——谁有权调用谁、继承的权限如何收缩、跨组织的智能体如何互认，这些都需要比提示词更硬的东西来承载。
对正在做智能体落地的团队来说，一个务实的起点是把「暴露面」先数清楚：哪些智能体持有写权限、哪些能访问外部网络、哪些保留了跨会话记忆。把这三类交集找出来，就大致知道了最需要优先加固的位置。