Deep Water research

DeepTest agent-excessive-agency defensive research (zh)

Write a thesis-sized defensive research report in Chinese for DeepTest on: Excessive agency, approval bypass, and unsafe tool authority. Topic id: agent-excessive-agency. Technique card: agent-excessive-agency. Related defensive guide ids: guide-agent-tool-agency-approval. Scope and safety: lawful authorized API penetration testing and secure agent review only. Do not provide exploit payload libraries, stealth guidance, credential theft workflows, persistence, malware, or instructions for unauthorized third-party targeting. Required structure: executive summary; conceptual attack anatomy; prerequisites; affected assets and trust boundaries; common root causes; safe lab validation objectives; detection signals; logs and telemetry; mitigations; remediation tasks; regression-test ideas; report-writing checklist; control mappings; residual risk; references. Make the report suitable for conversion into DeepTest local skills, technique cards, guide checks, MCP report tasks, remediation tasks, and PDF report sections.

Jun 27, 2026154 sources reviewed

执行摘要 (Executive Summary)

本报告针对大语言模型（LLM）Agent架构中日益凸显的过度代理（Excessive Agency）、审批绕过（Approval Bypass）以及不安全工具权限（Unsafe Tool Authority）等核心安全威胁进行了深入剖析。为确保企业级AI Agent安全符合监管与架构标准，本研究得出以下关键发现与建议：

  • 过度代理的根本性威胁：AI系统中的过度代理源于配置不当，赋予了Agent在缺乏足够监督的情况下自主执行高风险操作的权限 [5]。当结合MCP（模型上下文协议）服务器中高达60%的命令注入漏洞集中度 [6] 时，攻击面呈指数级扩大。
  • 多模态与间接提示注入导致审批绕过：攻击者正利用基于Web的间接提示注入（IDPI）[10] 及多模态符号（如表情符号序列或画谜）[9] 来规避现有的安全护栏，并欺骗Agent绕过预设的人类在环（Human-in-the-loop）检查点 [8]。
  • 执行环境信任边界的失效：传统的应用层沙箱无法有效约束Agent自主生成的动态代码，一旦执行控制权转移到子进程，应用层将失去对环境的可见性与控制力 [12]。
  • 纵深防御与身份委托架构：解决工具权限滥用需要结合纵深防御策略 [17]，实施严格的RAG授权过滤 [18]，并通过OAuth授权码流程实现直接委托访问，确保每一个Agent动作都与特定人类用户的授权直接绑定 [19]。
  • 合规驱动的审计与日志标准化：为满足《欧盟AI法案》[1] 和NIST AI RMF [2] 的合规要求，企业必须部署防篡改的代理审计跟踪（AAT），强制记录包括代理身份、人类授权者、操作结果及往返时长在内的核心字段 [25] [27] [28]。

1. 概念攻击剖析 (Conceptual Attack Anatomy)

在大语言模型Agent的安全模型中，攻击往往不是利用单一的内存破坏漏洞，而是通过操纵模型推理逻辑和工具调用链条来实现。针对“过度代理”和“审批绕过”的攻击剖析可分为三个核心概念阶段：

1.1 过度代理 (Excessive Agency)

过度代理指的是AI系统被配置了过度的自主权，在没有充分人类监督的情况下执行高风险动作（如财务交易、系统修改）[5]。攻击者无需寻找传统的提权漏洞，只需向Agent下达能够触发这些高权限工具的自然语言指令，由于模型本身的决策过程是一个“黑箱”（即便是对AI研究人员而言内部机制也难以完全解释）[7]，Agent可能会基于不完整或被操纵的数据执行未预期的破坏性操作。

1.2 审批绕过 (Approval Bypass)

人类在环（Human-in-the-loop）是一种架构模式，要求自治AI在特定的人类监督边界内执行复杂工作流 [8]。审批绕过是指Agent在执行敏感动作时，未能触发或被欺骗跳过了预定义的人工审批检查点。 近年来，“基于Web的间接提示注入”（Web-based IDPI）在野外被广泛发现。攻击者的目标是欺骗旨在审查或验证内容的AI Agent（例如广告审核Agent），使其批准本应拒绝的恶意内容，从而实现业务逻辑层的审批绕过 [10]。

