基于区块链的 Agentic AI 框架：面向安全软件供应链的资源优化与能耗感知

核心问题是如何把软件供应链安全检查与安全智能体自身的身份、报告完整性和发布授权连接起来。

• 应用场景：代码仓库、依赖、CI/CD、制品和部署共同构成检查对象。作者认为，攻击可发生在开发与构建阶段，仅检查部署后的系统不够。
• 现有方法：作者称，溯源和签名方案改善了完整性验证，但现有自动化仍难以对异构证据进行推理、学习和动态响应。
• 信任问题：引入 LLM 智能体后，还需要验证报告来源，并处理冒充、报告篡改和证据压制。引言也讨论了智能体消息及工具工作流中的提示注入风险。
• 威胁模型：Threat Model 节列出以下能力与假设。
  • 目标与控制面：攻击者可插入恶意代码或依赖、修改 CI 配置和制品；部分控制 CI/CD 的攻击者可绕过检查、关闭扫描器或破坏日志。
  • 智能体与证据：攻击者可尝试冒充智能体、伪造或修改报告；内部人员或编排层可尝试删除、修改或捏造输出。
  • 受保护系统：对象是软件开发生命周期及其安全智能体。论文未将攻击者知识划为 black-box、white-box 等类别。
  • 信任假设：许可链共识正确、多数验证者诚实、私钥安全；共识失陷和多数验证者串谋不在范围内。
• 提出的方案：AttestChain 将分层安全检查、注册身份、签名证明和链上发布策略组合起来。作者希望把智能体从不透明组件变成可追溯的验证实体。

论文把相关研究组织为供应链完整性、自动化控制与智能体防御，并用 Table 1、Table 2 做设计比较。

供应链设计与溯源

• Okafor 等、Ladisa 等——前者讨论透明性、有效性和分离等安全设计属性，后者分类 OSS 供应链攻击。作者将其分别定位为架构性和描述性研究。
• Tran 等——提出 SBOM 与证明元数据管理的参考架构。作者认为其没有自主推理；正文称其为2023年工作，参考文献 [31] 标为2024年。
• SLSA、in-toto、OpenSSF Scorecard——分别侧重构建溯源、端到端供应链完整性和仓库安全检查。Table 2 将这些框架列为没有显式智能体身份与证明模型。

自动化与工业修复

• ARGO-SLSA，Thariq 与 Ekanayake（2025）——在 Kubernetes 相关 CI/CD 中执行溯源与策略控制。作者将其描述为规则驱动自动化，而非自适应控制。
• JFrog、Lineaje（2025）——介绍包维护、依赖扫描和自动修复智能体。作者称这些工业材料没有提供可复现的学术评测或公开框架。
• 实验基线——实际比较对象是人工审查和传统自动扫描器，环境是受控软件供应链中的合成构建；上述命名框架没有对应的实测结果。

智能体、治理与自主防御

• Ko 等（2025）、Jannelli 等（2024）、Saga——分别讨论跨域多智能体安全挑战、供应链多智能体共识和智能体治理。作者称这些工作不直接面向软件开发流水线。
• Haque 等（2025）、Patnaik 等（2022）——分别研究自动驾驶软件供应链漏洞和硬件安全中的强化学习；作者将其视为领域相关但对象不同的研究。
• Syed 等 [36]、[38]——前者讨论提示注入防护，后者结合 LLM、强化学习、多智能体编排、CI/CD 与区块链账本开展供应链防御。

作者称 AttestChain 补充 [38] 的方向，重点是密码学注册的智能体身份、签名证明和链上发布策略。Table 1 中 Okafor 的年份为2024，而参考文献 [15] 为2022，论文存在年份不一致。

AttestChain 将链下 LLM 安全分析与链上证明及发布策略分开：智能体解释工具结果，证明客户端绑定身份和报告，CI/CD 查询链上决定。

分层智能体与工具推理

• 检查对象：五类智能体分别负责 source、dependencies、CI、artifacts 和 runtime，编排器按 build_id 保存全局状态（Figure 3、Figure 4）。
• LLM 职责：共享 LLM 后端生成分析计划、解释工具输出并形成报告，不直接修改系统；工具包括静态分析、SBOM 生成、漏洞扫描和配置接口。
• 报告生成：Algorithm 1 描述获取上下文、工具调用与追加分析，直到收敛后输出问题、严重度、风险分数和 OK／WARN／FAIL 状态。未给出收敛条件或迭代预算。

