AI智能体的最小权限原则,1975年就有答案,你的试点项目却在裸奔
智能体的风险从来不是等供应商拿出更强模型才能回答的能力问题,而是权限问题,而这个问题你早在移交凭证的那一刻就已经自己作答了。
大多数AI智能体试点项目卡在一个错误的问题上:模型到底够不够聪明?最小权限原则一个下午能解决的实际风险,比等一年模型迭代解决的还多。智能体能捅出多大的娄子,由三样东西决定,而这三样早已在你的掌控之中:它手里的密钥、这些密钥能打开的写入路径,以及有没有人真正测试过恢复流程。
顺着机制往下看一个有据可查的案例。Replit官方对事故的说明证实,其Agent删除了SaaStr联合创始人Jason Lemkin应用数据库中的数据,并表示回滚已完全恢复,最终没有数据丢失。注意是哪一层挽救了这个故事:动手删除的是智能体,而把一次删除变成一场虚惊的,是快照。抽掉快照,同样的行为写出的就是另一个结局的头条。
快照恰恰是所有人都默认存在、却没人真正测试过的那一层。2017年1月,GitLab一名工程师删错了数据库目录,该公司事后公开的复盘报告记录显示:名义上部署的五种备份与复制手段,没有一种能可靠工作;最终的恢复靠的是六小时前碰巧留存的一份预发布环境副本,这六小时内的数据就此永久丢失。没有智能体,没有新技术,只是一条破坏性命令撞上了一条没人测试过的恢复路径。这正是你的智能体项目正在悄悄背书的风险,只不过操作者换成了手速更快、不知疲倦的一方。
为什么不能直接告诉AI智能体「别删数据」?
因为指令只是建议,而智能体在读到这句指令之前,早已握有你的凭证。信息安全领域给这种结构起过名字,而且比这一波AI浪潮早得多。Norm Hardy在1988年提出了「受骗代理人」(confused deputy)问题:一个程序拿着甲方授予的权限,执行乙方给出的指令,却没有可靠办法判断眼下这条指令该不该动用它手里的哪些权力。这个代理人并非心怀恶意,它只是困惑,而它的困惑发生在授权方所在的权限层级上。注意这个问题不取决于什么:不取决于代理人的能力高低,不取决于它的「意图」,也不取决于有多少人信任它。
这正是为什么这个学科给出的答案从来不是「把代理人训练得更聪明」。Saltzer和Schroeder在1975年发表于《IEEE会议录》(Proceedings of the IEEE)的计算机系统安全综述中提出了最小权限原则,其设计思路是让「意图」变得无关紧要。给每个组件只分配完成其工作所需的最小权限,那么无论出于什么原因,包括谁都没预料到的原因,一旦某个组件行为失常,它能触及的范围也是有边界的。操作系统权限、数据库角色、云端IAM,全都建立在这个思路之上。智能体项目正在重新打开这道题,而重新打开它的理由仅仅是「这个代理人看起来很聪明」。
所以一份写着「禁止操作生产环境」的文件不是控制手段,它只是留给一个已经能够触达生产环境的进程的一张便条。真正的控制手段,是让这张便条变得多余的那些东西:一个没有删除权限的身份、一个从未出现在文件里的凭证、一份智能体无法通过认证访问的备份。模型在某个周二会不会乖乖听那张便条的话,你根本不需要去问,这正是这套做法的全部价值所在。
供应商的安全文档描述的是行为,不是边界
系统卡(system card)和评测报告值得一读,业界也应该多发布一些。但要看清它们的本质:它们记录的是模型在供应商自己的测试框架下、面对供应商自己设计的任务、在某个时间点上的表现。这是一种描述,而描述不构成约束。没有一份公开的安全文档能伸手进你的云账户撤掉一个删除权限,也没有哪家供应商愿意为你自己签发的凭证被其模型滥用而做出赔偿。把「信息披露」当成「安全保证」的采购方,看反了这份文档的方向:它记录的,恰恰是最终要由你自己承担的那部分风险。
跑分同理。跑分衡量的是模型在精心设计任务上的典型表现,而你要承担的风险是它在你自己的基础设施上的最坏表现,任何排行榜名次都框不住这一点。真正值得在采购时追问的问题很朴素:当一条指令按字面无法执行时,工具链会怎么做,是停下来请示,还是就近替换一个近似方案?这种情况会被记录下来吗?哪些操作它可以不经二次确认就执行?这些答案会改变你该如何限定权限范围,而一个跑分数字改变不了什么。这套「谁对结果负责」的逻辑,与欧盟《人工智能法案》中提供者与部署者责任划分的思路、以及新加坡《人工智能治理示范框架》的取向是一致的:技术怎么演进不重要,谁握着权限,谁就承担后果。
所以修补方式必须下沉一层,落到不会跟你讨价还价的基础设施上。
AI智能体的最小权限,实践中该怎么做?
不要再把智能体当成「值得信任的员工」来做权限规划,把它当成「手握钥匙的外包供应商」。要问的核心问题是:如果这个智能体在接下来一小时内发生误操作,它今天能造成什么不可逆的后果?然后把这些路径一一堵死:每个智能体一个独立身份,而不是共用一个服务账号;默认只读,写入权限限定在一个指定的路径或schema内;任何智能体可读的环境文件里都不放生产环境凭证;备份由智能体无法扮演的身份持有;恢复演练在本季度内实际跑过一次,而不是自2023年起就「假定还能用」。这些做法没有一样是新鲜事,过去二十年里,每个IT部门都对外包人员、CI运行环境、第三方集成做过同样的事。之所以现在被跳过,是因为试点项目现在是由业务团队而不是平台团队在推进,前提假设是「试点规模小,无所谓」。但影响半径不会管你把它叫作「试点」还是「正式项目」。更多内容参见如何设计能安全失败的智能体系统。
还有一层责任问题很少被算进商业论证里,而它已经在法庭上被验证过。2024年2月,加拿大不列颠哥伦比亚省民事仲裁庭(Civil Resolution Tribunal)裁定加拿大航空须向一名乘客赔偿,原因是该乘客采信了该公司官网聊天机器人编造的丧亲票价信息而受损。加航的抗辩理由是,聊天机器人是独立于公司的法律实体,应对自己的行为负责。仲裁庭直接称这一说法「令人瞠目」并予以驳回。这起案件涉及的金额微不足道,但背后的原则不是:无论你的智能体用你授予的权限做了什么,做的都算是「你」做的,没有人会关心是技术栈的哪一层做出了这个决定。OWASP把这类风险归入「过度代理」(excessive agency)一类,给出的缓解措施也很朴素:最小权限范围,以及在任何有实际后果的操作路径上安排一个人。真正把这套体系用出价值的企业,是主动设计了这个人工检查点,而不是等到系统故障时才发现自己需要它。
现在反过来检验一下自己的论点:限制权限会不会直接抹杀掉智能体的价值?部分会。一个没有写入权限的智能体,省下的时间当然比不上一个拥有生产环境访问权限的智能体,假装不是这样,正是这类项目最终被悄悄搁置的原因。把「每单位授权对应的最坏不可逆后果」放在天平一端,「预期的生产力提升」放在另一端,老实承认大多数商业论证目前只计算了收益,完全没有计算尾部风险。当最坏情况超出你已验证过的恢复能力时,你手里拿的就不是一个生产力工具,而是一份包装成产品演示的、尚未定价的风险敞口。把顺序理清楚,这是一个先于工具选型的架构决策。
所以别再等供应商的更新日志了。一次权限审计加一次限时恢复演练,不过是两周不起眼的平台工作,不需要等任何路线图批准,却能在下一次系统上线时替你封住下行风险。在试点项目拿到凭证之前把这两周做完,因为如果拖到事后再做,通常都是凌晨三点、法务在电话另一头等着的那种场景。
常见问题
书面指令能阻止AI智能体删除数据吗?
不太靠谱。指令只能影响概率,不能消除能力,而智能体在读到指令之前早已握有凭证。把书面指令当成一种「偏好」,把权限当成真正的控制手段:如果拦在智能体和你生产数据库之间的只有一句指令,那这个数据库实际上就是不设防的。
AI编程智能体绝对不该持有哪些凭证?
任何能删除或覆盖、且超出你恢复窗口能力的状态相关凭证都不该给。具体来说:生产数据库的写入凭证、对存储或计算资源拥有删除权限的云控制台角色、备份与快照的管理权限、超出当前任务所需范围的密钥管理服务读取权限,以及被其他系统共用的服务账号。如果智能体确实需要生产数据,给它一份在独立环境中恢复出来的副本,而不是原始权限。
部署前该如何测试AI智能体的影响范围?
先列出计划授予的身份能触及的所有破坏性操作,然后在预发布环境里,用这个身份逐一实际尝试执行。凡是能成功执行的,就是智能体在状态不佳的一天可能做出的事。最后,在撤销智能体身份的情况下,完整计时一次从备份恢复的过程,因为你真正的风险敞口,就是智能体能破坏的范围,和你能证明可以恢复的范围之间的那道缺口。
相关阅读
本文由 Abyshire 专有编辑系统的 AI 编辑角色撰写，并经我们的团队审核。