アカウント復旧サポートのAIは、依頼者が嘘をついていたとしても、実行できるすべての操作が本当の所有者のためになるなら安全です。 アカウントに登録済みのアドレスへ通常のリセットメールを送る操作は、このテストに合格します。攻撃者が一日中依頼しても、リンクは所有者の受信箱に届くからです。メールの変更、2FAのリセット、「とりあえずオフにする」は不合格です。そこでAIには、パスワード忘れとロックアウトを解決させ、2FAとメール変更の案件を仕分けして下書きを作らせ、乗っ取りの気配がするものはすぐ人に回させましょう。
この線引きが重要なのは、サポート窓口が侵入経路として知られているからです。米国のサイバーセキュリティ機関CISAのScattered Spiderに関する勧告は、攻撃者がヘルプデスクに電話してパスワードをリセットさせ、MFAを自分のデバイスに移させる手口を説明しています。同じ手口に乗せられてしまうAIは、その穴をより速くしたものにすぎません。
eeselは、Zendesk、Freshdesk、HubSpotなどのヘルプデスク内でこの方針に沿って動作します。許可したリセット用エンドポイントだけを呼び出し、リスクのある操作は承認待ちにし、APIキーは一切見ません。米国の州や大学向けに学生ポータルを運営するXAPは、Freshdesk上でポータルのパスワードリセットをeeselエージェントに任せつつ、アカウント削除はチームに残しており、すべての返信は人が送っています。
アカウント復旧のチケットはなぜ自動化が難しいのですか？
親切であることと安全であることが、反対方向に引っ張り合う唯一のチケットタイプだからです。顧客は締め出され、たいてい焦っていて、今すぐアカウントを取り戻したいと思っています。攻撃者はまったく同じメッセージを書いてきます。
量も多いのです。メールプロバイダFastmailのブロン・ゴンドワナ氏は、Hacker Newsで数字を挙げています。
"In 2016 before we had automated account recovery, lost password was in the top 3 categories of ticket every single week! Every member of the support team dealt with multiple account-loss tickets per day, both forgotten password or stolen account."
パスワード忘れとアカウント盗難が同じキューに並んでいることが、問題のすべてです。私は毎日eeselのサポートキューを見ていますが、「ログインできません」は、いちばん親切に思える返信が、送ってはいけない返信であることがあるメッセージの1つです。人間はためらいを感じ取れます。チケットを解決するように作られたチャットボットは、相手が誰であっても喜んで一件落着にしてしまいます。
もう1つの側面は、顧客が出来の悪い復旧フローにどれだけうんざりしているかです。あるHacker Newsのユーザーは、MFAのバックアップとサポート窓口への不満を一言でまとめました。
"Plus a ton of vendors allow customer support to trivially turn off MFA via social-engineering, so what is the point?"
つまり仕事は「アカウント復旧の自動化」ではありません。推測が外れてもコストがかからない部分を自動化し、推測が外れるとアカウントを誰かに渡してしまう部分を遅くすることです。朗報は、量の大半が前者にあることです。パスワードリセットだけを扱うなら、パスワードリセット依頼向けAIの記事がそのチケットタイプをより詳しく扱っています。このガイドは復旧キュー全体を対象にしています。
AIの復旧操作が合格すべきテストとは？
こう問います。このチャットの相手が攻撃者だったとしても、この操作は本当の所有者のためだけになるか。なるなら、AIが実行できます。ならないなら、人が判断します。
このテストは単純に聞こえますが、ほぼすべての復旧操作をきれいに仕分けできます。
| 顧客が求める操作 | 本当の所有者のためだけになるか | 誰が実行するか |
|---|---|---|
| 標準のリセットリンクを送る | はい、登録済みのアドレスに届く | AIが単独で |
| アカウントがロックされた理由と解除時期を説明する | はい、情報であってアクセスではない | AIが単独で |
| 保存済みの復旧コードの使い方を案内する | はい、コードを持つのは所有者だけ | AIが単独で |
| 登録済みの復旧用アドレスにコードを再送する | はい | AIが単独で |
| アカウントのメールや電話番号を変更する | いいえ、新しいアドレスは誰のものかわからない | 人が、確認のうえで |
| 2FAをリセットまたは解除する | いいえ、2つ目の鍵を外してしまう | 人が、確認のうえで |
| あるメールにアカウントがあるか顧客に伝える | いいえ、誰が顧客かを漏らすことになる | 誰も、絶対に |
| リセットリンクやコードをチャットに貼る | いいえ、チャットは信頼できないチャネル | 誰も、絶対に |
最後の2行は、リセットフローに関するセキュリティコミュニティの参照資料であるOWASP Forgot Password Cheat Sheetにそのまま載っています。そこでは、存在するアカウントにも存在しないアカウントにも一貫したメッセージを返すよう求めています。したがって、AIがアカウントの存在を確認できる場合でも、「そのメールにアカウントがあれば、リセットリンクを送信しました」という返信が正解です。
この表は、何を接続すべきかも教えてくれます。「リセットメールを送る」ボタンしか持たないAIエージェントは、危険な行を実行するように説得されることがありません。そのためのボタンがないからです。これは「慎重に」と指示するよりはるかに強い保証です。指示には反論できますが、存在しない権限には反論できません。この点は設定のセクションでも触れます。
AIが処理できるアカウント復旧の依頼はどれですか？
AIがだまされた場合に何が起きるかで分けます。どのチームにも、まず3つのレーンで始めることをお勧めします。
レーン1：AIが解決する。 パスワード忘れ、失敗によるロックアウト、復旧コードや2台目のデバイスをまだ持っている顧客。解決策は、所有者がすでに管理しているものを通って届きます。AIがリセットを実行し、ロックアウトを説明し、コードの使い方を案内して、チケットを閉じます。ここにボリュームの大半があり、AIが最も多くの時間を取り戻せる場所です。24時間365日稼働させるべきレーンでもあります。土曜日に締め出された人は、月曜まで待ちたくないからです。
レーン2：AIが準備し、人が判断する。 復旧コードのない2FA端末の紛失、登録済みメールへのアクセス喪失、新しい電話番号。所有を証明するチャネルが残っていないため、誰かが確認する必要があります。それでもAIは作業の大半をこなします。アカウントを読み、どの復旧手段があるかを一覧にし、案件を開き、身分証の依頼文を下書きし、引き継ぐ担当者が事実を押さえた状態で始められるよう社内メモを書きます。返金の人への引き継ぎと同じ形で、ボタンを押す人についてのルールがより厳しいだけです。
レーン3：セキュリティチームのみ。 「誰かがパスワードを変更した」、2FAを解除してほしいという依頼、管理者やアカウントオーナーのログインに関する依頼。ここでのAIの役割はスピードと沈黙です。緊急のタグを付け、振り分け、次に何が起きるかを顧客に伝え、最近変更されたアドレスには何も送りません。
ある顧客事例は、レーン1にキーワードだけでなく文脈が必要な理由を示しています。フランスのオンライン学習企業MentorShowは、eeselにHubSpotの各チケットを、サブスクリプションの状態や更新日を含む会員レコードとあわせて読ませています。彼らの指示には、どんな設定にもコピーしたい一文があります。有効なサブスクリプションがない人のログインの問題は、ログインの問題ではない。そのチケットに必要なのは請求に関する回答であり、リセットリンクでは会員を堂々巡りさせるだけです。
アカウント復旧について、セキュリティ標準は何と言っていますか？
この問題でほとんどのセキュリティチームが参照するのは、米国政府のデジタルID指針であるNIST SP 800-63B-4とOWASPの2つです。ログインシステムを作るエンジニア向けに書かれていますが、ルールの大半は、人であれAIであれサポート担当がすべきこと、すべきでないことにそのまま当てはまります。
| 標準の内容 | サポートチケットでの意味 |
|---|---|
| NISTは4つの復旧手段を挙げている：保存済みの復旧コード、復旧用アドレスに送る発行コード、復旧用の連絡先、本人確認のやり直し | エージェントは何かを約束する前に、そのアカウントにどれがあるかを確認する |
| 2FAを使うアカウントの復旧には、異なる手段の復旧コード2つ、コード1つと別の有効な要素、または本人確認のやり直しが必要（NIST） | 「生年月日を教えてください」は選択肢に入っていない。何も登録がない端末紛失の案件は人に回す |
発行された復旧コードの有効期限は、SMSや音声で最長10分、メールで24時間（NIST） | リンクの有効期間を顧客に伝え、古いメールに返信せず新しいものを請求するよう案内する |
| 新しい復旧用アドレスは、使う前にコードで確認する必要がある（NIST） | 顧客がチャットで入力したメールを、本人のものとして扱わない |
| すべてのアカウント復旧は、登録済みのアドレスに通知を送り、「これは自分ではない」と伝える手段を添える（NIST） | 古いアドレスにすべての復旧が通知されるので、本当の所有者が偽の復旧を止められる |
1つの認証要素での失敗は100回までに制限され、その後は無効になる（NIST） | ロックアウトは意図的なもの。説明すること。回避策を探さない |
| アカウントの有無にかかわらず同じメッセージを返す（OWASP） | AIは「はい、そのメールは顧客です」と絶対に確認しない |
| リセット後に自動でログインさせず、他のセッションを終了する選択肢を提示する（OWASP） | 乗っ取りの後は、新しいパスワードだけでは攻撃者を締め出せないことがある |
| 秘密の質問だけをリセットの確認にしない（OWASP） | 誕生日やペットの名前といった答えは、ネットで見つかることが多い |
この通知のルールは、サポートチームが最も忘れがちで、最も安上がりな防御策です。NISTは、復旧通知はアカウント上のすべての通知先アドレスに送られ、受信者が依頼していない場合に備えて明確な手順と連絡先を含めなければならないとしています。AIが復旧を実行するなら、システムが古いアドレスにもその通知を送るようにしてください。誰かがアカウントを乗っ取ろうとしていれば、所有者は次回ログインを試みたときではなく、数分で気づけます。
OWASPはまた、「ハッキングされたと思う」というチケットの扱いを変える指摘もしています。パスワードのリセットだけでは、侵害されたアカウントの制御は回復しないかもしれないというのです。攻撃者がまだ有効なセッションを持っていたり、復旧情報を変更していたりする可能性があるからです。だから乗っ取りの案件は、明るいリセットリンクのレーン1ではなく、全セッションを終了して何が変わったかを確認できるレーン3に置きます。
なぜAIはメール変更や2FAリセットを単独で行ってはいけないのですか？
それらこそ攻撃者がサポート窓口に持ち込む依頼であり、1つのチャットを読むモデルでは、本物の顧客と区別できないからです。
複数の大規模な侵害の背後にいるグループについてのCISAのScattered Spiderに関する勧告が、その手口を挙げています。このグループは従業員を装い、"to convince IT and/or helpdesk staff to provide sensitive information, reset the employee's password, and transfer the employee's MFA to a device they control" としていました。勧告は、こうした電話はたいてい複数回の会話に分けて行われ、まずヘルプデスクが何を聞くかを探り、次にその答えを用意して戻ってくると付け加えています。下調べはSNS、データ漏えい、公開情報から得られるため、「住所と生年月日を確認してください」が弱い確認方法である理由もまさにそこにあります。
Oktaも同じパターンを見ています。2023年のセキュリティ報告で、Oktaは複数の米国の顧客から、最も権限の強い管理者アカウントのすべてのMFA要素をサービスデスクにリセットさせようとする電話の報告があったと述べました。Oktaの助言には、ヘルプデスクでのより強い本人確認、ヘルプデスクの役割を制限して管理者アカウントに触れないようにすること、ユーザーのMFA要素がすべてリセットされたときにアラートを出すことが含まれます。
同じ攻撃がAIエージェントに向けられる場面を想像してください。疲れることなく、即座に答え、攻撃者は1時間に50通りの言い回しを試せます。エージェントに「MFAを解除する」操作が有効になっていれば、そのうちのどれかが通るかもしれません。その操作がそもそもなければ、どれも通りません。これが、どんなエージェントの設定にも書きたいルールです。AIは復旧を始められるが、リスクのある復旧を完了させることはできない。
メール変更には独自の警告が必要です。トラフィックの多いサイトを運営していたHacker Newsのコメント投稿者が、メール変更をまったく許可しないことで避けられるものを挙げています。
"Email change is one of the most abused recovery vectors in account takeover (ATO)."
メール変更を禁止するのはおそらく難しいでしょうが、チャットの依頼だけでAIが変更を行うことがないようにはできます。AIのハルシネーションへの懸念が誤った回答に向いているなら、こちらのほうが大きな懸念です。もっともらしい操作が、間違った相手のために実行されることだからです。
AIはどのようにログインシステムとやり取りすべきですか？
ユーザーデータベースへの管理者アクセスではなく、設計上安全な、範囲の狭いエンドポイント1つを通します。
ほとんどのIDプロバイダには、必要な呼び出しがすでにあり、それは地味なものです。登録済みのアドレスに標準のリセットメールを送る、というものです。一般的な4つのドキュメントを確認しました。
| ログインシステム | AIに与えてよい安全な呼び出し | AIから遠ざけるべき危険な呼び出し |
|---|---|---|
| Amazon Cognito | AdminResetUserPassword。ユーザー自身の「パスワードを忘れた」と同じ方法でリセットコードを送る | AdminSetUserPassword。パスワードを直接設定する |
| Firebase Authentication | パスワードリセットリンクを生成し、ユーザーの既存のアドレスにメールで送る | 依頼に応じて管理者SDKからメールやパスワードを設定する |
| Auth0 | 標準のパスワード変更メールを送信する | Management APIでユーザーのMFA登録を削除する。Auth0はこれをMFA登録の解除と同じだと説明している |
| Okta | ユーザー自身が開始するセルフサービス復旧 | すべての要素をリセットする。まさにOktaの2023年のインシデント報告にある依頼 |
Cognitoについて知っておきたい点が1つあります。ドキュメントによると、復旧メッセージは、メールまたは電話番号が確認済みのユーザーにしか送られません。どちらも確認されていなければ、管理者が対応する必要があります。これは自然なレーン2の案件であり、AIは再試行せず、そのとおりに伝えるべきです。
自社アプリに「パスワードを忘れた」ボタンがあるなら、最もすっきりした方法は、同じものを小さな内部エンドポイントとして公開することです。メールを受け取り、アカウントがあれば通常のリセットメールを送り、常に同じ応答を返します。AIはそれを呼び出します。公開のログインページが誰にでも許していること以外は、何もできません。
ヘルプデスクにアカウント復旧のAIを設定する方法
私ならこの順番で進めます。ステップ1から3は、AIに操作を一切実行させない場合でもやる価値があります。
ステップ1：実際に何が来ているかを数える
ルールを書く前に、1か月分のチケットを復旧タイプ別にタグ付けします。パスワード忘れ、ロックアウト、2FA紛失、メール紛失、新しい電話、乗っ取りの疑い、「実はログインの問題ではない」です。AIによるチケットタグ付けなら、過去のチケットにさかのぼって実行できます。その内訳が、その後のすべてを決めます。90%がパスワード忘れのキューに必要なのは、エンドポイント1つと良い返信です。2FA紛失だらけのキューには、まず本人確認プロセスの改善が必要です。
ステップ2：レーンを指示に書き込む
3つのレーンを、平易な言葉で、顧客が実際に書く例とともにエージェントの指示に入れます。「入れません」「新しい電話で、認証アプリがなくなった」「そのメールはもう使っていません」「誰かがパスワードを変えた」などです。厳格なルールも加えます。アカウントの有無を確認しない、リンクやコードをチャットに貼らない、依頼だけで連絡先を変更しない。eeselでは指示は編集できるプレーンテキストで、チャットで修正を伝えるとエージェントがそれを厳しくすることもできます。詳しくは指示のドキュメントをご覧ください。
ステップ3：アカウントの文脈を与える
相手が誰かをAIに伝えるものをつなぎます。サブスクリプションや請求のシステム、CRM、ヘルプデスクの顧客レコードなどです。これがMentorShowの教訓です。「ログインできません」のチケットの半分は、期限切れのプラン、製品違い、あるいは自社が運営していないポータルが原因です。XAPも同じことを見つけました。ログインできない学生の一部は、XAPが運営していない大学独自のポータルを使っているため、適切な返信はリセットではなく案内です。
ステップ4：安全なエンドポイントを1つ接続する
エージェントには、上のセクションで述べたリセット呼び出し1つだけを与え、ログインに触れるものは他に何も与えません。eeselではNetwork Accessがそれにあたります。ドメイン1つを許可し、設定で認証ヘッダを追加すれば、エージェントが呼び出せます。他のドメインへのリクエストは拒否されます。
復旧にとって重要なのは、この画面の上部にある行です。認証情報はヘッダとして保存され、AIには表示されません。リセットを実行できるキーがプロンプトの中に置かれることはないため、エージェントから言葉巧みに聞き出されることはありません。開発者はターミナルからも設定できます。eesel CLIはダッシュボードと同じエージェントとワークスペースを動かすので、エンジニア、スクリプト、またはClaude CodeやCursorのようなコーディングエージェントが、ブラウザを開かずにエンドポイントの接続、復旧用の指示の編集、エージェントのテストを行えます。
ステップ5：本人性に触れるヘルプデスクの操作はすべて承認制にする
eeselのエージェントが実行できる各操作は、エージェントごとに、自動で実行する、先に確認する、オフにする、のいずれかに設定します。アクションと承認のドキュメントは、返信と元に戻せない操作を承認制にして、監督付きで始めることを勧めています。
復旧については、タグ付けと社内メモは初日から自動で動かし、公開返信は最初の1〜2週間は承認制にします。返信が有効でも、特定の種類の案件だけを保留にすることもできます。「2FAやメール変更に関することには、返信する前に確認する」という指示を入れれば、エージェントはその案件だけで止まります。
ステップ6：レーン2と3を担当者を決めて振り分ける
レーン2は、本人確認を実施できる人、通常はシニアのエージェントかティア2に回します。レーン3は、セキュリティ担当者に、名前を指定し、緊急タグと短いSLAを付けて回します。AIはタグで振り分けることを瞬時にできますが、週末に誰も見ていない共有受信箱を指している振り分けルールを直すことはできません。ティア2のチームが小さいなら、AIに社内メモを書かせて、アカウントの事実を押さえた状態で始められるようにします。
ステップ7：過去のログインチケットでテストする
実際のチケットに触れさせる前に、すでに処理した復旧チケットでエージェントを動かします。リセットリンクをレーン1でだけ送ったか。メールにアカウントがあると確認したことはないか。怒った請求の苦情の中に隠れた乗っ取りを見抜いたか。過去のチケットでのシミュレーションなら、午後のうちに答えが出ます。このチケットタイプでは、私なら決して飛ばさないステップです。
このチケットはどのレーンに入りますか？
依頼の種類を選ぶと、誰が対応し、AIが何をし、その背後にあるルールが何かがわかります。
うまくいっているかどうか、どう測りますか？
スピードと安全性を並べて追います。速くても、ときどきアカウントを渡してしまう復旧の仕組みは、AIがないより悪いです。
- AIが解決した復旧チケットの割合。 ステップ1で出したレーン1の割合とほぼ同じになるはずです。それよりかなり高ければ、AIが閉じるべきでないチケットを閉じています。
- レーン1の初回返信までの時間。 締め出された顧客は1分1分を感じています。最も大きく下がるはずの数字です。
- レーン3の対応時間。 乗っ取りが6時間もキューに放置されるのは、見出しになってしまう類いの失敗です。SLAレポートで監視しましょう。
- 復旧通知への「これは自分ではない」という返信。 1件1件が、誰かが依頼していない復旧です。1件残らず読んでください。
- 7日以内の再問い合わせ。 同じ顧客が戻ってくるなら、リセットリンクが届いていないか、返信が本当の問題を外しています。
これらをタグ付きチケットから作る方法は、AIサポートレポートのガイドで紹介しています。
AIとアカウント復旧でよくある間違い
最初の1か月で私が注意して見るのは次の点です。
- AIにアカウントの存在を確認させる。 「アカウントが見つかりました、今リンクを送ります」は親切に思えますが、どのメールが顧客かを攻撃者に教えてしまいます。どちらの場合も同じ返信にします。
- チャットの情報を証拠として扱う。 名前、住所、下4桁、生年月日。どれも誰かのデータ漏えいに含まれています。CISAは、攻撃者が電話をかける前にまさにこうした情報を集めていると指摘しています。
- リンクやコードを会話に貼る。 復旧の場面で信頼できないのがチャットというチャネルです。コードは登録済みのアドレスに送ります。
- 「後で安全のため」とAIに管理者のAPIキーを渡す。 そのキーがMFAを解除できるなら、いつか誰かがエージェントを説得して試させると考えてください。必要な呼び出し1つだけを与えます。
- 通知を省く。 すべての復旧は古いアドレスに知らせるべきです。これまでに設定できる中で最も安上がりな乗っ取りアラームです。
- 別のログインを忘れる。 XAPのキューが示しました。学生がたどり着けないポータルが自社のものではないことがあります。リセットリンクより案内のほうが役立ちます。
このような導入が、監督付きから手放しの運用へどう進むかという全体像を知りたい場合は、その調整つまみを扱った導入スケジュールの記事をご覧ください。
アカウント復旧のチケットにeeselを試す
eeselは、サポート向けのAIチームメイトとしてヘルプデスクに加わります。ログインのチケットでは、顧客のアカウントの文脈とともに各チケットを読み、許可したリセット呼び出しだけを実行し、アカウントの有無にかかわらず同じ返信をし、2FAの変更、メールの差し替え、乗っ取りに見えるものはチームのために保留にします。Zendesk、HubSpotなどの主要なヘルプデスクで動作し、FreshdeskではFreshdesk連携から利用できます。
承認は、チームがすでに作業している場所に届きます。ダッシュボード、Slackのスレッド、ヘルプデスクのメモ内のリンクで、すべての承認には、誰がいつ判断したかが記録されます。APIキーは設定内にあってAIには見えず、eeselはTrust Centerによると、お客様のデータを基盤モデルの学習に使うことはありません。正直な欠点を1つ挙げると、eeselのSOC 2 Type II監査はまだ進行中です。セキュリティチームが今日すぐにレポートを必要とする場合は、まず現在の状況を確認してください。代わりに何を請求すべきかは、ベンダーのセキュリティチェックリストで解説しています。
XAPは、小さく始める良いモデルです。eeselエージェントの前段にあるフィルターは、案内の案件とポータルのパスワードリセットだけを通し、人が送信しない限り、学生には何も届きません。アカウント削除はチームに残ります。そこから始め、1か月測定し、それからレーン1を開放してください。eeselを試すなら、100クレジット付きで7日間無料です。