身份注册与证明绑定

• 认证通信：每个智能体配置密钥对和由网络 CA 签发的 X.509 证书，AgentRegistry 保存身份与公钥；关键组件之间使用同一 CA 支持的 mTLS。
• 报告证明：证明客户端核验授权，将报告做 SHA-256 哈希并签名，提交 AttestationLog；正文实现部分的载荷包含 build_id、agent_id、层、状态、风险分数和时间戳。
• 链上与链下：链上保留证明，完整报告可存入安全链下存储。作者假设采用 PoA 或 BFT-style 共识，并认为历史证明不能被单方重写或压制。

编排与冲突处理

• 状态写入：每个智能体仅追加自己负责层的不可变 LayerReport；编排器聚合引用，不重写其他智能体的报告。
• 同步屏障：所需层报告齐备后才进入策略评估，超时则标记 MISSING；同层多份报告按 FAIL、WARN、OK、MISSING 的优先次序取有效状态。
• 原型组件：实现使用 Python 3.10、LangChain v0.2、LangGraph v0.1、Pydantic 和 Web3.py，账本可用许可链或内存模拟器。强化学习只在背景和后续方向中讨论，未给出训练实现。

发布策略与文本不一致

• 策略目标：正文示例要求每个必需层至少有一份 OK 证明，且不存在 FAIL；还可结合风险阈值或人工审批。CI/CD 据此允许或阻断发布。
• 伪代码差异：Algorithm 3 第26行在 failLayers 为空时进入“存在失败层”的阻断分支，与正文规则相反；第20行选择同层一份证明，也未写出实现节的最坏状态合并规则。
• 字段差异：Algorithm 3 使用证明的 risk 字段，但 Algorithm 2 的载荷未列该字段；实现节则包含 risk score。论文未报告阈值 τ 的具体值。

Figure 5 图注及正文用源码检查案例串联仓库分析、报告签名、链上记录和发布查询。提供的文本没有保留图内连线与布局，不能据此核对图形是否与全部规则一致。

实验比较了受控供应链上的人工审查、自动扫描和 AttestChain；可读文本提供了总体相对变化与发布拦截数。

实验设置

• LLM 与智能体：五个 LangGraph 安全智能体使用 GPT-class LLM，经 LangChain 调用工具；论文未报告具体模型名称、版本或采样设置。
• 供应链环境：Git 仓库含200+次提交，依赖清单含48个第三方库，GitHub Actions 有14个工作流步骤；另含 Docker 构建和 Kubernetes 清单模拟部署。
• 工作负载：500次合成构建，每次注入一至三个问题，分布于源码、依赖、CI、制品和运行时配置；作者称各构建在相同条件下分析。
• 比较对象：人工审查、传统自动扫描器，以及带区块链证明的 LLM 多智能体方案。未报告扫描器名称或人工审查人数。
• 指标与判定：指标为分层检测覆盖、平均每构建验证时间、不安全发布拦截数、缺失或无效证明数。未给出覆盖率计算式、独立评审模型或人工一致性。
• 账本与重复：采用许可链证明层，假设 PoA 或 BFT-style 共识；论文未明确实际选用哪一种，也未报告重复次数或统计显著性检验。

主结果

下表数字来自 Results and Evaluation 正文、图注及 Summary of Findings；并非从不可见的柱高读取。模型仅标为 GPT-class LLM。

Swipe horizontally to read the table

方法与条件	指标	作者报告结果	出处
AttestChain，合成供应链构建，相对传统扫描	检测覆盖增加	38%	Figure 6 对应正文、Summary of Findings
AttestChain，合成供应链构建，相对传统自动扫描	验证时间减少	39%	Figure 7 图注
AttestChain，500次模拟构建，链上发布策略	拦截自动扫描会放行的不安全发布	23	Figure 8 对应正文

• 覆盖解释：作者将检测增幅归因于 LLM 的上下文推理和多智能体分析，尤其是对语义风险的检查。Figure 6 对应正文写“about 38%”，总结节写“38%”。
• 时间解释：作者将验证时间减少归因于并行分层分析与编排；未报告人工审查、扫描器和 AttestChain 的绝对平均耗时。
• 读图边界：转换文本仅保留 Figure 6–8 图注，未保留轴、图例和各柱数值，因而不能核对逐层差异、各基线总量或拦截原因的分项计数。

