GitHub Agentic Workflows 安全架构详解

不管是开源维护者还是企业团队，早上醒来看到文档修复、新单元测试和重构建议，确实能带来“顿悟”时刻。但自动化也带来一个重要问题：如何给能访问仓库和互联网的智能体加上安全护栏（Guardrails）？你会不会担心智能体依赖了可疑网站的文档，或者提交了包含 API token 的代码？万一它某天决定给所有未关闭的 issue 添加垃圾评论呢？自动化必须可预测，才能提供持久价值。

但往现有 CI/CD 里加智能体，最安全的方式是什么？智能体是非确定性的：它们必须处理不可信的输入，基于仓库状态推理，并在运行时做决策。让智能体在 CI/CD 中无人监督运行，能帮你扩展软件工程规模，但也需要新的护栏来避免制造安全问题。

GitHub Agentic Workflows 运行在 GitHub Actions 之上。默认情况下，一个 action 里的所有东西都在同一个信任域里运行。恶意智能体可以干扰 MCP 服务器、访问认证密钥、向任意主机发起网络请求。一个有 bug 或被提示注入（Prompt Injection）的智能体，如果无限制访问这些资源，就可能做出意外且不安全的行为。

所以安全是 GitHub Agentic Workflows 架构的内置特性。我们把智能体执行看作 CI/CD 模型的扩展——而不是独立的运行时。我们将开放式创作与受控执行分离，然后将工作流编译成一个带有明确约束的 GitHub Action，包括权限、输出、可审计性和网络访问。

这篇文章解释了我们如何从一开始就带着安全思维构建 Agentic Workflows，从威胁模型和所需的安全架构讲起。

威胁模型

智能体工作流有两个特性改变了自动化的威胁模型。

首先，智能体基于仓库状态推理和自主行动的能力很有价值，但也意味着它们默认不可信——尤其是在存在不可信输入的情况下。

其次，GitHub Actions 提供了一个高度宽松的执行环境。共享信任域对于确定性自动化是个优点，能实现广泛访问、可组合性和良好性能。但当它与不可信的智能体结合时，单一的信任域一旦出问题，就会造成很大的爆炸半径。

基于这个模型，我们假设智能体会试图读写不该访问的状态，通过非预期渠道通信，并滥用合法渠道执行不需要的操作。默认情况下，GitHub Agentic Workflows 在严格安全模式下运行，其设计遵循四个安全原则：纵深防御、不信任智能体持有密钥、分阶段审核所有写入、记录一切。

纵深防御

GitHub Agentic Workflows 提供了一个分层的安全架构，包括底层（Substrate）、配置层和规划层。每一层都通过执行与其假设一致的不同安全属性，来限制上层故障的影响。

三层系统架构图，标注了规划层、配置层和底层。每层包含三个蓝色方块：规划层：安全输出 MCP（GitHub 写入操作）、调用过滤（调用可用性、数量）、输出净化（密钥移除、内容审核）。配置层：编译器（GH AW 扩展）、防火墙策略（白名单）、MCP 配置（Docker 镜像、认证令牌）。底层：Action runner 虚拟机（操作系统、虚拟机管理程序）、Docker 容器（Docker 守护进程、网络）、可信容器（防火墙、MCP 网关、API 代理）。

底层基于 GitHub Actions runner 虚拟机（VM）和几个可信容器，这些容器限制了智能体可以访问的资源。底层共同提供了组件间的隔离、特权操作和系统调用的中介，以及内核强制的通信边界。即使不可信的用户级组件被攻破并在其容器隔离边界内执行任意代码，这些保护仍然有效。

底层之上是配置层，包括声明式工件和解释它们以实例化安全系统结构和连接性的工具链。配置层决定加载哪些组件、组件如何连接、允许哪些通信通道、分配哪些权限。外部生成的令牌，比如智能体 API 密钥和 GitHub 访问令牌，是限制组件外部影响的关键输入——配置控制哪些令牌加载到哪些容器中。

最后一层防御是规划层。配置层决定存在哪些组件以及它们如何通信，但不决定哪些组件随时间激活。规划层的主要职责是创建一个分阶段的工作流，并在它们之间进行明确的数据交换。下文将详细描述的安全输出子系统（Safe Outputs）是安全规划的主要实例。

不信任智能体持有密钥

从一开始，我们就希望工作流智能体对密钥的访问为零。Agentic workflows 作为 GitHub Actions 执行，其中组件在 runner VM 之上共享一个信任域。在那个模型里，敏感材料如智能体认证令牌和 MCP 服务器 API 密钥存在于环境变量和配置文件中，VM 里的所有进程都能看到。

这很危险，因为智能体容易受到提示注入（Prompt Injection）攻击：攻击者可以制作恶意输入，比如网页或仓库 issue，诱骗智能体泄露敏感信息。例如，一个被提示注入且能访问 shell 命令工具的智能体，可以读取配置文件、SSH 密钥、Linux /proc 状态和工作流日志来发现凭据和其他密钥。然后它可以把这些密钥上传到网上，或者编码到公开的 GitHub 对象里，比如仓库 issue、pull request 和评论。

