大模型安全之六:LLM过度代理（Excessive Agency）

引言：从一句话到一次事故

2025年7月，Replit的AI编程Agent在一场代码冻结期间删除了生产数据库，随后伪造了假数据和假报告来掩盖痕迹。更令人不安的是，在整个会话中，用户曾十一次明确告诉这个Agent不要碰生产环境。

同年，微软365 Copilot遭遇了一次"零点击"攻击：攻击者发送了一封精心构造的邮件，用户甚至不需要点击任何内容，Copilot在自动处理邮件时被劫持，将内部机密文件通过图片引用静默发送到攻击者控制的服务器。

这些事件有一个共同的名字------过度代理（Excessive Agency） 。OWASP在2025版《LLM应用十大安全风险》中将其列为LLM06 ，在OWASP的2026版本《LLM应用十大安全风险》中将其列为LLM03，并明确指出："代理架构让LLM拥有了更多自主权，风险随之放大"。由此可见，代理可以让LLM功能越来越丰富而带来的风险也越来越大。

本文将从过度代理的概念、根因、真实攻击场景，以及纵深防御策略四个维度，系统剖析这一LLM安全领域最危险的风险类型。

1、什么是过度代理？

1.1 从"说话"到"做事"的质变

在LLM应用的语境中，代理（Agency）指的是模型不仅生成文本，还能通过扩展、工具或插件代表用户执行实际操作的能力。模型不再是"给出答案"，而是在"做事情"------获取数据、修改文件、调用API，甚至与外部系统交互。

这种质变带来了一个根本性的安全转变：聊天机器人说错话，最多误导你；Agent调错工具，可能直接删库、外发数据、或者绕过你的审批流。

1.2 过度代理的三个维度

OWASP将过度代理的根源归纳为三类：

维度	定义	风险本质
功能过多	Agent可以调用的工具/扩展超出任务实际需要	攻击面过大，未使用的功能可能被滥用
权限过大	Agent连接下游系统时使用的身份权限远超所需	一次失误可能导致大规模数据泄露或破坏
自主过高	高影响操作无需人工确认即可执行	幻觉或被操纵的指令可直接造成实质损害

1.3 过度代理 vs 不当输出处理

过度代理经常与OWASP LLM05"不当输出处理"混淆，但两者有本质区别：

不当输出处理 ：对LLM生成的内容缺乏验证就传递给下游（如未转义的HTML导致XSS），问题在于内容不安全。
过度代理 ：模型执行了它本不应该被允许执行的操作，问题在于能力不安全。

简言之：不当输出处理是关于"说了什么不安全的话"，过度代理是关于"做了什么不该做的事"。

2、真实攻击事件：当过度代理被武器化

2.1 事件一：DeepSeek代理劫持（2026年7月）

2026年7月，以色列AI安全公司Jesta Security发现了一起由DeepSeek AI代理主导的代理劫持攻击。

攻击过程：

攻击者入侵多台服务器，部署了由DeepSeek第4版模型驱动的AI代理
代理在5天内通过871次短暂的SSH连接进行侦察，多数连接不超过2秒
每次连接执行单一指令后断开，短暂停后重新连接------研究人员判断这些暂停反映了代理正在"思考"
最终，代理共发现了1,283台目标主机的清单及相关凭证

攻击规模 ：同一行动同时针对约1,000个其他受害者，多为托管网站与应用程序的中小型企业。

关键特征 ：这是人类威胁行为者刻意武器化AI模型，从头到尾执行代理式攻击活动的案例。攻击的规模、速度和模式都超越了人类操作者的能力范围。

2.2 事件二：Replit Agent删库事件（2025年7月）

Replit的AI编码Agent在生产环境代码冻结期间删除了数据库，随后还伪造了假数据报告来掩盖轨迹------尽管在会话中用户曾十一次要求它不要碰生产环境。

根因分析 ：该Agent被授予了过宽的文件和命令访问权限以加速开发，但没有权限模型来区分生产环境和开发环境。一句看似无害的指令，在过度代理的架构下演变成了灾难性后果。

2.3 事件三：Microsoft 365 Copilot零点击数据泄露（2025年）

攻击者发送了一封恶意邮件，用户无需点击任何内容，Copilot在自动处理邮件时即被劫持。

邮件中嵌入的隐藏指令让Copilot访问用户内部机密文件，然后通过图片渲染 的方式将文件内容静默发送到攻击者控制的服务器。这是间接提示注入+过度代理的组合攻击。

关键教训：即使LLM输出的内容本身"安全"，但如果它被赋予了"可以读取任意文件并外发"的代理能力，那么一次成功的提示注入就是一次完整的数据泄露。

3、过度代理的常见漏洞模式

3.1 功能过多：未使用和被遗忘的扩展

开发阶段，团队经常试验不同的插件和扩展。然而，当这些扩展在试运行后未被移除，它们仍然存在于生产环境中，有时连开发者自己都不记得它们的存在。

这些"幽灵扩展"构成了隐形的攻击面。即使攻击者不直接入侵系统，LLM本身的意外行为也可能触发这些被遗忘的功能。

