連載前編は利用者、エージェント、接続先をトークンで結びます。短命の資格情報をAgentCore Identityで扱い、各ツールで権限を確認します。 共有アカウントから代理実行へ移る設計です。権限を外した直後も既存トークンが残る時間を含め、停止の仕組みを評価することが焦点です。 誰のために動くかを認証基盤へ伝える AWSは11月6日、Okta Cross App AccessとAgentCoreで代理実行を構成する連載の前編を公開しました。顧客情報を読んだりチケットを更新したりする際、どのエージェントが誰のために動くかを管理する内容です。利用者ごとの同意や共有サービスアカウントだけでは、組織が停止と監督を行いにくいという背景があります。Oktaが代理実行を許すかを判定し、AgentCore側がその判断を実行へつなぎます。小さな構成で仕組みを確認し、後編でGatewayによる集中管理へ広げます。概念と設定を説明するサンプルであり、完成済みの本番構成ではありません。 利用者とエージェントを短命のトークンで結ぶ 利用者はエージェントに結び付いた画面からサインインします。Oktaはエージェントの有効性、利用者の割り当て、対象アプリへの接続と利用範囲を確認します。その判断を示すID-JAGをAgentCore runtimeへ渡し、AgentCore Identityで接続先の短命なトークンへ交換します。道具は利用者の所属と範囲を確認して処理を許します。秘密情報はIdentity側で扱い、エージェントのコードへ直接見せない構成です。対象は業務エージェントを既存の社内認証へ組み込む担当者と見られます。利用者のID、代理実行の判断、接続先が受け取る資格情報は、それぞれ違う役割です。単にログインできたことを、すべての操作を許してよい理由にしない点が中心になります。 無効化した後の残存時間を確認する 原文の試験では、管理者が利用者の割り当てを外した後、新しい要求は約1秒で拒否されました。一方で発行済みのトークンは最長5分で失効するとしています。前者を即時にすべての操作が止まる保証として読むことはできません。導入では、利用範囲を最小限にし、既存の資格情報が有効な時間も含めて停止を設計することが論点です。発行者や対象が違うトークンを受け入れないか、各ツールで拒否を試す必要があると見られます。説明の断片コードは非本番用で、追加設定と組織の要件確認が残ります。認証の交換にかかる時間や、関連するサービスの利用料も評価対象です。権限変更がどこまで伝わったかを記録で追えるようにし、エージェントの利用拡大前に確認することが考えられます。 利用者の変更を継続して反映する 部署の異動や担当の変更では、利用者とエージェントと接続先の関係が変わります。次の判断点は、一度の設定確認だけでなく、その変更を試験と記録へ反映できるかです。新しい要求の拒否と、発行済みの資格情報の失効を別々に確かめる方法が考えられます。代理実行の追跡では、人の身元だけでなく使ったエージェントも残す必要があると見られます。便利な共有アカウントへ戻さず、変更を運営できる仕組みを保つことが焦点です。停止後の記録も確認対象です。