Managed Agentsを本番に出す前のセキュリティ点検 — 8項目の確認表
Managed Agentsの本番前に確認する設定を、ネットワーク・vault・Web系ツール・承認・ツール数・信頼できない入力・予算と停止手順の8項目に整理。危険な既定値も示します。
Managed Agentsを本番に出す前の点検は、8つの設定を上から順に確かめれば足ります。ネットワーク、vault、Web系ツール、承認、ツール数、信頼できない入力、予算、停止手順です。いずれも既定値のままだと広く開いているので、「何もしなければ安全」とは考えないほうが安全です。
Managed Agentsはベータ(managed-agents-2026-04-01)で、設定名は変わる可能性があります。以下は本番前の確認表です。
本番前の確認表
| 確認する設定 | 目指す状態 |
|---|---|
| 実行場所 | 目指す状態クラウド環境。ツールを自社基盤で動かす必要があるときだけセルフホスト |
環境の networking.type | 目指す状態limited、allowed_hosts は必要なホストだけ |
| vaultの認証情報 | 目指す状態注入先はリクエストヘッダーのみ、接続先ホストを限定 |
web_fetch / web_search の allowed_domains | 目指す状態両方に許可リストを設定 |
各ツールの permission_policy | 目指す状態取り消せない操作は always_ask |
default_config.enabled | 目指す状態false にして必要なツールだけ有効化 |
| 信頼できない入力を読むエージェント | 目指す状態書き込み・実行系ツールを always_allow にしない |
| セッションとデプロイメントの予算 | 目指す状態1回の実行費用に見合う上限 |
以降の節は、この表の順に見ていきます。
実行場所はクラウドが基本
ツールをどこで動かすかで、サンドボックスを守る担当が変わります。クラウド環境ならAnthropic、セルフホストなら自分です。自社基盤で動かす必要がなければクラウドが推奨されています。
セルフホストを選ぶと、次の4点が自分の責任に移ります。
- ネットワーク制限はクラウド環境向けの設定で、セルフホストでは自社のファイアウォールで同等の制限を掛ける
- Web系ツールはAnthropicのサーバー上で動くため、ファイアウォールでは止まらない。ドメイン許可リストで制限する
- 環境変数型の認証情報は、セルフホストではまだ使えない
- 隔離とハードニングは自社の責任になる
責任分界の詳細はセルフホストサンドボックスのセキュリティ責任分界にあります。
ネットワークはlimitedにして、毎回明示する
環境を作るときは networking.type を limited にし、allowed_hosts に必要なホストだけを並べます。networking を省いた作成リクエストは unrestricted になることがあるため、省略は禁物です。
{
"name": "support-agent",
"config": {
"type": "cloud",
"networking": {
"type": "limited",
"allowed_hosts": ["help.example.com"]
}
}
}limited には3つのスイッチがあります。
| 設定 | 開くもの | 推奨 |
|---|---|---|
allowed_hosts | 開くもの列挙したホストへの全リクエスト | 推奨信頼できるホストだけ。自分で運用または信頼するMCPサーバーのホストも含める |
allow_package_managers | 開くものパッケージマネージャーのホスト群。github.com などは誰でもコンテンツを置けて、サンドボックスからアップロードもできる | 推奨false。環境の packages に列挙するなら true が必要 |
allow_mcp_servers | 開くものホストは開かない。MCPへの接続はAnthropic側のサーバーから行われる | 推奨false にして、MCPサーバーのホストを allowed_hosts に書く |
許可はホスト単位で、操作単位ではありません。許可したホストには git push やパッケージ公開のようなアップロードも通ります。ワイルドカード(*.)や、誰でも公開できる共有ホスティングのドメインは避けます。
添付したファイル、メモリストア、GitHubリポジトリは、allowed_hosts に関係なく使えます。環境を絞ったあとは新しいセッションを始め、動いているセッションは止めてください。実行中のセッションは古い制限のまま動き続けることがあります。設定項目の全体はクラウド環境の構築手順にまとめています。
秘密情報はvaultに置き、注入先とホストを絞る
秘密情報はすべてvaultに入れます。サンドボックス内のコードにはプレースホルダーだけが見え、本物の値は許可したホストへのHTTPSリクエストにだけ差し込まれます。セッションやデプロイメントを作るとき、vault_ids にIDを渡して使います。
環境変数型の認証情報では、次を設定します。
injection_locationを{"header": true, "body": false}にする。リクエストボディはエージェントが読んだ内容で組み立てられやすく、キーが漏れやすい。両方のフィールドを明記すること(省略すると両方有効になる)- 認証情報側の
networkingをlimitedにして、そのキーが対象とするホストだけを書く - 発行元のサービスで、キーの権限を必要最小限にする
- GitHubリポジトリをマウントするなら、権限を絞ったfine-grainedトークンを使う
見落としやすいのがClaude APIキーです。vaultに入れても、サンドボックス内のコードはそのキーでClaude APIを直接呼べます。セッションの開始・削除などキーで許されることは何でもでき、ツール設定・承認・予算は効きません。エージェントにClaude APIキーを渡さない、が点検の項目です。
異なる信頼レベルの業務は、ワークスペースごとに分けます。同じワークスペースにアクセスできるAPIキーなら、誰でもそのvaultを参照できるためです。操作手順はVaultで秘密情報を渡す手順で扱っています。
web_fetchとweb_searchは許可ドメインで絞る
Web系ツールには allowed_domains を、両方に、すべての環境タイプで設定します。web_fetch が開くURLには、データを運ぶ力があります。取得先のサイトに情報を渡せるので、この一覧はセキュリティ制御です。web_search では、結果を返してよいサイトを書きます。ただし検索クエリそのものは検索プロバイダーに届きます。
blocked_domains は頼りません。列挙したホストとそのサブドメインしか止まらず、Webアーカイブやミラーから同じ内容が届くためです。
limited 環境では、allowed_hosts がWeb系ツールも制限します。2つの一覧の照合ルールが違う点に注意してください。
| 一覧 | 書いた値 | 一致する | 一致しない |
|---|---|---|---|
allowed_hosts(環境) | 書いた値example.com | 一致するexample.com | 一致しないwww.example.com |
allowed_hosts(環境) | 書いた値*.example.com | 一致するすべてのサブドメイン | 一致しないexample.com |
allowed_domains(ツール) | 書いた値example.com | 一致するexample.com と全サブドメイン | 一致しない他のドメイン |
ツールの allowed_domains に書いたドメインが allowed_hosts の外にあると、セッション作成は400エラーになります。デプロイメントが起動するセッションだけは作成されますが、そのドメインからは何も返りません。
web_fetch は、そのセッションにすでに出てきたURLしか開きません。ユーザーメッセージ、検索結果のアドレス、取得済みページの本文にあるURLは開けます。システムプロンプト、エージェントの設定、Claude自身の出力、bash の出力は開けません。注入された文章が、秘密を載せたURLを組み立てるのを防ぐ仕組みです。ただしこの制限があっても allowed_domains は必要です。
承認ポリシーは「取り消せるか」で分ける
エージェントツールセットの既定は always_allow で、承認なしにすべての呼び出しが走ります。次のように見直します。
| ツール | 推奨 |
|---|---|
read / glob / grep | 推奨always_allow(サンドボックス内を読むだけ) |
bash / write / edit | 推奨auto。サンドボックスの外に出た変更を取り消せないなら always_ask。エンドユーザーの文章を中継するなら bash は always_ask |
web_fetch | 推奨auto |
web_search | 推奨検索クエリに送りたくないデータを扱うなら always_ask、そうでなければ always_allow |
| 読むだけのMCPツール | 推奨ツールごとに configs で auto |
| データを変えるMCPツール | 推奨always_ask(MCPツールセットの既定のまま) |
| カスタムツール | 推奨権限ポリシーは適用されない。自分のコードで入力を検証する |
auto は人間のチェックポイントではありません。サーバーが各呼び出しを評価し、実行・拒否・一時停止のどれかを返します。長い実行で人が全件を承認するのは現実的でないため、ネットワーク制限、狭い権限のキー、予算、アイドル通知と組み合わせて使う想定です。人が必ず見るべきツールは always_ask にします。
always_ask で止まったセッションは、いつまでも待ち続けます。無人運用なら、止まった呼び出しに答えるか、セッションを中断するクライアントが要ります。内容を見せずに全部許可するクライアントは、always_allow と同じです。実装はツール確認リクエストへの応答、ポリシー設計の考え方は権限ポリシー設計に分けて書いています。
組み込みツールは全部切ってから必要な分だけ入れる
エージェントツールセットは、組み込み8ツール(bash、write、edit、read、glob、grep、web_fetch、web_search)を既定で全部有効にします。default_config.enabled を false にして、要るものだけ有効化します。次は、サポート担当エージェントの例です。
{
"type": "agent_toolset_20260401",
"default_config": {
"enabled": false,
"permission_policy": {"type": "always_ask"}
},
"configs": [
{"name": "read", "enabled": true,
"permission_policy": {"type": "always_allow"}},
{"name": "write", "enabled": true,
"permission_policy": {"type": "auto"}},
{"name": "web_fetch", "enabled": true,
"allowed_domains": ["help.example.com"],
"permission_policy": {"type": "auto"}}
]
}注文の照会は、アプリ側で動かすカスタムツール lookup_order に任せます。APIキーはアプリ側が持つため、エージェントに bash も認証情報も要りません。default_config を always_ask にしてあるので、あとから有効にしたツールにポリシーを書き忘れても承認待ちに倒れます。
更新にも落とし穴があります。エージェントを更新すると tools 配列が丸ごと置き換わるので、残したいエントリも全部送り直します。更新が届くのは新しいセッションだけです。デプロイメントはエージェントのバージョンを固定しているため、新しいバージョンを指し直します。このエージェントをサブエージェントとして列挙している別のエージェントも更新します。すでに動いているセッションは、そのセッションのツールを更新して締めます。個別の設定はツールの有効化・無効化にあります。
MCPサーバーも同じ考え方です。MCPツールセットは、サーバーが公開するツールを既定ですべて有効にします。default_config.enabled を false にして名前を挙げたツールだけ有効にすれば、サーバーが後から足したツールは無効のままです。使わないサーバーは外します。
信頼できない入力を読むエージェントに強いツールを持たせない
チケット、メール、Webページ、検索結果、リポジトリのファイル、アップロード、MCPの結果、中継したエンドユーザーの文章。社外の誰かが書ける文章は、すべて信頼できない入力です。そこに「強いツールを使え」と書かれていれば、エージェントは従う可能性があります。強いツールとは、bash、write、edit、web_fetch、web_search、データを書き込む・送るMCPツールやカスタムツール、認証情報を使うツールです。
読む入力と持っている力の組み合わせごとに、対処は次のとおりです。
| 読む入力 | 同時に持つ力 | 対処 |
|---|---|---|
| チケット・メール・アップロード | 同時に持つ力認証情報つきの bash | 対処1つのことだけするカスタムツールに置き換える。bash が必要なら always_ask |
| Webページ・検索結果 | 同時に持つ力ファイル書き込み・レコード変更 | 対処Web系ツールを切る。または自分が運用・信頼するサイトに限る |
| MCPの結果・リポジトリのファイル | 同時に持つ力書き込み系MCPツール | 対処MCPツールセットは always_ask、必要なツールだけ有効化 |
| マウントしたGitHubリポジトリ | 同時に持つ力あらゆるツール | 対処信頼できるリポジトリだけマウントする |
| 何であれ信頼できない入力 | 同時に持つ力メモリストアへの書き込み | 対処書く必要がなければ read_only でアタッチ |
メモリストアは、既定が read_write です。書かれた文章は後のセッションで信頼済みの記憶として読まれるため、一度の注入が長く残ります。
read にも注意が要ります。クラウド環境でファイルを read すると、CLAUDE.md と AGENTS.md が指示として読み込まれることがあります。@docs/setup.md のような参照は5段まで追われ、サンドボックス内のどこでも指せます。リポジトリの .claude/skills も、レビューなしでエージェントの指示になります。止める設定は read を無効にする以外にないため、社外の人が書けるリポジトリ、パッケージ、アーカイブは信頼できない入力として扱ってください。
読む作業と動く作業を両方させる必要があるときは、設計を3つから選びます。
- 読む役と動く役を分ける。1つのマルチエージェントセッションで、リードが取得役(
web_fetchとweb_searchだけ、それぞれallowed_domainsつき)と書き込み役(ファイルやレコードを変えるツール、Web系ツールなし)に仕事を渡す - 狭いカスタムツールを1つ持たせる。アプリ側が入力を検証し、認証情報も持つ
- 人を挟む。強いツールを
always_askにして、1件ずつ承認する
分割は、ツールと会話を分けるだけです。同じセッションのエージェントは、サンドボックス、ファイル、vaultの認証情報を共有します。もっと強く分けたいなら、環境とvaultを別にした2つのセッションを使い、アプリが注文IDのような決まったフィールドだけを受け渡します。
予算と止め方は、起動前に決めておく
予算はセッションの作成時に設定します。作成後に、予算のないセッションへ足すことはできません。上限を変える手順は、予算の記事に詳しく書いています。
| 手段 | 効果と注意 |
|---|---|
| セッション予算 | 効果と注意公開リスト価格での支出上限。到達するとセッションと各スレッドが一時停止する。処理中のリクエストは終わり、ツール呼び出しも走るため、上限を超えることがある |
| デプロイメント予算 | 効果と注意同じ上限を、デプロイメントが起動する各セッションに適用 |
user.interrupt イベント | 効果と注意モデルの応答を即座に止める。実行中のツール呼び出しは終わるまで走る。セッションは idle になり、次のメッセージで再開する |
| セッションのアーカイブ・削除 | 効果と注意アーカイブは履歴を残して新しいイベントを止める。削除は記録・イベント・サンドボックスを消す |
| デプロイメントの一時停止・アーカイブ | 効果と注意一時停止は新しい定期実行を止めるが、手動実行は可能。アーカイブは定期実行を完全に終える。実行中のセッションは動き続ける |
| vault・認証情報のアーカイブ・削除 | 効果と注意実行中のセッションからも秘密が消える。反映に遅れがあり、取得済みのトークンはサンドボックスに残る |
max_list_cost.amount は米セント単位の整数を文字列で書きます。"125" なら1.25ドルです。予算の設計はセッション予算の記事で扱っています。
止める手順は、次の順に決めておきます。
user.interruptを単独で送る- 定期実行のエージェントは、デプロイメントも一時停止する(恒久的に止めるならアーカイブ)
- キーが漏れた可能性があれば、発行元のサービスでローテーションする
- ワークフローの実行(run)が開いているなら、停止を頼む
user.messageも送る。割り込みはrunを終わらせないため - セッションが
idleになるのを待つ(実行中のセッションはアーカイブも削除もできない) - 履歴を残すならアーカイブ、不要なら削除する
割り込みは、エージェントがすでに行った操作を取り消しません。エージェントのアーカイブも、実行中のセッションを止めません。予算が制限するのは費用だけで、上限までの行動の範囲は制限しません。
運用に入ったあとの監視
セッションが idle になった、予算に達した、終了した、のいずれでも通知が届くよう、Webhookを設定します。session.status_idled は一時停止を含むあらゆる理由のアイドルで発火します。理由を知るには、types に session.status_idle、order に desc、limit に 1 を指定してイベントを引き、stop_reason.type が requires_action なら承認待ちです。配信は取りこぼされることがあるため、定期的にセッション一覧も確かめます。
イベントはセッションを削除するまで残ります。残したいイベントは自社のログに保存し、不要なセッションは削除します。Managed Agentsは現在、ゼロデータリテンション(ZDR)とHIPAAのBAAの対象外です。これらが要件の業務では、利用前に適合性を確かめてください。
点検表を通す順序
出し始めるなら、環境(limited)とツール(default_config.enabled: false)から固めます。この2つは、ほかの設定の前提になるからです。そこから必要なものだけ開けていけば、開けた理由を後から説明できます。承認と予算は、開けた後に被害の幅を決める設定です。