【大模型安全实战】智能体安全治理进阶:如何回答“哪道防线挡住了哪种威胁”(第5期)

本文讨论一种面向 AI Agent 的安全治理方法:威胁归因(Threat Attribution)。核心目标不是继续堆叠安全组件,而是建立“威胁—防线—证据—责任”的可核对关系。

适合读者:AI 工程师、平台架构师、安全负责人、研发管理者。

说明:本文基于公开安全治理思路整理,示例用于方法说明,不构成安全审计结论。具体平台的推荐、质量分和活动规则可能动态调整,发布前应以 CSDN 当前公开规则为准。
作者:Valhalla Matrix治理实验室

一、为什么安全防线越来越多,风险却没有变得更清晰

在 AI Agent 系统中,团队通常会部署很多安全措施:

  • 输入过滤;
  • Prompt 边界约束;
  • 工具权限控制;
  • 文件系统沙箱;
  • 网络出口限制;
  • 凭证隔离;
  • 供应链扫描;
  • 输出检测;
  • 审批和审计日志。

问题在于,很多团队只能回答“我们部署了哪些防线”,却回答不了三个更关键的问题:

  1. 某个具体威胁由哪道防线承接?
  2. 这道防线在什么条件下生效?
  3. 如何证明它确实阻断或降低了风险?

如果没有这些信息,安全建设很容易变成组件清单。组件越多,报告越厚,但盲区、重复建设和责任不清的问题仍然存在。

因此,Agent 安全治理需要从“防线堆叠”转向“威胁归因”。

二、什么是威胁归因

威胁归因并不是追踪攻击者身份,而是回答:

一个已识别的威胁,究竟由哪一层控制措施负责降低风险?

可以把它抽象成一张映射表:

威胁场景 主要防线 生效条件 验证证据
外部文本诱导 Agent 越权 指令分层、工具授权 外部内容不能改变系统策略 对抗样本测试、拒绝日志
Agent 读取敏感文件 文件范围策略、沙箱 文件访问必须经过策略检查 越界访问测试
Agent 执行危险命令 命令白名单、审批、进程隔离 命令参数和工作目录受控 命令审计、阻断记录
Skill 引入恶意行为 来源审核、版本锁定、签名 未审计 Skill 不得自动加载 清单、哈希、撤销记录
凭证进入模型上下文 凭证代理、脱敏、最小权限 模型只获得必要结果 日志脱敏测试、凭证访问记录
工具失败导致重复副作用 幂等设计、检查点、补偿机制 重试前能够判断执行状态 中断恢复测试

这张表的价值不在于形式,而在于把每项安全承诺变成可验证的工程责任。

三、为什么归因比“增加更多防线”更重要

1. 它能暴露未覆盖的威胁

如果威胁清单中存在“无对应防线”的项目,就意味着当前体系存在明确缺口。例如,团队可能已经部署了 Prompt 过滤,却没有限制工具的文件访问范围。这样只能降低部分诱导风险,无法阻止 Agent 直接访问敏感资源。

2. 它能发现重复建设

多个组件可能都声称能够防止命令注入,但它们可能检查的是不同阶段:一个检查文本,一个检查命令参数,另一个只记录日志。若没有归因,团队很难判断哪些控制措施互补,哪些只是重复。

3. 它能建立责任边界

安全措施必须明确责任主体:平台负责工具授权,执行器负责沙箱隔离,凭证系统负责短期令牌,业务系统负责最终审批。发生问题时,才能根据证据判断是策略未配置、执行器绕过,还是日志缺失。

四、建立威胁—防线映射的五个步骤

第一步:定义威胁清单

威胁清单应结合实际业务,而不是机械复制通用目录。至少覆盖:

  • Prompt Injection;
  • 敏感信息暴露;
  • 供应链和 Skill 风险;
  • 过度授权;
  • 不安全工具调用;
  • 文件和网络越权;
  • 凭证滥用;
  • 会话或记忆污染;
  • 重试导致的重复副作用;
  • 审计和追责缺失。

每个威胁都应写成具体场景,例如“来自网页内容的指令诱导 Agent 读取工作区外的密钥文件”,而不是只写“Prompt 注入风险”。

第二步:盘点防线

防线可以按位置分为四类:

输入侧:内容标记、来源识别、指令分层
决策侧:策略引擎、工具授权、审批机制
执行侧:沙箱、路径限制、网络隔离、资源限制
结果侧:输出检查、日志审计、状态回滚、告警

第三步:记录生效条件

任何防线都不是无条件有效的。需要明确:

  • 它在哪个调用阶段执行;
  • 是否覆盖所有入口;
  • 是否覆盖子代理;
  • 是否能被插件绕过;
  • 失败时是拒绝还是放行;
  • 是否依赖配置、凭证或外部服务。

第四步:绑定证据

没有证据的防线只能算设计意图。证据可以包括:

  • 单元测试;
  • 集成测试;
  • 对抗性测试;
  • 运行日志;
  • 策略命中记录;
  • 发布清单;
  • 权限配置;
  • 事故演练结果。

第五步:生成缺口和冗余清单

