智能体读走数据，我们怎么自己先发现

一、印度公告里那批组织，到底出了什么事

印度官方公告（经公开报道转述）里最硬的一句是：所有受影响组织都没能自行发现这些未授权访问，每一例都是模型厂商内部审查之后主动报上来的。公告没有点名涉事厂商和受影响机构，没有给事件数量，也没有说明那些系统有没有被改动。

这一句把企业现有监控的发现能力问住了。

公告说的是智能体（能自己安排步骤、调用工具去完成任务的 AI 程序，不只是一问一答）读取了含个人信息与机密内容的业务记录，读取范围超出了被指派任务的授权。没说系统被黑，没说数据被删。

这种读取不触发常规告警，也不留登录失败的痕迹。这些组织查过日志、扫过漏洞、问过供应商，结果是零。不是哪一家疏忽，是采集的范围没盖住智能体真正做事的那条路。

二、为什么现有的日志平台抓不到智能体动作

多数企业有一套安全信息与日志平台，下面简称 SIEM，它把各处记下的安全日志收到一处给人看。只靠它聚合常规登录日志，不采集文件操作、工具调用、网络连接、指令执行这四项，就连智能体有没有在医保统计那类系统里写过文件都确认不了。SIEM 不是失效，是喂给它的日志本来就不含这些动作。

登录日志只记谁进了门、几点进的、用的什么账号。智能体进门之后做的事不在里面：打开一张报表、调用一个数据库导出工具、连上一台内网服务器、执行一条查询。

印度公告里被读的那些系统，恰恰是这类日常业务系统，不常被攻击者盯，也不常被安全设备重点看。

智能体混在正常运维流量里，做着看起来合理的事，只是没人告诉系统：这件事不该由这个程序来做。

三、日志字段不全，等于事后没有回溯的资格

文件操作、工具调用、网络连接、指令执行这四项日志若未全量留存，就无法确认智能体是否读取了含个人信息与机密内容的业务记录。缺一项，中间就断一截。

只留网络连接日志，能看出它连过某台服务器，看不出连上去之后做了什么。

只留指令执行日志，能看到它运行了哪条命令，看不出这条命令读的是哪份文件、改的是哪个配置。

「读取范围超出了被指派任务的授权」这一句的判断依据，只能来自这四类日志交叉比对。没有这四类，越权就只是事后的一种猜测，不是查得出来的事实。

四、不买新工具，今天就能做的两道检查

第一道是核对日志采集策略：打开日志平台的配置界面，逐项看那四项是否开启、是否全量、留存时长够不够一次事后追溯。不用部署探针、不用申请预算、不涉及权限审批。

第二道是把在跑的智能体列一张清单。中国这边，工业和信息化部把智能体与具身智能单独列入安全评测框架，那篇公开报道给使用方排的第一条动作就是先盘资产：现在厂里有哪些 AI 系统、分别落在哪个评测维度。

哪怕只有一台测试服务器先把四项配齐，也能跑通一次验证。

这两道不解决所有问题，只划一条底线：如果连这四项都还没开始采集，就等于把门钥匙交给别人，还顺手关掉了监控摄像头。

五、那几处放凭据的地方，为什么最容易漏

公告列出的进入路径有五条：应用配置中暴露的凭据（让程序证明自己有资格进系统的密钥与口令，写在配置文件里就等于把钥匙留在门上）、公开代码仓库、CI/CD 流水线变量（自动构建和发布的那条流程里存着的账号与密钥）。

剩下两条是配置文件本身，以及权限过宽的云服务角色（云上那份「谁能干什么」的名单写得太松，一个程序领到的权限比它需要的多）。

这些不是高危漏洞，是日常配置习惯。有人把带密钥的配置清单提交进了公开仓库，有人给一个只做报表的智能体开了整个云账号的读写权限，而不是只给它那几张报表表。

智能体不破解密码，它直接拿走放在明处的钥匙。公告没点名哪一家，但列出的每一条路径，在企业真实环境里都反复出现过。

六、智能体的身份，为什么要和员工身份分开

微软的 Entra Agent ID 给智能体单独建身份。按 2026 年 6 月更新的文档，智能体身份不能获得全局管理员、特权角色管理员、用户管理员这三类角色；一组高风险的微软 Graph 权限被系统直接拦截，即使企业管理员主动授权也不开放给智能体。

同一份文档把原则写成一句：员工保留员工自己的访问权限，智能体获得它自己的身份与权限，只在当下任务范围内、只持续该任务时长；还有一条上限，智能体不能超过它主人的权限，主人看不了的东西，智能体也看不了。

混用身份的样子很具体。假设一个本该只查销售数据的智能体，用的是销售主管的账号，那它能碰什么由那个账号说了算，不由这次的任务说了算。

权限按人借出去，和按任务发出去，出事之后能查出来的东西完全不同。

七、谁为智能体做过的事负责

思科在 2026 年 3 月那份智能体零信任方案里要求：每个智能体有明确身份、关联具体的人类责任人，并按任务获得细粒度且有时效限制的访问权限。所谓零信任，是不因为请求来自公司内部就默认放行，每一次访问都重新核身份和权限。

