AWS上で、またはAWSに対して動くエージェントは、長期の認証情報を一切持つべきではない。 IAMユーザーも、シークレットマネージャーに置いたアクセスキーも、共有の「agents」サービスアカウントも駄目だ。AWSが提供する本格的な認証経路、インスタンスプロファイル、IRSA、EKS Pod Identity、OIDCフェデレーション、IAM Roles Anywhere、AgentCore Identityは、どれも同じことをするために存在する: 検証可能なアイデンティティの証明を、自動的に失効する一時認証情報と交換することだ。エージェントプラットフォームをこのルールから始めれば、難問の大半はひとりでに解ける。

昨日、姉妹サイトでこの問題のプロトコル層について書いた: SEP-1046がMCPエージェントに本物のクライアントクレデンシャルの仕組みを与えるという話で、署名付きJWTアサーションが共有シークレットを置き換える。本稿はその一段下の層だ。エージェントの対象がAWSそのものである場合、あるいはエージェントがAWS上で動いて他のすべてに到達する必要がある場合、そのアイデンティティは実際どういう形になるのか。答えはほぼすべてのケースで、SEP-1046が選んだのと同じ形をしている: 短命の署名付きトークンを入れると、短命の認証情報が出てくる。AWSはこのパターンを何年も大規模に運用してきた。静的キーでそれに逆らうのをやめればいいだけだ。

すべての土台にある一つのパターン: OIDCフェデレーション

製品名を剥がせば、AWSのエージェント認証は一つのメカニズムだ。アイデンティティプロバイダーがワークロードについてのJWTに署名する。そのプロバイダーのissuer URLをIAMにOIDCアイデンティティプロバイダーとして登録すると、IAMは/.well-known/openid-configurationのディスカバリードキュメント経由でプロバイダーのjwks_uriから公開鍵を取得する。ワークロードはトークンをsts:AssumeRoleWithWebIdentityに提示し、1時間以内に失効するロール認証情報を得る。ロールの信頼ポリシーは、トークンのaudとsubクレームへの条件で、誰を入れるかを固定する。

プラットフォームチームなら誰もが知っている実例がGitHub Actionsだ: ランナーはsubクレームにリポジトリとブランチをエンコードしたOIDCトークンを受け取り、ロールの信頼ポリシーはrepo:my-org/my-repo:ref:refs/heads/mainにマッチし、リポジトリシークレットにアクセスキーは一切置かれない。これはCIの小技ではない。エージェントを含む、あらゆる無人ワークロードの雛形だ。署名付きでaudienceに束縛され、数分で失効するアサーションが保存済みシークレットを置き換える。これはまさにMCP層でprivate_key_jwtがやっていることで、業界が二つの方向から同じ答えに収束したときは、たいていその答えが正しいというサインだ。

エージェントがどこで動くかがメカニズムを決める

フェデレーションを自前で組むことはめったにない。ランタイムに合ったパッケージングを選ぶ:

  • EC2またはECS上: インスタンスプロファイルまたはタスクロール。SDKのクレデンシャルチェーンが自動的に拾うので、エージェント側で設定するものはない。ここでエージェントフレームワークがアクセスキーを要求するなら、それはフレームワークの悪臭であって、AWSの要件ではない。
  • EKS上: 選択肢は二つ。IRSA (IAM Roles for Service Accounts)が古い方だ: クラスターがOIDC issuerを公開し、それをIAMに登録して、ServiceAccountにロールARNをアノテーションする。EKS Pod Identityが新しい方だ: クラスターごとのOIDCプロバイダー登録は不要で、ノード上のエージェントアドオンが認証情報を交換し、ロールの信頼ポリシーはクラスターごとのissuer URLではなくpods.eks.amazonaws.comを一度だけ指定する。クラスターを多数運用しているならPod Identityは実際の手間を減らす。単一クラスターならどちらでもいい。どちらも行き着く先は同じだ: エージェントワークロードごとに一つのIAMロール、Podにキーなし。
  • AWS外でIdPあり: 上記のとおりの素のOIDCフェデレーション。データセンターのワークロードも、別のクラウドも、SaaSのランナーも、自前のアイデンティティプロバイダーに認証してフェデレーションで入ってくる。GitHub Actionsパターンの一般化だ。
  • AWS外でIdPなし: IAM Roles Anywhere。信頼アンカーとして登録したCA (AWS Private CAまたは自前のPKI)が発行したX.509証明書をワークロードが提示し、プロファイル経由で一時的なロール認証情報と交換する。正直な注意点: 証明書のライフサイクル管理、発行、ローテーション、失効を抱え込むことになる。すでにPKIを運用していないなら、アイデンティティプロバイダーを立てる方が運用負荷はたいてい軽い。

AgentCore Identity: その上に載るエージェント向けの層

