エージェントに生産コード権限付与、夜も眠れぬ—Form3 モリッツ・ヨナー

エージェントに生産コード権限を渡す夜は眠れない：Form3 が挑む「サプライチェーン・アクター」としてのセキュリティ

AI エージェントに生産環境へのコード修正権限を与えた瞬間、それは単なる自動化ツールではなく、人間同様のリスクを持つ「サプライチェーン・アクター」へと変貌します。Form3 のモリッツ・ヨナー氏は、従来の依存関係管理ツールでは対応しきれない複雑なパッチ適用において、この新たな脅威にどう向き合うべきかを説きます。

既存の自動化ツールの限界と「推論」の欠如

ソフトウェアエンジニアにとって、脆弱性（CVE）のパッチ適用は「掃除機をかけるような」退屈で終わりのない作業です。Form3 のように数千ものリポジトリを抱える組織では、新しい脆弱性が次々と現れ、手動での対応は現実的ではありません。

そこで登場するのが Dependabot や Renovate といった既存の自動化ツールですが、これらは「マニフェストファイルのバージョンを bump（アップグレード）する」という単純な世界で設計されています。しかし、現代のコンテナベースの環境では状況は遥かに複雑です。

「脆弱な箇所が必ずしもツールの目に見える場所にあるとは限りません」

例えば、脆弱性が Dockerfile ではなく、そのベースイメージに含まれる OS パッケージに潜んでいる場合や、ビルドプロセスでダウンロードされるバイナリに含まれている場合は、既存ツールはそれを検知すらできません。また、パッチ適用は孤立して起こるものではありません。

Go のランタイムをマイナーバージョンアップする際、それに伴ってリンターもアップグレードする必要があり、新しいルールが導入されてコードベース全体がエラーに陥るといった「依存関係の絡み合い」が発生します。既存ツールは単にバージョンを bump して PR を作成し、残りの複雑な問題を放置してしまうのです。

エージェントは「サプライチェーン・アクター」として扱え

この課題に対し、Form3 は AI エージェントを導入しましたが、情報セキュリティチーム（Infosec）から「これは自動化なのか、それとも待ち構えるサプライチェーン事故なのか？」という鋭い指摘を受けました。その答えが、本稿の核心となる提言です。

「有用なコーディング・エージェントは、計画していようとなかろうと、サプライチェーン・アクターである」

生産環境に権限を与える瞬間、AI エージェントはエンジニアと同様のリスクを持つ存在となります。したがって、人間に対して適用するガードレール（安全装置）を、エージェントに対しても同様に適用する必要があります。

決定論層と推論層の分離：「Patch Pilot」の設計思想

Form3 が開発した解決策「Patch Pilot」は、権限と役割を明確に分離した二層構造を持っています。これは特別な魔法ではなく、堅牢なアーキテクチャの再構築です。

1. 決定論的（Deterministic）なオーケストレーション層

まず、Go で書かれた「退屈で単純」なアプリケーションが全体の指揮を執ります。この部分は推論を行わず、以下の役割を担います。

• 脆弱性のある OCI イメージの発見とスキャン
• イメージとリポジトリの紐付け
• エージェントへのコンテキスト（プロンプトやマニフェスト）の準備
• エージェントが修正したファイルの検証（空ファイルや不要なバイナリの除去）
• PR の作成、コミット、プッシュ、CI 実行のトリガー

2. 推論（Reasoning）を行うエージェント層

一方、AI エージェントには「ファイルの修正」という最小限の権限しか与えません。具体的には以下のような役割です。

• CI 失敗の原因究明：インフラ障害なのか、前回の改修が原因なのかを判断
• 最小限の変更セットの実行：CVE を解決するためのバージョンアップのみを行い、最新バージョンへの安易なアップグレードは行わない
• 自己検証：Dockerfile のビルド成功とイメージの再スキャンを確認

この分離により、エージェントに「PR を作成する」「CI を監視する」といった危険な権限を与えず、バーストラジウス（被害範囲）を物理的に制限しています。

効果的なサンドボックス環境の構築

権限の分離だけでなく、実行環境そのものの安全性も極めて重要です。Form3 は、既存のツールでは不十分なため、ネットワーク制御や Docker ソケットへのアクセス制限を含む専用環境「Micro Sandbox」を構築しました。

エージェントは、この閉じられた環境内でのみ動作します。これにより、外部への不正な通信や、ホストシステムへの悪意のある影響を防ぎます。

継続的な改善と人間の役割

Patch Pilot は完璧ではありません。CI が失敗し続け最大リトライ回数に達した場合は、自動的に人間へ引き継がれます。また、エージェントの動作を可視化するため、各タスク完了後に「何がうまくいき、何が失敗したか」を簡潔な回顧（レトロスペクティブ）として取得する仕組みも導入しています。

このフィードバックデータを集約・分析することで、インフラの問題やリポジトリ固有の複雑さといった課題を特定し、エージェントのプロンプトや指示を改善していくことができます。実際、Form3 の事例では、人間が見過ごしていた「ベースイメージで既に修正済みだったパッケージのピン解除」といった微妙な最適化も、エージェントが見事に実行しました。

まとめ

AI エージェントを生産環境に導入する際、単なる自動化ツールの延長として扱うのではなく、それは「サプライチェーン・アクター」であると認識し、権限の分離と最小限の変更セットの強制という原則を徹底する必要があります。これがなければ、夜も眠れないセキュリティリスクを抱えることになります。

Form3 のアプローチは、大規模なコードベースを持つ企業にとって、自動化とセキュリティの両立を実現するための重要な指針となるでしょう。