AIエージェントのOAuth同意を安全に設計する　AWSの新機能から学ぶ代理アクセスの守り方

この記事では、AIエージェントがGitHub、Slack、Google Workspaceなどへ「利用者の代理」で接続するとき、何を同意画面に表示し、誰の権限としてトークンを保存し、どこまで操作を許し、問題発生時にどう止めるべきかが分かります。

結論から言えば、OAuthの同意画面を追加するだけでは安全になりません。安全な代理アクセスには、少なくとも次の六つが必要です。

利用者本人を確かめる認証
必要なサービスと権限だけを選ばせる明示的な同意
同意した本人と発行された資格情報を取り違えないセッション結び付け
トークンをAIの会話、ブラウザ、ログへ露出させない保管
エージェントが実行できる操作をさらに絞る実行時制御
誰がいつ接続し、何を実行し、いつ切断したかを追える監査と失効

OAuthは「このアプリへ、この範囲のアクセスを委任した」という技術的な認可です。「AIが行うすべての操作をユーザーが承認した」という意味ではありません。また、個人情報保護法制などで求められる法的な同意と常に同じものでもありません。この二つを混同しないことが、本記事で最も重要な判断基準です。

なぜ今、AIエージェントのOAuth同意を見直すのか

Amazon Web Servicesは2026年9月14日、Amazon Bedrock AgentCore Identityに、エンドユーザー向けのConsent portalを追加したと発表しました。AWSの発表によると、利用者は組織のIDプロバイダーでサインインし、エージェントから利用可能な外部サービスを確認したうえで、GitHubやSlackなどを個別に接続できます。認可後のトークンはAgentCore Identityのトークン保管庫に保存され、同意したユーザーと結び付けられます。

従来もAIアプリからOAuthを利用できましたが、認可URLの提示、公開HTTPSコールバック、戻ってきた利用者の再確認、ブラウザセッションの管理、認可結果とユーザーの結び付けを、アプリ側で実装する必要がありました。新しいポータルは、このうち同意画面とセッション結び付けをマネージド機能として提供します。

この発表が示す変化は、単にAWSの設定画面が一つ増えたことではありません。AIエージェントがIDEやMCPクライアントから外部サービスを継続利用し、利用者の代わりに情報を検索したり、Issueを作成したり、メッセージを投稿したりする運用が現実になったことです。一回のチャットへ文章を貼り付ける使い方と異なり、保存された認可は会話終了後も有効な場合があります。したがって、導入時の確認単位も「AIへ何を入力したか」から「誰の権限で、どのサービスへ、いつまで接続できるか」へ広げる必要があります。

なお、以下のうち、Consent portalの仕様や記録されるイベント名はAWSの一次情報で確認した事実です。一方、操作の段階分け、承認基準、テスト項目は、一次情報を基にAI活用ナビが整理した実務上の提案です。

認証、認可、同意、実行承認は別物

代理アクセスの事故は、似た言葉を一つの仕組みで済ませようとしたときに起こります。まず四つの役割を分けます。

仕組み	答える問い	代表例	それだけでは防げないこと
認証	操作を始めた人は誰か	組織アカウント、OIDC、多要素認証	その人が外部サービスへの接続を許したか
OAuth認可	どのサービスの何の権限を委任するか	リポジトリ閲覧、Issue作成、メッセージ投稿	個々の投稿内容や変更内容が妥当か
セッション結び付け	認可を始めた人と完了した人は同一か	ユーザーセッションと認可結果の関連付け	エージェントが後で危険な判断をしないか
実行承認	今回の具体的な操作を実行してよいか	投稿前確認、削除前承認、差分レビュー	保存済みトークンの漏えいや過剰な有効期間

たとえば「Slackへの投稿を許可」というOAuthスコープを承認しても、利用者が将来作られるすべてのメッセージを確認したわけではありません。エージェントが外部文書中の命令を誤って実行したり、宛先を取り違えたりする可能性は残ります。投稿、送信、削除、権限変更のように結果が外部へ確定する操作には、OAuthとは別の実行時承認を置くべきです。