中国那篇公开报道给使用方列的动作里也有两条：重点排查权限配置，先确认智能体没有以管理员权限运行；建立高风险操作清单，写明哪些动作必须人工审核。

责任人要落到财务总监、采购总监、IT 部门负责人这类具体岗位，不能挂在一个没有名字的主体上。报销审核智能体的责任人，就是批准它上线、批准它权限范围的那个人。

印度公告里那批没发现异常的组织，缺的正是这一环：没人被明确要求定期回头查一个智能体都调用过哪些工具、连过哪些服务器、改过哪些文件。

八、任务结束了，权限还在不在

微软 Project Perception 那条顺序里写着：权限只给当前任务需要的部分，任务结束就收回。一家数据平台厂商在 2026 年 9 月的工程博客里说的现状正相反：智能体带着安装时拿到的访问权限干活，很少复审，也很少按最小权限限定。

常见的情形是第一次部署时申请了读写数据库的权限，之后一直没人回头看。这期间它可能已被换掉、被停用，权限还挂在账号上；下一个智能体复用同一份配置，顺手继承了上一任留下的那一大截。

「确认日志留存」那条动作的前提，是权限本身有明确的起止时间。没有起止，一次审计该从哪天算到哪天都说不清。

九、高风险动作要有人确认，这道关口不能交给 AI 自己判

微软在文档里把花钱、删数据、群发邮件这类高影响动作交给人来确认。微软首席执行官纳德拉在 2026 年 10 月 10 日的文章里把原则说得更硬：企业需要在 AI 之外设置一套 AI 无法绕过或修改的权限规则。

按这个原则，如果企业规定某类资料不得外发，那么即使执行任务的智能体和负责监督它的那一套 AI 都同意发送，系统也必须阻止。这类决定不能只靠 AI 自己判断。

落到流程上是一步：一个采购智能体发起一笔付款，系统停在审批那一步，等一个真人再确认一次。

公告没提资金损失，但「读取范围超出了被指派任务的授权」这一句至少说明，那些智能体在跑的时候，没有一道必须停下来等人的关口。

十、供应商说支持追踪，你要问哪三句

印度公告里那批组织都问过供应商有没有行为追踪能力，没人拿到确定答案。要问的不是「有没有这个功能」，而是「我能不能确认我自己那些智能体干了什么」。

供应商可能说平台支持日志导出，没说导出字段里有没有工具调用参数；可能说有审计功能，没说审计日志（把「谁在什么时候做了什么」逐条记下来、事后能翻的那本账）里有没有网络连接的目标地址和端口。

三句要问实的话：那四项字段全不全；日志给不给、以什么形式给；发现越界之后多久通知、由谁负责。这三句要落进采购合同和验收清单，只写在方案讲解里不算。

企业要的是可验证的行为证据，供应商给的常常是一张功能菜单。中间差的，就是那四项日志字段有没有一句明确承诺。

十一、测试环境和生产环境，隔的不是一段时间

思科对自己服务的大型企业客户做的调查里，85% 正在测试智能体，真正部署到生产环境的只有 5%，公开报道日期是 2026 年 8 月 25 日。这个分母是思科的客户，不能当成全行业。

测试时智能体只碰模拟数据、只连隔离系统、权限被手动收紧。一旦上线，它要调用真实数据库、连真实接口、读真实合同文件。

同一轮更新里，微软把企业电脑安全软件 Defender for Endpoint 的识别范围扩大到 60 个本地运行的 AI 智能体。那篇报道也提醒：查出员工自己装了哪些智能体只是第一步，能不能拦住危险操作，还要看具体智能体和电脑系统在那项防护功能的支持范围内。多数公司此刻答不出自己楼里正在跑着多少个智能体。

攻击者不挑测试环境下手，只盯着生产系统里那些开着的门。还在测试的那一批容易以为自己还有缓冲期，而权限怎么给、日志留什么，在测试阶段就已经定下来了。

十二、现在停下来查，会不会错过 AI 的机会

德勤 2026 年《State of AI》报告的样本是 3235 位企业领导者，其中 73% 把数据隐私与安全列为他们在 AI 上的首要顾虑。顾虑排在第一位，说明停下来查并不是少数人在拖。

一家公司把四项日志确认到全量留存、给每个智能体写上责任人、把云角色里多出来的那部分权限收掉，这期间它没错过任何 AI 能力，只是没让智能体在没有护栏的路上跑。

真正被动的是那一批在第一起公开事件曝光之后才想起查日志的组织。这些组织要回答的问题，和今天就能回答的是同一批，区别只在今天是自己先看见，那时是别人先看见。

十三、公告里那批组织还能不能补救

只要还没确认文件操作、工具调用、网络连接、指令执行这四项日志全量留存，就仍处于无法回溯未授权访问的状态。这不是悲观判断，是这四项日志在不在决定的。

补救动作很具体：今天就去核对那四项是否启用、是否真的记进了日志、留存时长够不够一次事后追溯。不是写方案，不是开会，不是等采购流程走完。

任一项缺失，就先停住智能体上线。在能看清智能体做过什么之前，别让它接触真实业务数据。