IAMが答えるのは「このワークロードはどうやってAWSを呼ぶか」だ。エージェントにはあと二つ問題がある: 誰がエージェント自体を呼べるのか、そしてエージェントがユーザーの代理でAWS外のサービス、Slack、GitHub、Googleにどう到達するのか。Amazon Bedrock AgentCore Identityがカバーするのはこの部分で、AgentCoreを使わない場合でも理解する価値がある。ロールの先にエージェントのアイデンティティへ何が必要かを、AWS自身が書き下したものだからだ。

  • エージェントのワークロードアイデンティティ。 各エージェントは共有プリンシパルではなく、自分専用のディレクトリエントリを持つ。IAMロールと同じ、ワークロードごとに一つのアイデンティティというルールを一段上に適用したものだ。
  • インバウンド認証。 呼び出し側は素のSigV4 (通常どおりのIAM)か、JWTオーソライザー経由でエージェントに到達する: ディスカバリーURLと許可するaudienceを設定すると、Cognito、Okta、Entra IDのトークンがエージェントの入口を守る。AgentCore Gatewayはツールエンドポイント向けにも同じCUSTOM_JWTオーソライザーを公開しており、前回の記事で発行の話をしたトークンを、AWS上のMCP的なゲートウェイはこうやって検証する。
  • アウトバウンド認証。 トークンボールトがサードパーティサービス向けのOAuthグラントを保持する。サービス間は2-legged、ユーザーが一度同意し、その同意に基づいてエージェントが後から代理で動く場合は3-leggedだ。これは代理実行パターンで、同意が環境変数に貼り付けたリフレッシュトークンではなく、サーバー側に保存される。
  • 料金の補足。 AgentCore RuntimeまたはGateway経由なら追加費用はゼロ。単体利用では、成功したOAuthトークンまたはAPIキーのリクエストごとに課金される。どちらにせよ安い。高くつくのはいつだって、これで回避できるインシデントの方だ。

この上のプロトコル層も動き続けている。MCP仕様リポジトリのauthキューには、ゲートウェイが1年以内に出会うことになる提案が並んでいる。混在認証サーバー向けのツールメタデータのsecuritySchemes(SEP-1488)、セッション途中でOAuthフローを起動する標準化されたツールエラー(SEP-1489)、リモートサーバーの認証方式の事前宣言(SEP-2742)。AWSでMCPゲートウェイを運用しているなら、EKSのリリースノートを見るのと同じ目でこのラベルを見ておくべきだ。

監査で実際に問われるのはアトリビューション

一時認証情報は盗難の問題を解決するが、それだけでは「どのエージェントがやったのか」は解決しない。三つの習慣がその穴を塞ぐ。エージェントごとに一つのロール。これでCloudTrailのロールセッションが最初からワークロードを名指しする。ロール引き受け時のsts:SourceIdentityの設定。これでエージェントを起動した人間またはシステムが、ロールチェーンをまたいでも下流のすべてのログ行に残る。そしてセッションポリシーで広いロールを目の前のタスクに絞り込む。これでプロンプトインジェクションを受けた、あるいは単に間違えたエージェントの爆発半径は、ロールの権限ではなくタスクの権限になる。常設の権限は読み取り専用に保ち、すべての変更操作にゲートを置くこと。この主張は何度も書いてきたので、常連の読者なら暗唱できるはずだ。

月曜にやること

  • aws iam list-usersを実行し、自動化に属する有効なアクセスキー付きのIAMユーザーをすべて指摘事項として扱う。エージェントは自動化だ。
  • 各エージェントをそのランタイムに対応付け、合うメカニズムを採用する: インスタンス/タスクロール、IRSAまたはPod Identity、OIDCフェデレーション、Roles Anywhere。この優先順で。
  • すべてのOIDC信頼ポリシーをaudと、書ける限り最も狭いsubパターンで固定する。sub条件のない信頼ポリシーは、立派な看板の付いた開けっ放しのドアだ。
  • すべてのエージェントのassume-role呼び出しでsts:SourceIdentityを設定し、CloudTrailのクエリでそれを使う。インシデントの後からアトリビューションを後付けしても機能しない。
  • AgentCoreを使っているなら、エージェントの前段にJWTオーソライザーを置き、サードパーティのOAuthグラントをトークンボールトへ移す。使っていないなら、この形を写す: エージェントごとのアイデンティティ、検証済みのインバウンドトークン、サーバー側での同意の保存。

MCPの記事との共通線は見逃しようがない。プロトコルごとに、プラットフォームごとに、エージェントのアイデンティティは署名付き短命アサーション、audienceバインディング、ワークロードごとのプリンシパルへと収束しつつあり、その部品はいまや両方の層に揃っている。いまだにアクセスキーをエージェントの設定にコピーしているチームは、何かのアーリーアダプターではない。2026年のワークロードを2015年のセキュリティ態勢で動かしているだけだ。

次に読む

Agent Toolkit for AWS: The Docs Have a New Readerは、認証を済ませたエージェントがAWSアクセスで実際に何をするかを扱う。姉妹サイトのEnterprise MCP Auth: Agents Finally Get Service Accountsは本稿のプロトコル層側の半分で、ercanermis.comには私が書くその他すべての地図がある。

参考資料