AWSのAgentCore Identity用語集では、ユーザーの同意を伴うAuthorization Code Grantを3-legged OAuthと説明しています。また、エージェントアクセストークンにはワークロードの識別情報とユーザーの識別情報の両方を含められ、トークン保管庫では、資格情報を取得したエージェントとユーザーの組み合わせにアクセスを限定するとしています。この「AIアプリ自身」と「代理される利用者」を分ける考え方が重要です。

安全運用を支える六つの境界

1. 人の本人確認

同意ページを開いた人が、組織で許可された利用者であることを確認します。共有アカウントや、退職後も残る個人アカウントを入口にすると、誰が同意したか追跡できません。組織のIdPを使い、多要素認証、アカウント停止、所属グループの管理と連動させます。

認証は入口だけで終わらせません。部署異動、休職、退職、委託終了が発生したとき、保存済みの外部サービス認可も無効になるか確認します。組織アカウントを停止しても、外部サービス側のリフレッシュトークンが自動的に失効するとは限らないためです。

2. 同意の理解可能性

同意画面には、技術的なスコープ名だけでなく、利用者が理解できる操作を表示します。「repo」だけではなく、「非公開リポジトリの一覧と内容を読み取れる」「Issueを作成できる」など、対象、操作、影響を分けます。

最低限、次の情報が必要です。

接続するAIエージェントの名称と管理部署
接続先サービス
読み取り、作成、変更、送信、削除の区分
対象となる組織、ワークスペース、リポジトリ
認可の有効期間または再確認時期
切断方法と問い合わせ先
自動実行される操作と、人の確認が必要な操作

名称が「gateway-01」のような内部識別子だけでは、利用者は何へ権限を渡すのか判断できません。AWSの発表でも、Gateway名はエンドユーザーに表示されるため、明確で認識可能な名前を選ぶよう案内されています。

3. セッション結び付け

セッション結び付けは、認可を開始したユーザーと、外部サービスで同意して戻ってきたユーザーを正しく関連付ける処理です。ここが弱いと、攻撃者が始めた認可結果を別の利用者のセッションへ混ぜる、別人のトークンをエージェントへ渡す、といった取り違えが起こり得ます。

AWSのConsent portal設定資料では、ポータルが組織のOIDC IdPで利用者を認証し、OAuthフローをサーバー側で処理するため、ブラウザがトークンを保持しないと説明しています。マネージド機能を使う場合も、正しいIdP、Gateway、外部サービスのOAuthアプリが結び付いていることを管理者が確認しなければなりません。

自前でOAuthフローを実装する場合は、RFC 9700に沿った確認が必要です。同文書は、登録済みリダイレクトURIとの厳密な文字列一致、任意の転送先を受け付けるオープンリダイレクターの禁止、公開クライアントでのPKCE、トランザクションごとに値を安全に結び付けることなどを求めています。「コールバックが動いたから完成」と判断してはいけません。

4. トークンの保管

アクセストークンやリフレッシュトークンは、AIへのプロンプトとして渡す情報ではありません。会話履歴、モデルのコンテキスト、ブラウザのローカルストレージ、平文の設定ファイル、デバッグログにも置かないことが基本です。エージェントは必要な操作をツールへ要求し、資格情報管理層が対応するトークンを注入する構成にします。

とくにリフレッシュトークンは、短命なアクセストークンを繰り返し取得できるため、漏えい時の影響が長くなります。RFC 9700は、リフレッシュトークンを通信時と保存時に秘匿し、同意されたスコープとリソースへ結び付けることを求めています。公開クライアントでは、送信者制約またはリフレッシュトークンのローテーションによって再利用を検知することも推奨されています。

AWSの発表では、外部サービスがリフレッシュトークンを返した場合、AgentCore Identityがそれを保管し、アクセストークンの期限切れ後に新しいトークンの取得へ利用します。リフレッシュトークンが発行されない、期限切れになる、または失効した場合は、利用者による再認可が必要です。便利さのため無期限接続を前提にするのではなく、接続先の仕様に合わせて期限、ローテーション、再認可を設計します。

5. エージェントの実行権限

