作者：Landon Cox & Jiaxiao Zhou
排版：Alan Wang
GitHub Agentic Workflows 构建于隔离、受限输出以及全面日志记录之上。了解我们的威胁模型和安全架构如何帮助团队在 GitHub Actions 中安全运行智能体。

无论你是开源维护者还是企业团队的一员，早上醒来看到文档修复、新的单元测试以及重构建议，都会是一个真正的“aha”时刻。但自动化也带来了一个重要问题：如何为能够访问你的代码仓库和互联网的智能体设置护栏？你是否会担心你的智能体依赖了某个不可靠网站的文档，或者提交了包含 API token 的 commit？如果某一天它决定在每一个未关闭的 issue 下添加大量无意义评论怎么办？自动化必须是可预测的，才能提供长期价值。

但将智能体引入现有自动化（例如 CI/CD）的最安全方式是什么？智能体是非确定性的：它们必须处理不可信输入、基于仓库状态进行推理，并在运行时做出决策。在没有实时监督的情况下让智能体在 CI/CD 中运行可以帮助你扩展软件工程能力，但这也需要新的护栏机制来避免引入安全问题。

GitHub Agentic Workflows 运行在 GitHub Actions 之上。默认情况下，一个 action 中的所有内容都运行在同一个信任域中。失控的智能体可能会干扰 MCP servers、访问认证密钥，并向任意主机发起网络请求。一个存在缺陷或被提示注入的智能体，如果对这些资源拥有不受限制的访问权限，就可能以不可预期且不安全的方式运行。

因此，安全性从一开始就被嵌入到 GitHub Agentic Workflows 的架构中。我们将智能体执行视为 CI/CD 模型的扩展，而不是一个独立的运行时。我们将开放式的编写（authoring）与受控的执行（execution）分离，然后将工作流编译为一个带有明确约束的 GitHub Action，例如权限、输出、可审计性以及网络访问。

本文将解释我们如何从第一天起就以安全为核心构建 Agentic Workflows，从威胁模型以及其所需的安全架构开始。

威胁模型

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

首先，智能体能够基于仓库状态进行推理并自主行动，这使它们非常有价值，但也意味着在默认情况下不能信任它们——尤其是在存在不可信输入时。

其次，GitHub Actions 提供了一个高度宽松的执行环境。共享信任域对于确定性自动化来说是一种特性，它支持广泛访问、良好的可组合性以及高性能。但当与不可信智能体结合时，单一信任域可能在出现问题时带来巨大的影响范围。

在这一模型下，我们假设智能体会尝试读取和写入其不应访问的状态，通过非预期通道通信，并滥用合法通道执行不希望发生的操作。默认情况下，GitHub Agentic Workflows 在严格安全模式下运行，并基于这一威胁模型进行设计，其设计遵循四个安全原则：纵深防御、不将密钥交给智能体、对所有写操作进行分阶段与审查，以及全面记录日志。

纵深防御

GitHub Agentic Workflows 提供了一个分层安全架构，由底层（Substrate）、配置层（Configuration）和规划层（Planning）组成。每一层通过执行与其假设一致的独立安全属性，来限制其上层发生故障时的影响范围。

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

在底层之上是配置层，它包含声明式配置及解释这些配置以构建安全系统结构和连接关系的工具链。配置层决定加载哪些组件、组件如何连接、允许哪些通信通道，以及分配哪些权限。外部生成的令牌（例如智能体 API key 和 GitHub 访问 token）是限制组件外部行为的关键输入——配置层控制这些 token 被加载到哪些容器中。

最后一层防御是规划层。配置层决定系统中有哪些组件以及它们如何通信，但并不决定在某一时刻哪些组件处于活动状态。规划层的主要职责是创建一个分阶段的工作流，并在各阶段之间定义明确的数据交换。后文将详细介绍的安全输出子系统，是安全规划的主要实现。

不要让智能体接触密钥

从一开始，我们就希望工作流中的智能体完全无法访问密钥。Agentic Workflows 作为 GitHub Actions 执行，其中各组件在运行器虚拟机之上共享单一信任域。在这种模型下，诸如智能体认证 token 和 MCP server API key 等敏感信息通常存储在环境变量和配置文件中，并对虚拟机中的所有进程可见。

