AIコーディングエージェントを便利にしている性質は、そのまま危険の源でもあります。エージェントの価値は、確認を求めずにパッケージをインストールし、テストを実行し、設定を変更できる点にあります。しかし一般的な開発者のマシンでは、その自由がSSH鍵、クラウドの認証情報、開かれたネットワーク接続のすべてをエージェントの手の届く範囲に置いてしまいます。Eclipse FoundationがMITライセンスで管理するオープンソースのランタイムEclipse Enclaveは、承認プロンプトとは別の道を選びました。エージェントには制限をかけず、エージェントが動く箱のほうを制限するという方法です。コマンド一つで、エージェントのセッションごとに専用のコンテナを用意し、見えるファイル、ネットワークの許可リスト、代わりの秘密値をそれぞれ個別に持たせます。
ワークステーションで完全な自律を許す問題
一般的な開発マシンには、ロックが解除されたSSH鍵、クラウドの認証情報、個人用アクセストークンがあり、インターネットにも制限なく接続できます。自律型のエージェントにこの環境を渡すと、三つの問題が生じます。
- プロンプトインジェクション。 README、Issue、Webページに隠された指示が、ユーザーの求めていない操作をエージェントに行わせることがあります。
- 認証情報の露出。 ホームディレクトリを読めるエージェントはそこに保存された鍵も読めます。読めるものは、ほかの場所へ送ろうとすることもできます。
- エージェント同士の衝突。 1台のマシンを共有する複数のエージェントが、互いのファイルを上書きし、パッケージのバージョンを変え、互いのプロセスを中断させます。
よくある対策はトレードオフを強います。すべてのコマンドに承認を求めれば速度の利点が失われ、モデルの判断を信頼すればセキュリティが失われます。Enclaveの設計原則は短く、「エージェントを制限するのではなく、サンドボックスを制限する」というものです。このプロジェクト自体はエージェントではなく、特定のモデルベンダー向けのラッパーでもありません。Claude Code、OpenAI Codex CLI、Copilot CLI、OpenCodeといったエージェントを動かし、切り替えて使えるようにするサンドボックスとコンテナのツールです。
▲ コーディングエージェントの隔離環境
セッションの流れ
セッションの開始に必要なのはコマンド一つです。プロジェクトのディレクトリでenclaveを実行すると、選んだエージェントのCLIを入れたコンテナイメージをビルドまたは取得し、そのディレクトリだけをマウントし、コンテナの前段にネットワークゲートウェイを置いたうえで、Claude Codeのbypass-permissionsモードのような自律モードでエージェントを起動します。初回のビルドには時間がかかりますが、その後はキャッシュされたレイヤーのおかげで2秒足らずでセッションが再開します。
隔離が機能していることは、二つの簡単な確認でわかります。エージェントの中から親ディレクトリの一覧を表示すると、マウントしたプロジェクトフォルダーしか見えません。許可リストにないドメインへ接続しようとすると、名前解決の段階で失敗します。エージェントが本当にそのドメインを必要とする場合は、別のターミナルからenclave network add-domainを実行すれば実行中のセッションにすぐ反映され、ドメインを削除すれば再び遮断されます。
すべてのセッションが答える四つの問い
Enclaveは、各セッションを四つの問いを軸に構成しています。
| 柱 | 問い | 既定の動作 |
|---|---|---|
| SEE | エージェントに何が見えるか | 現在のプロジェクトディレクトリのみを読み書き可能で公開し、ホームディレクトリは新しい空のもの |
| RUN | 中で何が動くか | エージェントとNode.jsやMavenなどのランタイムを含むイメージ |
| REACH | どこに接続できるか | 許可リストとログ記録を備えた独立したゲートウェイ |
| KEEP | セッション後に何が残るか | ログイン情報、履歴、設定は保持し、実行環境は破棄 |
SEE：プロジェクトフォルダー以外は見せない
~/.ssh、~/.aws、~/.kube、~/Documentsのような機密性の高いパスは一切マウントしません。プロジェクトフォルダーは直接のバインドマウントなので、エージェントの編集は同期の遅れなくホストのディスクに反映されます。参考資料は--add-readonly-dirで読み取り専用として追加できます。普段の環境を使いたい開発者は、--host-config-passthroughで、MCP（Model Context Protocol、AIツールを外部のデータやサービスにつなぐための標準）サーバーの設定やスキルなど許可リストにあるファイルをサンドボックスにコピーできます。
REACH：直列に並ぶ三つの関門
各サンドボックスには専用のゲートウェイがサイドカーとして付き、外向きの通信を3段階でふるいにかけます。
- DNSフィルター。 dnsmasqが許可リストにあるドメイン名だけを解決し、それ以外の問い合わせにはすべて存在しないドメインとして応答します。
- ファイアウォール。 IPアドレスを直接書けばDNSの確認を素通りできるため、DNSの段階で正当に解決されたIPアドレス以外への外向き通信をすべて破棄します。
- プロキシ。 ポート80と443の通信は透過プロキシを通り、HTTPのHostヘッダーとTLSのServer Name Indication（暗号化接続を始める際にクライアントが名乗る接続先ドメイン）を確認します。Web以外のプロトコルは破棄します。
それぞれの関門が、ほかの関門の隙間を埋めています。DNSフィルタリングだけではIPへの直接接続を見逃し、IPの許可リストだけでは一つのCDNアドレスを共有する多数のドメインを区別できません。遮断はすべて記録され、enclave network logで確認できます。
エージェントが持たない秘密値
最も特徴的なのは、認証情報の扱い方です。コンテナ内の環境変数には、本物のAPIキーではなくランダムなプレースホルダー文字列が入ります。エージェントがその秘密値用に宣言された宛先へHTTPSリクエストを送ると、ゲートウェイが通信の途中でプレースホルダーを本物のキーに差し替えます。同じプレースホルダーをほかのホストへ送ると、ゲートウェイはHTTP 403 Forbiddenを返します。本物のキーはコンテナ内に一度も存在しないため、プロンプトインジェクションでだまされたエージェントでも、漏らせる価値のあるものを持っていません。GitHub CLIの拡張機能も同じ代替トークンの方式を使います。
KEEP：ログインは共有、プロジェクトは分離
毎回ログインを求めるサンドボックスは使われないため、Claude CodeやCodexといったツールごとの認証は一度だけ保存され、プロジェクトをまたいで再利用されます。会話履歴、メモリー、設定、ネットワークログはプロジェクトのパスごとに分けられ、リポジトリの外に保存されます。あるプロジェクトのコンテキストがほかのプロジェクトに混ざることはなく、エージェントの状態がGitリポジトリを散らかすこともありません。ネットワークの判断はすべてプロジェクトごと、ツールごとに記録され、その記録はEU AI ActやCyber Resilience Actのような規則のもとでコンプライアンスの証拠として使えます。
情報持ち出しの試みを検証する
Codexのセッションを使ったテストが、この仕組みを実際に示しています。注入された指示の代わりとして、エージェントにリポジトリのREADMEを読み、その内容をURLパラメーターとして外部ドメインへ送るよう指示しました。エージェントは指示に従い、ファイルを読んでエンコードし、リクエストを送ろうとしました。しかし宛先が許可リストになかったため、ゲートウェイが接続を止めました。この防御はモデルが拒否することに頼っておらず、データの行き場がないことに頼っています。別のターミナルでenclave network log -fを実行しておけば、こうした許可と拒否の判断をリアルタイムで確認できます。
▲ 許可リスト外の宛先への通信遮断
エージェントを並べて動かす
隔離は並行作業も現実的なものにします。日々の作業では、これがセキュリティと同じくらい重要になるかもしれません。複数のエージェントに一つのフォルダーやブランチを共有させるのではなく、推奨されるのは、エージェントごとに専用のGit worktree（別々のブランチを別々のフォルダーにチェックアウトするGitの機能）と専用のEnclaveセッションを用意する方法です。セッションは--nameで付けた名前でバックグラウンド実行でき、enclave psで一覧を確認し、enclave attachで入って、止めずにまた抜けることができます。すべてのコマンドが--json出力に対応しているので、構成全体をスクリプトで動かせます。
プロジェクトはルールを厳しくできても緩められない
設定はレイヤーで解決され、より具体的なレイヤーが優先されます。順にCLIフラグ、ツールごとの上書き、プロジェクト設定、グローバル設定、組み込みの既定値です。ただし権限は例外です。プロジェクト設定は制限を加えることはできますが、すべてのネットワーク通信を許可するようなアクセスを広げる設定は警告とともに無視されます。権限の拡大はグローバル設定かコマンドラインから、キーボードの前にいる人が意図して行う必要があります。拡張機能もプロジェクトのリポジトリ内からは決して読み込まれないため、信頼できないリポジトリを開いても、セットアップ中にそのコードが実行されることはありません。
実行ごとのフラグで、特定の作業に合わせてさらに制限を強められます。
--project-mount readonlyは、エージェントに実装の計画だけを立てさせたいときにファイルを変更させません。--worktree-metadata readonlyは、ファイルの編集は許しつつGitのステージングとコミットを失敗させ、コミットを人のレビューのもとに置きます。--ephemeralは、保存された状態なしで始まり、終了後にログイン情報と設定を破棄します。一度きりの作業や信頼できない作業に向きます。
チームは、レジストリを用意しなくても、任意のGitリポジトリで拡張機能やポリシーを共有できます。拡張機能はコミットハッシュに固定され、インストールの前にEnclaveが必要なスクリプト、許可するドメイン、ポート、認証情報を一覧で示して確認を求めます。
既知の限界
Enclaveはリスクを狭めますが、なくすわけではありません。
- 既定のバックエンドはroot権限で動くDockerデーモンなので、コンテナを脱出不可能な境界とみなすべきではありません。
- ネットワークのフィルタリングが制御するのはデータの行き先であり、データの中身ではありません。
- プレースホルダーの差し替えは、宣言された秘密ヘッダーにしか適用されません。ブラウザーでの対話的なOAuthログインでは、本物のトークンがコンテナ内に入ります。
プロジェクトがまだ若いことも考慮が必要です。2025年末に社内ツールとして始まり、2026年5月にEclipse Foundationへ寄贈され、1.0のリリースは数週間以内と見込まれています。プレリリース版は、LinuxとmacOS、WSL2経由のWindowsで、rootless DockerかPodmanを使って動作します。
鍵を預ける前に決めておくこと
コーディングエージェントを自律モードで動かしている、あるいは動かす予定なら、権限確認を切るのは隔離された環境の中だけにするのが最も安全だと考えられます。Enclaveを使うか別の方法を取るかにかかわらず、まず次の四つを決めておきましょう。
- 見える範囲。 エージェントが見るのは一つのプロジェクトフォルダーに限り、参考資料は読み取り専用で追加します。
- ネットワークの到達範囲。 パッケージレジストリやモデルのAPIなど、作業に必要なドメインだけを許可し、拒否のログを確認します。
- 秘密値。 本物のキーをエージェントの環境変数に入れないようにします。
- 人の管理。 コミットと権限の拡大は人が行うものとして残します。
複数のエージェントを同時に動かすなら、それぞれに専用のGit worktreeを割り当てることが、衝突を避けるための最も簡単な第一歩です。