1.3 护栏规避与多模态注入

传统的基于文本的安全护栏（Guardrails）很容易受到多模态输入的降维打击。研究表明，攻击者可以使用符号化的视觉输入（如表情符号序列或视觉画谜 Rebus puzzles）来破坏Agent系统并规避现有的安全护栏 [9]。此外，对抗性指令通过提示注入（Prompt Injection）可以覆盖系统级指令，迫使Agent以违背其安全配置的方式运行 [16]。

2. 漏洞发生的前提条件 (Prerequisites)

在DeepTest等平台进行安全验证时，识别Agent是否易受攻击需评估以下前提条件：

  1. 缺乏细粒度的工具授权（Lack of Granular Tool Authorization）： Agent被授予了全局的 API 密钥，而不是基于会话或基于具体用户的降权Token。
  2. MCP服务器的固有脆弱性（Inherent MCP Server Vulnerabilities）： 使用了易受攻击的模型上下文协议（MCP）集成。由于Agent与工具之间调用模式的固有风险，MCP服务器是注入漏洞的重灾区，超过60%的问题与命令执行缺陷相关 [6]。
  3. 人类审批链的逻辑缺陷（Flawed HITL Logic）： 系统虽然实现了人工审批，但审批的触发条件是由LLM自行决定的。如果LLM被恶意提示误导，认为当前上下文“安全”或“已获授权”，则不会调用审批中断（Interrupt）机制。
  4. 缺乏状态持久化校验（Lack of State Persistence Validation）： 在多轮对话中，如果没有安全地维持消息历史（例如在 LangGraph 中使用 MemorySaver 检查点机制 [4]），Agent 可能会混淆当前的授权状态，将前一轮的无害上下文与后一轮的恶意工具调用错误结合。

3. 受影响的资产与信任边界 (Affected Assets and Trust Boundaries)

AI Agent 的引入彻底改变了现代云原生和SaaS架构的信任边界模型。

3.1 沙箱与运行时环境的边界破裂

传统的应用层安全控制存在严重的局限性。应用层只能在执行前拦截工具调用和参数，但一旦控制权转移给执行代码的子进程，应用程序就会失去对该子进程的可见性和控制力 [12]。 由于自治AI Agent会根据非受信任的自然语言输入在运行时生成并执行全新的代码，这创造了一个传统安全控制未曾设计去应对的全新风险面 [11]。

3.2 云计算与主机信任边界的渗透

在基于云的Agent执行环境中，从云环境到主机实例的信任边界在设计上具有一定的渗透性。拥有高权限云API调用能力（例如IAM凭证）的受损Agent可以利用这些凭证突破OS级别的身份验证系统，在不同的认证和授权边界之间进行横向移动 [13]。

3.3 矢量数据库与RAG上下文边界

受影响的资产还包括通过检索增强生成（RAG）接入的私有数据。如果信任边界未能下推至数据访问层，Agent在处理外部恶意提问时，可能会检索并泄露未脱敏的敏感文档。

4. 常见根源分析 (Root Causes)

Agent 工具权限滥用的根本原因通常可归结为以下几个架构设计缺陷：

  1. 身份混淆（Identity Confusion）： Agent使用系统级超级服务账号运行，而不是采用专门的“Agentic Identity”（智能体身份）。例如，正确的设计应该像微软 Intune 漏洞修复代理一样，在专属的智能体身份下运行，其操作严格限制在该身份被委托的权限范围内 [21]。
  2. 过度依赖模型的语义判断进行权限控制： 将访问控制决策委托给黑盒模型 [7] 是危险的。模型无法区分“合法的数据请求指令”与“利用提示注入伪装的数据请求指令”。
  3. 单点防御思维： 仅在Prompt层面添加“不要执行恶意操作”的系统指令。如果没有跨越Agent、工具、提示词及运行时环境的结合性保障措施，单一缓解手段是不足够的 [17]。

5. 安全实验室验证目标 (Safe Lab Validation Objectives)

