GitHub、Agentic Workflowsのセキュリティアーキテクチャを公開

GitHubは2026-03-09の投稿で、GitHub Actions上でAgentic Workflowsをどのように保護しているかを詳しく説明した。出発点は、agentを「便利な自動化」ではなく、untrusted inputを取り込み、リポジトリ状態を解釈し、実行時に危険な判断を行いうる非決定的コンポーネントとして扱うことにある。

先にセキュリティモデルを置く

GitHubの問題設定は明快だ。従来のCI/CDでは、1つの trust domain の中で広いアクセス権を共有することは主に利便性だった。しかし agent が入ると、同じ設計が blast radius の拡大につながる。prompt injection やバグのある agent が secrets を読んだり、MCP server に干渉したり、任意の host に通信したりできるからだ。そこでGitHubは、Agentic Workflowsが strict mode を前提とし、defense in depth、don’t trust agents with secrets、stage and vet all writes、log everything の4原則で設計されていると説明する。

3層の防御

アーキテクチャは substrate、configuration、planning の3層として整理されている。substrate layer は GitHub Actions runner VM と trusted container を使い、コンポーネントを分離しつつ privileged operation を仲介する。configuration layer は何を起動し、どう接続し、どの token をどの container に渡すかを決める。planning layer は workflow の段階と data exchange を明示し、高レベルの orchestration が低レベルの制約を迂回しないようにする。

特に重要なのが「zero-secret agents」という考え方だ。GitHubは model や MCP の credential を agent container に直接渡さず、LLM への通信は isolated API proxy 経由、MCP へのアクセスは trusted MCP gateway 経由に限定する。ネットワークは firewall で制御され、agent は chroot jail の中で動く。つまり、コーディングに必要なローカル文脈は残しつつ、agent が発見・改変できる範囲をできるだけ狭める設計だ。

なぜ重要なのか

GitHubが実質的に主張しているのは、agent runtime の安全性を後付けの機能ではなく、CI/CD 契約の一部として扱うべきだということだ。企業導入で本当に問われるのは、agent がコードを書けるかより、token、リポジトリ状態、production workflow の近くでどこまで予測可能に制御できるかだ。isolated execution、constrained outputs、staged writes を前面に出した今回の説明は、agentic automation を実験的な prompt の寄せ集めではなく、governed infrastructure として見せる方向性だと言える。