Chainguard WorkspacesとChecks、AIコーディングエージェントにセキュリティゲートを導入

Chainguardは、AIコーディングエージェントを隔離環境内に置き、その作業がプルリクエストに到達する前に検証済みのチェックを必須とする2つのベータ製品を発表した。Chainguard WorkspacesとChecksは、開発チームがもはや無視できない対立に焦点を当てる。エージェントには作業のための幅広い自由が必要だが、その自由はより大きなセキュリティ境界を生み出す。

Workspacesは、各ワークロードを分離するために設計された小規模な仮想マシンである専用microVM上で、リモート開発セッションを提供する。Checksは別個のmicroVMで継続的インテグレーションタスクを実行し、構造化された結果をエージェントに返す。両製品を組み合わせることで、コードの作成、テスト、修正を制御されたループとして実現する。

この発表は、なじみ深い開発モデルに圧力をかける。Claude Code、GitHub Codespaces、ローカルのエージェントサンドボックスといったツールは、すでにコーディングワークフローの一部を隔離している。従来のCIシステムは、開発者がコミットをプッシュした後で、それらを別途検証する。Chainguardはこれらの段階を結び付け、検証済みテストをエージェントの作業ループの一部にしようとしている。

このアプローチは理にかなっているように聞こえるが、重要な主張は大規模な運用ではまだ実証されていない。Chainguardは、より強力な隔離と署名付き結果が、CIの遅延をポリシー、設定、プラットフォーム上の摩擦に置き換えることなく、信頼を向上できることを示す必要がある。

Chainguard WorkspacesとChecks、CIをエージェントループの内側へ移す

今回の発表は、隔離された実行環境と、エージェントがタスク完了と見なせるタイミングを管理できる検証サービスを組み合わせるものだ。

ChainguardはAssemble LondonイベントでWorkspacesとChecksを発表した。最初の製品報道によると、両製品はベータ版として提供を開始した。同一ワークフローの異なる段階に対応する。

Workspaceは、開発者またはコーディングエージェントがファイルの編集、パッケージのインストール、コマンド実行、稼働中プロセスの維持を行えるリモートmicroVMだ。開発者はChainguardのコマンドラインツールからセッションを開始し、ローカルの作業ツリーをリモート環境へ同期する。

その同期には、未コミットの変更や未追跡ファイルも含められる。実行は開発者のノートPCから離れるが、使い慣れたエディタとGitワークフローはローカルに維持できる。ローカルのエージェントは、認証情報、ブラウザセッション、バックグラウンドサービス、割り当てとは無関係なファイルに到達し得るため、この分離は重要だ。

開発者が切断した後もセッションは継続できる。Chainguardによれば、アイドル期間の後に環境をスナップショットして停止状態にし、ディスク、メモリ、プロセス、キャッシュを保存する。開発者は後から環境を再構築することなく、セッションを再開できる。

Workspacesは並列実験にも対応する。開発者は同じリポジトリから新しいセッションを開始し、複数のエージェントに異なる実装の探索を依頼できる。各エージェントには、他のエージェントと書き込み可能な環境を共有する代わりに、独自のmicroVMが与えられる。

Checksは検証側を担う。リポジトリは必要なコマンドを.chainguard/ci.yamlファイルまたは関連する設定ディレクトリで定義する。その後、このサービスは、より長期間存続するWorkspace内で生成された結果を信頼するのではなく、個々のチェックを新しいmicroVMで実行する。

この違いは不可欠だ。Workspaceはエージェントに生産的な環境を与えるが、その状態はタスクの進行を通じて変化する。クリーンなチェックは、生成されたコードが蓄積された状態の外でも動作するかどうかを、より強く検証する。

開発者はコマンドライン、pre-commitフック、またはGitHub連携を通じてChecksを呼び出せる。エージェントはSDKまたはModel Context Protocolサーバーを通じて呼び出せる。MCPは、AIエージェントが定義済みのインターフェースを通じて外部ツールを呼び出すためのプロトコルだ。

