AIエージェントがMCPからクラウドインフラを管理するには、計画と実行を分離し、認証情報を限定し、重大なアクションに承認を求め、書き込みを安全に照合し、すべての効果を追跡し、復旧をテストする必要があります。ツールを検出できるだけでは、これらの制御は一つも得られません。
最初に公開する最も安全な機能は、読み取り専用のinventoryです。使い捨て環境に対するplanとポリシーの経路が機能してから、変更操作を追加します。
planとapplyを分ける
planには、正確なテナント、環境、リソース、依存関係、権限変更、コスト、不可逆な効果を含めます。planのapplyには、plan digestに紐づく別のツールまたはapproval tokenを必要とします。
モデルがpayloadを作成した後、一つの汎用ツールへdryRun: falseを渡せるようにしてはいけません。applyを独立した機能にすると、クライアントとポリシーレイヤーから遷移が見えます。
infrastructure as codeのツールでは、すでにこのレビューパターンが使われています。MCPでもこれを維持し、計画と実行を一つのモデルturnへ圧縮しないでください。
各レイヤーでIDを制限する
MCPサーバーはクライアントと代理対象のユーザーを認証します。ポリシーは、表示または呼び出し可能なインフラツールを制限します。プロバイダー認証情報は、対象アカウント、プロジェクト、環境、アクションに限定します。最後にプロバイダーが最終リソースを認可します。
CloudflareのMCP認可アーキテクチャでは、IDと認可をエージェントセッション状態から分けています。MCP認証ガイドは、tokenのaudienceとpassthroughに関する現在のプロトコル要件を適用します。
開発ツールをorganization ownerのtokenで動かしてはいけません。プロバイダーで必要なscopeを表現できない場合、前段に狭いコントロールプレーンを置きます。
すべての書き込みを操作として扱う
承認済みの変更に、一つの操作IDと冪等性キーを割り当てます。plan digest、呼び出し元、対象リソース、試行、プロバイダーrequest ID、状態、結果を保存します。再試行では同じ操作を参照する必要があります。
タイムアウト後は、呼び出しを繰り返す前にプロバイダーと操作の状態を調べます。プロバイダーが処理を完了した後、クライアントだけがレスポンスを失う結果不明状態は珍しくありません。
エージェントの復旧ガイドでは、インフラ以外のチェックポイントと結果照合も扱っています。
効果が発生する前に承認を求める
承認では次を示します。
- 正確な環境とアカウント
- 作成、変更、削除する各リソース
- 新しい権限とネットワーク公開範囲
- 予想コストと請求への影響
- データ損失または停止時間のリスク
- アクションを元に戻せるか
- 承認が失効する時刻
OAuthへの同意を、将来の本番削除への承認として扱ってはいけません。同意が許可するのは、ある種類のアクセスです。影響の大きいアクションには、現在のポリシー判断が必要です。
復元可能な操作を優先する
プロバイダーが対応している場合は、soft delete、snapshot、段階的なtraffic移行、以前の設定の保持を使います。Railwayの2026年4月のインシデント報告では、エージェントが広範なtokenを見つけ、古い即時削除経路を呼び出した事例を説明しています。Railwayはvolumeを復旧し、APIの削除を48時間のsoft deleteへ変更しました。
この事例では、認証情報のscopeと削除のセマンティクスの両方が効果を制限できませんでした。監査ログだけでは、後から削除の経緯を説明できるにすぎません。
インフラの出力を制限する
プロバイダーの完全なpayloadではなく、安定した公開用の結果を返します。
{
"operationId": "op_1842",
"state": "pending",
"resources": ["database:db_73"],
"statusUrl": "/operations/op_1842",
"retryAfterSeconds": 15
}
次の認可済み手順で本当に必要な場合を除き、プロバイダー認証情報、アカウント全体の識別子、内部ネットワークの詳細、debug headerを削除します。
制御経路を追跡してアラートを出す
ユーザー、エージェント、セッション、plan digest、承認、ツール呼び出し、操作ID、対象、プロバイダーrequest、ポリシー判断、状態遷移、最終効果を記録します。次の場合にアラートを出します。
- 開発IDから本番環境を対象にした場合
- 新しい広範な権限
- 削除または作成の反復試行
- 承認の迂回または失効
- 高コストのリソースクラス
- 結果不明状態のまま止まった操作
本番エージェントのチェックリストでは、これらのフィールドをリリースゲートに変換します。
制御された失敗をテストする
使い捨てプロジェクトで、プロバイダーが受理した可能性がある時点にapply呼び出しを中断します。ワークフローを再開し、最初の操作を照合することを確認します。次にエージェントの認証情報を実行途中で取り消し、その後のアクションが停止することを確認します。
開発環境向けに作成したplanを本番環境へapplyできないこと、計画したリソースを一つでも変更すると承認が無効になることもテストします。
plan専用ツールから始める
applyを無効にしたまま、inventoryとplanningを公開します。実際のタスクについてエージェントにplanを生成させ、運用者にまだ必要な情報を確認します。承認、再試行、トレース、復旧のテストに合格してから、範囲の狭いapplyツールを一つ追加してください。
以下のプロンプトは、このプロジェクトで最も影響の大きいツールに対してplan専用レビューを実行します。