【AWS Dogwood入門】認可はどこに置かれているか

Transcript

1. 2026年8月 認可はどこに置かれているか AWS Dogwood 入門⑤（全7回）── AgentCore Gateway と、単発認可の限界 赤神 青空
2. ▪言語の話から、置き場所の話へ 前回までのおさらい ここまでは言語そのものの話でした。今回は場所の話です。 Dogwoodが効くのは Gateway と Policy Engine の境界 そのGatewayが何をするものかを、先に押さえる AgentCoreを全部知る必要はありません 今ココ おさらい 2/13
3. ▪正式にはAgentCore とは何か Amazon Bedrock AgentCore エージェントを試作から本番まで運ぶための、AWSの基盤サービスです。 必要な部品だけ選んで使えます 01 02 03 04 Strands / LangGraph / CrewAI など Bedrock 上でも、それ以外 でもよい 使った分だけ。基盤の面倒 を見なくてよい 全部入りで採用する必要は ない フレームワーク不問 今ココ 前提知識 モデルも選ばない サーバーレス 部品の集合 3/13
4. ▪Dogwood5つの部品でできている の話に出てくるのは Gateway だけ エージェント本体 Strands / LangGraph / CrewAI / LlamaIndex ── フレームワークもモデルも問わない Runtime エージェントを動かす場所 セッションごとに 隔離されたmicroVM Gateway ツールの⼊り⼝ 既存のAPIやLambdaを MCPサーバーに変える AgentCore Policy Gateway に付ける認可の層 Memory 短期‧⻑期の記憶 ユーザー単位で 持ち回す Identity エージェントの⾝元 Cognito / Okta / Entra ID とつなぐ Observability 推論‧ツール呼び出しの トレース CloudWatch へ 組み込みツール Code Interpreter（コード実⾏）∕ Browser（ブラウザ操作） 必要なものだけ選んで使える。全部⼊りで採⽤する必要はない Policy は Gateway に付ける。ほかの4つとは独立している 今ココ 前提知識 4/13
5. ▪既存のAPIを、MCPツールとして見せてくれる Gateway が何をするか 既存のAPIやLambdaを、フルマネージドのMCPサーバーに変えてくれます。 何をつなげるか Lambda 関数、OpenAPI のREST API、Smithy モデル 既存の MCP サーバーもそのまま登録できる エージェントから見た姿 全部が MCP ツールとして、1つの窓口に見える MCPサーバーを自分で立てて運用しなくてよい ツールが増えても、エージェント側の接続先は増えない 今ココ 前提知識 5/13
6. ▪Inbound入口と出口の両方に認証 / Outbound という言い方をする Gateway エージェント MCPクライアントとして 1つの窓⼝だけを⾒る Lambda 関数 Inbound Auth フルマネージドの MCPサーバー Outbound Auth REST API（OpenAPI） OAuth / JWT を検証 Cognito‧Okta‧Auth Policy Engine IAM / APIキー / OAuth ターゲットごとに設定 Smithy モデル Cedar / Dogwood ツールの意味検索もここ サーバーの管理は不要 既存の MCP サーバー エージェントから⾒ると、右側の何もかもが「MCPツール」に⾒える この付け替えのために、全ツール呼び出しが必ず1点を通る。だから認可の置き場所として都合がいい 呼ぶ側の認証と、呼ばれる側への認証を、別々に設定する 今ココ 前提知識 6/13
7. ▪場所の選び方に理由がある なぜここに認可を置くのか ツール呼び出しが必ず1点を通るから、そこで見れば漏れがない。 通るものが多い MCPツール・A2A呼び出し・モデル 推論 場所が外側 エージェントのコードの外なので回 避されない 結果として 挙動を時系列で考える場所が1つに 決まる プロンプトで言い聞かせるのとは、担保の質が違います。 今ココ 前提知識 7/13
8. ▪この機能自体、まだ新しい Policy の来歴 以前 25/12 26/3 26/8 Interceptors で自作 re:Invent で予告 一般提供を開始 temporal policies 今ココ 前提知識 Lambdaを書いて認可を作り込む Cedar による宣言的な認可へ 東京を含む13リージョン ここで Dogwood が登場する 8/13
9. ▪Cedar を直接書かなくてもよい 書き方は2通りある 自然言語で書いた条件を、Cedar に翻訳させる経路も用意されています。 自然言語から生成する流れ LLM が日本語や英語の指示を Cedar に翻訳する MCPのツール説明から Cedar スキーマを自動生成する 生成物を検証にかけて、通ったものだけ採用する 運用の入り方 まず LOG_ONLY で流して、拒否されるはずのものを観測する 確かめてから ENFORCE に切り替える 今ココ 前提知識 9/13
10. ▪この3つが、そのまま強みであり制約でもある Cedarという言語の性質 Cedar は point-in-time、つまり1回ずつの認可のための言語です。 各リクエストを単独で評価する 同じ入力なら常に同じ結果を返す 評価順にも過去の状態にも依存しない 監査と執行はこの性質に依存している 自動推論で「何を許すか」を実行前に証明できる 状態を持たないので評価コストが読める 今ココ 単発の限界 10/13
11. ▪書けないのは設計不足ではなく、意図した割り切り 得意なことと、書けないこと ◯ 1回の呼び出しで決まること 誰がどのツールを呼べるか どの引数なら許すか 返金額の上限はいくらか リソースの所有者かどうか ✕ 呼び出しの並び 承認を取ってから実行したか 直近1時間で何回やったか 累計いくら動かしたか 機密を読んだ後に外部へ出ていないか 1回の呼び出しなら止められるが、呼び出しの並びは止められない。 今ココ 単発の限界 11/13
12. ▪エージェントは実行時に順番を自分で決めてしまう 問題は並びにある 1回ずつは正しい。列として並べたときにだけ、誤りになる。 従来のアプリ 順序も鮮度も業務ロジックが握って いた エージェント どのツールをどの順で呼ぶか実行時 に決める だから 順序そのものを統治対象にしたくな る ここが Dogwood の出発点になっています。 今ココ 単発の限界 12/13
13. ▪この回の持ち帰り まとめ 01 GatewayがMCPツールに見せる API・Lambda・既存MCPが、1つの窓口にまとまります。 02 だから認可の置き場所になる 全ツール呼び出しが必ず1点を通るので、そこで見れば漏れません。 03 ただし単発では足りない 承認・順序・累計は、1回の呼び出しを見ても判定できません。 今ココ おわりに 13/13