チェックが失敗すると、Workspaceは構造化された失敗ログを伴って再開できる。エージェントはセッションを再構築したり、すべての依存関係を再ダウンロードしたりせずに変更を修正できる。発表の詳細では、固定された依存関係を記録するプロジェクトのlockfileから構築されるウォームスナップショットが説明されている。

成功した実行では、環境、結果、コミットに紐付く署名付きアテステーションが生成される。アテステーションとは、何が実行され、どのような結果が得られたかを示す暗号学的証跡である。Chainguardは、エージェントの自己申告を無条件に信頼する代わりに、この証跡をマージゲートで使うことを提案している。

したがって、このイベントは単なるリモート開発環境の発表ではない。Chainguardは自律的コーディングの完了条件を定義しようとしている。エージェントは、提出しようとする正確な変更を独立したシステムが検証した後にのみ完了する。

圧力はローカルエージェントと従来型CIに及ぶ

Chainguardは、エージェントがコードを作成する場所と、組織がそのコードを受け入れ可能と判断する場所の隔たりに挑戦している。

コーディングエージェントには、通常のチャットアシスタントが必要としなかった権限が求められる。リポジトリを調査し、複数ファイルを変更し、シェルコマンドを実行し、依存関係をインストールし、外部サービスと通信する。こうした行為を絶え間ない承認なしで完了できるほど、その有用性は高まる。

同じ自律性は、潜在的な被害範囲も広げる。誤解を招くリポジトリの指示は、開発者が挙動を確認する前にエージェントへ影響を及ぼし得る。侵害されたパッケージはインストール中に実行される可能性がある。不必要なネットワーク権限は、ローカルの秘密情報を攻撃者が抽出できるデータに変えかねない。

OWASPは、過剰な機能、権限、または自律性によって生じるリスクを過剰なエージェンシーとして説明している。コーディングエージェントは、この3つの条件をすべて体現し得る。強力なツールを与えられ、複雑なリポジトリ全体で動作し、限られた監視下で行動を繰り返す。

ローカルの権限プロンプトは完全な答えではない。プロンプトはワークフローを中断し、繰り返される承認は、ユーザーが各リクエストを注意深く評価しなくなることを促す。Anthropicは、追加の自動制御を導入する前、ユーザーがClaude Codeの権限プロンプトのおよそ93％を承認していたと報告している。

この傾向は、強制可能な境界への移行を説明する一助となる。Anthropic自身の封じ込めアプローチは、あらゆる危険な行為を予測しようとするのではなく、エージェントが到達できる範囲を制限することを重視している。Chainguardも、隔離を外部CI検証と組み合わせている点は異なるものの、同じ大きな原則に従っている。

従来型CIは別の問題に直面する。通常、開発者またはエージェントが変更をプッシュした後に動作する。試行のたびにキューへ入り、環境を再構築し、依存関係を取得し、別個のインターフェースを通じてログを返す場合がある。

この順序は、人間が比較的少数の意図的な変更を行う場合には機能する。だが、エージェントが多数の修正を生成してテストする場合には、コストが高くなる。並列エージェントは、最終的な提出物の品質を高めることなく、ビルド数を増やす可能性がある。

Chainguardのモデルは検証を早める。エージェントはタスクの文脈をまだ保持している間にChecksを呼び出し、失敗に即座に対応できる。同社は、成功の証跡が最終的なコミットとともに移動することを目指している。

これは既存CIプロバイダーに圧力をかけるが、それらを時代遅れにするわけではない。大規模組織は、成熟した統合、デプロイ承認、監査履歴、カスタムランナー、複雑なテストマトリクスに依存している。ベータ版のサービスは、その一部を置き換える前にこれらのシステムへ適合しなければならない。

この圧力はホスト型エージェントベンダーにも及ぶ。Anthropicはすでに、重要な認証情報をエージェントのサンドボックス外に保持するクラウドセッションを含め、Claude Code向けのファイルシステムおよびネットワーク隔離を提供している。GitHub Codespacesは、リモート開発環境とリポジトリスコープのトークンを提供する。