在DeepTest等渗透测试和安全评估平台中，进行合法的安全验证应聚焦于以下测试目标（禁止使用破坏性利用）：

  • 目标 1：HITL 逻辑绕过测试。向Agent提交包含隐蔽意图或多模态符号 [9] 的请求，验证Agent是否在未暂停执行等待人类审查的情况下，直接触发了如修改配置等高风险操作 [22]。
  • 目标 2：工具权限边界探测。提供良性但越权的工具调用提示（如尝试读取同级租户目录），验证应用层沙箱或子进程监控是否有效阻断了Agent生成的动态代码越权行为 [12]。
  • 目标 3：OAuth 委托完整性验证。测试直接委托访问机制 [19]，确认Agent在执行工具时，是否能够突破当前人类用户的OAuth授权码流作用域（Scopes）。
  • 目标 4：Web间接指令注入（IDPI）容错性。通过模拟的外部URL或文档传入包含恶意指令的Web内容，验证负责审核的Agent是否会无视安全策略而批准该内容 [10]。

6. 检测信号 (Detection Signals)

要在执行阶段捕获Agent的越权行为，SOC（安全运营中心）和自动化检测工具应关注以下信号：

  1. 基于大语言模型的意图检测： 由于Agent生成的代码或调用参数高度动态，传统的静态正则匹配可能失效。可以利用基于LLM的检测系统（类似于Datadog用于检测恶意Pull Requests的方案），通过分析代码修改和上下文元数据来推理修改背后的“意图”。每一次判决都可以作为安全信号直接输入内部仪表盘 [14]。
  2. 工作流跨度（Span）异常： 使用LLM可观测性平台检查LLM工作流中的每一个Span [20]。如果一个简单的“信息查询”任务衍生出了“写入操作”的Span，或者往返时间（Round-trip duration）发生显著的异常波动 [25]，则构成高危信号。
  3. 审批阶段跳跃（Approval Step Skipping）： 在编排引擎（如LangGraph）的状态机流转日志中，检测从“意图识别”节点直接跳转至“工具执行”节点，而缺失了“MemorySaver记录人类确认”[4] 的流转事件。

7. 日志与遥测数据 (Logs and Telemetry)

建立标准化的审计跟踪（Audit Trails）不仅是调试的需要，更是实现合规安全审计的前提。目前行业正在推进所有类型Agent的标准化日志模式（Schemas）以防止分析瓶颈 [15]。

7.1 Agent审计日志核心字段

全面的AI审计日志能够告知企业其员工如何使用AI、分享了哪些数据以及触发了哪些安全策略 [26]。根据行业最佳实践，每条日志条目应至少捕获8个关键字段，其中包括：触发命令的来源（Agent source）、授权ID（Grant ID）、请求ID以及以毫秒为单位的往返时长（Round-trip duration）等 [25]。

7.2 SIEM与合规集成要求

为确保日志具备合规性并能有效接入SIEM系统，兼容的AI Agent审计跟踪必须包含以下六个元素 [27]：

  1. Agent身份 (Agent identity)
  2. 人类授权者 (Human authorizer)
  3. 访问的数据 (Data accessed)
  4. 执行的操作 (Operation performed)
  5. 策略评估结果 (Policy evaluation outcome)
  6. 防篡改时间戳 (Tamper-evident timestamp)

7.3 IETF Agent Audit Trail (AAT) 草案格式

根据IETF正在制定的标准，Agent审计跟踪（AAT）定义了基于JSON的记录结构，强制包含Agent身份、动作分类、结果跟踪以及信任级别报告 [28]。 配置代码示例 (AAT JSON结构):

{
  "timestamp": "2023-10-24T12:00:00Z",
  "agent_identity": "vuln-remediation-agent-01",
  "human_authorizer": "user-oauth-subject-id",
  "action_classification": "MCP_TOOL_EXECUTION",
  "data_accessed": "arn:aws:s3:::internal-sec-logs",
  "operation_performed": "READ",
  "policy_evaluation_outcome": "APPROVED",
  "trust_level_report": "VERIFIED_DELEGATION",
  "round_trip_duration_ms": 450
}