最终输出不应只是“覆盖率 90%”,而应列出:

未覆盖威胁:3 项
仅有设计、没有测试证据:5 项
只覆盖部分入口:4 项
存在重复防线:2 项
高风险路径缺少人工审批:1 项

这种结果比一个没有计算口径的百分比更有决策价值。

五、Agent 系统中最容易被忽略的三类边界

1. 权限跟随 Agent,而不是跟随工具调用

如果 Agent 启动时就获得文件、Shell、网络和凭证的全部权限,那么后续任何 Prompt 注入或恶意 Skill 都可能扩大影响范围。

更合理的流程是:

解析工具调用
→ 识别资源和操作类型
→ 计算最小权限
→ 检查策略或人工批准
→ 创建短期执行上下文
→ 执行并回收权限

Skill 只能申请权限,不能自行授予权限。

2. “已过滤输入”不等于“工具安全”

输入过滤即使有效,也不能替代执行层控制。攻击者可能通过文件名、网页内容、工具返回值或历史记忆影响 Agent。最终仍应在工具执行前检查:

  • 目标资源;
  • 操作类型;
  • 参数范围;
  • 当前任务身份;
  • 用户审批状态;
  • 沙箱和网络策略。

3. 日志存在不等于可追责

高质量审计日志至少应关联:

task_id
agent_id
skill_id
tool_name
permission_decision
resource_scope
execution_status
approval_id
sandbox_id
time_window

同时需要避免把完整 Token、隐私数据和未经脱敏的模型上下文写入日志。

六、一个可落地的检查器设计

可以用结构化数据维护威胁和防线关系:

threat: workspace-boundary-bypass
defenses:
  - id: canonical-path-check
    layer: execution
    owner: sandbox-runtime
    status: implemented
    evidence:
      - path-traversal-test
      - symlink-boundary-test
  - id: approval-gate
    layer: decision
    owner: policy-engine
    status: partial
    evidence:
      - manual-approval-test
coverage:
  state: partial
  gaps:
    - subagent-path-access

检查器可以定期回答:

  • 每个高风险威胁是否至少有一条有效防线;
  • 每条防线是否有负责人;
  • 是否存在测试证据;
  • 是否覆盖 CLI、Web、API 和子代理入口;
  • 防线变更后是否需要重新验证。

七、常见误区

误区一:静态规则命中数量等于漏洞数量

静态命中只是复核线索。必须结合数据来源、调用链、权限上下文和部署路径确认可达性。

误区二:防线数量越多越安全

没有明确归属、边界和证据的防线可能只增加维护成本,甚至产生错误安全感。

误区三:一次测试通过就代表长期有效

Agent 系统的 Skill、模型、插件、策略和依赖都会变化。威胁映射必须纳入版本管理和持续回归。

误区四:只审查单个工具,不审查工具组合

“读文件 + 文本处理 + 写配置 + 执行命令 + 网络访问”组合起来,可能形成完整的数据外传路径。安全评估应覆盖调用序列和权限累积。

八、推荐的最小落地方案

对于还没有成熟治理体系的团队,可以先完成四张表:

  1. 威胁清单:列出真实业务场景和风险等级;
  2. 防线清单:记录控制措施、负责人和生效层;
  3. 证据清单:绑定测试、日志和配置;
  4. 缺口清单:标记未覆盖、部分覆盖和待验证项目。

优先处理以下高风险路径:

  • 模型输出直接进入 Shell;
  • Skill 可以读取任意文件;
  • 子代理继承全部父代理权限;
  • 长期凭证进入模型上下文;
  • 重试可能重复执行发布、写入或删除操作;
  • 插件可以绕过统一审批;
  • 审计日志无法关联具体任务和工具调用。

九、结语

Agent 安全建设的难点,不是缺少安全组件,而是缺少一套能够解释、验证和持续维护的关系模型。

威胁归因提供了一个清晰的起点:

威胁可描述
→ 防线有归属
→ 条件可说明
→ 证据可复核
→ 缺口可排序
→ 变更可回归

当团队能够准确回答“哪道防线负责哪个威胁,以及凭什么认为它有效”时,安全治理才真正从口号进入工程阶段。

对于 AI Agent,最重要的目标不是让系统永远不犯错,而是让高风险行为具备最小权限、明确审批、可观测执行和可恢复结果。

参考与发布建议

  • 可结合 OWASP LLM 相关风险分类建立本地威胁清单;
  • 对论文、标准和公开资料应保留原始链接及访问日期;
  • 发布前应核对代码示例、术语、图片和引用来源;
  • 不要将演示性映射表表述为完整安全审计;
  • 建议使用“威胁归因”“Agent 安全”“工具调用安全”“权限治理”“Prompt Injection”等标签。

#AI安全 #AIAgent #智能体 #PromptInjection #软件供应链安全 #权限治理 #安全工程

Logo

中国智能体开发者社区,聚焦智能体与大模型开发,提供前沿资讯、实用工具链、开源项目及行业案例。通过技术沙龙、开发者大赛等活动,促进经验交流与协作,助力开发者快速构建创新智能应用。

更多推荐