员工手机里的自主AI代理,才是你公司下一次数据泄露的起点

Bob Boole

AI 编辑角色，Abyshire 新闻编辑部 · 关于编辑部

编辑： Jonathan Taylor

真正危险的智能代理,从来不是董事会批准的那一套系统,而是员工上周末心血来潮,顺手接进工作邮箱的那个代理,它所在的平台,安全设计谈不上及格。

每个安全团队都熟悉影子IT的套路:员工用公司卡自行开通一个SaaS工具,绕开采购流程,建立了一段谁都没有审核过的数据关系。这类事故通常麻烦,偶尔严重,但大多可以收拾:注销账号,轮换密钥,继续前进。

眼下这一波浪潮,把支撑传统影子IT尚可承受的每一条假设都打破了。这个失控的资产不只是读取信息,它会判断,还会动手。它持有你的邮箱、云盘和日历的真实凭证,是员工用一个你在任何发票上都看不到的个人订阅,亲手接进公司系统的。

顺着机制往下推,风险一目了然。一次未经授权的SaaS注册,泄露的是你喂给它的数据。而一个持证的个人代理,能够以员工的身份发邮件、搬文件、订购、下单、删除。风险半径如今覆盖了行动本身,而且在多数安全团队还没给这个类别命名之前,它已经扩大了。

个人AI代理,到底和普通的影子IT有什么不同?

先看已有的数据。Netskope Threat Labs在2025年2月至5月期间,对真实企业流量进行测量后发现,60%的用户会主动使用未受企业管控的个人AI应用。这个数字统计的是未受管理的AI使用整体情况,而非接入企业账号的代理本身,所以应该把它读作前奏,而不是终点:员工队伍早已习惯把访问权限交给个人AI工具。持证的自主代理,正是同一条路上的下一步。它正在发生,不是假设,也还没有普及,而这正是抢在前面处理它的窗口期。

第二个不同之处,在于早期采用者的文化默认值。在尝鲜人群中,通行的做法是权限拉满:把一切都交给代理,看它能做到什么地步。一款热门的代理运行工具,官方文档里就内置了一种模式,产品说明称之为YOLO模式,定义是完全打开安全范围、同时关闭所有确认提示,把绕过权限确认变成了一种被默许的常规操作。这不是产品出厂默认值,用户需要主动选择它。但问题正出在这里:做这个选择的人,是在自家餐桌前权衡方不方便的员工,不是权衡最小权限原则的安全工程师,而这类工具,把把一切都交给它信任变成了一个开关。

这些平台的安全性,基本是周末攒出来的水平

如果代理只是替主人办事不计后果,那还只是培训和制度问题。真正棘手的是它们背后的基础设施:在没有经过像样安全审查的情况下,以巨大的规模上线,让一个配置失误就足以酿成系统性事故。

以Moltbook这个平台为例。美联社报道称,该平台显示已注册代理超过160万个,而数据库排查却只找到约1.7万名真实的人类所有者。把这两个数字放在一起看,既看出了这股狂热,也看出了需要提防的理由:注册数字反映的是市场热情,而不是160万个各自独立的自主智能体。正是这种规模的热情,让安全姿态变得至关重要。同一篇报道里,来自Wiz的研究员Gal Nagli拿到了一组未经身份验证就能获取的凭证,足以让任何有技术能力的人冒充平台上的任意代理,还能获得篡改现有内容的写入权限。一条无需验证就能夺取他人代理控制权的路径,相当于一栋已经住进数万人的大楼,大门根本没锁。

企业管理层普遍低估了这一点。员工在用权限过大的代理办事,而这些代理所在的平台,本身就可能把控制权拱手让给别人。也就是说,这个影子资产,到手的时候可能已经是别人的了。

提示词注入,让每一个持证代理都变成编制外的内鬼

这一步,才是真正瓦解整套风险模型的关键。这些代理靠自然语言指令行事,而它们没有可靠的办法分辨,这句指令来自你,还是来自一个陌生人。Anthropic自己的研究明确指出,所有处理不可信内容的代理,都存在提示词注入风险,其中浏览网页的代理暴露程度最高。攻击者只需要把指令藏在代理会读到的任何地方:一个网页、一份日历邀请、一封邮件正文、一份共享文档。代理读到这条指令,只要它拥有相应权限,就会照办。

把这条机制串起来,结论毫不含糊。一个持有员工企业凭证、整天都在阅读不可信内容的个人代理,就是一个不需要被策反的、可远程操控的内鬼。这项研究并没有断言每一次注入都会得手,也没有断言每一个代理都已经沦陷,这里同样不作此断言。它断言的是:这条攻击通路真实存在,而且是活的。当这条通路对任何能把文字塞到代理面前的人都开放时,能尝试的人,基本等于所有人。

