无论你是开源维护者还是企业团队的一员，早上醒来看到文档修复、新的单元测试以及重构建议，都会是一个真正的“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，从威胁模型以及其所需的安全架构开始。
