GitHub Actions 自托管 Runner 私有化部署：3 种安全构建产物隔离方案

1. 构建产物隔离不是“加个权限”就能解决的事

我第一次把 AI 编程工具接入公司 CI 流水线时，以为只要在自托管 Runner 上装好git,node,python和那个热门的 AI 辅助插件 CLI，再配个GITHUB_TOKEN就万事大吉。结果上线第三天，安全团队发来一份扫描报告：构建产物目录里混进了.env.local、secrets.json和一段未脱敏的数据库连接字符串——它们本不该出现在任何构建输出中，更不该被推送到制品仓库。

问题出在哪？不是 Runner 没装好，也不是 GitHub Actions YAML 写错了。而是我们默认把“构建环境”和“AI 工具执行上下文”当成同一个容器来管理。AI 编程工具（比如你用的 Cursor、Trae 或基于 Claude Code 的本地封装）在生成代码、补全测试、重构函数时，会主动读取当前工作目录下的大量文件——.gitignore不拦它，actions/checkout@v4不限制它，甚至run: npm ci前的ls -la都可能被它悄悄解析。当它和构建任务共享同一份挂载卷、同一个$HOME、同一套环境变量时，“隔离”就成了一句空话。

这和传统人工编码有本质区别：人写代码前会看 README，会问同事“这个 config 怎么来的”，会下意识避开敏感目录；而 AI 工具只认路径、不辨语义，它看到config/就