これらの製品は実行を隔離できるが、Chainguardはより限定的なセキュリティ上の主張を行っている。ワークスペース、依存関係環境、チェック設定、マージの証跡を一つの連鎖として構成したい考えだ。その連鎖が、同社にとって主要な差別化要因となる。

開発者は今回の発表を、2つのワークフロー設計の競争として捉えるべきだ。一方は、ローカルまたはホスト型のエージェントと、別々に構成されたセキュリティおよびCIシステムを組み合わせる。もう一方は、隔離と検証をエージェントのデフォルト実行経路の一部にする。

エージェントに適切な振る舞いを求めるより、隔離の方が重要だ

Chainguardの中心的な賭けは、強制可能なインフラ制御により、プロンプトやモデルポリシーでは確実に防げないミスを封じ込められるというものだ。

各Chainguard Workspaceは、共有カーネルのコンテナではなく専用microVMで動作する。このアーキテクチャは、信頼できないコードと基盤ホストの間に仮想化の境界を置く。各Checksタスクにも新しいmicroVMが割り当てられる。

同社によると、ホストディレクトリはこれらのマシンにマウントされない。代わりに、リポジトリの内容が環境へストリーミングされる。この選択は、侵害されたプロセスがプロジェクトディレクトリから無関係なホストファイルへ移動する可能性を抑える。

Chainguardはリポジトリのコードも敵対的なものとして扱う。この前提は、エージェントがソースファイル、ドキュメント、生成物、依存関係、接続されたツールを通じて指示に遭遇し得るため有用だ。信頼できるユーザーであっても、リポジトリ内のすべての成果物まで信頼できるとは限らない。

システムのセキュリティモデルは、永続的な認証情報をゲスト環境から分離する。ソフトウェアが認証済みアクセスを必要とする場合、microVM外のコンポーネントが承認済みリクエストへ認証情報を追加する。

一部のサービスでは、Workspace内のコードがローカルホスト名を通じて通信する。次に外部プロキシがアウトバウンドリクエストを認証する。Chainguardによると、ディスク上の認証情報を期待するツールには、有効なセッション外では価値を持たない暗号化された代替情報を与えられる。

この設計は認証情報の直接的な窃取を減らすが、認証情報の悪用をなくすわけではない。VM内のコードは、承認済みリクエストに付与された権限を依然として利用できる。接続されたIDに過剰な権限があれば、悪意あるエージェントは永続的なリソースを作成できる可能性がある。

Chainguardは、この境界をドキュメントで認めている。顧客に対し、ワークロードIDには各チェックが必要とするアクセスだけを付与するよう助言している。また、チームは無人作業を許可する前にセッション認証情報を確認しなければならない。

ネットワーク制御はさらに一層の防御を加える。設定にネットワークルールがない場合、Checksにはデフォルトでネットワークアクセスが与えられない。リポジトリ所有者は、タスクで必要な場合に特定のホストを許可したり、パブリックネットワークアクセスを許可したりできる。

Workspaceのデフォルト設定には、より注意を払う必要がある。Chainguardのドキュメントでは、チェック固有のegress制限が適用されない場合、セッションはオープンインターネットへ到達できるとされている。したがって、デフォルト拒否の姿勢を求めるチームは、許可リストを持つチェックを中心にセッションを構成する必要がある。

この違いは、隔離が単一のスイッチではない理由を示している。microVMはカーネルを分離できる一方で、機密性の高いネットワーク操作を依然として許可し得る。プロキシは認証情報の値を保護できる一方で、損害を与えるリクエストを依然として認可し得る。署名付き結果はテストが成功したことを証明できても、そのテストが十分だったことまでは証明できない。

これらの制御が相互に補強し合うとき、モデルはより強固になる。VMはローカルで到達できる範囲を制限する。egressルールは外部の接続先を制限する。ホスト側の認証情報は秘密情報の露出を減らす。新しいチェックは、変更可能な開発セッションの外でコードをテストする。

