技术深度解析
为什么SBOM对AI Agent不适用
传统SBOM是一份静态的软件组件清单——库名、版本号和许可证。它对于单体应用效果良好，因为这类应用的依赖关系在构建时确定且保持不变。然而，AI Agent本质截然不同。Agent是一个运行时组合引擎：它选择工具、调用模型、处理数据，这些序列在执行前无法完全预知。例如，一个被要求“总结这份PDF并通过邮件发送结果”的Agent可能会：
1. 调用一个PDF解析工具（如PyMuPDF）
2. 将提取的文本传递给一个语言模型（如GPT-4o）
3. 使用模型的输出触发一个邮件API（如SendGrid）
每一步都涉及一个具有不同安全属性的组件。SBOM会列出PyMuPDF、GPT-4o API和SendGrid SDK，但它无法捕捉到PDF解析器的输出直接流向邮件工具——这是一个关键的数据路径。如果PDF解析器被攻破（例如通过恶意PDF），攻击者可以注入任意文本，模型随后将其传递给邮件API，从而可能从受信任账户发送钓鱼邮件。
组合图架构
组合图是一种有向属性图，其中：
- 节点代表组件：模型、工具、数据源、API端点，甚至子Agent。
- 边代表交互：调用、数据流、控制流和上下文约束。
- 属性捕获元数据：时间戳、权限、输入/输出模式和安全策略。
该图由可观测层在运行时构建，该层拦截所有组件间通信。这类似于微服务中的分布式追踪（如OpenTelemetry），但针对AI Agent工作流进行了定制。关键区别在于，组合图还必须建模语义上下文——例如，哪个模型的输出被用作哪个工具的输入，以及这是否违反了策略。
示例图结构：
```
[PDF解析器] --(输出文本)--> [LLM] --(摘要)--> [邮件API]
[LLM] --(工具调用)--> [网页搜索API]
```
开源工具与仓库
多个项目正在探索组合图：
- LangChain的LangSmith：提供追踪能力，可用于重建Agent执行路径。然而，它主要用于调试，而非安全策略执行。（GitHub: langchain-ai/langsmith，约5k星）
- Cisco的OpenTelemetry for AI：OpenTelemetry标准的扩展，增加了针对模型调用和工具使用的AI专用跨度。仍处于早期阶段。
- Protect AI的Guardian：一个运行时安全层，使用基于图的策略引擎阻止异常Agent行为。（GitHub: protect-ai/guardian，约2k星）
- MIT的VeriAgent：一个研究原型，使用组合图生成Agent行为的形式化证明。尚未公开。
性能基准测试
| 方法 | 检测延迟 | 误报率 | 运行时路径覆盖率 | 更新频率 |
|---|---|---|---|---|
| SBOM（静态） | 不适用（部署前） | 不适用 | 0%（无运行时信息） | 每次发布 |
| 组合图（运行时） | 每次交互50-200ms | 2-5% | 95%以上（完全追踪时） | 实时 |
| 手动审计 | 数小时到数天 | 10-20% | 30-50%（抽样） | 每个审计周期 |
数据要点： 组合图引入了少量延迟开销（每次交互50-200ms），但实现了接近完全的运行时路径覆盖率，而SBOM的这一数字为零。2-5%的误报率通过适当调优可以管理，且远低于手动审计。
关键参与者与案例研究
初创公司与研究团队
- Protect AI：总部位于西雅图，2024年完成3500万美元A轮融资。其产品Guardian使用组合图执行诸如“模型输出不得直接传递给文件写入工具”等策略。他们报告称已捕获一起真实攻击，其中被攻破的PDF解析器试图将恶意脚本写入磁盘。
- HiddenLayer：专注于对抗性机器学习检测，但最近增加了Agent工作流监控。其方法更偏向签名而非基于图。
- MIT CSAIL：VeriAgent项目使用组合图上的形式化验证来证明Agent无法违反安全约束。仍处于学术阶段，但对于高保证应用前景广阔。
案例研究：PDF解析器攻击
2025年初，一家金融服务公司部署了一个AI Agent来自动化发票处理。该Agent使用一个流行的开源PDF解析器（PyMuPDF）提取数据，然后将其传递给一个微调后的LLM进行验证，最后传递给一个支付API。一名攻击者提交了一个恶意PDF，利用PyMuPDF中的缓冲区溢出注入了一个载荷，将LLM的输出替换为向不同账户转账的指令。SBOM列出了PyMuPDF v1.23.4，但漏洞存在于运行时交互中：PDF解析器的输出被信任为安全，并直接传递给了后续组件。组合图本可以检测到这种异常数据流——PDF解析器的输出不应直接触发支付指令——并阻止该交易。