Managed AgentsとNVIDIAが連携 — エージェントの権限を外から縛る
AnthropicとNVIDIAが、Managed Agentsの資格情報保管とOpenShellの実行制限を組み合わせ、エージェントの権限を多層で縛る構成を示しました。
要点 — 資格情報はvaultに、実行の制限はOpenShellに置く
NVIDIAが9月28日に発表した「Open Agent Safety Platform」は、AIのセキュリティを強化するためのオープンなソフトウェア基盤とリファレンス設計です。Anthropicはこの発表に合わせ、エージェントの実行基盤に安全策を足す形で協力しました。
Claude Managed Agentsは、エージェントに必要な資格情報をvault(保管庫)に置き、エージェント自身には見せません。NVIDIAのオープンソースソフトウェアOpenShellは、エージェントが実行できることと到達できる範囲を作業中に制御します。
今回の協力で示された主張は次の4点です。
- Managed AgentsとOpenShellの組み合わせで、エージェントにできることを制限し、やったことを見直し、制限が効いていることを確認できる
- 保護は層構造で、モデル内部の安全策に加え、モデルの外側にも制限を置く
- 各層はそれぞれ独立して制限を強制するよう設計され、特定の1層に依存しない
- 層はモジュール式で、自社の環境に合うものだけを採用できる
エージェントに渡す権限が増えるほど、企業側の統制と確認の重みも増します。今回の発表は、その統制をモデルの外側に置く方針を、具体的な構成部品で示したものです。
あなたの運用はどう変わるか
Managed Agentsを使っているチーム
Managed Agentsでは、オーケストレーション(モデルが動く側)はAnthropicが受け持ち、ツールの実行はサンドボックスで行われます。サンドボックスは、既定ではAnthropicが管理するクラウド上のものです。パスワードやアクセスキーといった資格情報はvaultに登録しておき、セッション作成時にIDで参照します。エージェントが資格情報の値を目にしないことは、今回の発表で初めて示された話ではなく、Managed Agentsのvaultのドキュメントにすでに書かれている挙動です。
Managed Agentsには、各エージェントの行動を記録する監査証跡と、企業の既存のアクセス制御との連携も備わっています。サンドボックスは自社で用意でき、自社インフラでもマネージドプロバイダーでも動かせます。Managed Agentsは発表日から利用できます。
vaultの具体的な扱いはManaged AgentsにVaultで秘密情報を渡す手順にまとめています。ツールごとの許可の設計はManaged Agentsの権限ポリシー設計が扱っています。
NVIDIA OpenShellを足したいチーム
OpenShellはNVIDIAのオープンソースの安全なランタイムソフトウェアで、エージェントの操作を監視し、1つずつポリシーに照らして許可・拒否します。ライセンスはApache 2.0で、GitHubとNVIDIAの開発者向けリソースのページから入手できます。
規則の適用はエージェントの外側で行われます。OpenShellは、規則が許可しない限り、すべてをブロックします。エージェントが使おうとするツールを1つずつ確認し、触れるファイル、ネットワーク接続、データに規則を当てます。許可した判断もブロックした判断もログに残ります。
導入の進め方として示された手順
導入は、狭い権限から始める進め方が示されています。
- 狭い権限で始める
- ログを見直す
- Claudeを使い、タスクに必要な最小限のアクセスへ向けて規則を絞る
- OpenShellのポリシープルーバーで、チームが書いた規則のもとでエージェントが到達できる範囲を確認する
ポリシープルーバー(policy prover)は数学的な証明によって、その確認を行います。実際に動かして確かめるテストとは違い、規則そのものから到達範囲を導く考え方です。NVIDIAのリポジトリの説明では、ポリシーの変更を適用する前に形式検証を行い、新しいホストへ資格情報つきで到達するといった危うい変更を人間のレビュー待ちにします。
セルフホストサンドボックスのどこにOpenShellが入るか
発表の文面だけでは、OpenShellがManaged Agentsのどの地点に規則を当てるのかは分かりません。Managed Agentsのドキュメントと、OpenShellのリポジトリの説明を並べると、規則が必要になる場所と、規則を当てる仕組みの対応が見えてきます。
分離される3つの場所
セルフホストサンドボックスでは、オーケストレーションはAnthropic側に残り、ツールの実行だけが自社インフラに移ります。自社で動かす環境ワーカーは、Anthropicから届くツール実行の要求を受け取り、ローカルで実行して結果を返すプロセスです。ツールの入力と出力はAnthropicのコントロールプレーンへ流れ続けるため、モデルは結果を見て次の手を決められます。
セキュリティモデルのページでは、境界がこう引かれています。Anthropicが守るのはコントロールプレーンで、セッションとワークキューの整合性、マルチテナント分離、エージェントに渡すコンテキストの最小化です。サンドボックスイメージの堅牢化、外向き通信(egress)の制御、ツールが動くプロセスの権限は自社の責任になります。環境ワーカーの認証に使う環境サービスキー(ANTHROPIC_ENVIRONMENT_KEY)の保管とローテーションも自社側の責任で、信頼できないコードを動かす場合は、信頼境界ごとにワークスペースと環境を分けることが案内されています。
自社が持つ責任とOpenShellの規則の対応
責任分界で自社に残る項目と、OpenShellのリポジトリが説明する制御を並べると、次のようになります。
| 自社が持つ項目 | OpenShellの説明にある制御 | 残る確認事項 |
|---|---|---|
| 外向き通信の制限(VPC・ファイアウォール) | OpenShellの説明にある制御すべてのネットワーク接続が、サンドボックスを出る前にポリシーの確認を通る | 残る確認事項接続先の許可リストをどう作るか |
| ツールが動くプロセスの権限 | OpenShellの説明にある制御カーネルの制御で、使えるシステムコールを絞る | 残る確認事項エージェントの実行ユーザーとの兼ね合い |
| マウントするファイルの範囲 | OpenShellの説明にある制御アクセスできるファイルをカーネルの制御で絞る | 残る確認事項ワーカーが置くmemory storeの作業コピーの扱い |
| 資格情報の見え方 | OpenShellの説明にある制御実際の資格情報はエージェントに見せず、承認済みの接続先向けのリクエストにだけ付ける | 残る確認事項vaultとの役割分担(次項) |
この対応は、2つの資料を並べた筆者の整理です。OpenShellをManaged Agentsの環境ワーカーへ組み込む手順は、公開資料には書かれていません。したがって、実際にどの層に置くかは、導入する側が試して決める領域です。
資格情報の置き場所は2か所ある
vaultのドキュメントによると、環境変数型の認証情報(environment_variable)は、サンドボックス内には不透明なプレースホルダーとして置かれます。エージェントが外向きのリクエストを出すと、プレースホルダーはエグレス時に本物のシークレットへ置き換わります。エージェントは値を目にしません。MCPサーバー向けの認証情報(mcp_oauth、static_bearer)は、エージェントがそのURLのサーバーへつないだときに、トークンが自動で差し込まれます。
OpenShell側にも、同じ形の仕組みがあります。リポジトリの説明では、エージェントは実際の資格情報を見ず、OpenShellが承認済みの接続先へ向かうリクエストにだけ資格情報を付けます。資格情報が働く場所を接続先で絞る点は、vaultの環境変数型と共通しています。どちらを主に据えるかは、環境変数型がセルフホストで使えるようになるまでは、構成ごとの判断になります。
試すときの入口
OpenShellはLinux、Apple SiliconのmacOS、WSL 2上のWindows(実験的)で動きます。DockerかPodman、またはホストの仮想化が要ります。READMEのクイックスタートは次の2行です。
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo既定のサンドボックスイメージは、エージェントが入っていない最小のUbuntuです。実際のエージェントで試す手順はREADMEの「Run Your First Agent」にあり、エージェントが必要とするアクセスを都度承認していく流れです。ポリシーはファイルシステム、ネットワーク、プロセスの3種類で書き、変更内容の確認にはアドバイザーとプルーバーが使えます。
セルフホストの組み立て自体はManaged Agentsのセルフホストサンドボックス構築手順に、責任分界の全項目はセルフホストサンドボックスのセキュリティ責任分界にあります。
背景 — 質問に答えるAIから、業務を動かすAIへ
権限が増えるほど統制が要る
前提にあるのは、企業がAIを質問への回答用途から、複雑な業務をこなす用途へ移していることです。エージェントは事業部門をまたいで動き、社内の独自データを使い、利用者に代わって行動します。モデルが良くなるほどエージェントの用途は広がり、アクセス権も増えます。
アクセスが増えるほど、企業はエージェントの行動を制御し、確認する必要が高まります。この流れが、今回の協力の出発点です。
層ごとに担当が違う
保護はモデル内部の安全策から始まります。Managed AgentsとNVIDIA OpenShellは、その外側に、エージェントの行動に効く制限を足します。
| 層 | 担当 | 役割 | 導入側が決めること |
|---|---|---|---|
| モデル内部 | 担当Claude | 役割保護の出発点となる安全策 | 導入側が決めること使うモデルの選択 |
| 資格情報とループ | 担当Managed Agents | 役割資格情報をvaultで保持し、ループとサンドボックスを分離。監査証跡とアクセス制御連携 | 導入側が決めること認証情報の種類、サンドボックスの置き場 |
| 実行と到達範囲 | 担当OpenShell | 役割規則が許可しない操作をブロックし、判断をログに残す。ポリシープルーバーで範囲を確認 | 導入側が決めること許可する接続先とファイルの規則 |
各層が独立して制限をかける設計で、どれか1層に頼らないため、1層が破られても残りの層が効くように作られています。
Managed Agentsが含むもの
Managed Agentsは、本番向けエージェントを作って展開するための、組み合わせ可能なAPI群です。含まれるものは次のとおりです。
- 安全なサンドボックス、認証、ツール実行が組み込まれた本番向けエージェント
- 数時間にわたり自律的に動き、切断が起きても進捗と出力が保持される長時間セッション
- エージェントが他のエージェントを立ち上げて指揮し、複雑な作業を並列化するマルチエージェントの編成
- スコープ付きの権限、ID管理、実行トレースを備え、実際のシステムへのアクセスを与えられるガバナンス
製品の役割や、自作のAgent SDK・Claude Codeとの違いはManaged Agentsの使い分けで扱っています。
導入事例として挙がった3社
- Notion: ワークスペース内でClaudeに仕事を任せられる。エンジニアはコードの出荷に、それ以外の社員はウェブサイトやプレゼン資料の作成に使い、数十のタスクを並列に動かしながらチームで成果を確認する
- Rakuten: エンジニアリング、プロダクト、営業、マーケティング、財務の各部門で専門エージェントを動かし、各エージェントは1週間以内に展開された
- Asana: Asanaのプロジェクト内で人と並んで働き、タスクを引き受けて成果物の草案を作る「AI Teammates」を構築した。Managed Agentsを使ったことで、使わない場合より速く高度な機能を追加できた
安全性の主語はモデルから運用構成へ移る
安全性の主語が、モデルから運用構成へ移っています。モデル内部の安全策は出発点に置かれたままですが、その外側に、エージェントが実際に何をしたかを規則で縛り、ログで追い、証明で確かめる層が並びました。
とくに「確認できる」ことへの比重が大きいのが特徴です。制限をかけるだけでなく、制限が効いていることを確かめる手段まで組み込んでいます。監査の場面では、規則を設定したという事実より、規則が実際に効いているという証拠のほうが求められます。規則のもとで到達できる範囲を証明で示す役目はポリシープルーバーが、実際の許可・拒否を記録する役目はログが受け持ちます。
一方で、発表から分からない点も残ります。Open Agent Safety Platform全体がどの部品で構成されるのか、Managed AgentsとOpenShellをつなぐ具体的な設定手順や、既存のサンドボックス構成にどう組み込むのかは、今回の発表には書かれていません。実際の導入コストや、規則を絞る作業の手間は、公開されるドキュメントと実運用での検証を待つことになります。
似た問題意識は、手元のコーディングエージェントにもあります。ローカルで動くエージェントを隔離する方法はAIコーディングエージェントのサンドボックス実装比較にまとめています。ホスト型でも手元でも、権限の置き場所をモデルの外に持つという方向は共通しています。
まとめ
- Managed Agentsを本番で使う企業: 資格情報の分離、監査証跡、アクセス制御連携に加え、OpenShellで実行と到達範囲を外側から縛る構成が選べる
- 独自のサンドボックスを持つ企業: Managed Agentsは自社インフラ上でも動くため、層をモジュールとして必要な分だけ採用できる
- セキュリティ・監査の担当者: 許可と拒否の判断がログに残り、ポリシープルーバー(policy prover)で到達範囲を確認できる点が、統制の説明材料になる
モデルを信じるだけでは、監査の席で説明が足りなくなります。制限をモデルの外に置き、効いていることを示せる部品が揃ったのが今回の協力で、あとは自社の環境にどこまで当てはめられるかの検証が残っています。