Checksは、レビュー対象の変更からポリシーの一部も保護する。Chainguardによれば、プルリクエストが自らのブロッキング要件を即座に弱めることはできない。必須チェックの削除や助言的な扱いへの変更は、該当する変更がマージされた後にのみ有効になる。

この詳細によって、明白な迂回策は封じられる。エージェントが自らの作業を評価するポリシーを編集し、弱められたポリシーの下で承認を得ることは許されるべきではない。どのチェックを実行すべきかを決める権限は、ベースブランチに残る。

クリーンな検証環境は、偶発的な成功にも耐える。エージェントは開発中に未宣言のパッケージをインストールしたり、サービスを変更したりする可能性がある。そのWorkspace内ではコードが機能しているように見えても、ほかの全員の環境では失敗しかねない。

新しいmicroVMでChecksを実行すると、こうした隠れた依存関係が明らかになる。その結果は従来のクリーンなCIビルドに似ているが、サービスはその証拠をアクティブなエージェントループへ直接返す。

署名付きChecksがエージェントの完了の意味を変える

最も重要な機能はリモートWorkspaceではない。独立して検証された証拠を、エージェントの終了条件にしようとする試みである。

多くのコーディングエージェントは、モデルの判断とツール出力を組み合わせて、作業完了を判断する。エージェントはテストコマンドの成功を確認し、編集内容を要約して、プルリクエストを作成する。この一連の流れには、いくつもの信頼上の隔たりがある。

エージェントが誤ったテストを実行することもある。失敗を見落としたり、古い出力を使ったり、提出したコミットと一致しなくなった環境でテストしたりする可能性もある。また、証拠が許容する以上に確信を持って結果を説明することもあり得る。

Chainguard Checksは、別個の権威を設ける。エージェントは定義済みの検証実行を要求し、判定を受け取り、必須チェックが通過した場合にのみ先へ進める。システムは成功した結果を、特定のコミットSHA、環境、チェック結果に結び付けられる。

これにより、CIは自律ループ内部の制御機構となる。失敗した実行は構造化ログを提供し、エージェントは次の反復に利用できる。成功した実行は、別のシステムが評価できる証拠を生み出す。

この仕組みは、バックグラウンドで保守を行うエージェントを運用するチームにとって重要だ。複数のリポジトリにまたがり、古くなった依存関係の更新を任されたエージェントを考えてみよう。開発者のノートPCにアクセスせずに、マニフェストの変更、lockfileの再生成、互換性テストの実行を行える。

チェックが失敗した場合、セッションは以前の状態とウォームキャッシュを維持したまま再開する。エージェントは失敗を調査し、より限定的なバージョン変更を試せる。人間が別のCIインターフェースからログをコピーする必要はない。

同じパターンはレガシーコードのリファクタリングにも当てはまる。複数のエージェントが別々のWorkspaceで競合する変更をテストできる。リポジトリで定義されたチェックに通過した候補だけが、プルリクエストへ進むべきだ。

署名付き証明書は、下流のガバナンスにも役立つ。マージサービスは、提出されたコミットがテスト済みのコミットと一致するかを検証できる。これは、エージェントがテストを実行したと述べるコメントを受け入れるより強力だ。

ただし、証明書が確立するのは、それが記録したプロセスに関する事実だけである。テストスイートがすべてのセキュリティ上の欠陥を網羅していることは証明できない。製品要件が正しかったかどうかも判断できない。さらに、通過した変更がデプロイに値することも保証しない。

したがって、このアプローチは信頼の問題を解決するのではなく、範囲を狭める。チームは、テスト実行に関するエージェントの報告を信頼する必要がなくなる。一方で、テスト定義、ポリシー設定、実行サービス、署名インフラは依然として信頼しなければならない。

この境界は妥当だが、購入者は理解しておく必要がある。「暗号学的な証明」という表現は、実際の保証範囲より広く聞こえることがある。この証拠が示すのは、特定された入力に対して、定義済みのチェックが定義済みの結果を生んだということだ。