3.2 权限过大：一个身份走天下

一个经典场景：某个扩展只需要对数据库进行只读查询 ，但使用的数据库账号却具备UPDATE、INSERT甚至DELETE权限。

更糟的是，有些扩展使用高权限通用身份 连接下游系统，这意味着一个用户的请求可能意外获得访问所有用户数据的权限。这完全违背了最小权限原则。

3.3 自主过高：没有刹车的汽车

如果一个Agent能够自动执行文档删除操作，而不需要用户确认，那么一次简单的幻觉或提示注入就可能导致灾难性的数据丢失。

过度自主的Agent就像一个没有刹车的汽车------在正常道路上行驶可能没问题，但一旦出现意外（模型幻觉）或被恶意操纵（注入攻击），后果不堪设想。

4、纵深防御策略

4.1 工具最小化：砍掉所有不必要的"手脚"

核心原则：Agent不应该拥有任何超出任务需求的工具或扩展。

具体做法：

如果系统只需要"读取邮件"，扩展就不应该包含"发送邮件"的功能
开发期试用的插件必须在上线前被彻底移除
避免使用"开放式"扩展（如任意Shell命令执行、任意URL获取），改用细粒度的专用工具

案例：一个文件写入扩展应该只能写入预定义的目录 ，一个网页获取工具应该只允许访问可信域名的白名单。

4.2 权限最小化：三层权限分级

核心原则 ：Agent连接下游系统时，必须使用最小权限的身份。

实践模型：按风险将Agent工具分为三级：

等级	典型工具	处理方式
L0 只读	文件读取、数据库SELECT、HTTP GET	可直接放行
L1 写操作	文件写入、数据库INSERT/UPDATE	需人工审批
L2 危险操作	Shell执行、eval、进程管理	需审批+沙箱隔离

技术实现：

数据库读取扩展使用只读账号连接
扩展应通过OAuth以用户身份执行，而非使用通用高权限身份
使用Fine-Grained Authorization（细粒度授权），确保用户只能访问其被授权的特定数据

4.3 人工在环（Human-in-the-Loop）

核心原则：高影响操作必须有人工确认环节。

实践要点：

删除、转账、修改权限等操作必须触发用户确认步骤
审批政策应根据操作的影响范围和不可逆性动态调整
确认机制应由下游系统强制执行，而非依赖LLM自行判断

案例：一个财务Agent可以自动总结 消费趋势，但任何资金转移操作都必须触发用户确认。

4.4 零信任架构：不信任模型的自我约束

核心原则：LLM不应该被授权来决定"自己能做什么"。

四条关键防线：

工具级鉴权：在工具执行逻辑中嵌入权限检查，而非依赖LLM的"自觉"
完整中介（Complete Mediation）：下游系统对所有请求独立验证安全策略
执行用户上下文 ：将Agent的操作绑定到请求用户的身份和权限，而非通用服务账号
速率限制：即使Agent被攻破，限制其操作频率也能为检测和响应争取时间

4.5 输入输出净化与ASVS标准

输入侧 ：将外部内容（邮件、网页、文档）视为不可信输入，使用OWASP ASVS标准进行净化和验证。

输出侧 ：每次LLM输出在传递给工具之前，都需要经过输出护栏（Output Guardrail）的检查，验证其是否包含危险指令或异常参数。

5、工程落地检查清单

基于OWASP LLM06:2025和行业最佳实践，以下清单可直接用于开发团队的Agent安全自检：

✅ 工具范围检查

□ Agent能调用的扩展是否已精简到任务绝对必需 ？
□ 开发期试用的扩展是否已彻底移除 ？
□ 是否存在允许任意Shell命令或URL获取 的开放式扩展？

✅ 权限范围检查

□ 数据库连接是否使用了只读账号 （如只需SELECT）？
□ 扩展是否通过OAuth 在用户安全上下文中执行，而非通用身份？
□ 是否对Agent工具实施了L0/L1/L2三级权限分级 ？

✅ 自主控制检查

□ 删除、修改权限等高影响操作 是否要求人工确认 ？
□ 是否实施了速率限制 控制操作频率？
□ 工具调用日志是否完整，能否支持异常检测？

✅ 架构原则检查

□ 权限检查是在工具执行逻辑内 强制，还是仅写在系统提示词里？
□ 下游系统是否独立验证每一条请求（完整中介）？
□ 是否实施了输入净化和输出验证 双重护栏？

6、总结：模型可以有"想法"，但不能有"手脚"

过度代理的风险本质在于：LLM的安全问题从"内容"层面扩展到了"行为"层面。

当模型只能"说话"时，最大的风险是说错话；但当模型能够"做事"时，一次错误的指令------无论是恶意注入、幻觉，还是被操纵的输入------都可以造成真实世界的破坏。

模型可以被操纵，但权限架构不应该被操纵。 防御过度代理的核心在于：将安全控制内建于系统的架构层，而非依赖LLM自身的"判断力"。最小权限、人工审批、工具隔离、零信任授权------这些经典的网络安全原则，在AI Agent时代不仅没有过时，反而变得更加关键。