Red Hat AI 3.5、OpenShellをOpenShiftに導入し、カーネルレベルのポリシーでエージェントの副作用を制約

Red Hatは[AI 3.5](https://www.redhat.com/en/blog/red-hat-ai-35-scaling-and-governing-ai-agents-production)で、NVIDIA主導のエージェントサンドボックスOpenShellをOpenShift AIに導入し、現時点ではDeveloper Previewとして提供している。狙いは、プロンプトフィルタリングをもう一層追加することではなく、エージェントが引き起こし得る副作用の判定をOSと外部ポリシーエンジンに委ねることだ。Landlock LSMはファイルパスを制限し、seccompは危険なシステムコールをフィルタリングし、独立したネットワーク名前空間は接続を分離する。OPAは、宛先、ポート、実行ファイルに加え、HTTPメソッド、パス、ヘッダーに基づいてL4／L7のエグレスポリシーを適用できる。

[OpenShellのアーキテクチャ](https://github.com/NVIDIA/OpenShell/blob/main/architecture/sandbox.md)では、ワークロードを管理権限を持つsupervisorと、非特権のagent childに分割する。前者は分離環境の構築、ネットワークのプロキシ、設定の注入を担い、後者は起動前にcapability bounding setを空にする。権限を正しく削除できない場合、ワークロードまたはSSH shellの作成は失敗する設計になっている。認証情報もエージェントに直接公開されない。環境内には不透明な代理tokenのみが配置され、エグレスプロキシは、リクエストがネットワークポリシーと、ホスト、ポート、パスのバインディングを同時に満たした場合に限り、それを実際の認証情報へ置き換える。

Red Hatは、この実行境界をNeMo Guardrails、Garakによるレッドチームテスト、サプライチェーン制御とも組み合わせている。NeMo Guardrailsは、入力、検索、対話、ツール実行、出力の各段階でコンテンツを検査できる。エージェントイメージはKonfluxでビルドされ、UBI9、RPM lock file、SBOM、署名検証が組み込まれる。また、プラットフォームはCodex、Goose、OpenClaw、OpenCodeなどのビルド済みエージェントharnessを提供し、チームごとにベースイメージを独自構成することで生じる差異を抑える。

ただし、「カーネルによる強制」を完全な分離と同一視することはできない。[NVIDIAのポリシードキュメント](https://docs.nvidia.com/openshell/reference/policy-schema)によると、Landlockのデフォルトは`best_effort`である。カーネルABIが対応していない場合や、すべてのパスに適用できない場合でも、システムは警告を出したうえで実行を継続する可能性がある。確実なフェイルクローズを必要とするデプロイでは、`hard_requirement`へ変更しなければならない。OpenShell自体も依然としてalphaと位置付けられており、Kubernetesおよびマルチテナント向けの実装は発展途上にある。試用を検討するチームは、ノードのカーネルバージョン、ポリシー適用失敗時の挙動、暗号化トラフィックの検査、GPUデバイスの公開範囲、監査ログの完全性、アップグレード時のCRDおよびポリシーの互換性を検証すべきだ。