OAuthスコープを最小化しても、スコープ内で不適切な操作が行われる可能性は残ります。そこで、ツール単位と操作単位でも制御します。

たとえば開発支援エージェントなら、最初は「許可されたリポジトリの一覧取得」と「Issue案の作成」だけにします。Issueの公開、コードのpush、ブランチ保護変更、Secrets参照、メンバー招待は別権限にします。Slackなら、公開チャンネル一覧の取得、下書き作成、実際の投稿、DM送信を分けます。

操作の危険度は次のように整理できます。

段階	操作例	推奨制御
読み取り	公開チャンネル一覧、許可済みIssueの取得	対象範囲を限定し、ログを残す
下書き	Issue案、返信案、投稿案の生成	自動化可能だが、外部へ確定しない
作成・送信	Issue公開、Slack投稿、メール送信	内容、宛先、対象を人が確認する
変更	ラベル変更、担当変更、ファイル更新	差分表示とロールバック手段を用意する
高影響操作	削除、権限変更、秘密情報取得、本番変更	原則として自動実行させず、別経路の強い承認を要求する

AI活用ナビの判断として、導入初期はOAuthスコープ上可能な操作よりも、エージェントのツール定義を狭くすることを勧めます。接続先が広いスコープしか提供していない場合でも、Gatewayや業務APIで対象リソースと操作を絞れば、AIが触れられる面積を減らせます。

6. 監査、失効、停止

監査ログには、同意の記録と実操作の記録の両方が必要です。「接続に同意した」ことだけ分かっても、その後何が行われたか分からなければ事故調査はできません。反対に、操作ログだけあり、どのユーザーの委任に基づくか分からない状態も不十分です。

AWSの発表では、Consent portalによる認可開始、セッション結び付け、認証済みユーザー向けGatewayアクセスの取得がCloudTrailへ記録されると説明されています。イベントには資格情報プロバイダー、要求スコープ、OAuthフロー、実行ロール、リージョンなどが含まれ、機密性の高いトークンやstate値は伏せられます。

ただし、これらは主に認可フローの記録です。GitHubでどのIssueを作成したか、Slackのどのチャンネルへ何を投稿したかは、Gateway、エージェント、接続先サービスの監査ログも組み合わせて確認します。相関できるリクエストIDや実行IDを設けつつ、トークンや入力中の秘密情報をログへ複製しない設計が必要です。

停止手段は三段階で準備します。

特定ユーザーと特定サービスの接続を切る
特定ツールまたは危険な操作を組織全体で停止する
Gateway、エージェント、OAuthアプリ全体を緊急停止する

利用者がポータルでDisconnectを選べることは重要ですが、それだけで過去の操作が取り消されるわけではありません。作成済みIssue、送信済みメッセージ、変更済みファイルは別途回復が必要です。また、ポータル側の切断と接続先サービス側の認可失効がどのタイミングで反映されるかもテストします。

導入前に実施する九つの手順

手順1　代理させる業務を一文で定義する

「開発業務を支援する」では広すぎます。「指定された3リポジトリから未解決Issueを取得し、担当者が確認する週次要約を作る」のように、対象、入力、出力、頻度を固定します。この一文に不要な権限は付与しません。

手順2　人、エージェント、接続先を図にする

最低でも、利用者、組織IdP、AIエージェント、Gateway、資格情報保管場所、外部サービスを並べます。各境界で、誰が誰を認証し、どの識別子で結び付けるか記入します。共有アカウントや識別子の変換がある場所は、取り違えの候補として重点確認します。

手順3　操作から必要スコープを逆算する

接続先が提供する最大スコープから選ぶのではなく、必要操作から逆算します。読み取りだけで足りる業務に、投稿、削除、管理者権限を含めません。複数の外部サービスは個別に同意できるようにし、GitHubを使うためにSlackまで一括承認させない設計にします。

手順4　同意画面を非技術者で確認する

テスト担当者へ同意画面だけを見せ、「どのサービスで何が可能になるか」「いつまで有効か」「どこで取り消せるか」を説明してもらいます。正しく答えられなければ、表示名や説明を修正します。同意取得の成否ではなく、理解できたかを合格条件にします。

