こんにちは、セキュリティエンジニアの田所です。
先日参加してきた AWS Summit Japan 2026 からセッションの模様をお届けします。

セッションについて

SEC353 エージェンティック AI アプリのセキュリティ・UX・開発速度を同時に実現 ─ Amazon Bedrock AgentCore Identity が解決する3つの課題

エージェンティック AI アプリが外部の CRM やメール、SaaS にユーザーの代わりにアクセスする ── この構成を本番で安全に運用するには、「エージェントへの過剰な権限付与」「連携先ごとに繰り返される認可プロンプト」「認証連携の自前実装」という3つの課題が障壁になります。 本セッションでは、Amazon Bedrock AgentCore Identity を使い、最小権限でのアクセス制御、ユーザー体験を損なわない同意管理、マネージドな認証連携による開発工数の削減をどのように実現するかを、アーキテクチャ図を交えて解説します。エージェンティック AI アプリの本番運用を検討されている方におすすめのセッションです。

エージェンティック AI を本番導入するうえでの ID とアクセス管理の課題と、その解決策となる Amazon Bedrock AgentCore Identity を扱うブレイクアウトセッションでした。

1. エージェンティック AI のアイデンティティの課題

エンタープライズではエージェントへの投資が倍増しており、業務への組み込みも増えています。
2028 年までにエンタープライズソフトウェアの 33% がエージェンティック AI を搭載し、日常業務の意思決定の 15% が自律的に行われるようになるという予測も紹介されました。
生産性の向上、コンテキストに基づく意思決定、市場投入までの時間短縮が期待されています。

一方で、組織全体で活用できているかというと、そこにはセキュアなアクセス、制御された自律性、進化するガバナンスという 3 つの実現が求められます。
エージェントの一般的なアクセスパターンは、ユーザーの代理でタスクを実行するものと、事前の認可を受けたエージェントがイベントに対してタスクを実行するものの 2 つです。
いずれにしても、CRM や財務システム、メールなど、何らかのデータにアクセスする必要があります。

このとき、呼び出し元の検証、同意の管理、限られたシステムアクセスへの制限といった要素を盛り込んだカスタムコードの開発が必要になります。

整理すると、課題は セキュリティ・UX・開発速度 の 3 つに集約されます。

  • セキュリティ：エージェントに過剰な権限を与えず、安全に権限を委任できるか
  • UX：連携先ごとに繰り返される認可の承認依頼、いわゆる同意疲れをどう抑えるか
  • 開発速度：認証・認可の連携を連携先ごとに自前で実装すると、開発工数がかさんでしまうがどう対処するか

これらを同時に成り立たせることが難しいのは、自身の運用やセキュリティの経験からしても納得感があります。

2. Inbound Auth と AgentCore Identity

Amazon Bedrock AgentCore は、AI エージェントを安全に大規模にデプロイ・運用するための基盤サービス群です。

その中の AgentCore Identity は、マネージドなエージェントの ID とアクセス管理を担います。
AgentCore Identity では以下の 3 つを実現することができます。

  • 安全な委任アクセス：エージェント固有の ID を付与して大規模に安全な運用を実現する
  • 最適化された体験：トークンボールトで同意疲れを最小化する
  • 開発の加速：Okta や Microsoft Entra ID、Amazon Cognito など既存の ID システムとシームレスに統合する

エージェンティック AI の認証認可は、ユーザーがアプリケーションからエージェントにアクセスする Inbound Auth と、エージェントがリソースにアクセスする Outbound Auth の 2 方向に分かれ、AgentCore Identity はその両方をサポートします。

Inbound Auth では、既存 IdP が発行したトークンを AgentCore Identity が検証し、ワークロードアクセストークン (WAT) を返却します。
このユーザーは誰か、このユーザーはこのエージェントを呼び出す権限があるか、を確認する流れです。

ワークロードアクセストークン (WAT) とは、IdP トークン（アクセストークン）と Agent Identity を組み合わせてできたトークンです。
誰が、どのエージェント経由でアクセスしているかを厳密に管理でき、設計上、他のユーザーと混ざらない仕組みになっています。
こうしたセキュアバイデザインの仕組みにそのまま乗っかれるのは、運用する側としては助かりそうです。

なお、エージェントへのアクセス制御の方式は、IAM SigV4 と JWT の 2 つです。
呼び出し元が EC2 / ECS / EKS などで稼働していて IAM でアクセス制御が完結する場合は IAM が、リアルタイム性がある場合は JWT がおすすめとのことでした。

3. Outbound Auth と AgentCore Identity

Outbound Auth は、エージェントがユーザーに代わって保護されたリソースにアクセスできるかを扱います。
その鍵になるのがトークンボールトで、ユーザーの OAuth トークンを安全に保管します。
エージェントは WAT を提示してボールトからトークンを取り出すため、初回の同意以降は再認可を求めずに済み、同意疲れを抑えられます。

Outbound Auth がサポートするアクセスパターンは、AWS リソースへのアクセス、AWS リソース以外へのユーザー代理アクセス、AWS リソース以外へのマシンアクセスの 3 つです。
それぞれ IAM、3LO / On-Behalf-Of、2LO / API Key といった方式に対応し、ユーザーからマシン、マシンからマシンのどちらの Outbound Auth もカバーします。

開発者体験の面では、AgentCore Runtime に Identity が組み込まれており、実行時に WAT が自動で受け渡されるため、トークン管理を自前で作り込まずに済みます。
Identity API のコールは AWS CloudTrail にイベントとして記録でき、AgentCore Observability との統合により、インバウンドの認証リクエストやアウトバウンドのトークン・API キー取得の成功率をトレース・モニタリングできます。

まとめ

エージェンティック AI の セキュリティ・UX・開発速度 という 3 つの課題と、それを Inbound / Outbound の両面から解く Amazon Bedrock AgentCore Identity を見てきました。

エージェントが外部システムにユーザーの代わりにアクセスする構成では、最小権限・同意管理・認証連携をどう成立させるかが本番運用の分かれ目になります。
これらを自前で作り込まずに AgentCore Identity を活用することで、セキュアバイデザインのマネージドな仕組みにそのまま乗せられるのは、開発・運用の両面で大きな助けになりそうだと感じました。

おしまい