【大模型安全实战】智能体安全的攻防二元性：同一种能力，为什么既是防线也是攻击面？（第4期）

专栏：智能体攻防卷·进阶
主题：攻防二元性
作者：Valhalla Matrix治理实验室
论文锚点：LLM Agents Security Duality: A Comprehensive Survey of Self-Security and Empirical…，arXiv:2606.28450
文章类型：原创技术分析
适合读者：AI 工程师、安全工程师、架构师、技术负责人

本文讨论的是 AI Agent 的安全设计方法，不提供针对真实系统的攻击步骤。文中的攻击面分析用于风险识别、防护设计和安全测试。

---

摘要

AI Agent 正从“生成文本”逐渐发展为能够理解任务、制定计划、调用工具、访问文件、操作网络和管理长期记忆的复杂执行系统。

能力的增加带来了效率提升，也扩大了潜在风险。一个 Agent 越能理解上下文，越可能识别复杂攻击；但同样的理解能力，也可能被用于构造更精准的提示注入。一个 Agent 越能调用工具，越能自动化完成任务；但一旦权限控制失效，也可能执行超出用户意图的操作。

这种现象可以概括为：

Agent 的许多能力同时具有防御价值和攻击价值。

本文将这种现象称为“攻防二元性”，并从能力识别、威胁建模、权限控制、运行时验证和安全测试五个方面，说明如何把“能力越强、风险越大”的抽象判断，转化为可执行的工程方法。

---

一、什么是 Agent 的攻防二元性？

传统软件安全中，功能通常被理解为相对固定的能力。例如：

• 身份认证用于阻止未授权访问；
• 日志系统用于追踪异常行为；
• 文件系统用于保存数据；
• 网络接口用于提供服务。

但 AI Agent 的能力具有更强的上下文依赖性。相同的能力，可能因为调用者、输入内容、权限范围和执行环境不同，产生完全不同的结果。

可以用下面的公式描述：

[
\text{实际风险}

f(\text{能力},\ \text{输入},\ \text{权限},\ \text{环境},\ \text{意图})
]

其中，“能力”只是风险的一部分。真正决定结果的，还包括：

• 谁在调用；
• 输入是否可信；
• Agent 能访问哪些资源；
• 工具是否有副作用；
• 是否需要人工审批；
• 执行结果是否经过验证。

示例：工具调用

能力：调用工具

防御用途：

• 自动检查代码；
• 扫描配置；
• 分析日志；
• 修复低风险格式问题；
• 执行安全巡检。

攻击用途：

• 诱导 Agent 读取敏感文件；
• 构造越权命令；
• 修改安全配置；
• 访问未授权网络资源；
• 将数据发送到外部服务。

因此，不能简单地说“工具调用能力是安全能力”或“工具调用能力是危险能力”。

更准确的说法是：

工具调用是一种高价值、高风险的通用能力，其安全性取决于权限、边界和执行环境。

---

二、三类典型能力的双向影响

1. 自主规划

维度	防御价值	潜在攻击面
任务规划	自动拆解复杂安全任务	被错误目标诱导
步骤编排	提高巡检和响应效率	形成未经授权的操作链
失败恢复	提升任务连续性	在错误方向上重复执行
多工具协作	自动完成复杂流程	放大工具组合风险

自主规划的风险不只是“计划错了一步”，而是错误计划可能连续调用多个工具，形成副作用链路：

读取配置
  → 发现凭证
  → 生成脚本
  → 执行命令
  → 上传结果

每一步单独观察时可能都不明显，但组合起来就可能造成严重后果。

2. 工具调用

维度	防御价值	潜在攻击面
文件工具	分析代码和文档	越权读取或写入
Shell 工具	自动运行测试和检查	命令注入或危险操作
网络工具	查询漏洞和官方文档	数据外传或恶意内容进入上下文
数据库工具	自动完成查询和分析	未授权读取或数据修改