发布策略与证明完整性

• 测量对象：作者以500次具有不同安全状态证明的模拟构建评估策略门控，讨论缺失证明和智能体报告失败导致的阻断（Figure 8 正文）。
• 证明结果：Summary of Findings 报告“Zero false attestations”，并将其归因于身份密码学绑定和链上记录；未说明这一指标的分母、测试攻击集合或与“无效证明”的关系。
• 判定范围：引言讨论了提示注入风险，但结果节没有给出独立的提示注入成功率或防护结果，也未报告自适应攻击评测协议。

区块链时延

• 实现报告：Attestation and Blockchain Integration 节称实验中的区块确认时延为数百毫秒到数秒，并认为适合 CI/CD 门控且不在构建关键路径上。
• 数值边界：论文未提供确认时延的测量表、分布、节点数或对端到端时间的单独贡献，无法把这段描述与 Figure 7 的时间降幅进一步拆分。

其他消融与分析

• 消融报告：论文未提供移除 LLM、移除区块链、改变智能体数目或改变模型的消融数值。
• 失败与例外：未报告具体失败案例、误报率或逐层漏检计数；Algorithm 3 的规则不一致见第3问，实验未说明执行的是哪个版本。

作者明确讨论的后续方向集中在计算开销、模型推理、密钥保护、合约验证和扩展部署。

作者指出的局限与后续方向

• 查询开销：Discussion 指出系统继承了 LLM 查询的计算开销，并行只能部分抵消；后续可探索模型蒸馏。
• 推理依赖：Discussion 指出智能体推理质量取决于提示词设计及所选模型的语义能力，提出用图结构或强化学习智能体扩展跨层推理。
• 特权密钥：Discussion 指出区块链不可变性不能防止所有内部威胁，尤其是特权私钥滥用；后续可探索硬件支持的密钥存储。
• 合约验证：Implementation 的 Attestation and Blockchain Integration 小节明确将智能合约形式化验证放在当前范围之外，留待后续改进。
• 组织与监控：Conclusion 计划扩展到分布式开发组织，并集成运行时行为监控。
• 证明对象：Conclusion 计划把证明模型扩展到生成式和自适应智能体。

实验覆盖范围

• 数据规模：Evaluation Setup 使用500次合成构建，每次注入一至三个问题，检查五个 SDLC 层；不是论文命名的公开基准。
• 比较范围：Results and Evaluation 比较人工审查、传统扫描和完整 AttestChain；Table 2 是框架设计比较，没有这些框架的实测成绩。
• 模型报告：Evaluation Setup 只写 GPT-class LLM；未报告具体版本、采样设置、分析迭代预算和调用次数。
• 评测报告：未报告重复次数、统计检验、检测覆盖计算式、误报率或评审与人工的一致性；Figure 6–8 的图内数值在提供文本中不可见。
• 信任条件：Threat Model 假设多数验证者诚实、共识正确和私钥安全，明确排除共识失陷及多数验证者串谋。

AttestChain 是一个把 LLM 安全检查、智能体身份验证和许可链发布策略连接起来的软件供应链防御框架。

• 问题定位：作者希望检查源码、依赖、CI、制品与运行时配置，同时避免安全智能体的身份和报告成为不可追溯的信任环节。
• 方法结构：分层智能体生成结构化报告，客户端对报告做哈希和签名，AgentRegistry 与 AttestationLog 保存身份和证明，ReleasePolicy 向 CI/CD 返回发布决定。
• 检测结果：在受控供应链的合成构建中，作者报告 AttestChain 相对传统扫描的检测覆盖增加38%（Figure 6 对应正文、Summary of Findings）；未提供可读的逐层检测数。
• 时间与门控：同一评测中，作者报告相对传统自动扫描的验证时间减少39%（Figure 7 图注）；在500次模拟构建中拦截23次自动扫描会放行的不安全发布（Figure 8 正文）。
• 证明结果：作者报告“Zero false attestations”（Summary of Findings），但没有给出该项分母和测试协议。发布策略伪代码的失败层条件与正文相反，论文未交代实验所用版本。
• 结论边界：作者认为可验证、不可变和可审计的行动证据有助于可信自主系统。作者同时指出 LLM 开销、提示词与模型能力依赖及特权密钥风险；具体 LLM、重复次数和统计检验未报告。