这非常危险，因为智能体容易受到提示注入攻击：攻击者可以构造恶意输入（例如网页或仓库 issue），诱导智能体泄露敏感信息。例如，一个被提示注入的智能体如果可以执行 shell 命令，就可能读取配置文件、SSH 密钥、Linux /proc 状态以及工作流日志，从而获取凭据和其他敏感信息。随后，它可能将这些信息上传到网络，或编码进公开的 GitHub 对象（例如 issue、pull request 或评论）中。

我们的第一项缓解措施是将智能体隔离在一个专用容器中，并严格控制其出站访问：通过防火墙限制互联网访问，通过受信任的 MCP 网关访问 MCP，通过 API 代理访问 LLM API。为限制互联网访问，agentic workflows 在智能体与防火墙之间创建一个私有网络。MCP 网关运行在单独的受信任容器中，负责启动 MCP servers，并独占访问 MCP 认证信息。

尽管像 Claude、Codex 和 Copilot 这样的智能体必须通过认证通道与 LLM 通信，但我们避免将这些 token 直接暴露给智能体容器。相反，我们将 LLM 认证 token 放在隔离的 API 代理中，并将智能体配置为通过该代理访问模型。

零密钥智能体在安全性与实用性之间存在根本权衡。编码任务需要广泛访问编译器、解释器、脚本以及仓库状态，但扩展容器内部环境会重复现有 action 的配置逻辑，并增加防火墙需要允许的网络目标。

因此，我们通过容器卷挂载小心地暴露主机文件和可执行程序，并在 chroot jail 中运行智能体。具体做法是：将整个虚拟机文件系统以只读方式挂载到 /host，然后在部分路径上叠加空的 tmpfs 层，并以 /host 为根目录启动智能体的 chroot jail。这种方式既保留了主机侧环境，又将智能体可写和可发现的范围限制在其任务所需的最小集合。

对所有写操作进行分阶段与审查

即使智能体无法访问密钥，被提示注入的智能体仍然可能造成破坏。例如，一个失控的智能体可能向仓库大量创建无意义的 issue 和 pull request，淹没维护者，或者在仓库对象中加入不当链接和内容。

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

• 活跃组件及其权限（只读或读写）

• 该阶段产生的数据产物

• 这些产物允许被哪些下游组件消费

在智能体运行期间，它可以通过 GitHub MCP server 读取 GitHub 状态，并只能通过安全输出 MCP server 暂存其更新。当智能体执行结束后，这些由安全输出 MCP server 缓存的写操作会被一系列安全分析处理。

首先，安全输出允许工作流作者指定智能体可以执行的写操作类型，例如创建 issue、评论或 pull request。其次，安全输出限制更新数量，例如限制一次运行中最多创建三个 pull request。第三，安全输出会分析更新内容，移除不需要的模式，例如通过输出清洗去除 URL。只有通过整个安全输出流程的产物才会被放行，从而确保每个阶段的副作用都是明确且经过审查的。

全面记录日志

即使实现了零密钥和写操作审查，智能体仍可能以非预期方式处理仓库数据或调用工具，甚至尝试突破我们施加的约束。智能体为了完成任务会尝试各种手段，其“工具箱”往往比预期更丰富。一旦行为异常，事后分析需要完整的执行路径可见性。

Agentic Workflows 将可观测性作为架构的一等属性，在每个信任边界进行全面日志记录。防火墙层记录网络及目标访问行为，API 代理记录模型请求/响应元数据及认证请求，MCP 网关和 MCP servers 记录工具调用。我们还在智能体容器中加入内部监控，用于审计环境变量访问等潜在敏感操作。这些日志共同支持端到端的取证重建、策略验证以及异常行为的快速检测。

全面日志也为未来的信息流控制打下基础。任何可以观测通信的地方，也可以进行控制。Agentic Workflows 已支持 GitHub MCP server 的 lockdown 模式，未来几个月内我们还将引入更多安全控制，根据可见性（公开或私有）以及仓库对象作者角色，在 MCP servers 之间实施策略约束。

接下来是什么？

我们非常希望你参与进来！欢迎在社区讨论中分享你的想法，或加入 GitHub Next Discord 中的 #agentic-workflows 频道，与我们（以及众多优秀开发者）交流。期待看到你使用 GitHub Agentic Workflows 构建的成果。祝你自动化愉快，也请关注后续更多更新！