工具越接近操作系统，越不能只依赖系统提示词进行约束。

3. 长期记忆

维度	防御价值	潜在攻击面
历史经验	减少重复分析	污染后续任务
用户偏好	提升交互效率	泄露个人或业务信息
安全规则	保留防护经验	旧规则长期失效
会话上下文	支持任务恢复	跨用户或跨租户混淆

长期记忆尤其需要来源、可信度和有效期。未经验证的外部文本不应直接升级为永久 Agent 规则。

---

三、一个常见误区：能力越多，系统就越安全

很多团队在建设 Agent 时，会自然采用这样的思路：

增加更多工具
  → Agent 能做更多事情
  → 自动化程度提高
  → 系统更强
  → 系统更安全

问题在于，中间缺少了权限和验证环节。

更合理的关系是：

能力增加
  → 可执行范围扩大
  → 攻击面扩大
  → 需要更细的权限控制
  → 需要更强的运行时验证
  → 才可能获得可控的自动化收益

可以将 Agent 的有效安全能力表示为：

[
\text{有效安全能力}

\text{基础能力}
\times
\text{边界控制}
\times
\text{结果验证}
]

如果边界控制或结果验证接近于零，基础能力再强，也无法形成可靠的安全收益。

---

四、从“控制能力”转向“控制用途”

面对高风险能力，常见的两种做法是：

做法一：完全关闭能力

例如：

• 禁止所有 Shell；
• 禁止所有网络访问；
• 禁止 Agent 读取文件；
• 禁止子代理；
• 禁止长期记忆。

这种方法简单，但会明显降低系统实用性。

做法二：保留能力，限制用途

例如：

• 只允许读取当前工作区；
• 只允许执行固定命令；
• 网络默认关闭，仅开放指定域名；
• 写文件前要求用户确认；
• 凭证按任务临时发放；
• 高风险操作需要二次审批；
• 外部内容只能作为不可信数据进入上下文。

第二种方法更适合企业系统，但需要更完整的权限模型。

---

五、用途边界应该如何设计？

1. 工具级边界

每个工具都应有独立的权限描述，而不是由 Agent 统一继承全部能力。

一个简化的工具权限模型如下：

tool: file-reader
permissions:
  filesystem:
    mode: read
    roots:
      - workspace
  network: deny
  credentials: deny
  approval: not_required

对于修改文件的工具：

tool: file-editor
permissions:
  filesystem:
    mode: write
    roots:
      - workspace
  network: deny
  credentials: deny
  approval: required

对于 Shell 工具：

tool: shell
permissions:
  filesystem:
    read:
      - workspace
    write:
      - workspace/tmp
  network:
    mode: deny_by_default
  process:
    timeout: 60s
    max_children: 4
  approval:
    required_for:
      - package_install
      - git_push
      - deployment

这里的关键不是配置格式，而是治理原则：

工具应主动声明需要什么权限，策略系统负责决定是否授予。

2. 数据级边界

仅限制工具还不够，还要限制工具可以处理哪些数据。

建议为输入和输出增加数据标签：

data:
  classification: internal
  tenant: team-a
  source: workspace
  allowed_destinations:
    - local-session
    - approved-report

对于包含凭证、个人信息或生产数据的内容，应增加：

• 脱敏；
• 出口检测；
• 目的地限制；
• 审批；
• 审计；
• 自动过期。

3. 任务级边界

权限不应只绑定 Agent，还应绑定具体任务。

例如，同一个 Agent 在不同任务中可能拥有不同权限：

任务 A：代码阅读
  文件：只读
  Shell：禁止
  网络：禁止

任务 B：运行测试
  文件：工作区读写
  Shell：允许白名单命令
  网络：仅允许依赖镜像

任务 C：发布服务
  文件：受限
  Shell：受限
  网络：受限
  凭证：短期、审批后发放

任务完成后，权限应自动回收。

---

六、最小案例：文档总结能力的两面

