AI代理配置安全就是供应链安全

2026年4月29日，安全团队报告称，SAP生态系统中的部分软件包遭到入侵，影响并未止步于凭据窃取。Mini Shai-Hulud攻击还把持久化逻辑写入了开发者配置：Claude Code钩子、VS Code任务，以及代码仓库工作流文件。¹²³

这个细节改变了审查边界。被投毒的软件包不必一直保留在项目里，只要它能在开发者信任的文件中留下启动命令即可。删除依赖项也许能移除第一次触发，但代理或编辑器配置仍可能保留下下一次触发。

AI代理配置是可执行软件。每一个钩子、任务、MCP服务器定义、技能、插件、软件包脚本和工作流文件，都应视为软件供应链的一部分，因为这些文件可能决定在人类读到差异之前先运行什么代码。

要点速览

Mini Shai-Hulud展示了一条从依赖安装到开发工具持久化的现实路径。安全研究人员报告称，恶意npm软件包会在安装期间使用生命周期脚本，收集开发者和CI凭据，并写入.claude/settings.json与.vscode/tasks.json文件，从受信任的开发者界面重新运行代码。¹²⁴官方文档也确认了这些底层界面确实具备执行权限：Claude Code钩子会运行生命周期命令，命令钩子以用户权限执行；而VS Code的folderOpen任务，在用户允许该文件夹自动任务后，可以在文件夹打开时运行。⁵⁶

教训不是“关闭代理”。更准确的教训是：代理配置应进入依赖审查、代码审查、事件响应和发布关口。过去看起来像本地偏好的点目录，如今已经位于执行路径上。严肃的AI工程实践需要配置差异审查、钩子审查、任务审查、最小权限令牌，以及启动界面审计。

核心结论

