Agent 权限蔓延：如何在增量需求中悄悄发生

当聊天机器人产生幻觉时，用户读到答案可以发现。当Agent产生幻觉时，在有人查看之前，它可能已经运行了查询、发送了邮件或改变了配置。正是这个根本差异，使得Agent安全成为独立的学科而不仅仅是应用安全的一个分支，也正因此OWASP在2025年12月发布了专门针对Agent应用的Top 10，而不是将其纳入现有的LLM列表中。

我交流过的大多数团队并不是因为不同意这一点而忽视了。他们之所以忽视，是因为安全工作从来没有在计划中争取到一席之地。Agent已经上线、运行良好，它第一天就有的访问模型在第九十天仍然没变。

权限蠕变是真正的攻击面

实际发生的事件很乏味。一个Agent被构建来总结文档。两个sprint之后，有人需要它生成总结文件，于是它获得了写入权限。接着它需要发布总结，所以它又获得了API令牌。没有人坐下来正式批准过一个既有文件系统写入权限又有网络写入权限的文档总结器，但现在的情况正是如此。而且访问模型从未被重新审视，因为什么都没有损坏。

最小权限原则容易达成共识，但维护起来很枯燥，这正是它失败的原因。实际有效的做法是一条规则而非原则：每个Agent都从零权限开始，你添加的每项功能都要触发对整个权限集的重新评估，而不是简单地附加到现有权限上。

间接提示词注入把数据变成指令

提示词注入仍是OWASP针对LLM应用的头号风险，在Agent场景下风险显著加大，因为回报不再是误导性的回答，而是真实的行动。

直接注入是用户输入覆盖系统提示的情况，这是大家都会测试的。真正让人栽跟头的是间接注入：恶意指令藏在网页、工单、PDF或Agent被指示去读的数据库行里。Agent没办法区分它被要求处理的内容和它被要求遵循的指令，所以它就照做了。

这就是为什么权限和注入是同一个问题而不是两个问题。一个只能读取的Agent很糟糕。一个能读取被污染的页面然后对其采取行动的Agent才是事件。

Agent行为的纵深防御

单一的控制不够，所以有效的模式是多层独立失效的防御：

限制工具范围，不仅限制数据。一个只能向内部地址发送邮件的"发送邮件"工具，与持有通用SMTP凭据的Agent风险完全不同。

在关键操作面前放置人工检查。超过阈值的财务交易、生产基础设施变更、外部通信和访问控制变更都应需要批准，批准界面应在提议的行动旁边展示Agent的推理过程，这样人类是在做决定而非盖章。

在Agent间验证。在多Agent管道中，Agent之间不加检查地相互信任会将一个被破坏的步骤转化为十个坏输出。

监控决策，不仅仅是错误。大多数Agent监控统计失败。更有用的信号是Agent选择调用什么工具的分布，因为从外部看，调用模式的缓慢漂移就是成功注入的样子。

本周开始的行动

选择一个已在生产环境运行的Agent，列出它拥有的所有权限以及谁批准了每一项。在大多数团队，这份文档还不存在，光是制作这份清单通常就够发现至少一个没人记得授予的能力了。

从那里开始，有效的步骤是：撤销不需要的权限，在你绝对不希望出错的操作面前放置批准流程，并添加记录工具调用而不仅仅是失败的日志。

完整的分析（包括威胁类别、治理方面和合规要点，因为《欧盟AI法案》将在2026年8月对高风险系统全面执行）可在此查阅：https://www.autolearningagents.com/ai-agent-safety/

早期采取行动的团队不是在谨慎行事。他们是在避免事后改造，而改造成本远高于最初的工作。