エージェントコアゲートウェイでAIエージェントのツールアクセスを段階的に統制

問題の構造

AWSは2026年8月21日、公式ブログでAmazon Bedrock AgentCoreの新機能「AgentCore Gateway」を使ったAIエージェントのツールアクセス統制ガイドを公開した。ガイドは、「どのAIエージェントが顧客データにアクセスできるのか」「誰が許可したのか」「クレデンシャルが漏えいしたらどんな影響があるのか」に1分以内で答えられない組織を読者に想定している。対象となるのは、コーディング支援や自律型、人間との対話型を問わず、MCP（モデルコンテキストプロトコル）を使うAIエージェント全般である。

記事はMCPを導入した企業システムに共通する五つの構造的な問題を挙げる。1つ目は、認証情報が各ローカルの設定ファイルに散らばる「クレデンシャルスプロール」である。2つ目は、設定がN×M通りに分岐して静かに乖離する「ポリシードリフト」だ。そのほか、誰がいつ何を呼び出したかが分からない監査の欠如、チーム単位で費用を把握できないコストの不透明さ、レビューを経ずに導入されるシャドーITも指摘されている。

具体例として、インフラエンジニアが同僚のノートPCでビルドを調査した際、mcp.jsonという設定ファイルに本番データベースのパスワードが平文で保存されていた場面を挙げる。ファイルには「これをローテーションする」と書かれたTODOコメントが残っているだけだという。セキュリティチームには、どのAIエージェントが内部ツールに到達しているか、誰がアクセスを許可したか、クレデンシャルが漏えいした場合の影響範囲が見えていない。

4段階のスコープ

解決策の中核は、エージェントからの通信を単一のゲートウェイに集約することだ。AgentCore Gatewayは、MCPを使うエージェントと社内ツールの間に立ち、認証、認可、ポリシー適用、ログ記録を一元的に担う。認証・認可とクレデンシャル管理はAgentCore Identityが、ツールとのやり取りに対するセキュリティ制御はAgentCore Policyが担当し、Amazon Bedrock Guardrailsで安全性とプライバシー保護を追加できる。

導入は四つのスコープに分かれ、各段階が単独でも価値を持つ設計だ。Scope 1（Connect）は1〜20人のパイロット利用者を想定し、SSO認証、クレデンシャルの一元管理、CloudTrail監査を導入する。Scope 2（Control）はユーザー基盤の拡大に合わせて、Cedar RBAC/ABACによるアクセス制御、PII（個人識別情報）の除去、3LO（ユーザー同意型のOAuth）による同意取得、DCR（動的クライアント登録）を追加する。

Scope 3（Catalog）は、チームがツールを自分たちで登録・公開・発見できるようにする段階で、オンプレミスのツールも対象に含む。Scope 4（Harden）はユーザー数が1,000人を超える段階を想定し、プライベート接続、ガバナンスダッシュボード、非推奨化のワークフロー、多リージョンでの障害時切り替えを整備する。各スコープは、次に直面する統制上の課題に応じて選択できる。

記事は、先回りして完全なゲートウェイを構築しようとする従来の進め方を「何カ月もかけて間違ったものを届ける」と評し、実際のニーズに合わせて制御レベルを選ぶことを推奨している。ガバナンスの課題が生じた段階で、次のスコープへ進むのが基本方針だ。

Scope 1・2の実装

Scope 1では、Amazon CognitoをIdP（アイデンティティプロバイダー）とするJWT（JSON Web Token）オーソライザーを備えたゲートウェイを作成し、読み取り専用のLambdaターゲットを1件登録する。クライアントはセッションごとにCognitoトークンを取得し、tools/listとtools/callの呼び出しにBearerトークンを付与する。ゲートウェイはJWTを検証してターゲットへルーティングし、バックエンドの認証情報はAWSの外に出ない。

導入計画は3つのフェーズに分かれている。初日にCognitoユーザープールの準備とゲートウェイのデプロイ、Lambdaターゲットの登録を行い、2〜3日目に更新したmcp.jsonをMDM（モバイルデバイス管理）経由で配布して、トークン取得からツール一覧、ツール呼び出しまでの経路を検証する。1週間以内に、各呼び出しのCloudWatch LogsとCloudTrailへの記録を確認する。

Scope 2では、認可の基準をマシン単位からユーザー単位へ引き上げる。クライアントがゲートウェイに接続すると、RFC 9728/8414/7591に基づくディスカバリが行われ、LambdaとAPI Gatewayで構成されたDCRシムが新しいアプリクライアントをCognitoに登録してallowedClientsへ追加する。ユーザーはSSOでサインインし、Authorization Code + PKCEフローを経て、アクセストークンのsubクレームに実際のユーザーIDが入る仕組みだ。

リクエストはAgentCore Policyが受け取り、CedarルールでIdPのグループクレームやトークンクレーム、パラメータ値を条件にRBAC/ABACを適用する。許可されたリクエストにはAmazon Bedrock GuardrailsがPIIフィルターやプロンプト攻撃の検知をゲートウェイ層で適用する。構造的な変換が必要な場合はリクエストインターセプターLambdaが補完し、GitHubやFigmaのような外部SaaSへはAgentCore Identityのクレデンシャルプロバイダーが3LOフローでユーザーの同意をブラウザ経由で取得する。

自己ホスト型との比較

記事は、自己ホスト型の選択肢としてKong Gateway、Open Policy Agent（OPA）、NeMo Guardrails、LangFuseも併記している。マネージド型のAgentCore Gatewayが認証・ポリシー・ガードレールを一式で提供するのに対し、自己ホスト型は各機能を個別に組み合わせて自前で運用する構成になる。どこまでをAWSに任せ、どこを自前で持つかは、既存の技術基盤やコスト方針によって判断が分かれるところだ。

このブログ記事は導入ガイドであり、AgentCore Gatewayの料金や利用可能なAWSリージョン、サービス上限などの情報は含まれていない。また、掲載されているCLIコマンドの例は、実際の環境や要件に合わせて調整する必要がある。採用を判断するには、AWSの公式ドキュメントで最新の仕様や制約を確認するのがよい。