NVIDIA OpenShell を使った AI Agent 環境のガードレイル策
こんにちは。ジェダイパンくず🍞 です。 以前の記事 自作 Go ツールに導入したガードレール策 や Google ADK Go 2.x の Dynamic Workflow とその為のガードレール では、AI エージェントに作業させるときのガードレールをコードやワークフローの側で考えていました。一方で最近は LiteLLM 1.107.0 の PyPI パッケージ侵害 や、Cursor Marketplace で配布された Claude Code 拡張にバックドアが仕込まれた件 など、エージェントが動く開発環境そのものが狙われる事件が続いています。 そんな中で、NVIDIA の OpenShell が 0.1.x で安定したリリースサイクルに入り、Hacker News でも話題になっていました。OpenShell は「自律 AI エージェントのための安全でプライベートなランタイム」をうたうもので、エージェントが触れるファイル・ネットワーク・API をポリシーで宣言し、カーネルレベルで強制します。README を読むだけでは実際にどこまで防げるのかが分からなかったので、サンプル環境を作って手を動かしてみました。 コードは下記に置いてあります。 https://github.com/jedipunkz/openshell-playground 検証したバージョンは OpenShell v0.1.6、環境は macOS + Docker Desktop です。 結論 試したこと 結果 ポリシーを指定せずに外へ通信 TCP も DNS もすべて拒否される GitHub API を GET のみ許可 GET は通り、POST は L7 で 403 になる。ルール追加は再起動不要 credential を provider 経由で渡す エージェントには placeholder しか見えず、紐付けた宛先にだけ本物の値が送られる 窃取スクリプトの模擬 外部送信・許可ホストへの POST・別バイナリからの通信・metadata 参照・許可外パスへの読み書きは拒否される。書き込み可能な workspace への永続化は防げない policy prover 上限ポリシーを超える変更を反例付きで検出できる。CI に組み込める 「エージェントが何を持ち出せて、どこに送れるか」をホスト・メソッド・バイナリ単位で絞り込めて、その判定がすべてログに残るのが OpenShell の価値だと感じました。逆に、許可した範囲の中で何が起きるかまでは面倒を見てくれないので、workspace の扱いは別途考える必要があります。 ...