手順5　リダイレクトとセッション結び付けを確認する

登録していないコールバックURLが拒否されること、別ブラウザや別アカウントで認可結果を横取りできないこと、期限切れの認可コードを再利用できないことを確認します。自前実装ではRFC 9700を基準に、PKCE、stateまたはnonce、リダイレクトURIの厳密一致、TLS、秘密情報を含まないエラー処理を点検します。

手順6　トークンの露出経路を探す

ブラウザ開発者ツール、アプリログ、エージェントの会話履歴、トレース、エラー監視、分析基盤、サポート画面を確認します。値そのものだけでなく、URLのクエリ、例外メッセージ、画面キャプチャへ混入していないか調べます。AWSのマネージドポータルを使う場合も、周辺アプリや独自ツールのログまで自動的に安全になるわけではありません。

手順7　実行時承認を危険度別に置く

読み取りは対象を限定して自動実行、下書きは保存まで、送信や変更は差分確認後、削除と権限変更は別の管理者承認、というように段階を決めます。承認画面には、AIの説明だけでなく、実際に呼び出すツール、対象、変更差分を表示します。

手順8　監査と失効を端から端まで試す

テストユーザーが接続し、読み取り、投稿、切断を行います。その後、IdP、OAuth管理、Gateway、エージェント、接続先のログを時系列でつなげられるか確認します。接続を切った後に、保存済みセッションやリフレッシュトークンで再実行できないことも確かめます。

手順9　小さい対象で期間限定の試行を行う

最初から全社、全リポジトリ、全チャンネルへ展開しません。テスト用ワークスペースまたは低リスクな対象で始め、利用者、誤操作、拒否された操作、再認可、問い合わせ、停止に要した時間を記録します。権限追加は、実際に不足が確認された場合だけ行います。

最低限のテストケース

本番前には、正常系だけでなく、取り違え、期限切れ、失効を含むテストを実施します。

利用者Aの認可結果を利用者Bのセッションで利用できない
許可されていない組織アカウントではポータルへ入れない
GitHubだけに同意した利用者がSlackツールを実行できない
読み取り権限だけで投稿、変更、削除が拒否される
登録されていないリダイレクトURIが拒否される
期限切れまたは再利用された認可コードが拒否される
Disconnect後に新しい操作が実行できない
外部サービス側で認可を取り消した後、再認可を要求される
退職者の組織アカウント停止後、保存済み委任を利用できない
ログ、エラー画面、会話履歴にアクセストークンやリフレッシュトークンが残らない
同じ操作の再試行で投稿やIssueが重複しない
高影響操作は、プロンプトで要求されても人の承認なしに実行されない

「拒否された」という結果だけでなく、誰の、どのポリシーによって拒否され、その記録を管理者が見つけられるかまで確認します。

失敗しやすい設計

共有ボットアカウントへ全員の権限を集める

設定は簡単になりますが、誰の意思による操作か分からなくなり、退職者だけを切り離すことも難しくなります。利用者単位の委任が必要な業務では、個別の同意とユーザーへの結び付けを維持します。

最大スコープで一度だけ同意を取る

将来の機能追加に備えて広い権限を要求すると、現在の業務に不要な影響範囲が生まれます。新しいツールや書き込み機能を追加するときは、変更内容を説明し、追加同意または再承認を求めます。

同意を操作内容の承認として扱う

OAuth同意は接続の許可です。AIが生成した投稿本文、変更差分、宛先の妥当性を保証しません。外部へ確定する操作には別の確認を置きます。

ポータルの導入だけで安全対策が完了したと考える

マネージドポータルは、複雑なOAuth処理の一部を安全に実装する助けになります。しかし、過剰なスコープ、危険なツール、プロンプトインジェクション、誤った宛先、監査不足までは自動的に解決しません。

実行ロールを広くしすぎる

Consent portal自体にも、Gateway設定や資格情報プロバイダーを参照する実行ロールが必要です。AWSの実行ロール資料は、SourceAccountとSourceArnで、どのアカウントとポータルからロールを引き受けられるか制限する例を示しています。必要なポータルや資格情報プロバイダーへリソースを絞り、汎用的な管理者ロールを流用しないことが重要です。