Chainguardは、セキュリティ制御がコーディングツール内部に組み込まれつつある分野にも参入している。Anthropicのサンドボックスシステムは、ファイルシステムの制限とネットワーク制限を組み合わせている。GitHubは、Codespacesを通じてスコープを限定したリポジトリアクセスとリモート環境を提供する。

Chainguardの以前のCursor統合は、生成プロジェクトを精査済みのパッケージとコンテナイメージへ導くことに焦点を当てていた。WorkspacesとChecksは、その戦略を依存関係の選定から実行と検証へ拡張する。

より広い競争は、Chainguardと単一のベンダーとの対決ではない。エージェント生成コードを囲む信頼境界を誰が制御するかをめぐる競争だ。モデル企業、開発者プラットフォーム、CIプロバイダー、セキュリティベンダーはいずれも、このレイヤーに対してもっともな主張を持つ。

ベータ版には依然としてセキュリティと導入の課題がある

Chainguardのアーキテクチャは信頼できるリスクに対処しているが、最も強い運用上の主張には、実際のエンタープライズワークロードによる独立した証拠がなお必要だ。

両製品は依然としてベータ版である。ChainguardはWorkspacesをテクノロジープレビューと説明しており、現行ドキュメントではClaude Codeが統合されたモデル認証情報サポートを受けるとしている。ほかのエージェントもセッション内で実行できるが、同じ認証情報ワークフローはまだ適用されない。

この制約は、エンタープライズのエージェント群が多様化しているため重要だ。あるチームでは、実装に一つのエージェント、レビューに別のエージェント、移行やテストに特化ツールを使うかもしれない。各エージェントで異なる統合動作が必要になると、セキュリティポリシーはより難しくなる。

パフォーマンスも未解決の問いだ。ウォームスナップショットと事前構築済みの依存関係は、繰り返し発生するセットアップ作業を減らすはずである。しかし、発表では既存CIサービスやほかのリモート開発環境との比較ベンチマークは示されていない。

チームには、現実的なリポジトリを対象にした測定が必要だ。有用な証拠には、コールドスタート時間、ウォーム再開時間、キャッシュヒット率、同時セッション時の挙動、失敗したチェックからエージェント作業再開までの遅延が含まれる。

信頼性は速度と同じくらい重要である。エージェントがそれなしにはタスクを完了できない場合、検証サービスは開発のボトルネックになる。組織は、サービスレベルの約束、地域ごとの可用性、障害復旧時の挙動、機能低下時の明確な運用ルールを求めるだろう。

署名システムにも精査が必要だ。顧客は、鍵がどのように保護、ローテーション、監査、失効されるのかを知る必要がある。証明書を独立して検証し、どの発行者を自社のマージゲートが信頼するかを決める方法も必要だ。

InfoQは、Chainguardがログの改ざん耐性に関する主張を顧客がどのように検証すべきかを示す詳細を公開していないと指摘した。これは設計を無効にするものではない。セキュリティ製品を評価するうえで必要な要素を示している。

Workspaceの認証情報は、もう一つの微妙なリスクを生む。トークンをVMの外部に置くことで、コードがその生の値を読み取ることは防げる。しかし、コードがプロキシに認可済みアクションの実行を求めることまでは防げない。

侵害されたエージェントは、許可された経路を通じてGitHubアクセス、クラウド権限、LLM認証情報を悪用する可能性がある。防御は、狭いスコープ、リクエスト検証、egress制限、監視に依存する。チームはこのポリシー作業をmicroVMに委ねることはできない。

ホスト側の統合にも注意が必要だ。セキュリティ研究者は、信頼されたホストコンポーネントが攻撃者の制御する出力を消費する場合、サンドボックスの価値が失われ得ることを示している。変更された設定ファイルがサンドボックスを離れた後、特権的な動作を引き起こす可能性がある。

Chainguardのストリーミングおよびプロキシアーキテクチャは、ホストへの露出の一部を減らすが、顧客は完全なデータ経路をテストすべきだ。そこにはローカル同期、Git操作、IDE拡張機能、MCPサーバー、マージ自動化、エージェント出力を受け取る通知システムが含まれる。