假设一个 Agent 具备“读取并总结文档”的能力。

正常路径

用户指定文档
  → Agent 验证路径
  → 读取授权范围内的文件
  → 提取关键信息
  → 输出摘要

防御价值包括：

• 快速分析安全文档；
• 从日志中提取异常；
• 比较配置变化；
• 汇总代码审查结果；
• 生成项目知识摘要。

风险路径

外部文档包含恶意指令
  → Agent 将文档内容误认为系统指令
  → 继续读取其他文件
  → 将敏感信息放入输出

问题并不在“读取文档”这个功能，而在于：

• 文档内容和系统指令没有区分；
• 文件路径没有限制；
• 输出没有敏感信息检测；
• Agent 没有执行前的权限确认；
• 读取和外传被错误地串联起来。

改进后的安全路径

用户请求
  → 校验用户身份和工作区
  → 校验目标路径
  → 将文档标记为不可信数据
  → 禁止文档内容修改系统策略
  → 执行摘要任务
  → 对输出进行敏感信息检测
  → 记录工具调用和数据范围

此时，系统保留了总结能力，同时降低了越权读取和数据外泄风险。

---

七、对 Agent 进行双向威胁建模

建议每增加一种 Agent 能力，都填写一张“能力双向评估表”。

项目	需要回答的问题
能力名称	该能力具体做什么？
正常用途	它为用户解决什么问题？
输入来源	输入来自用户、模型、文件还是网络？
防御价值	它可以帮助发现或阻止什么问题？
攻击面	被滥用后可能造成什么后果？
所需权限	需要文件、网络、Shell、凭证还是数据库权限？
组合风险	与哪些其他能力组合后会放大风险？
约束方式	通过白名单、沙箱、审批还是数据标签限制？
结果验证	如何确认输出没有越权或错误副作用？
回滚方式	操作失败后能否恢复？
审计信息	是否记录调用者、参数、结果和权限决策？

这张表的价值在于：它迫使团队同时考虑“这个能力能做什么”和“这个能力可能被如何利用”。

---

八、四个工程控制点

1. 输入不等于指令

Agent 可能从以下位置读取文本：

• 用户消息；
• 代码注释；
• README；
• Issue；
• 网页；
• 日志；
• 文档；
• 工具返回值；
• 数据库记录。

这些内容都不应自动获得系统指令级别的信任。

推荐区分三类信息：

系统策略：可信
用户请求：受身份和权限约束
外部内容：默认不可信，仅作为数据

即使外部内容包含“请执行某命令”之类的句子，也应被视为待分析文本，而不是授权指令。

2. 工具调用必须重新授权

模型提出工具调用，并不等于工具调用已经获得授权。

应经过：

模型提议
  → 参数校验
  → 权限计算
  → 风险分级
  → 用户或策略批准
  → 沙箱执行
  → 输出检查

尤其需要防止：

• 模型自行批准高风险操作；
• 工具 A 间接绕过工具 B 的权限；
• 子代理继承过多权限；
• 重试机制重复执行写操作；
• 工具输出未经处理直接回到高信任上下文。

3. 结果也需要验证

防护不能只发生在执行前，工具输出同样需要检查：

• 是否包含凭证；
• 是否包含系统提示词；
• 是否包含恶意指令；
• 是否超出任务范围；
• 是否来自预期资源；
• 是否应该写入长期记忆；
• 是否可以直接展示给用户。

对于高风险操作，建议使用结构化结果：

{
  "status": "completed",
  "changed_files": [],
  "side_effects": [],
  "warnings": [],
  "requires_review": false
}

结构化结果比让 Agent 自由解释执行状态更容易审计。

4. 失败和中断必须安全

一个成熟的 Agent 系统不仅要处理成功路径，还要处理：

• 模型超时；
• 工具超时；
• 网络中断；
• 用户取消；
• 子进程异常；
• 插件崩溃；
• 会话恢复；
• 重试；
• 部分写入；
• 凭证回收失败。

