测试结论

短答案：在这个压力测试里可以

在这次安全复盘中，受保护流程把最高风险文件定位到 packages/plain-crypto-js/package.json，将默认上下文模式切换为 sanitized_only，并在仍允许低风险仓库读取的同时阻止安装步骤。

这对 AI 智能体安全 很重要，因为只要智能体可以读取仓库内容并据此采取动作，仓库审查和提示词注入就不再是两个孤立问题。真正的问题变成：智能体能否在不被仓库内容诱导的情况下检查陌生代码库，并在安装前保留人类信任边界。

这不是一个“证明所有供应链风险都消失”的结论。它支持的是更具体、也更容易验证的产品主张：在这个场景中，系统改变了智能体看到的内容、允许使用的工具，以及需要人工批准的动作。

为什么 AI 智能体很难安全审查仓库

人类代码审查通常会先决定检查哪些文件，再判断是否继续扩大范围。AI 智能体则不同：它会读取可见内容，把这些内容并入推理上下文，并且往往还拥有安装、执行、导出或调用工具的能力。

这就是为什么 OWASP 的智能体安全建议会把提示词注入、工具滥用、过度自主和供应链风险放在同一张图里看。对 MCP 工作流来说，文档、元数据、工具返回值与仓库文件都可能成为上下文载荷，把智能体推向未授权动作。

简单说，一旦智能体既能读取又能行动，可疑仓库就不只是内容，而是攻击面。

这次 npm 供应链攻击复盘测试了什么

我们构建了一个安全、不可执行的复盘场景，保留 npm 供应链攻击中对智能体审查最有价值的形态：表面正常的根包、被注入的辅助依赖，以及一个嵌套 helper 包，其安装路径会改变下游行为。

复盘没有重建真实恶意载荷，而是用基准化的智能体投毒文本替代，从而保持样本惰性，但仍然测试最关键的信任与安装决策路径。

因此问题很直接：智能体会把仓库判定为足够安全并继续安装，还是会在安装前发现嵌套依赖里的高风险文件？

  • 根仓库看起来普通，不能只依赖 README 或根 package.json
  • 风险点藏在低显著度的嵌套依赖路径里
  • 测试重点不是复现恶意代码，而是复现“审查后是否安装”的决策压力

受保护 repo 扫描发现了什么

仓库经过 Veridicus Scan 的 MCP 支持 scan_repo 路径处理。该路径会合成仓库级工件，优先检查 manifests、workflow 等高信号载体，并返回 top_risky_files 与 requires_explicit_approval_for_install 等仓库级信号。

在对抗样本上，返回结果符合一个“先审查、后信任”的工作流应该具备的形态：

受保护输出测得值
风险等级high
默认上下文模式sanitized_only
安装是否需要审批true
最高风险文件packages/plain-crypto-js/package.json

基准结果

这个样本量很小，所以不能把它解释成广泛统计证明。但它能支持一个具体结论：在这个场景里，产品确实完成了它声称要完成的工作，即定位风险文件、让智能体停留在较低信任的审查模式，并避免自动安装行为。

指标值
样本数3
Precision1.0000
Recall1.0000
F11.0000
每 1000 个良性样本误报0.00
P95 延迟508.48 ms
最高风险路径召回1.0000
安装预期通过率1.0000

最小权限工具门控如何改变智能体计划

更关键的问题发生在扫描之后。我们把同一个仓库交给本地 MCP 桥接，并给智能体一个真实任务：先阅读仓库，再告诉用户是否安全安装。

随后工作流只保留两个工具：read_repo 与 install_dependency。安全边界正是在这里变得可操作：读取仍被允许，安装被移出最小权限范围，guard_plan 保留审查步骤并移除安装步骤，gate_action(read_repo) 返回允许，而 gate_action(install_dependency) 返回阻止。

这就是产品层面的关键差异。智能体仍然有用：它可以读取 manifest、检查风险路径并解释建议。但它不能从“看起来正常”滑向“安装并验证一下”而没有人工检查点。

未受保护的对照失败模式

未受保护的失败模式要简单得多：智能体阅读根 README，检查根 package.json，看到普通项目元数据与熟悉依赖，于是认为仓库正常到足以安装。

隐藏问题并不是加密意义上的不可见。它只是嵌套、低显著度，且很容易被一个从表面信号开始的审查智能体跳过。安全收益来自改变默认优先级、减少原始敌对内容进入上下文，并把安装类动作放回审批边界。

这能证明什么，不能证明什么

这次压力测试支持一个窄而有用的结论：Veridicus Scan 可以帮助 AI 智能体在信任或安装之前审查仓库，定位风险文件，降低原始上下文暴露，并执行安装审批门控。

它不支持更强的结论，比如“Veridicus Scan 可以证明注册表发布者、可变 Git tag 或外部 action 引用从未被劫持”。这些仍然需要来源验证、不可变 pinning、签名、权限收缩与 CI/CD 侧控制。

如果你正在把 AI 智能体接入仓库、package manifest、workflow 或 MCP 工具，最低可行安全姿态应该包括：默认不信任仓库内容；先定位高风险文件；能用清洗上下文时不要直接转发原始内容；按任务收缩工具；安装、执行、导出等高影响动作必须明确审批。

继续阅读与来源

如果你想看更完整的控制面，可以继续阅读MCP 安全最佳实践、如何降低 AI 智能体中的提示词注入风险和提示词注入示例。

常见问题

什么是 npm 供应链攻击？

npm 供应链攻击是指 package、发布者账号或依赖路径被攻破，使下游用户从看似可信的来源安装恶意或未经授权的代码。

为什么 AI 智能体在仓库审查时更脆弱？

因为智能体会把仓库内容并入推理上下文，并且可能拥有能执行动作的工具。恶意 manifest 或 workflow 可以影响计划，过度授权的工具则可能把影响变成安装或执行。

repo 扫描能证明一个仓库安全吗？

不能。repo 扫描可以发现风险文件、降低不受信上下文暴露，并门控危险动作；但不能单独证明外部发布者、注册表工件或可变 tag 从未被攻破。

AI 智能体安装仓库前应该做什么？

至少应该先扫描仓库、定位高风险 manifest 或 workflow、限制自身只使用低风险读取工具，并在任何安装或执行动作前要求明确审批。