GitHub 揭示 AI 代理工作流背后的安全架构

GitHub 公布 Agentic Workflows 的安全隔离机制

GitHub 详细介绍了其 Agentic Workflows 如何通过零密钥容器、分阶段写入和全面日志记录，在 CI/CD 管道中隔离 AI 代理。

GitHub 发布了关于其 Agentic Workflows 功能背后安全架构的详细技术文档，揭示了一个多层次的防御系统，旨在让 AI 代理在 CI/CD 管道中运行时无需访问密钥或不受限制的写权限。

设计核心：零密钥策略

该架构最激进的立场是：AI 代理永远不会接触身份验证令牌。GitHub 将每个代理隔离在一个专用容器中，并通过防火墙限制互联网访问，同时将 LLM API 调用路由到一个独立的代理服务器，该代理服务器持有实际凭据。即使攻击者成功对代理进行提示注入攻击，也无法从容器中窃取任何敏感信息。

“代理容易受到提示注入攻击：攻击者可以伪造恶意输入（如网页或存储库问题），诱使代理泄露敏感信息，”微软研究院和 GitHub 的研究人员兰登·考克斯 (Landon Cox) 和周佳晓写道。他们的解决方案是：假设系统可能被攻破，并据此设计。

代理容器只能以只读方式挂载主机文件系统，并通过空覆盖隐藏敏感路径。代理在 chroot 监狱中运行，将其可发现的表面限制为任务所需的内容。

分阶段写入：降低风险扩散范围

第二大限制是：代理无法直接修改任何内容。所有写操作（例如创建问题、打开拉取请求、添加评论）都通过一个“安全输出”MCP 服务器进行缓冲，直到代理退出。

随后，一个单独的分析管道会根据可配置规则验证每个分阶段写入。工作流作者可以限制代理仅执行特定操作类型、限制每次运行的最大写入数量（例如最多三个拉取请求），并清理内容以去除 URL 或其他模式。只有通过这一系列检查的工件才会被执行。

这解决了恶意代理通过垃圾问题淹没存储库以压垮维护者的场景。

三层防御模型

GitHub 在底层、配置层和规划层之间构建了安全性。底层负责处理容器之间的内核级隔离；配置层控制哪些组件加载、如何连接以及令牌流向何处；规划层（通过安全输出实现）则管理随着时间推移实际发生的事情。

每一层都强制执行不同的属性。某一层中的受损组件无法绕过在其下层实施的限制。

为何这对加密开发至关重要

对于在 GitHub 上运行的区块链项目而言，这一架构的影响意义重大。智能合约存储库通常包含带有私钥引用的部署脚本、节点提供商的 API 令牌以及推送至测试网或主网的 CI 工作流。如果让 AI 代理在没有强大隔离的情况下接近这些基础设施，将会非常危险。

这一时间点也与更广泛的 DevSecOps 趋势相吻合。Datadog 于 3 月 5 日发布的 DevSecOps 实践报告验证了类似架构方法的有效性，而 2 月 27 日披露的 CVE-2026-27701（LiveCode GitHub Actions 中的远程代码执行漏洞）则进一步强调了隔离的重要性。

未来计划与社区反馈

GitHub 表示，未来几个月将推出更多安全控制措施，包括基于存储库可见性和作者角色的策略。公司正在通过其社区讨论论坛和 Discord 频道征求反馈，技术预览仍在继续。