導入面でのトレードオフもある。開発者は、エージェントにツールをインストールさせ、ドキュメントを検索させ、APIを呼び出させ、不慣れなコードを探索させたい。厳格なegressおよび認証情報ポリシーは、こうした作業を中断させかねない。広い権限は利便性を戻す一方、隔離を弱める。

製品は、アドホックなローカル設定よりも安全なポリシーを保守しやすくしなければならない。そうでなければ、チームは寛容な許可リストを作成したり、過大な権限を持つIDを使い回したり、緊急作業のためにシステムを迂回したりする可能性がある。

WorkspacesとChecksで共有設定を用いるChainguardの方式は、重複を減らせる。しかし組織は依然として、各リポジトリの依存関係、サービス、テスト要件をマッピングする必要がある。この移行作業は、基盤技術と同じくらい導入を左右する。

慎重な結論は明快だ。このアーキテクチャには、特に新しい検証環境とゲスト外に保持される認証情報という点で、いくつものよく考えられた制御がある。ベータ版は、それらの制御が多様な本番パイプラインでどのように機能するかを、まだ確立していない。

このモデルが機能するかを示す三つのシグナル

次の試練は、Chainguardが首尾一貫したセキュリティ設計を、再現可能な証拠、幅広いエージェントサポート、実用的なエンタープライズ導入へと変えられるかどうかである。

最初のシグナルは、公開された技術検証だ。Chainguardは、起動時間、チェック実行、キャッシュ挙動、並列セッションについて、再現可能なベンチマークを提供すべきである。認証情報プロキシ、証明書システム、ログ完全性に関する独立評価があれば、さらに重みを持つ。

強い結果は、セキュリティ制御を実用範囲を超えて遅くすることなくエージェントループに組み込めるという主張を支える。結果が欠けている、または狭く選別されていれば、中核的なパフォーマンス論は未解決のままだ。

二つ目のシグナルは、より広範なエージェント統合である。現在、WorkspacesではClaude Codeに最も明確に文書化された経路があり、追加エージェントへのサポートは計画段階にとどまる。広く使われるほかのコーディングエージェントへのネイティブサポートは、このアーキテクチャが本当にエージェント中立かを試すことになる。

その拡張では、同じセキュリティ特性を維持しなければならない。一部のエージェントでVM内のシークレットが必要になったり、意図された検証経路を迂回したりするなら、互換性リストが長くなっても意味は薄い。

三つ目のシグナルは、日常的なエンタープライズ利用の証拠だ。最も強力な事例研究は、多数のリポジトリにわたる依存関係の更新、リファクタリング、保守作業をエージェントが完了したことを示すものだろう。失敗率、人間による介入、ポリシー例外、節約された時間を報告すべきである。

顧客の行動は、署名付きチェックが本物のマージゲートになるのか、それとも単なるステータスバッジになるのかを明らかにする。また、セキュリティチームが新しいツールのたびにポリシーチケット化することなく、有用な制限を維持できるかも示す。

Chainguard WorkspacesとChecksは、業界がエージェントの振る舞いを監督する段階から、エージェントの能力を制限する段階へ移る中で登場した。この方向性は、エージェントベンダーやセキュリティ団体のガイダンスと一致する。それでも、この特定の実装が勝つ保証はない。

ベータ版を評価する開発者は、限定されたリポジトリと狭い権限で始めるべきだ。明示的なegressルールを定義し、クリーンなチェックを要求し、提出されたコミットがその証明書と一致することを検証すべきである。エンジニアリングチームは、こうした知見を共有の技術ナレッジベースに文書化することもできる。

最後の問いは、哲学的なものではなく運用上のものだ。認証情報、ポリシー、マージ権限をエージェントの制御外に保ちながら、エージェントが独立して作業できるようにすることは可能か。その答えは、ローンチ発表だけではなく、検証データ、統合の広がり、顧客の実践から明らかになる。