智能体的行动速度极快，直接绕过了那层曾意外保护我们系统安全的”人工摩擦力”，我们需要的是为机器速度的行动而设计的安全机制，而不是为人类的停顿而设计的。

我曾针对一个内部IT支持智能体做过一次红队演练，它接入的技术栈任何大型企业都不陌生：ServiceNow处理工单，SharePoint存放策略和流程文档，内部目录负责路由，该智能体对这三个系统都拥有合法的读取权限，可以草拟回复但不能发送。不到两个小时，它就把一张常规的权限申请工单，逐步关联成了一条完整的推理链，还原出了一场正在进行中的组织重组——而链路上没有任何一个人被授权讨论这件事。没有任何一次工具调用超出策略范围，没有任何权限被错误配置，每一步都留有完整的审计记录。

这就是我反复看到的模式，当前的安全讨论一直围绕模型行为展开——幻觉、越狱、不安全输出——但一旦AI系统接入了工具、记忆和内部工作流，更棘手的问题就变成了执行治理：系统被允许做什么、它的访问范围延伸到多远、事后是否有人能还原出完整的行动链，这才是大多数企业真正暴露风险的地方。

很少有人承认的是，我们所依赖的企业管控机制从设计之初就没有考虑过”人工摩擦力”，尽管它们实际上一直依赖于此。一个分析师在串联十几条敏感查询之前会犹豫一下，一个人在工作流走到第七步时，会觉得哪里不对劲然后停下来，这种延迟是人类作为执行者的副产品，而非任何人刻意的设计选择，它实际充当了一种意外的安全属性，嵌入在我们构建的每一个流程中。

自主式AI把这一切都抹掉了，智能体在工作流中穿行，不存在摩擦力、疲劳感或不安感——而正是这些东西让人类在关键时刻放慢脚步，我们构建的管控机制，从未被设计用来弥补它们的缺失。

部署数据证实这不是未来才会出现的问题，根据RSAC 2026上公布的ETR数据，37%的企业已经部署或正在积极测试AI智能体，但只有3%的企业报告已建立了广泛的智能体专项安全控制，大多数企业都在让智能体运行于根本没有被设计用来管控它们的环境中。

为什么你依赖的管控机制并非为此而建

当我看到企业应对提示词注入风险时，本能反应几乎都一样：输入过滤——在恶意指令到达模型之前就把它分类拦下。当风险在于智能体的访问权限时，应对方式则是收紧身份控制以缩小爆炸半径，两种直觉都是对的，但都用错了层面。

2026年3月，OpenAI发布了一份针对真实世界提示词注入攻击的评估报告，让过滤问题变得具体可感，他们发现，最有效的攻击越来越像社交攻击，而非简单的提示词覆盖，而识别一段精心构造的对抗性提示词，本质上和在没有完整上下文的情况下检测谎言是同一个问题。一封伪装成常规HR邮件的攻击，在OpenAI全部防御机制开启的情况下，成功率仍高达50%，他们的结论是：防御不能主要依赖输入过滤，系统必须被设计成即使攻击穿透了防线，被操控所造成的影响也能被限制在可控范围内。

这个问题之所以重要，要追溯到最初的假设。提示词层的防御是建立在一个预期之上的：下游某处有一个人可能会审查输出、发现异常、或者拒绝执行最后一步。当智能体自主执行了那一步时，承担了全部防线重量的过滤器就必须拦截一切，而没有任何证据表明它做得到。

身份层的控制承载着一个平行的假设，它们评估的是谁在访问什么，按资源和系统逐一判定，但从未被设计用来评估一个系统代表某个身份在一连串行动中到底做了什么。一个拥有员工目录、项目管理系统和日历合法访问权限的智能体，可以将三者关联起来，得出任何单一权限都不曾意图覆盖的结论——而沿途的每一次访问都是被授权的，这就是马赛克效应：一个源自情报学和隐私学科的概念，描述的是将单独看来都合法的信息聚合在一起，可以产生比任何单一信息都更敏感的结果。

2026年2月，NIST发布了一份概念文件，提议将现有的身份和授权框架专门适配于AI智能体，明确指出原因在于现有框架从未为非人类主体而设计——这些主体自主行动、串联操作，且需要持续性授权而非基于会话的授权。

真实的攻击面到底长什么样

