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つずつ確認し、触れるファイル、ネットワーク接続、データに規則を当てます。許可した判断もブロックした判断もログに残ります。
導入の進め方として示された手順
導入は、狭い権限から始める進め方が示されています。
規則を絞り込む4段階
- 1
狭い権限で始める
最初から広く許可せず、必要になったアクセスだけを足していきます。
- 2
ログを見直す
許可した判断もブロックした判断も記録されるので、何が止まったかを後から追えます。
- 3
Claudeで規則を絞る
ログを読ませ、タスクに必要な最小限のアクセスへ向けて規則を絞ります。
- 4
ポリシープルーバーで確認する
チームが書いた規則のもとで、エージェントが到達できる範囲を確かめます。
ポリシープルーバー(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との役割分担(次項) |
この表は、責任分界のページとOpenShellのREADMEを突き合わせた対応です。OpenShellをManaged Agentsの環境ワーカーへ組み込む手順は、どちらのページにも載っていません。どの層に置くかは、導入する側が試して決めることになります。
表に入らなかった項目も、責任分界のページにあります。
- ワーカーが受け取る作業ごとに、セッション単位の
secretが付くことがあります。memory storeのエンドポイントは環境サービスキーを受け付けず、このsecretを求めます。secretはそのセッションのサンドボックスにだけ渡し、イメージや共有ボリュームに置かず、ログにも出しません read_onlyで付けたmemory storeが守るのはアップロードで、ローカルの書き換えは止まりません。bashツールや、サンドボックスから提供するカスタムツールは、ワーカーの権限で手元のコピーを変えられます。ローカルの見え方まで固定するなら、そのエージェントではbashを無効にし、ファイルシステムへ書くカスタムツールも持たせません- 会話内容とツールの出力はワーカーを通り、自社環境に残ります。保持・墨消し・削除は自社の責任で、Anthropicの管理の外に出ます
資格情報の置き場所は2か所ある
vaultのドキュメントによると、環境変数型の認証情報(environment_variable)は、サンドボックス内には不透明なプレースホルダーとして置かれます。エージェントが外向きのリクエストを出すと、プレースホルダーはエグレス時に本物のシークレットへ置き換わります。エージェントは値を目にしません。MCPサーバー向けの認証情報(mcp_oauth、static_bearer)は、エージェントがそのURLのサーバーへつないだときに、トークンが自動で差し込まれます。
資格情報を隠す2つの仕組み
vaultの環境変数型
サンドボックスには不透明なプレースホルダーだけを置き、エグレス時に本物へ置き換えます。置換先はnetworking.allowed_hostsで絞ります。セルフホスト型サンドボックスでは未対応です。
Providers
エージェントには実際の資格情報を見せず、承認済みの接続先へ向かうリクエストにだけ付けます。通信は、サンドボックスを出る前にポリシーの確認を通ります。
どちらも資格情報が働く場所を接続先で絞る点は同じです。環境変数型がセルフホストで使えない間の代替は、vaultのドキュメントにもOpenShellのREADMEにも書かれていません。MCP向けの認証情報(未対応と書かれていない型)の扱いは、使う前に試して確かめる点です。
vault側のallowed_hostsが決めるのは、どのリクエストに秘密を使うかだけで、通信の許可ではありません。エージェントがそのドメインへ届くには、環境側のネットワーク設定にも同じドメインが要ります。両方に入って初めて、置換つきのリクエストが通ります。
環境変数型の資格情報が効かないクライアント
置換はエグレスで起きるため、サンドボックス内で秘密を加工するクライアントは動きません。
環境変数型でつまずく3つの型
署名を計算するクライアント
AWS SigV4のように秘密から署名を作る場合、手元にあるのはプレースホルダーなので、署名が無効になります。
起動時に形式を検証するクライアント
資格情報の形式を起動時に検証するものは、プレースホルダーを拒否することがあります。
本文に秘密を入れるクライアント
Consoleで作った資格情報はヘッダーへの注入だけが有効です。フォーム形式のトークン要求のように本文へ入れる場合は、
injection_locationで{"body": true}を有効にしないと、プレースホルダーがそのまま送られ、相手側の認証エラーになります。
置換は送信方向だけです。保存した秘密でセッショントークンを取りに行く方式(OAuthのクライアント認証情報グラントなど)では、返ってきたトークンはサンドボックスに伏せられずに届きます。そうした交換型の流れは、自分で交換してできたトークンをvaultに保存する形が案内されています。
そのほかの制約として、vault1つに入れられる資格情報は最大20件、secret_nameは有効なものの中で一意です。キーは変更できず、変えるときは資格情報をアーカイブして作り直します。APIキーは、エージェントに必要な権限だけに絞ります。エージェントはキーが許す操作をすべて実行できるためです。
試すときの入口
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層に頼りません。
Managed Agentsが含むもの
Managed Agentsは、本番向けエージェントを作って展開するための、組み合わせ可能なAPI群です。含まれるものは次のとおりです。
- 安全なサンドボックス、認証、ツール実行が組み込まれた本番向けエージェント
- 数時間にわたり自律的に動き、切断が起きても進捗と出力が保持される長時間セッション
- エージェントが他のエージェントを立ち上げて指揮し、複雑な作業を並列化するマルチエージェントの編成
- スコープ付きの権限、ID管理、実行トレースを備え、実際のシステムへのアクセスを与えられるガバナンス
製品の役割や、自作のAgent SDK・Claude Codeとの違いはManaged Agentsの使い分けで扱っています。
導入事例として挙がった3社
- Notion: ワークスペース内でClaudeに仕事を任せられる。エンジニアはコードの出荷に、それ以外の社員はウェブサイトやプレゼン資料の作成に使い、数十のタスクを並列に動かしながらチームで成果を確認する
- Rakuten: エンジニアリング、プロダクト、営業、マーケティング、財務の各部門で専門エージェントを動かし、各エージェントは1週間以内に展開された
- Asana: Asanaのプロジェクト内で人と並んで働き、タスクを引き受けて成果物の草案を作る「AI Teammates」を構築した。Managed Agentsを使ったことで、使わない場合より速く高度な機能を追加できた
安全性の主語はモデルから運用構成へ移る
安全性の主語が、モデルから運用構成へ移っています。モデル内部の安全策は出発点に置かれたままですが、その外側に、エージェントが実際に何をしたかを規則で縛り、ログで追い、証明で確かめる層が並びました。
とくに「確認できる」ことへの比重が大きいのが特徴です。制限をかけるだけでなく、制限が効いていることを確かめる手段まで組み込んでいます。監査の場面では、規則を設定したという事実より、規則が実際に効いているという証拠のほうが求められます。規則のもとで到達できる範囲を証明で示す役目はポリシープルーバーが、実際の許可・拒否を記録する役目はログが受け持ちます。
一方で、発表から分からない点も残ります。AnthropicのブログにはOpen Agent Safety Platform全体の部品構成が載っていません。Managed AgentsとOpenShellをつなぐ設定手順や、既存のサンドボックス構成への組み込み方は、ブログにもドキュメントにもREADMEにも載っていません。実際の導入コストや、規則を絞る作業の手間は、公開されるドキュメントと実運用での検証を待つことになります。
似た問題意識は、手元のコーディングエージェントにもあります。ローカルで動くエージェントを隔離する方法はAIコーディングエージェントのサンドボックス実装比較にまとめています。ホスト型でも手元でも、権限の置き場所をモデルの外に持つという方向は共通しています。
まとめ
セルフホストで資格情報を守る構成は、vaultの環境変数型が使えない間、MCP向けの認証情報の扱いが、試して確かめる候補になります。使うクライアントが署名計算や起動時の形式検証をするかどうかが、導入前に確かめる分かれ目です。
モデルを信じるだけでは、監査の席で説明が足りなくなります。制限をモデルの外に置き、効いていることを示せる部品が揃ったのが今回の協力で、あとは自社の環境にどこまで当てはめられるかの検証が残っています。