切断手順を利用者へ知らせない

管理者だけが認可を取り消せる運用では、不審な動作に気付いた利用者がすぐ止められません。利用者向け切断、管理者向け停止、接続先サービス側の失効という複数の経路を案内します。

この方式をそのまま適用しない条件

すべてのエージェント接続に、ユーザー同意型OAuthが適しているわけではありません。

人ではなく、組織が所有する定期バッチとして動く処理に、架空の利用者や共有ユーザーの同意を流用すべきではありません。その場合は、専用ワークロードID、サービスアカウント、対象を限定したマシン間認証を検討し、業務責任者による承認と定期棚卸しを別に設けます。

医療、採用、融資、法務判断、本番インフラ変更など、人への重大な影響がある処理では、OAuth同意があっても自動実行の根拠にはなりません。専門職による確認、職務分離、法令・契約上の根拠、異議申立てや訂正の手段を別途確認します。

接続先が細かなスコープ、短い有効期間、監査ログ、迅速な失効を提供しない場合も、直接接続を見送る判断が必要です。読み取り専用の中継APIを設ける、必要データだけを承認済み領域へ複製する、AIには下書きまで任せる、といった代替策があります。

運用担当者向け判断チェックリスト

本番化の前に、次の質問へすべて答えられるか確認してください。

誰の代理で動くエージェントか識別できるか
接続するサービスと必要な操作を一文で説明できるか
読み取り、作成、変更、送信、削除を分けたか
不要なスコープを外したか
同意した本人とトークンを安全に結び付けられるか
トークンがモデル、ブラウザ、ログへ露出しないか
保存期間、更新、ローテーション、失効条件を決めたか
高影響操作に実行時承認があるか
同意ログと実操作ログをユーザー単位で追跡できるか
利用者自身、管理者、緊急対応者の停止手段があるか
退職、異動、OAuthアプリ変更時の棚卸し手順があるか
正常系だけでなく、別人への結び付け、期限切れ、失効後の再実行を試したか

一つでも答えが曖昧なら、権限を広げる前に設計へ戻るべきです。

まとめ

AIエージェントの代理アクセスで守るべきものは、トークンだけではありません。「誰が」「どのエージェントへ」「どの外部サービスの」「何の権限を」「いつまで」渡したのかという関係全体を守る必要があります。

2026年9月14日に発表されたAWSのConsent portalは、ユーザー認証、明示的同意、セッション結び付け、サーバー側OAuthフロー、トークン保管、CloudTrail記録を一つの構成へまとめる例です。ただし、同意後にエージェントが何を実行できるか、送信や削除を誰が承認するか、事故時にどう戻すかは、導入組織が設計しなければなりません。

安全な順序は、業務を狭く定義し、読み取りから始め、利用者単位で同意を取り、資格情報をAIから隔離し、高影響操作へ人の承認を置き、最後に失効まで試すことです。OAuthの接続成功をゴールにせず、切断と回復まで確認できて初めて運用可能と判断します。

確認日：2026年9月16日。主要な一次情報として、AWSの機能発表、Consent portal設定資料、AgentCore Identity用語集、実行ロール資料、IETFのOAuth 2.0 Security Best Current Practiceを確認しました。

PRIMARY SOURCES

なぜ今、AIエージェントのOAuth同意を見直すのか

認証、認可、同意、実行承認は別物

安全運用を支える六つの境界

1. 人の本人確認

2. 同意の理解可能性

3. セッション結び付け

4. トークンの保管

5. エージェントの実行権限

6. 監査、失効、停止

導入前に実施する九つの手順

手順1 代理させる業務を一文で定義する

手順2 人、エージェント、接続先を図にする

手順3 操作から必要スコープを逆算する

手順4 同意画面を非技術者で確認する

手順5 リダイレクトとセッション結び付けを確認する

手順6 トークンの露出経路を探す

手順7 実行時承認を危険度別に置く

手順8 監査と失効を端から端まで試す

手順9 小さい対象で期間限定の試行を行う