RFC 9700は2025年1月に公開されたOAuth 2.0のセキュリティに関する推奨事項です。そこでも認可情報の扱いは重要な論点です。(RFC 9700) 今週は、使っているAIエージェントがパスワードを直接扱うのか、ログイン済みの状態だけを使うのかを確認してください。AIエージェントが必ずパスワードを奪うわけではありませんが、ブラウザーやパスワード管理ツール、既存のセッションを通じてアカウントを操作できる場合があります。安全性は、認可の範囲と実行環境によって変わります。
パスワードの流出を心配している一般ユーザー、ウェブ操作を行うAIエージェントを開発・導入する技術者、チームのアカウント管理を担う人に向けた内容です。
資金移動や本人確認など、失敗時の影響が大きい操作を任せたい場合は、仕組みを確かめる前に本番アカウントを接続しないでください。
AIエージェントがパスワードに触れる経路
まず、「パスワードを知ること」と「アカウントを操作できること」を分けて考えます。画面を見てマウスやキーボードを操作する方式では、ログイン画面にパスワードを入力させる設定なら、入力内容がエージェントに渡る可能性があります。一方、すでにログインしたブラウザーを操作する仕組みでは、パスワードを再入力せずにページを操作できる場合があります。
AIエージェントがウェブサイトを操作するとき、パスワードも見えるのでしょうか。
実装によって異なります。たとえば、コンピューター操作の統合ガイドでは、画面の情報をモデルに渡し、クリックやキー入力を実行する仕組みが説明されています。パスワード欄を含む画面を渡すか、入力をどのように処理するかは構成次第です。(コンピューター操作の統合ガイド)
パスワード管理ツールとの連携も一様ではありません。利用者がログイン情報をコピーして指示に貼り付ければ、エージェントがその文字列を処理する可能性があります。自動入力を使う場合も、エージェントが入力欄を操作できるのか、保存済み情報を読み取れるのかを確認してください。「パスワード管理ツールを使っている」だけでは、エージェントに見えないとは限りません。
OAuthなどの認可方式では、利用者がサービスへのアクセスを許可し、エージェントがパスワードそのものではなく認可情報を使う設計があります。許可する情報や操作の範囲はサービスごとに異なります。(GoogleのOAuthユーザー認可の説明)
| 操作経路 | パスワードへの接触 | 主な確認点 | 露出リスクの目安 |
|---|---|---|---|
| エージェントにパスワードを入力させる | 入力内容を処理する可能性があります | 入力が記録・保存されるか | 高め |
| ログイン済みブラウザーを操作する | パスワードなしでも操作できる場合があります | セッションの保存先、共有範囲、終了後の消去 | 中程度 |
| OAuthなどで認可する | 通常、パスワードをエージェントに渡さない構成が可能です | 許可範囲、有効期間、取り消し方法 | 比較的低め |
リスクの目安は仕組みを比べるための編集上の評価です。実際の危険度は、サービスの設定やエージェントの実装、保存方法によって上下します。認可トークンもアカウントへのアクセスに使われる情報です。パスワードを渡さない方式であっても、トークンの保護や失効方法の確認は欠かせません。
アカウント操作に伴うリスク
認証情報へのアクセスを許すと、意図した作業を超えて変更・送信・削除を行う「過剰な権限」の問題が生じます。OWASPは、AIシステムに必要以上の自律性や権限を与えるリスクを解説しています。(OWASPによる過剰なエージェンシーの説明)
また、ウェブページに書かれた悪意ある指示が、エージェントの判断を誘導するプロンプトインジェクションも考慮が必要です。ページの内容を信用して操作する設計では、利用者が頼んでいない送信や情報の開示につながる可能性があります。OpenAIも、コンピューター操作におけるプロンプトインジェクションのリスクと防御上の考え方を公開しています。(プロンプトインジェクションのリスクと対策)
セッションや認可情報が実行環境に残る場合、環境を共有する人や後続の処理からアクセスされる可能性もあります。ただし、これはすべてのエージェントで起きると確認された事実ではありません。ログ、保存期間、セッションの分離、削除手順を、利用する製品の説明や設定で個別に確かめる必要があります。
権限を絞る運用手順
実際にログインを任せる前に、次の手順で影響範囲を小さくしてください。
- 作業を限定する。 読み取りや情報整理など、失敗しても影響が小さい作業から始めます。メール送信、購入、削除、パスワード変更は別扱いにします。
- 専用または低権限のアカウントを使う。 業務上可能なら、本番データや管理機能にアクセスできないアカウントを用意します。個人の主要アカウントをそのまま使うより、誤操作の範囲を抑えやすくなります。
- 認可画面を確認する。 OAuthなどを使う場合は、読み取りだけか、更新や送信も可能かを確認します。用途を説明できない権限は許可しないでください。
- 実行環境を分ける。 日常利用のブラウザーと同じプロファイルを使わず、専用のブラウザーや分離した環境を選びます。共有端末では、セッションが残らないかも確認します。
- 保存と削除の条件を読む。 入力、画面情報、操作ログ、認可情報が何のために保存され、いつ消えるのかを確認します。非公開の条件を推測で補わないことが大切です。
- 取り消し手段を試す。 サービス側の連携解除やトークン失効の手順を確認します。Googleの認可関連資料には、認可を取り消すためのインターフェースが示されています。(Googleの認可取り消しリファレンス)
- 重大な操作には人の確認を残す。 支払い、送信、権限変更、削除などは、実行前に内容を表示させて本人が承認する運用にします。
ウェブサイトの指示や表示内容をモデルが誤って信頼する可能性を考えると、確認画面は単なる手間ではありません。OpenAIのコンピューター操作に関する安全ガイドも、操作環境や確認の必要性を検討するための資料です。(コンピューター操作の安全ガイド)
ログイン代行の判断条件
AIエージェントがブラウザーのログイン済みセッションからアカウントに入ることはありますか。
あります。パスワードを知らなくても、ログイン状態を維持したブラウザーを操作できれば、そのセッションで許された範囲のページにアクセスできる場合があります。セッションを使う操作では、パスワードを知られないことと、アカウントを操作されないことは同じではありません。
次の条件で、任せる範囲を決めてください。
- 読み取りだけの作業で、専用アカウントを用意でき、保存・削除・権限の説明も確認できるなら、低リスクの作業から試します。
- 広範な操作権限が必要でも、実行前に本人の確認を必須にできるなら、承認が必要な操作だけを段階的に任せます。
- 権限範囲が不明、認可を取り消せない、セッションの保存先が分からない場合は、ログインを任せず本人が操作してください。
- 資金、本人確認情報、重要な業務データを扱い、誤操作を戻せない場合は、十分な制限と監査方法を確認できるまで本番アカウントを使いません。
将来、AIエージェントがログインするたびにパスワードを入力する必要はなくなるのでしょうか。
認可や公開鍵を使い、パスワードをエージェントに渡さず操作する仕組みは選択肢になり得ます。しかし、ウェブサイト側が何を許可するか、本人確認をどう行うか、操作の責任を誰が負うかは別の課題です。W3CはWebAuthn Level 3を公開鍵資格情報にアクセスするための勧告として説明していますが、これはAIエージェントがあらゆるサイトへログインできるという意味ではありません。(WebAuthn Level 3のW3C勧告)
したがって、ログイン代行が広がる可能性はあっても、すべてのウェブサイトがAIに認証情報を渡すとは限りません。本人による認可、最小限の権限、取り消し可能性、重要操作の確認が整うかを見て判断してください。
エージェントを動かす環境を選ぶときは、日常利用のブラウザーとセッションを分けられるか、保存情報を消去できるかを確認しましょう。運営者や提供内容を確認したい場合は、VPSSparkの運営者情報を参照できます。利用環境について確認事項が残る場合は、問い合わせ窓口で必要な情報を確認してください。環境を分離しても、認可範囲や本人確認の問題が解決するわけではありません。まずは低リスクの作業で試し、資金、本人確認、重要データを扱う操作は慎重に判断してください。
AIに任せる前に、認証と権限を見直しましょう
まずは、利用するAIエージェントがパスワードを入力するのか、ログイン済みの状態で操作するのかを確認してみてください。
次に、専用アカウントや必要最小限の権限を使い、任せる作業の範囲を絞る方法を関連ガイドで確かめてみましょう。