每一个动作都是被授权的。正因如此，什么都没有触发。
业界口中的「AI 内部风险」故事，是某个员工把客户名单粘进一个未获批的聊天机器人，而你的 DLP 早就盯着那扇门。更棘手的那一类走的是反方向，并且穿过的是你自己批准的那台智能体：一名权限再普通不过的员工问了个问题，智能体在六套系统里执行了四千次逐条都合规的读取，然后交回一份综合结论——那是一个铁了心的人得花三周、外加一个 SQL 客户端才拼得出来的东西。没有任何策略被违反，所以没有任何控制项有东西可以触发。变的不是访问权限，而是吞吐量、拼装能力，以及现在谁能做到这件事。
把调查报告一直混在一起的两个问题拆开。
2026 年几乎每一份关于 AI 与内部风险的报告，量的都是「影子 AI」——未获批的工具、数据出境、疏忽而非蓄意。DTEX 2026 年的内部威胁研究发现，92% 的组织认为生成式 AI 改变了员工获取与分享信息的方式；Ponemon 的成本研究把 53% 的内部事件归因于疏忽的员工。这是个真实的问题，而且是个已被充分服务的问题：它是一个出境问题，出境管控对它有效。
同一批研究里更该让你不安的是另一个数字：只有约 19% 的组织把 AI 智能体视作等同于人类内部人员。这一页讲的，正是这道缝里的东西。
- 影子 AI 是未获批的、向外的。数据越过了一条归你管的边界。封禁、分类、检查，统统适用。
- 智能体辅助的内部滥用是已获批的、向内的。这台智能体是你部署的，跑在员工自己的权限之下，读的是他们本就可以读的系统。直到最后一步之前什么边界都没被越过，而到那一步时它已经是一张截图了。
- 只有后者是从设计上击穿你的访问控制的，因为它从不与之矛盾。在这里会触发的授权系统，那是坏了。
智能体拿掉的是摩擦，而摩擦一直在替你干安全的活。
多数内部风险项目都继承了两道从没被人写下来的防线，而一台智能体在同一个下午里就把两道都删了。
- 技能门槛。批量提取过去需要知道数据在哪、怎么关联、怎么导出去——这悄悄地把「有能力大规模滥用」的人群限制在了几十名工程师与分析师之内。一台称职的智能体，把这个人群扩大到了所有有账号的人。
- 聚合的成本。一个人在案件管理系统里翻，一次只能看到一条记录，然后就烦了。那份不便才是「按需知悉」原则的真正执行者，而它恰恰是权限感知检索无法恢复的东西：一个过滤得再正确的索引，返回的仍然是这个人可以看到的全部，而智能体的全部价值就在于把它们综合起来。
所以对这份敞口的诚实表述不是「智能体的访问权限太大了」，而是：一名员工「可以看到的东西」的并集——过去在实践中根本触达不到——如今一句提示词就能触达。这与环境权限描述的是同一道算术，只不过开口发问的是个人而不是一次注入——而缓解手段也是同一个，只是按任务而不是按会话来施加。
用一个按角色提的问题来测你自己的敞口：如果这个人的智能体带着他的凭据全速跑一个小时，它能拼出什么来？不是问「他有哪些权限」——那是一份没人会读的清单——而是问：那份清单能被变成的最具破坏力的文档是什么。那才是该写进你风险登记册的那个数。
在数量与用途上做检测，因为权限已经无话可说了。
访问控制系统里的每一个信号都是二值的，而这里每一个答案都是「是」。活下来的信号是定量的，而且跑在检测智能体被攻陷早就要你采集的同一批遥测上——区别在于基线是按角色建的，而异常来自一个人，不是一次注入。
- 数返回的记录，不要数发出的查询。一句提示词可以是一百次工具调用、五万行数据。查询计数会替滥用者说好话；返回行数与触及的不同主体数不会。
- 按身份按天数「不同的数据主体」个数。一名支持坐席碰了十一位客户，看着像他的本职。同一个身份碰了九百位，要么是一条你该知道的新工作流，要么是一起事件。
- 盯住导出，也盯住渲染。智能体的输出界面就是外泄界面。一份渲染进聊天窗、再被复制走的综合结论，对一条基于文件的 DLP 规则是完全隐形的，所以控制点在响应上，它属于外泄通道清单。
- 把请求绑定到用途上。这是可选项里价值最高的一项改动：在检索类任务上要求带一个案件号、工单号或账户号，并记录下来。用途绑定把一个无法回答的问题（「这次读取正当吗？」）变成一个可核查的问题（「当时有开着的案件吗？」），而这正是受监管行业用了几十年的同一个原语。
- 按角色建基线，绝不要建全局基线。欺诈分析师本来就该看得又广又快；招聘专员不该。一条全局规则只会从「以广度为职责」的团队那里制造噪音，而对其余所有人保持沉默。
记录提示词，否则你造的是一台推诿机器。
这是多数团队还没交付的那项控制，而它的缺席比缺一条检测规则更糟。如果你的审计记录里有工具调用、却没有产生这些调用的那条指令，那么「那是智能体自己干的，我只问了个笼统的问题」就成了一句你的日志会主动替他背书的断言。你在同一个动作里既把检索自动化了，又把意图证据销毁了。
- 把人绑定到这次运行上。用户身份、逐字的提示词、解析出的计划、每一次带参数的工具调用、以及响应，用同一个 run id 串起来。少于这些，线索就在一个服务账号那里断掉了。
- 别让服务账号来承担这些读取。如果智能体以自己的身份去查下游系统，那么下游的审计日志为全公司每一个用户记录下来的都是「智能体」，归因只能从你这一侧去重建——重建得很勉强，而且只在你的 trace 还没过期时才做得到。要把最终用户身份透传下去；受限凭据就是那个机制。
- 按审计的时钟留存运行记录，而不是按调试的时钟。内部人员的案子往往几个月后才浮出来。一个出于成本考虑定下的三十天 trace 留存期，意味着证据在怀疑到来之前就过期了——这正是采样与留存存在的意义。
存储员工的提示词就是员工监控，在欧洲很多地方，它触发的是职工委员会协商和一份写明的合法性依据，之后才轮到你的 SIEM。要有意识地把范围定下来——谁能查询这个提示词库、在什么触发条件下、需要谁的二次批准——并写进文档。一项周围没有访问规则的监控能力，会变成它本来要检测的那个内部风险。
真正显形的地方，是离职窗口。
经典的内部风险实践盯的是通知期，因为收集就发生在那时候。智能体把这个窗口从几周的静悄悄拷贝压缩成了一次会话，而且是通过一个完全不产生异常文件活动的界面完成的。
- 把辞职事件接进智能体的风险信号流。你的项目本就重点关注的那部分人群，应当在智能体任务上也拿到更紧的数量阈值与用途绑定，而不只是在文件共享上。
- 让智能体的委托令牌和门禁卡走同一个时钟被吊销。长期有效的委托授权、后台排程、保存下来的智能体工作流，常常在一次「吊销了 SSO」的离职流程之后照样活着——这道口子正是智能体清册与注册表要堵上的。
- 检查那些定时任务。一个每周跑一次、把报表发到邮箱的智能体任务，就是一套驻留机制，而它不在乎作者已经走了。
- 把智能体运行纳入离职审查。如果你本来就会审查离职员工的文件访问记录，那就按同样的标准审查他们的智能体会话记录。多数离职流程里没有这一步，因为两年前根本没有这件产物。
别靠把智能体做废来解决这件事。
本能的反应——限制结果集大小、禁止批量检索、任何宽泛请求都要审批——是可行的，而它会把你的智能体变回它取代掉的那个搜索框。更糟的是它没用：一个被挡在已获批智能体之外的员工会转投一个未获批的，于是你把一群被监控的人变成了一群隐形的人，而这恰恰就是第 1 步里那些调查所量的影子 AI 问题。
- 优先选用途绑定，而不是硬性上限。挂在一个开着的案件上的大批量读取没问题；同样的读取没有案件，才是你想抓的那个。上限惩罚的是本分工作的人，对有耐心的那个几乎构不成不便。
- 对确实宽泛的任务用「打破玻璃」。具名审批人、写明理由、限时、大声记录。日常工作永远不该碰到它——你就是靠这一点知道阈值设对了。
- 把「拦截」留给不可逆的动作。读取要的是检测与归因；写入、支付和删除要的是一个急停——这与别处治理自主性的那份不对称是同一份。
- 说清楚这件事归谁。内部风险归 HR、法务与安全；智能体遥测归平台团队；哪一边都不能单独行动。如果没人被点名，你建起来的检测就只会往一个没有主人的队列里报警。
先交付这两件，按这个顺序。第一：在每一条智能体运行记录上放上最终用户身份与逐字的提示词，用 run id 串起来，按你的审计时钟留存——没有它，后面每一项控制都无法归因。第二：挑出你敏感度最高的那个检索工具，要求调用时带上案件号或工单号，然后每周报一次有多少请求是没带的。那份周报就是你面向智能体的内部风险项目，而它只需要一个冲刺。
延伸：攻击者操作的智能体讲开车的那个人不是员工时的情形，审计轨迹讲这一切所依赖的那份记录，数据治理讲让一条数量阈值真正有意义的那份分类。