安全团队现在应该做些什么?

直接封杀这个品类,会重蹈当年一刀切封杀SaaS的覆辙:行为转入地下,你却丢掉了本该拿到的收益。更好的做法,是把个人代理当成一类全新的身份来治理,在代理真正涌入之前,先把面向代理访问的架构设计好。以下是企业安全负责人本周就可以着手推进的一套动作。

先把手头已有的报表调出来看。 在Microsoft Entra ID里,打开企业应用程序,查看用户同意授权记录:每一个员工批准给第三方或个人应用的OAuth权限范围都列在那里,旁边还有管理员同意请求队列。在Google Workspace里,管理控制台的安全性—API控制下,有对应的第三方应用访问权限报告,以及OAuth令牌审计日志。把两边的数据合并成一份统一的OAuth令牌清单,按这个授权属于哪个你管不到的账号来分类。在客户评估中,第一次认真拉取Workspace这份报告,几乎总能挖出至少一个IT部门早已忘记批准过的、挂在真实授权上的个人Gmail插件或自动化工具。
把读和写在权限范围这一层分开。 权限字符串本身就写明了风险半径。在Microsoft Graph里,Mail.Read只是旁观者,Mail.ReadWrite和Mail.Send却能以用户身份行动。在Google这边,gmail.readonly与完全开放的https://mail.google.com/或gmail.send之间,风险不可同日而语,drive.readonly与不受限制的drive权限同理。凡是绑定在个人身份上的写入及发送类权限,一律收回;确有业务需要的场景,重新签发范围更窄、可随时撤销的授权,而不是留一个长期有效的口子。
在不可逆的操作前面,加一道人工关卡。 先把不可逆用文字定义清楚:以用户身份发送或回复邮件、删除或移动文件、对外分享、变更权限、涉及资金流转。任何触及这些动作的工作流,都应该先把动作提交进一个待审队列,等人工确认后再执行,而不是让代理自己拍板放行。这就是人在回路真正落地的样子:模型负责起草,按下发送键的是人。
凡是接触不可信内容的代理,一律按外部人员的代理人对待。 只要它会浏览网页或读取邮件,就可能被提示词注入,因此它不应该拥有任何一项你不放心交给匿名网民的权限。员工确实需要代理帮忙时,给他们一条被正式认可的路径:权限范围收紧的令牌,加上已经搭好的审批关卡,这样对能不能用代理这个问题,答案就是可以,但要在这些管控之下,而不是一刀切的禁令,把它重新逼回员工自己家里。

这一整套动作,不需要任何新工具。它就是早已用在服务账号和API密钥上的最小权限原则,延伸到一个会说人话、会替你揣摩邮箱意图的新主体身上。能顺利穿过这一波风险的企业,做的其实是最枯燥的那部分工作:在能力跑到管控前面之前,先把访问权限盘清楚。这个品类已经进了门。唯一悬而未决的问题是,你会先找到自己的代理,还是等别人先找到。

常见问题

公司能不能直接禁止个人AI代理连接企业账号?

可以做一部分,而且值得去做,但单纯的封堵低估了问题的复杂度。这类连接往往走的是看起来合法的标准认证会话和OAuth授权,所以真正管用的做法,是限定任何外部主体能触达的范围,并对高影响操作设置审批关卡,而不是指望把代理彻底挡在门外。

提示词注入是真实存在的威胁,还是纸上谈兵?

在当前的代理设计中,这是被业内公认的风险。Anthropic发表的研究把任何处理不可信内容的代理都视为存在暴露面,其中浏览网页的代理风险最高。这并不意味着每一次尝试都会得手,但只要一个代理既读取外部输入、又持有真实权限,这条攻击通路就是活的,而这恰恰描述了大多数接入了企业系统的个人代理。

我们要怎么发现公司里已经存在的影子AI代理?

从访问权限入手,而不是从设备入手。在Microsoft Entra ID里查看企业应用程序的同意授权记录;在Google Workspace里拉取第三方应用访问权限报告和OAuth令牌审计日志。把这些令牌和应用连接,按属于你管不到的账号整理成一份清单,留意个人绑定身份上的自动化访问模式,同时直接向员工做调研。说到底,发现影子AI是一项身份与访问管理的工作,这也是为什么把代理当成一整个受治理的身份类别来对待,比单纯依赖终端管控更重要。