技术速递｜底层机制：GitHub Agentic Workflows 的安全架构

作者Landon Cox Jiaxiao Zhou排版Alan WangGitHub 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 的配置逻辑并增加防火墙需要允许的网络目标。因此我们通过容器卷挂载小心地暴露主机文件和可执行程序并在chrootjail 中运行智能体。具体做法是将整个虚拟机文件系统以只读方式挂载到/host然后在部分路径上叠加空的tmpfs层并以/host为根目录启动智能体的chrootjail。这种方式既保留了主机侧环境又将智能体可写和可发现的范围限制在其任务所需的最小集合。对所有写操作进行分阶段与审查即使智能体无法访问密钥被提示注入的智能体仍然可能造成破坏。例如一个失控的智能体可能向仓库大量创建无意义的 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 构建的成果。祝你自动化愉快也请关注后续更多更新社区讨论https://github.com/orgs/community/discussions/186451/?wt.mc_id3reg_webpage_reactorGitHub Next Discordhttps://gh.io/next-discord/?wt.mc_id3reg_webpage_reactor