面向开发者： - 在信任代码仓库之前，审查.claude/settings.json、.vscode/tasks.json、.github/workflows/*、package.json脚本、MCP配置，以及代理插件或技能清单。 - 像审查新的可执行文件一样，审查新的启动钩子和文件夹打开任务。 - 发生可疑安装后，删除持久化文件并轮换凭据。仅仅删除软件包并不能证明清理完成。

面向安全团队： - 将代理配置文件纳入供应链检测、CODEOWNERS、密钥响应和事件范围界定。 - 标记任何新增启动执行、宽泛shell命令、不透明下载二进制文件，或隐藏点目录载荷的PR。 - 优先使用短期发布凭据和只读安装凭据。长期写入令牌仍是蠕虫传播的燃料。

面向代理平台构建者： - 让执行界面可见、可审查、可解释。 - 将加载上下文的钩子与执行命令的钩子分离。 - 为用户提供一等审计视图，展示启动动作、外部网络调用和被修改的配置。

Mini Shai-Hulud改变了什么

针对软件包管理器的供应链攻击已有熟悉模式。受信任的软件包发布了恶意版本。安装脚本执行。载荷窃取令牌。注册表下架或版本回滚通常发生在若干开发者和CI作业已经安装恶意版本之后。

Mini Shai-Hulud增加了更贴近代理时代的一步。Endor Labs、Wiz、Socket、StepSecurity和Cloud Security Alliance的报告都描述了相同的大致形态：SAP开发者生态系统中的受害软件包利用npm安装时执行，收集GitHub、npm、云和CI凭据，并通过开发工具配置建立持久化。¹²³⁴⁷

Wiz记录了一条回退路径：攻击会把文件放入代码仓库，使未来在Claude Code或VS Code中打开时再次触发执行。²Endor Labs描述了一个Claude Code的SessionStart钩子，以及一个带有runOn: "folderOpen"的VS Code任务。¹Socket的攻击活动追踪器列出了通过.claude/settings.json和.vscode/tasks.json实现的持久化，并将其与npm和PyPI软件包入侵并列。³

具体载荷应留给事件报告，而不是放进一篇通用工程文章。这里真正经得住时间检验的教训是：

目标已经从某个软件包版本，转向了软件包周围的开发者环境。

配置文件已经变成启动程序

Claude Code的钩子参考文档说明，钩子是用户定义的shell命令、HTTP端点或LLM提示，会在生命周期事件中自动执行。⁵同一份文档还说明，SessionStart会在Claude Code启动或恢复会话时运行；安全章节也警告，命令钩子会以用户的完整权限运行。⁵

VS Code的任务文档提供了另一类执行界面。任务可以把runOn设置为folderOpen；当用户允许该文件夹使用自动任务后，VS Code会在包含该任务的文件夹打开时运行它。⁶这个同意提示很重要。它比在每台机器上静默执行的风险更低。但这并不意味着文件无害。受信任的代码仓库、疲惫的开发者、此前已允许的工作区，或组织策略，仍然可能把一次配置变更转化为代码执行。

npm则提供了安装时桥梁。npm脚本文档把preinstall、install和postinstall列为npm ci与npm install期间的生命周期脚本；npm最佳实践部分还指出，除目标架构编译外，作者几乎不应显式设置preinstall或install脚本。⁸

这3个事实构成了攻击链：

1. 安装依赖时运行安装脚本。
2. 脚本写入或修补开发工具配置。
3. 编辑器或代理稍后运行配置好的启动动作。
4. 开发者信任该工具界面，因为提示或UI看起来像正常工作。

危险之处不在于任何单一功能。安装脚本、钩子、任务和工作流都支持正当自动化。真正危险的是信任传递。一次软件包安装，不应悄无声息地决定未来每次代理会话或文件夹打开时要执行什么。

审查边界错了

多数代码审查习惯把源文件视为主要产物，把配置文件当作辅助材料。当配置文件能够执行命令时，这种习惯就会失效。

新的钩子应获得与新shell脚本相同的审查。新的任务应获得与新二进制文件相同的审查。新的MCP服务器应获得与新网络集成相同的审查。新的软件包生命周期脚本应获得与测试前运行的新代码相同的审查。

可以使用这张审查表：

工具增强型代理的执行环境防御曾指出，强制约束应位于工具调用边界。Mini Shai-Hulud把同一标准再往前推了一层。启动边界同样需要强制约束。

启动权限需要最小化

团队已经把最小权限应用于API密钥。代理配置也需要同一规则。

Claude Code区分了PreToolUse、PostToolUse和SessionStart等钩子事件。⁵这种区分应塑造策略。加载静态上下文的钩子不应需要shell访问。验证命令的钩子不应需要网络访问。记录本地元数据的钩子不应需要凭据。

同一规则也适用于VS Code任务和CI工作流：

npm可信发布文档解释了为什么短期凭据很重要。可信发布使用OIDC，因此软件包发布可以不依赖长期npm令牌；npm还建议，在配置可信发布者后，禁止传统的基于令牌的发布。⁹npm也建议，在通过OIDC发布时，为安装私有依赖使用只读粒度访问令牌。⁹

这些建议并不能消除工作流风险。如果受害工作流拥有过多权限，仍然可以造成破坏。教训是两端都要收窄：短期凭据，以及范围清晰的工作流。

把代理配置当作依赖项

依赖审查通常会问：哪些软件包版本发生了变化。代理时代的审查还应追问：哪些执行界面发生了变化。

在接受依赖更新、插件安装、生成配置或模板变更之前，检查：

重点不是疑神疑鬼，而是准确分类。钩子文件可能看起来像配置，但行为像代码。任务文件可能看起来像编辑器设置，但可以启动shell。工作流可能看起来像发布管道，但可以接触凭据。

AI代理安全始于小软件从设计角度提出过类似观点：更窄的工具更少藏错。安全版本则是：更窄的配置更少隐藏持久化。

安全的配置扫描

防御性审查不需要执行可疑代码。先从只读检查开始：

git diff -- .claude/settings.json .vscode/tasks.json package.json .github/workflows
rg -n '"SessionStart"|"runOn"\\s*:\\s*"folderOpen"|preinstall|postinstall|curl|wget|bun|node .*setup' \
  .claude .vscode package.json .github/workflows
find . -path '*/.claude/*' -o -path '*/.vscode/tasks.json' -o -path '*/.github/workflows/*'

这些命令不能证明机器是干净的。它们只是让审查者先看一遍最可能把配置变成执行的界面。如果可疑安装已经发生，应进入事件响应，而不是把干净的搜索结果当作保证。

恢复需要配置扫描

针对受害依赖项的事件响应，不应止步于卸载软件包。

建议采用以下恢复顺序：

1. 确认受影响的软件包版本是否安装在开发者机器或CI运行器上。
2. 冻结该环境，避免它继续执行更多工作。
3. 审计代码仓库中的启动配置文件，以及主目录下的代理或编辑器配置。
4. 删除可疑钩子、任务、工作流、生成的载荷文件和意外分支。
5. 轮换受影响进程可访问的所有凭据，包括软件包令牌、GitHub令牌、云密钥、SSH密钥和CI密钥。
6. 检查软件包发布者访问权限和代码仓库写入权限。
7. 审查工作流日志，查找密钥暴露和意外出站调用。
8. 使用干净检出和已知良好的依赖集重建环境。

GitHub的Actions安全指南支持这一响应中的凭据部分：为工作流令牌使用最小权限，轮换暴露的密钥，审计密钥处理方式，并考虑要求作业在访问环境密钥前经过审查。¹⁰GitHub还建议对工作流文件使用CODEOWNERS，让.github/workflows下的变更必须获得指定审查者批准。¹⁰

把代理配置加入同一治理路径。如果.github/workflows/*因为能接触密钥而需要代码负责人审查，那么.claude/settings.json和.vscode/tasks.json也应因为能在密钥附近运行命令而接受审查。

代理平台应该构建什么

代理平台和编辑器可以通过显式展示启动权限来降低审查负担。

有价值的产品界面包括：

这些界面不应依赖模型阅读JSON文件后自行判断。执行环境应直接暴露权限。用户应清楚看到“从README加载上下文”和“在会话启动时运行shell命令”之间的区别。

MCP工具需要动作级授权曾指出，持有者令牌验证必须继续细化到每个工具、每个角色和每个动作。代理配置也需要同样的形态：每个启动动作都应声明所需权限，执行环境应强制执行最小可行权限集。

一份实用的本地策略

即使平台界面尚未完善，团队也可以先从一个小型策略文件开始：

好的策略会点明文件和权限。诸如“使用代理工具时要小心”这样的模糊规则，经不起真实工作。诸如“没有负责人审查不得添加SessionStart命令钩子”这样的清晰规则，才给了审查者可执行的标准。

常见问题

AI代理配置真的属于供应链吗？

是的。供应链风险跟随执行与信任，而不是文件扩展名。如果一次软件包安装、插件、模板或代码仓库变更能够修改代理配置，并让该配置稍后执行命令，那么这份配置就在供应链之内。

团队应该禁用Claude Code钩子或VS Code任务吗？

不必。钩子和任务支持正当自动化。团队应审查、限定范围并记录它们。加载上下文的钩子和执行shell的启动钩子，不应获得同等信任。

VS Code会在运行文件夹打开任务前询问吗？

VS Code文档说明，用户第一次打开包含folderOpen任务的文件夹时，VS Code会询问是否允许该文件夹使用自动任务。⁶这个提示有帮助，但任务仍然值得代码审查，因为一旦批准，文件就变成了执行路径。

npm可信发布能解决软件包入侵吗？

不能。可信发布通过短期OIDC凭据降低长期npm写入令牌风险。⁹团队仍然需要工作流审查、最小权限、软件包监控，以及针对受害代码仓库或恶意安装脚本的事件响应。

可疑安装后我应首先审计什么？

审计安装时脚本、代理和编辑器启动配置、工作流文件、意外点目录文件、新分支，以及暴露给受影响进程的凭据。随后轮换受影响环境中的凭据。

结语

AI编码代理让配置更强大，也让配置更危险。

正确回应不是害怕自动化，而是诚实面对执行到底存在于哪里。如果一个文件能够运行命令、获取数据、读取密钥、发布软件包或改变代理行为，它就应进入审查路径。

代理配置已经越过这条线。请像对待代码一样对待它。

参考资料