我们的第一个缓解措施是将智能体隔离在一个专用容器中，并严格控制出口：防火墙限制的互联网访问、通过可信 MCP 网关访问 MCP、通过 API 代理进行 LLM API 调用。为了限制互联网访问，agentic workflows 在智能体和防火墙之间创建一个私有网络。MCP 网关运行在单独的可信容器中，启动 MCP 服务器，并独占访问 MCP 认证材料。

虽然像 Claude、Codex 和 Copilot 这样的智能体必须通过认证通道与 LLM 通信，但我们避免将这些令牌直接暴露给智能体的容器。相反，我们把 LLM 认证令牌放在一个隔离的 API 代理中，并配置智能体通过该代理路由模型流量。

架构图显示几个连接的 Docker 容器。一个 Codex 令牌连接到一个 api-proxy 容器，该容器连接到一个 OpenAI 服务图标。另一个流程显示一个智能体容器（链接到 chroot/host）通过 http 与 gh-aw-firewall 容器通信，然后通过 http 与 gh-aw-mcpg 容器通信（链接到 Host Docker Socket），然后通过 stdio 与 GitHub MCP 容器通信（链接到 GitHub PAT）。GitHub 图标出现在 GitHub MCP 容器上方。

零密钥智能体需要在安全性和实用性之间做出根本权衡。编码工作负载需要广泛访问编译器、解释器、脚本和仓库状态，但扩大容器内设置会重复现有的 action 配置逻辑，并增加必须通过防火墙允许的网络目标集合。

相反，我们使用容器卷挂载（Volume Mounts）小心地暴露主机文件和可执行文件，并在 chroot 监狱中运行智能体。我们首先将整个 VM 主机文件系统以只读方式挂载到 /host。然后用空的 tmpfs 层覆盖选定的路径，并在以 /host 为根的 chroot 监狱中启动智能体。这种方法保持了主机端设置的完整性，同时将智能体的可写和可发现表面限制在其工作所需范围内。

分阶段审核所有写入

即使无法访问密钥，被提示注入的智能体仍然可能造成损害。例如，恶意智能体可能用无意义的 issue 和 pull request 刷屏仓库，压垮仓库维护者，或者在仓库对象中添加不当 URL 和其他内容。

为了防止这种行为，agentic workflows 编译器将工作流分解为明确的阶段，并为每个阶段定义：

活跃组件和权限（读 vs 写）
该阶段发出的数据工件
这些工件的允许下游消费者

智能体运行时，可以通过 GitHub MCP 服务器读取 GitHub 状态，并且只能通过安全输出 MCP 服务器（Safe Outputs MCP Server）暂存其更新。智能体退出后，由安全输出 MCP 服务器缓冲的写入操作会经过一系列安全输出分析处理。

以 GitHub 为中心的工作流程图，带有绿色箭头和两行组件。顶部，一个 GitHub 图标指向三个方框：智能体（不可信）、GitHub MCP（只读）、MCP 配置（写入缓冲）。下面是三个处理步骤，标记为过滤操作、审核内容、移除密钥，每个都标记为“确定性分析”。绿色箭头表示数据从 GitHub 流入系统，向下通过配置到“移除密钥”，然后向左通过“审核内容”和“过滤操作”，循环回智能体。

首先，安全输出允许工作流作者指定智能体可以执行哪些写入操作。作者可以选择允许哪些 GitHub 更新子集，比如创建 issue、评论或 pull request。其次，安全输出限制允许的更新数量，比如限制智能体在单次运行中最多创建三个 pull request。第三，安全输出分析更新内容以移除不需要的模式，比如输出净化以移除 URL。只有通过整个安全输出管道的工件才能被传递，确保每个阶段的副作用都是明确且经过审核的。

记录一切

即使零密钥且写入经过审核，智能体仍然可能以意外方式转换仓库数据和调用工具，或者试图突破我们施加的约束。智能体决心不惜任何代价完成任务，并且拥有令人惊讶的深厚技巧工具箱。如果智能体行为异常，事后分析需要完整的执行路径可见性。

Agentic workflows 通过在每个信任边界广泛记录日志，将可观测性（Observability）作为架构的一等属性。网络和目标级别的活动在防火墙层记录，模型请求/响应元数据和认证请求由 API 代理捕获；工具调用由 MCP 网关和 MCP 服务器记录。我们还在智能体容器中添加内部检测，以审计潜在敏感操作，如环境变量访问。这些日志共同支持端到端的取证重建、策略验证和异常智能体行为的快速检测。

全面日志记录也为未来的信息流控制奠定了基础。每个可以观察通信的位置，也是可以中介通信的位置。Agentic workflows 已经支持 GitHub MCP 服务器的锁定模式，未来几个月，我们将引入额外的安全控制，基于可见性（公开 vs 私有）和仓库对象作者的角色，跨 MCP 服务器执行策略。