# 仓库扫描能阻止 AI 智能体安装被投毒的代码库吗？ > 复盘一次受 npm 供应链攻击启发的 AI 智能体安全测试，说明仓库扫描、最小权限与安装审批如何阻止不安全动作。 - Canonical page: [https://veridicuscan.app/zh-cn/ai-agent-security-repo-scan-supply-chain-attack](https://veridicuscan.app/zh-cn/ai-agent-security-repo-scan-supply-chain-attack) - Language: Simplified Chinese - Published: 2026-04-01 - Last materially updated: 2026-05-30 AI 智能体安全测试 我们基于 npm 供应链攻击形态构建了一个安全复盘，测试受保护的仓库审查流程是否能定位高风险文件、降低原始上下文暴露，并在信任建立前拦住安装类动作。 更新于 2026年5月30日 本文包括 - 为什么仓库审查会变成 AI 智能体安全问题 - 这次供应链攻击复盘实际测试了什么 - 受保护流程允许了什么、阻止了什么 - 这个基准能证明什么，不能证明什么 测试结论 ## 短答案：在这个压力测试里可以 在这次安全复盘中，受保护流程把最高风险文件定位到 `packages/plain-crypto-js/package.json`，将默认上下文模式切换为 `sanitized_only`，并在仍允许低风险仓库读取的同时阻止安装步骤。 这对 **AI 智能体安全** 很重要，因为只要智能体可以读取仓库内容并据此采取动作，仓库审查和[提示词注入](https://veridicuscan.app/zh-cn/what-is-prompt-injection)就不再是两个孤立问题。真正的问题变成：智能体能否在不被仓库内容诱导的情况下检查陌生代码库，并在安装前保留人类信任边界。 这不是一个“证明所有供应链风险都消失”的结论。它支持的是更具体、也更容易验证的产品主张：在这个场景中，系统改变了智能体看到的内容、允许使用的工具，以及需要人工批准的动作。 ## 为什么 AI 智能体很难安全审查仓库 人类代码审查通常会先决定检查哪些文件，再判断是否继续扩大范围。AI 智能体则不同：它会读取可见内容，把这些内容并入推理上下文，并且往往还拥有安装、执行、导出或调用工具的能力。 这就是为什么 OWASP 的智能体安全建议会把提示词注入、工具滥用、过度自主和供应链风险放在同一张图里看。对 MCP 工作流来说，文档、元数据、工具返回值与仓库文件都可能成为上下文载荷，把智能体推向未授权动作。 简单说，一旦智能体既能**读取**又能**行动**，可疑仓库就不只是内容，而是攻击面。 ## 这次 npm 供应链攻击复盘测试了什么 我们构建了一个安全、不可执行的复盘场景，保留 npm 供应链攻击中对智能体审查最有价值的形态：表面正常的根包、被注入的辅助依赖，以及一个嵌套 helper 包，其安装路径会改变下游行为。 复盘没有重建真实恶意载荷，而是用基准化的智能体投毒文本替代，从而保持样本惰性，但仍然测试最关键的信任与安装决策路径。 因此问题很直接：智能体会把仓库判定为足够安全并继续安装，还是会在安装前发现嵌套依赖里的高风险文件？ - 根仓库看起来普通，不能只依赖 README 或根 `package.json` - 风险点藏在低显著度的嵌套依赖路径里 - 测试重点不是复现恶意代码，而是复现“审查后是否安装”的决策压力 ## 受保护 repo 扫描发现了什么 仓库经过 Veridicus Scan 的 [MCP 支持](https://veridicuscan.app/zh-cn/mcp-automation) `scan_repo` 路径处理。该路径会合成仓库级工件，优先检查 manifests、workflow 等高信号载体，并返回 `top_risky_files` 与 `requires_explicit_approval_for_install` 等仓库级信号。 在对抗样本上，返回结果符合一个“先审查、后信任”的工作流应该具备的形态： | 受保护输出 | 测得值 | | --- | --- | | 风险等级 | `high` | | 默认上下文模式 | `sanitized_only` | | 安装是否需要审批 | `true` | | 最高风险文件 | `packages/plain-crypto-js/package.json` | ## 基准结果 这个样本量很小，所以不能把它解释成广泛统计证明。但它能支持一个具体结论：在这个场景里，产品确实完成了它声称要完成的工作，即定位风险文件、让智能体停留在较低信任的审查模式，并避免自动安装行为。 | 指标 | 值 | | --- | --- | | 样本数 | 3 | | Precision | 1.0000 | | Recall | 1.0000 | | F1 | 1.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 安全最佳实践](https://veridicuscan.app/zh-cn/mcp-security-best-practices)、[如何降低 AI 智能体中的提示词注入风险](https://veridicuscan.app/zh-cn/how-to-reduce-prompt-injection-risk)和[提示词注入示例](https://veridicuscan.app/zh-cn/prompt-injection-examples)。 - [StepSecurity 对 axios npm compromise 的复盘](https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan) - [StepSecurity 对 tj-actions/changed-files 事件的复盘](https://www.stepsecurity.io/blog/when-changed-files-changed-everything-our-black-hat-2025-presentation-on-the-tj-actions-supply-chain-breach) - [OWASP AI Agent Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) - [OWASP MCP06:2025 Prompt Injection via Contextual Payloads](https://owasp.org/www-project-mcp-top-10/2025/MCP06-2025%E2%80%93Prompt-InjectionviaContextual-Payloads) ## 常见问题 ### 什么是 npm 供应链攻击？ npm 供应链攻击是指 package、发布者账号或依赖路径被攻破，使下游用户从看似可信的来源安装恶意或未经授权的代码。 ### 为什么 AI 智能体在仓库审查时更脆弱？ 因为智能体会把仓库内容并入推理上下文，并且可能拥有能执行动作的工具。恶意 manifest 或 workflow 可以影响计划，过度授权的工具则可能把影响变成安装或执行。 ### repo 扫描能证明一个仓库安全吗？ 不能。repo 扫描可以发现风险文件、降低不受信上下文暴露，并门控危险动作；但不能单独证明外部发布者、注册表工件或可变 tag 从未被攻破。 ### AI 智能体安装仓库前应该做什么？ 至少应该先扫描仓库、定位高风险 manifest 或 workflow、限制自身只使用低风险读取工具，并在任何安装或执行动作前要求明确审批。 关键要点 - 仓库审查是 AI 智能体安全问题，不只是代码审查问题 - 受保护流程在安装前定位了嵌套高风险 manifest - 最小权限保留读取能力，同时阻止安装步骤 - 这个基准证明的是工作流效果，不是通用来源真实性证明 继续阅读 - [返回博客](https://veridicuscan.app/zh-cn/blog) - [MCP 自动化](https://veridicuscan.app/zh-cn/mcp-automation) - [MCP 安全最佳实践](https://veridicuscan.app/zh-cn/mcp-security-best-practices) - [降低提示词注入风险](https://veridicuscan.app/zh-cn/how-to-reduce-prompt-injection-risk)