必须明确：

任务失败后是否重试？
写操作是否幂等？
进程是否被回收？
临时文件是否删除？
凭证是否失效？
会话是否记录真实状态？

---

九、三个容易被忽视的结论

结论一：减少能力不一定等于提高安全

关闭所有工具当然可以降低部分风险，但也会让 Agent 失去实际价值。

更合理的工程目标是：

保留必要能力
+
缩小权限范围
+
限制数据出口
+
增加运行时验证
+
保留人工接管能力

结论二：能力边界比能力数量更重要

一个拥有十个权限清晰工具的 Agent，可能比一个拥有一百个无边界工具的 Agent 更安全、更稳定。

评价能力时，应关注：

• 权限是否最小；
• 操作是否可逆；
• 输出是否可审计；
• 风险是否可分级；
• 失败是否可恢复。

结论三：攻防双方会使用相似的自动化能力

防守方可能使用 Agent：

• 分析日志；
• 识别异常；
• 归并告警；
• 检查配置；
• 生成修复建议。

攻击方也可能使用类似的自动化能力：

• 识别暴露面；
• 生成变体；
• 归并目标信息；
• 自动尝试错误配置；
• 扩展攻击范围。

因此，防守体系不能只依赖“对手不会使用自动化工具”这一假设。更重要的是：

• 限制系统被滥用的权限；
• 提高异常行为的可见性；
• 缩短检测和响应时间；
• 对高风险动作保留人工控制。

---

十、落地检查清单

能力上线前

• 明确能力的正常用途；
• 列出输入来源；
• 列出所有外部副作用；
• 标注文件、网络、Shell 和凭证权限；
• 明确是否允许被其他 Skill 调用；
• 设计拒绝路径；
• 增加调用和结果审计；
• 为不可逆操作配置人工审批。

工具调用时

• 模型输出不直接执行；
• 参数经过结构化校验；
• 路径经过规范化和边界检查；
• 命令参数避免字符串拼接；
• 环境变量使用白名单；
• 网络访问默认限制；
• 工具超时后回收子进程；
• 结果经过敏感信息检测。

Skill 管理时

• 记录来源和版本；
• 保留变更记录；
• 明确依赖；
• 标注权限；
• 设置有效期；
• 支持撤销和回滚；
• 禁止未经审核的自动升级；
• 对外部内容进行不可信标记。

---

十一、总结

AI Agent 的安全问题，不能简单归结为“模型是否安全”或“工具是否危险”。

更准确的理解是：

同一种能力，既可能帮助系统发现问题，也可能在边界失效时放大问题。

自主规划可以提升响应效率，也可能形成错误的执行链；工具调用可以自动完成任务，也可能造成越权操作；长期记忆可以积累经验，也可能保存污染内容和敏感信息。

因此，Agent 安全建设的重点不是一味减少能力，而是建立完整的用途边界：

能力定义
  → 权限声明
  → 输入分级
  → 工具授权
  → 沙箱执行
  → 输出检查
  → 失败恢复
  → 审计追踪

最终可以用一句话概括：

能力决定 Agent 能做什么，边界决定 Agent 最终会做什么。

当团队评估一个新的 Agent 能力时，至少要同时回答两个问题：

1. 这个能力能够帮助我们解决什么问题？
2. 如果输入、权限或运行环境被滥用，它最坏会造成什么后果？

只有把这两个问题放在同一张设计表中，才能真正理解 Agent 的攻防二元性，并将其转化为可执行的工程控制。

---

延伸阅读

• LLM Agents Security Duality: A Comprehensive Survey of Self-Security and Empirical…，arXiv:2606.28450
• OWASP Top 10 for LLM Applications
• OWASP Agentic Applications Security
• NIST AI Risk Management Framework
• MITRE ATLAS

本文仅用于安全设计、风险识别和防护研究。实际系统应结合自身数据、权限、网络和部署环境进行独立评估。