AI エージェントを外側のポリシーで閉じ込める（NVIDIA OpenShell）
エージェント本体ではなく外側の Supervisor がファイル・通信・プロセス・認証情報を強制し、仮キーだけ渡して許可先への通信時に本物の鍵へ差し替える。
何を解決するか / いつ使うか
- Claude Code や Codex など既存エージェントに本番相当の権限を渡さず、サンドボックス内で走らせたいとき。
- AI エージェントと本番の間にプロトコル単位のファイアウォールを置く（Claw Patrol） のようなプロトコル代理に加え、カーネルレベルのファイル／プロセス制限と認証情報の非開示まで一括で欲しいとき。
- 複数エージェントの分離は worktree＋ネットワーク namespace で十分なことが多い では足りない（未信頼入力や破壊的操作のリスクがある）とき。
仕組みと導入の要点
- OpenShell（Apache 2.0）でエージェントをサンドボックス起動する。制御面は Gateway、実行境界は各サンドボックス内の Supervisor。エージェントは制限付き子プロセスとして起動される。
- 静的制御（作成時に固定、変更はサンドボックス再作成）:
- ファイルシステム: Landlock などで宣言パス以外を遮断（読み取り専用／読み書きをポリシーで指定）。
- プロセス: 権限ドロップ＋seccomp で危険な syscall や昇格を抑制。
- 動的制御（稼働中に
openshell policy update/policy setで更新可）:- 外向き通信は Supervisor 経由のポリシープロキシのみ。HTTP / GraphQL / MCP などを検査し、同じ API でも読み取りのみ許可・書き込み拒否が可能。
- ネットワークと推論プロバイダ向けルールはホットリロードできる。
- 認証情報の分離: エージェントには仮キーだけ渡し、ポリシーと認証紐付けの両方を満たす接続に限り Supervisor が外側で本物のキーへ置換する。許可外へ仮キーを送っても拒否され、キー自体に書き込み権限があっても読み取り専用ポリシーで書き込みを止められる（AI エージェントに資格情報を渡す 4 パターンと使い分け の「渡さない」寄り）。
- ポリシー検証: 形式論理で「与えた権限が管理者の意図範囲に収まるか」を証明し、範囲外の操作があれば具体例を出す。エージェント自身の説明では結果が変わらない設計。
- 人の承認: ポリシー提案を有効にするとエージェントは範囲を絞った権限変更を提案できるが、既定では人の審査待ちで、自分の要求は承認できない。
- 任意の追加層 Sentry（BlueField / DOCA）でホストから独立した監視も可能。OpenShell 本体は BlueField なしでもローカル／オンプレ／クラウド／Kubernetes で動くと説明されている。
既存のコーディングエージェントを作り直さずに載せられる点が実務向き。
注意点
- 静的ポリシー（ファイル・プロセス）の変更はサンドボックス再作成が必要。運用フローに「ポリシー改訂＝再作成」を織り込む。
- BlueField 付きの Sentry はハードウェア依存。まずは OpenShell 単体の Supervisor 境界から始めるのが現実的。
- どのサンドボックスでも「ポリシーに書いた範囲＝漏えい・破壊の上限」。読み取り許可したパスやエンドポイントの見直しは必須。
- 一次情報は NVIDIA のドキュメント／ブログを直接確認する（投稿は要約）。