無力であることの設計思想
5 min read
Last edited:
2026年6月1日、Krebs on Securityが報じたところによると、親イラン派ハッカーがMetaのAIサポートチャットボットをソーシャルエンジニアリングし、オバマ・ホワイトハウスのページを含むInstagramアカウントを乗っ取った。サーバーに侵入したわけでも、認証情報を盗んだわけでもない。チャットを開き、パスワードリセットを要求し、ボットを説得してリカバリーメールを自分たちが管理するアドレスに変更させた。リセットコードが攻撃者に届いた。それが攻撃の全貌だ。
キルチェーンは5ステップ：
- 攻撃者がサポートチャットを開く（VPN経由でIPを偽装）
- 攻撃者がパスワードリセットを要求
- ボットが攻撃者のメールをリカバリーアドレスとして追加（検証ゲートなし）
- ボットが攻撃者のメールにOTPを送信
- 攻撃者がリセットを完了し、アカウントを掌握
攻撃者自身が、MFAが有効なアカウントに対しては失敗したと述べているが、それは偶然の失敗だった。ボットにはアカウント状態を変更する前にMFAを要求する強制メカニズムがなかった。たまたまMFAアカウントはボットが完了できない別のフローを持っていただけだ。
このような話を聞くと、最初の反応は大抵「ボットが騙されやすすぎた」というものだ。言われたことを何でも信じてしまったのだから、騙されにくくすればいい、と。
チェックを追加し、操作を認識するよう訓練し、こういった手口に引っかからないよう指示を改善すればいい、と。
私はこの反応は本質を完全に見誤っていると思う。
問題はボットが騙されやすいことではない。権限を持たないものが騙されやすくても何の問題もない。問題は、ボットがIDプロバイダーの状態（メールアドレス、リカバリーオプション）に対して、中間の検証レイヤーなしに直接書き込みアクセスを持っていたことだ。
これがセキュリティ用語でいう「非仲介エージェント権限（unmediated agent authority）」であり、ここでの実際の脆弱性クラスだ。
コールセンターを運営していて、新入社員全員にパスワードデータベースへの直接書き込みアクセスを与えたと想像してほしい。
誰かがレビューするリクエストを起票するツールではなく、データベースそのものへのアクセスだ。疲れた従業員を言いくるめられる人なら誰でも、会社の全アカウントを手に入れられる。
こんなことは絶対にしない。明らかに正気の沙汰ではない。しかし、Metaがやったことは基本的にこれと同じだ。ただし従業員が言語モデルだっただけで、言語モデルは十分な自信を持って表現すれば、ほぼ何でも信じてしまう。
AIエージェントがWebフォームよりも危険な理由がある。パスワードリセットのフォームに入力するとき、フォームには判断力がない。
入力された内容を収集し、次に何が起こるかを決定するシステムに渡すだけだ。フォームを説得することはできない。説得する対象が存在しないからだ。
AIエージェントは違う。それは判断する。判断するものに権限を与えた瞬間、会話そのものが認可になる。説得できたことは何でも実行される。
だから修正すべきは「より賢いボット」ではなく「分離」だ。互いを信頼しない2つの部分としてシステムを構築する。1つはユーザーと会話して要望を把握する部分、もう1つは実際にアクションを実行する部分。会話する部分には権限がなく、権限を持つ部分は会話しない。
エージェントはチケットを起票する。それだけだ。
我々はSDA（Service Desk Automation）を構築し、パスワードリセット、MFAリセット、アクセスプロビジョニングを会話型AIで処理できるようにした。Metaが対応しようとしていたのと同じユースケースだ。アーキテクチャの違いは、エージェントがIDシステムに対してゼロの書き込み権限しか持たないことだ。
AIレイヤーができることは5つ：要望の把握、コンテキストの収集、適用されるポリシーの参照（「これはマネージャー承認が必要、これは不要」と説明できるように）、ワークアイテムの作成、そしてステータスの通知。
リストはそれだけだ。コミットする前に何が起こるか分かるので、それに応じて判断できる。しかし、エージェントはOktaやAzure ADの認証情報を持っていない。
IDプロバイダーに到達するAPIを持っていない。パスワードリセットを依頼すると、フォームに記入した場合と同じようにイシューを作成するだけだ。エージェントは越えることができないトラストバウンダリーの上に位置している。
重要なことはすべてそのラインの下、意図的に退屈で決定論的なワークフローエンジンで起こる。2つのフェーズで実行され、2番目は1番目が通過した場合にのみ発火する。
フェーズ1：知識ではなく所有で本人を証明する
Metaのボットは会話的な証明を受け入れた。「私がオーナーです、誕生日はこれです。」我々の検証フェーズはボットに伝えられたことをすべて無視する。
ディレクトリそのものからユーザーを解決し、チャットで主張されたことではなく、HRISから実際の属性とグループメンバーシップを取得することから始まる。
次に、知識ではなく所有物で検証する。事前に登録したデバイスにチャレンジをプッシュする。エージェントはレスポンスを見ない。レスポンスはエージェントを経由しないからだ。
IDプロバイダーの検証エンドポイントに直接送られる。チャットウィンドウの誰かが誕生日について一日中嘘をつくことはできる。しかし、他人の携帯電話に通知を表示させることはできない。
ここから2つの重要な分岐がある。
リクエストがMFAリセットの場合、デバイスは定義上侵害されたか紛失したものなので、プッシュは機能しない。
その場合、システムはマネージャー証明にフォールバックする。別の認証済みチャネルを通じてマネージャーに承認カードを送信する。リクエスト者は自身のリクエストを承認できない。承認フローは、DevRevのネイティブ承認、Okta、または顧客が好むシステムのいずれを通じて実行されるかに関わらず、承認者リストからリクエスト者を明示的に除外する。自分自身の証明者にはなれない。
そして一部のユーザーは、オファリングレベルのポリシーが何と言おうと、常に最も厳格なパスを通る。
指定グループ（例えば経営幹部）のユーザーは最高の検証ティアに強制される。この決定はHRISのグループメンバーシップからサーバーサイドで行われ、リクエスト者が主張することからは決して行われない。VIPをより簡単な検証に引き下げることはできず、攻撃者がVIPステータスを主張してルールを自分に有利に変えることもできない。
認可は認証とは別の問題だ
あなたが誰であるかを知ることと、許可されているかどうかを知ることは同じではない。検証が通過した後でも、システムはリクエストしているものに対する権限があるかどうかを確認する。ロジックは静的設定に対する単純な集合演算だ：
ワークフロートリガーでサーバーサイド評価
scope_match = user.groups ∩ entitlement_scope.scope_groups
role_match = user.roles ∩ entitlement_scope.scope_roles
if not (scope_match or role_match): → エスカレーション（権限なし、人間のレビューが必要）
AIエージェントはこれをオーバーライドできない。スコープオブジェクトは静的設定であり、LLMがアクセス可能な状態ではない。権限を付与するプロンプトインジェクションは存在しない。なぜなら、権限を付与するものはプロンプトを聞いていないからだ。
そして、単純なグループとロールのマッチングでは不十分な場合、システムはカスタム述語をサポートする。時間帯、場所、リスクスコア、またはポリシーが要求するその他の条件をサーバーサイドで評価する任意の条件だ。
ポイントは同じだ：決定ロジックはエージェントが見ることも影響を与えることもできない設定に存在する。
フェーズ2：実行
本人確認と権限確認が完了して初めて、何かが書き込まれる。ワークフローエンジンはDevRevのComputer Memoryのナレッジグラフのリンクを辿ってアカウントの背後にあるバッキングシステム（Okta、Azure AD、その他）を解決し、そのシステムのAPIを呼び出してリセットを実行する。
キーリング管理されたサービスアカウントで認証する。ユーザーのトークンではなく、エージェントが保持しうるものでもない。影響範囲は会話がどれほど説得力があったかではなく、権限ポリシーによって制限される。
フェイルクローズ：まずロック、調査は後
Metaのボットとの最も重要な違いは、不確実性に対する対応だ。Metaのボットは確信がないとき、処理を続行した。このシステムでは、センシティブなフローでの異常は即座に順序立った対応をトリガーする。例えば：
異常検出 →
1. POST /api/v1/users/{id}/lifecycle/suspend（即時）
2. DELETE /api/v1/users/{id}/sessions（全セッション終了）
3. セキュリティチーム向けエスカレーションイシューを作成
4. 専用エスカレーションチャネルで通知
人間が確認する前にアカウントがロックされる。確認後ではない。不確実性は慎重に進める理由ではなく、停止する理由だ。
すべてが削除できない記録を残す
完了したすべてのアクションは不変のEntitlementGrantレコードを書き込む。これはDevRev Computer Memoryのカスタムオブジェクトで、クエリ可能、リンク可能、削除不可能だ。
コンプライアンスは「過去90日間のすべてのパスワードリセット、各承認者、使用された検証方法を表示」と尋ね、単一のクエリで回答を得ることができる。Metaのボットにはこれに匹敵するものは何も残されていなかった。
攻撃の再現
このアーキテクチャに対してMetaの攻撃を再現し、どこで失敗するか見てみよう。攻撃者がチャットを開きリセットを要求する：エージェントはイシューを作成し、IDシステムには何の変更もない。
オーナーだと主張する：システムは主張を無視し、登録済みデバイスにMFAプッシュを送信する。
デバイスを持っていない：プッシュがタイムアウトし、フローはマネージャー証明に移行する。
マネージャーの承認チャネルにアクセスできない：承認は届かず、リクエストはTTL後に期限切れになる。
ボットに検証スキップを説得しようとする：ボットにはスキップするAPIがない。検証はワークフローゲートであり、ボットが行える判断ではないからだ。
異常検知に引っかかる：IdPでアカウントが停止され、全セッションが終了し、セキュリティチームに通知される。
Metaが露出させた攻撃面 - IdPへの直接アクセスを持つエージェントの会話的操作 - は、このアーキテクチャには単純に存在しない。エージェントは洗練されたフォーム送信インターフェースだ。セキュリティはエージェントが到達できないワークフローレイヤーに存在する。
一般原則
AIに探索や判断を委ねたいタスクは数多くある。リサーチ、要約、トリアージ、プロトタイプ構築。
しかしパスワードリセットはその一つではない。規制対象であり、監査可能であり、決定論的フローに従わなければならないタスクには、モデルの振る舞いではなく構造に存在するセキュリティが必要だ。これが私がこの件から得る設計原則だ。
これは居心地が悪い。なぜなら振る舞いこそ我々が上手くなってきたものだからだ。モデルをより慎重に、よりアラインし、騙されにくくすることができる。そうすべきだ。しかし、それらの改善はすべて確率的だ。
悪い結果の可能性を低くするが、不可能にはしない。1,000回中999回操作を拒否するモデルは、1,000回目の試行で悪用されるモデルであり、攻撃者は1,000回試すことに何の問題もない。
構造は別種の保証だ。AIがリカバリーメールを変更する手段を文字通り持っていなければ、どんなに巧みに尋ねても関係ない。
システムに与えられていない権限を付与する文章は存在しない。モデルが良い判断をすることを信頼しているのではない。その判断がそもそもモデルのものではないように物事を配置したのだ。
重要なのは、これによって何も失わないということだ。モデルはまだそこにあり、会話的で、有用だ。何が起こるか説明し、選択肢を案内し、誰が何を承認する必要があるか教えてくれる。
ユーザー体験は静的なフォームよりも優れている。ただ、便利なものに同時に権限を持たせないだけだ。
ここから5つの原則が導かれる：
- AIの最小権限。エージェントはワークアイテムを作成できる。それだけだ。IdP認証情報なし、IDシステムへの直接APIアクセスなし。
- 知識ではなく所有による検証。セキュリティの質問ではなく、デバイスバウンドのチャレンジ。知識はソーシャルエンジニアリングされうるが、デバイスの所有はリモートで偽装できない。
- チャネルの分離。リクエストチャネル（チャット）≠ 検証チャネル（プッシュ通知）≠ 承認チャネル（マネージャーの認証済みセッション）。1つを侵害しても他へのアクセスは得られない。
- フェイルクローズ、まずロック。不確実性はアカウント停止と人間へのエスカレーションをもたらし、処理の続行にはならない。
- ポリシーはコードではなくデータ。権限スコープ、検証要件、承認フェーズは宣言的な設定オブジェクトであり、操作可能なLLMプロンプトに埋め込まれた条件ではない。
我々は今後数年間で、インシデントごとにこれを痛い目に遭いながら再学習することになる。エージェントにもう少しだけ範囲を広げたいという誘惑は常にある。非常に有能で、すべてをスムーズにしてくれるからだ。
毎回それは合理的に感じられ、そしてときどき誰かがこれらのエージェントの1つに、そもそも決してできるべきではなかったことをさせてしまう。
実際の攻撃者との接触を生き延びるエージェントは、必ずしも最も賢いエージェントではない。鍵を渡されなかったエージェントだ。
