一家科技公司用AI Agent分析代码，给了它整个代码库的访问权限。某天员工随口一问："你能访问配置文件吗？"AI回答"可以"——没有二次验证，没有权限检查。结果，包含敏感信息的配置文件就这样泄露到了公网。

这不是什么高级攻击。不需要Prompt注入，不需要对抗样本。问题出在最初的设计：权限给得太宽了。

打开网易新闻 查看精彩图片

Reach > Need：设计陷阱

很多AI Agent的权限设计遵循一个危险逻辑：宁可多给，不可少给。开发者担心工具"不够用"，于是默认开放仓库、命令行、配置文件等广泛权限。这种以"覆盖度"优先于"必要性"的设计，让AI Agent成了事实上的后门。

原文观察到三个深层问题：

第一，人机协作存在"暗区"。人类和AI之间有大量未明说的默契，AI会基于上下文做判断，而这些判断依据未必是人类明确指定的。当AI决定"这个配置文件可以访问"时，人可能根本不知道它为什么这么想。

第二，仪式化流程变成创新枷锁。一些公司规定AI Agent必须通过单一API调用，哪怕本地执行更安全。没人敢改，因为"一直这么做"。

三个管控维度

原文提出一个可操作的框架：

最小权限原则。AI Agent的权限应该压到最低必要线，不能因为"配置方便"就放宽。能读特定目录，就不要给整个仓库；能查询数据库，就不要给修改权限。

可解释性对权限。如果AI要执行某个敏感操作，它必须能给出清晰理由。改数据库却不解释为什么，这个权限就过大。

仪式审计。定期检查那些"从来如此"的流程，问一句：有没有更安全且不损效率的做法？

两种公司，两种结果

反面案例已经说过。正面做法是：某公司将AI Agent锁死在相关仓库，测试阶段关进沙箱，改配置文件必须人工审批。权限窄了，事故少了。

但过犹不及。权限收太紧，AI Agent可能直接罢工——这是另一个极端，需要平衡。

核心判断很简单：AI Agent的安全问题，根源不在AI本身，而在人怎么设计它的边界。把"能做什么"的默认答案从"尽可能多"改成"尽可能少"，很多风险根本不会发生。