智能体暴露出的漏洞并不新鲜，权限过宽、检索过度、连接器范围松散、工作流设计中隐含着”人类会在关键步骤前停一下”的假设——这些一直都是企业的薄弱环节，改变的是，智能体会以机器速度持续利用这些弱点。

Black Hat USA上展示的研究说明了这些条件组合起来有多快，攻击者向一个连接Zendesk的支持邮箱发送邮件，Zendesk自动同步到Jira。一个开发者的AI编程智能体在正常工作流中读取了这张工单，被注入的提示词胁迫它提取仓库中的密钥，包括API密钥和访问令牌——受害者除了正常使用工具之外，不需要做任何事，智能体从未超出被分配的权限，爆炸半径完全来自于它被合法授权去做的事情的范围。

但授权问题比任何单次访问都更深，2025年12月的一篇论文发现，超过90%的隐私研究文献只关注单步泄露，而目前使用的所有智能体级评估框架都没有对多工具推理链进行建模——在这种场景中，智能体从它完全有权查看的各个片段中拼出完整图景，速度快到任何审查流程都来不及干预，对象级的权限审计捕捉不到这类风险。

这正是我自己研究中最关注的动态，在一项关于自修改智能体身份漂移的预注册试点实验中，最干净的发现并不戏剧化。在对智能体的自我描述做了一次浅层回滚之后，逐动作审计是干净的：每一步都在策略内，每次变更都有记录，但在嵌入层面衡量的行为轨迹并没有随之回滚，这个模式令人不安地广泛适用于企业部署场景：一个在事故后被回滚的智能体——系统提示词已重置、指令已收紧——仍可能在其记忆中残留之前状态的痕迹，并继续据此行动。当治理的最小单元是动作时，你真正想要管控的东西可以在你眼皮底下悄悄漂移。

执行层治理真正需要什么

贯穿全文的主线是：控制必须存在的位置发生了转移。提示词层和身份层的控制都隐含地依赖于人类行为，而智能体并不满足这些依赖。缺失的那一层是执行治理：控制系统在行动时到底能做什么，这是一个不同于控制它能看到什么或收到什么指令的问题。

OpenAI在2026年3月提出的框架提供了一个有用的组织原则：设计系统时，要确保即使操控穿透了防线，成功攻击的后果仍被限制在可控范围内。一个被限制为只能执行可逆操作、在执行关键步骤前必须暂停等待确认的智能体，无论被告知什么，都能将爆炸半径控制在可管理范围内。真正的设计问题在于：在攻击预防之外，还要实现结果遏制。

在实践中，大多数部署都还没有建成这些要求。读与执行的分离必须是一个硬性的架构区分，总结一份文档和从中传输数据是两种不同的操作，系统应当强制执行这种区分，而不是假设智能体会自觉遵守。记忆和上下文需要显式的边界，因为持久化本身就是一个具有真实爆炸半径影响的安全原语。请求、上下文、工具调用和输出的完整追踪，需要从一开始就被设计进去，而不是等出了问题再事后拼凑，而红队演练需要针对完整工作流进行，而非将模型孤立测试。

在这四项中，读/执行分离是我看到团队持续低估的那一项。一个拥有Salesforce读取权限且能草拟客户邮件的销售运营智能体，距离向第三方传输数据只差一次工具调用——而大多数管控机制从未被设计用来检测”总结一个客户账户”和”发送一份客户账户摘要”之间的区别。

那场看起来不像故障的故障

2026年一项针对1253名网络安全专业人士的调查发现，32%的企业目前对AI智能体缺乏可见性。报告描述了一个值得深思的场景：一位SOC分析师周一早上到岗，追踪一次异常的权限变更，发现源头是一个智能体在72小时前创建的服务账户，而该智能体整个周末都在向生产系统写入数据，每一个动作都有日志记录，但没有触发任何告警，因为不存在针对智能体发起行为的检测规则。

让我担忧的是，在缺乏智能体感知检测的情况下，这起事件会被归类为服务账户控制失效，作为已知问题类型被修复并关闭——而底层的AI治理问题未被识别，产生它的条件也未被改变。

在那个周一早上到来之前，真正值得问的问题是：你的检测和响应工作流如果遇到了AI治理失效，能识别出来吗?还是说日志里只会显示一个忙碌的服务账户?