8. 缓解措施 (Mitigations)

防范过度代理和审批绕过，必须采取纵深防御（Defense-in-depth）架构 [17]。以下是不同维度的控制措施与权衡分析：

8.1 身份与访问管理 (IAM)

  • 直接委托访问 (Direct Delegated Access)：通过OAuth授权码流程，将每一个AI动作与特定最终用户绑定，保留了直接的“人-机-动作”映射，提供强大的可审计性 [19]。
  • 专属智能体身份 (Agentic Identity)：Agent不应继承管理员权限，而应运行在其专属身份下，操作严格限制在授予该身份的权限内 [21]。

8.2 RAG与数据检索过滤

  • 基于授权的查询过滤：在RAG架构中，引入授权过滤器（如Cerbos提供的方法）以限制从向量数据库提取的信息。查询数据库时，应基于用户的具体授权来过滤适用的文档，确保AI只能检索用户有权查看的数据 [18]。

8.3 运行时与执行安全

  • 独立代理执行沙箱 (Agent Execution Sandbox)：鉴于应用层沙箱的局限性，必须使用专为动态生成代码设计的强隔离沙箱（如基于MicroVM的OS级隔离）来约束Agent运行时权限 [11] [12]。

8.4 强制人类在环 (Forced Human-in-the-Loop)

  • 强制审批检查点：对于财务、合规或访问相关的敏感决策，必须在工具调用前引入中断检查点，暂停Agent执行直至人工审查完成 [22]。在使用 LangGraph 等框架时，利用 MemorySaver 持久化机制准确保存中断时的状态与上下文，防止状态被后续恶意提示篡改 [4]。

缓解策略对比矩阵

控制维度 实施方案 优势 性能与安全权衡 (Tradeoffs)
API 授权 OAuth 直接委托访问 [19] 极强的可审计性与最低权限原则 需要频繁刷新Token，增加架构复杂度和延迟
数据访问 RAG 查询授权过滤 [18] 避免上下文污染，符合数据隐私合规 增加向量检索之前的权限判决延迟
执行环境 动态代码的OS级沙箱隔离 [11] [12] 防止子进程逃逸及底层系统破坏 限制了Agent执行系统级诊断的能力，资源开销大
决策边界 人工审批检查点 (HITL) [22] 彻底解决模型黑盒带来的自主性风险 打破了Agent的完全自治，严重降低全自动化工作流的处理速度

9. 修复任务流程 (Remediation Tasks)

构建针对Agent工具权限滥用的修复工作流，应考虑使用专职的“代理式修复”（Agentic Remediation）平台架构：

  1. 多智能体协作架构 (Multi-Agent Architecture)： 使用多智能体AI架构来处理修复生命周期。可以部署不同的专职Agent——如分诊Agent、根本原因分析Agent、补丁生成Agent、责任人发现Agent及工单路由Agent——相互协作进行漏洞的自动化修复与降级 [23]。
  2. 人工审查的无缝介入： 虽然由多智能体协作生成修复方案，但工作流必须嵌入检查点（Checkpoints），在向生产环境推送访问控制变更（如收缩Agent的IAM角色）之前，暂停执行等待安全专员审批 [22]。

10. 回归测试方案 (Regression-Test Ideas)

防止Agent权限控制相关的漏洞（如被成功利用的审批绕过）在代码迭代中死灰复燃，需要强大的LLM评估框架：

  • 建立“黄金数据集”（Golden Dataset / Golden Sets）： 对于LLM应用，建立包含参考输入和预期输出的“黄金数据集”是一项至关重要的回归测试实践 [34]。
  • 黄金集设计： 黄金集是代表关键功能的精选测试用例集合。针对权限测试，每一个黄金集用例应包含：输入（特定的越权指令或间接提示注入载荷）、可选的预期输出/参考（如“返回API鉴权失败”或“触发人类审批回调”），以及评分标准（Scoring Criteria） [36]。 每次Agent系统的Prompt调整或MCP工具链更新后，均需对照此黄金数据集运行自动化评估框架（如语义相似度对比或模型级评估器 LLM-as-a-judge），确保护栏未被削弱 [34]。

11. 报告写作检查清单 (Report-Writing Checklist)

在为DeepTest撰写Agent安全评估报告（SAR - Security Assessment Report）时，应遵循以下清单以确保高质量交付：

  1. 非行话执行摘要：报告必须包含摘要部分（Summary），以不含术语、通俗易懂的语言为利益相关者提供报告目的和高级别调查结果的概述 [30]。
  2. 动态演进视角：网络安全评估清单本身不应是一份静态文档，而应作为随着威胁、合规标准和IT环境变化而不断发展的“持续工作计划” [29]。
  3. 验证要素清单：
    • 确认是否详细描述了导致漏洞的具体Prompt/Payload。
    • 确认是否明确指出了被规避的信任边界或沙箱机制 [12]。
    • 确认是否提供了违规MCP工具调用的工作流跨度（Span）日志证据 [20]。
    • 确认是否提出了针对性的权限降级（如OAuth委托）建议 [19]。

12. 控制映射 (Control Mappings)

将Agent工具权限控制与国际权威框架对齐，可极大提升企业内部的合规可见度：

  • NIST AI RMF (人工智能风险管理框架)： 旨在将可信度考虑因素（Trustworthiness considerations）纳入AI系统的设计、开发和评估中 [2]。其核心通过四个具体功能来实施风险管理：治理（Govern）、映射（Map）、测量（Measure）和管理（Manage）[3]。 具体映射：针对“审批绕过”引发的风险事件，对应于 MEASURE 3.3：要求建立并整合终端用户和利益相关者的反馈流程，以便报告问题并识别现有及突发的AI风险 [35]。
  • 欧盟《人工智能法案》(EU AI Act)： 严格禁止有害操纵和漏洞利用的行为（第5(1)条，(a)和(b)款）。企业在设计和开发AI Agent时，可能需要部署特定保障措施（Safeguards）以避免这些被禁止的实践 [1]。控制Agent工具权限、防止其被操纵对基础设施发起越权操作，是直接响应欧盟AI法案的核心举措。

13. 残余风险 (Residual Risk)

在部署了上述所有防御控制（严格沙箱、OAuth授权、强制HITL、日志审计）后，组织仍需面对残余风险。

  • 残余风险的定义：是指在组织实施了所有可能的安全控制和缓解策略后，仍然存在的网络安全风险 [31] [32]。它代表了安全控制的局限性 [33]。
  • 在Agent系统中的表现： 由于AI模型的黑盒本质和非确定性输出 [7]，即使具备充足的控制措施，残留的风险遗迹依然不可避免，并且可能导致敏感数据暴露 [24]。例如，极度隐蔽的“零日”多模态提示注入可能在底层模型更新导致其“安全语义对齐”发生微小漂移时，突然成功绕过此前的回归黄金测试集。因此，残余风险要求企业必须持续进行AI系统的动态监控和自适应红蓝对抗。

14. 局限性与开放问题 (Limitations / Open Questions)

尽管本研究涵盖了从日志审计到架构隔离的深层控制，仍存在以下亟待解决的行业局限性：

  1. 人类疲劳与“审批疲劳”：虽强制引入人类在环（HITL），但如果Agent产生海量微小工具调用的审批请求，极易导致操作员的“点击疲劳”，从而在未仔细验证的情况下批准恶意操作。
  2. MCP协议的安全演进：由于MCP（模型上下文协议）设计初衷偏向于敏捷集成而非严格安全隔离，如何在不大幅损失Agent灵活性的情况下对内置服务器协议进行深度安全加固，当前仍是一个未完全解决的研究课题 [6]。
  3. 多模态意图识别的模糊性：现有LLM作为裁判（LLM-as-a-judge）在检测纯文本攻击意图时表现尚可 [14]，但在分析复杂的图像画谜（Rebus puzzles）攻击时仍缺乏标准化的量化指标 [9]。

参考资料与来源 (Sources)

Source Quality Summary Evidence draws on 3 government publications and 33 professional security/technology sector sources.