暗号技術は通信途中で誰がメッセージを読めるかを決め、アクセス制御とエージェントの設計は受信者が読んだ後に何をできるかを決めます。
メッセージアプリにおけるプロンプトインジェクション攻撃は、メッセージの本文がAIアシスタントを誘導し、本来のルールを無視して権限のない要求を実行させようとするものです。エンドツーエンド暗号化は通信中のメッセージを保護します。しかし、ユーザーがボットにチャットの閲覧を許可していたり、端末がマルウェアに感染していたりする場合、暗号化では、その正規の受信者の振る舞いを制御できません。
重要なポイント
- エンドツーエンド暗号化が防ぐのは通信途中でのメッセージの読み取りであり、復号済みの本文を閲覧する権限を持つ仮想アシスタントによる悪用ではありません。
- 間接的なプロンプトインジェクションは、非公開メッセージ、ファイル、キャプション、引用された内容に潜み、処理時に指示として扱われる可能性があります。
- AIエージェントがチャット、メモリ、外部ツールに加え、送信や操作の実行も同時に行えると、情報漏えいのリスクが高まります。
- データと指示の分離、権限の最小化、人による確認、出力の制限は重要な防御層ですが、どれか一つで完全な保証が得られるわけではありません。
- Livaraの文書によると、ダイレクトチャットと互換性のある非公開グループは、E2EEが有効な状態でエンドツーエンド暗号化されます。互換性のない古いグループは対象外となる場合があります。この保護は、本文を受け取った後のアシスタントの振る舞いを保証しません。
メッセージアプリのプロンプトインジェクション攻撃はどう動くのか？
プロンプトインジェクション、すなわち「指示の注入」とは、攻撃者が入力を作り、言語モデルにデータではなく指示として受け取らせ、本来のポリシーから逸脱させることです。OWASPのプロンプトインジェクションガイドでは、直接の入力と外部コンテンツが、このリスクの経路として挙げられています。エージェント型システムでは、回答の逸脱が、接続されたツールの意図しない利用にまで及ぶ場合があります。
直接的な攻撃では、ユーザー自身がボットに、それまでのルールを無視するよう伝えます。間接的な攻撃では、アシスタントが別の作業のために読む内容に悪意ある指示が埋め込まれます。受信メッセージ、引用文、キャプション、文書、ツールの出力などです。後者では、攻撃者がAIエージェントとアカウントを共有している必要はありません。攻撃者のコンテンツが、エージェントの処理するコンテキストに届けばよいのです。
例えば、ユーザーがアシスタントに新着メッセージの要約を依頼します。そのうち一つに「システム指示」を装う文章が含まれ、要約を中止し、コンテキストから別の情報を取り出して外部の宛先へ送るよう要求していたとします。このシナリオが必ず成功するわけではなく、モデル、アプリの設計、アクセス権限、出力制御に左右されます。それでも、ツールを使えるアシスタントにとっては、その可能性自体にセキュリティ上の意味があります。
モデルの回答を操作することと、実際に行動できるエージェントを攻撃することは区別すべきです。誤った回答は迷惑で済むかもしれませんが、メッセージ送信、ファイル取得、サービス呼び出しの権限を持つエージェントは、同じ操作をデータの漏えいや意図しない行為へとつなげる可能性があります。
AIチャットボットの安全性が暗号化だけでは決まらないのはなぜか？
AIチャットボットの安全性は、メッセージアプリ、端末、モデル、メモリ、ツール、提供者のサーバー、権限ポリシーという信頼の連鎖全体に依存します。エンドツーエンド暗号化が保護するのは、送信者から正規の受信者までの間で、非公開の内容を読まれないようにするという特定の境界だけです。
メッセージは、権限のある端末に届くと、ユーザーに表示するために復号されます。アシスタントが同じ端末上で、または許可された接続を通じて本文にアクセスできる場合、目にするのは復号後のデータです。プロトコル上は、許可されたボットやアプリは正当な受信者かもしれません。しかし、ユーザーから見ると、その受信者が過大な権限を持っていることもあります。
この違いは次のように整理できます。暗号技術は通信途中で誰がメッセージを読めるかを決め、アクセス制御とエージェントの設計は受信者が読んだ後に何をできるかを決めます。前者の境界を理解するための、エンドツーエンド暗号化と保護されないもののガイドでは、E2EEはマルウェア、裏切る受信者、侵害された表示装置への対策にはならないと説明しています。
「暗号化メッセージアプリとAI」という組み合わせを、自動的に安全または危険と判断するべきでもありません。永続メモリも出力ツールもないローカルエージェントと、履歴、ファイル、外部アカウントにアクセスできるクラウドボットでは、リスクの水準が異なります。結果を左右するのはアーキテクチャと権限の範囲です。
AIアシスタントが非公開チャットにアクセスすると、どのようなリスクが生じるのか？
AIアシスタントに非公開チャットへのアクセスを認めると、それまで会話の参加者である人間だけが見ていた内容が、新たな信頼境界に入ります。主なリスクは、アシスタントが本文を読むだけでなく、保持し、他のデータと組み合わせ、別の経路で外部に送れることです。
このような機能を有効にする前に、次の五つの問いへの明確な答えが必要です。
- アシスタントは、具体的にどの会話、添付ファイル、期間の内容を読みますか？
- 処理は端末上で行われますか。それとも内容が別のサーバーへ送られますか？
- 提供者はどのデータを保持し、それを学習に利用しますか？
- エージェントには、メッセージ送信、ファイルのアップロード、検索、操作の実行に使えるどのようなツールがありますか？
- 機密性の高い操作には、毎回ユーザーの明示的な確認が必要ですか？
選択した一つのメッセージを要約するだけの機能に「すべてのチャットを読む」権限を与えるのは、最小権限の原則に反します。この原則は、各構成要素に、現在の作業に必要な最小限のアクセスだけを与えるというものです。権限を一つのメッセージ、一つの会話、一回のやり取りに限定すれば、被害の範囲を狭められます。ただし、その範囲の内容自体に攻撃が含まれる可能性は残ります。
メタデータは本文とは別のものです。Livaraの文書によると、送信者、宛先、配信時刻などの運用メタデータは、ルーティングと同期のために保存されます。メッセージアプリのメタデータとそこから分かる情報のガイドは、この境界を説明しています。アシスタントは本文だけでなく、連絡のパターンや時刻からも推測できるため、アクセス方針では両方を考慮する必要があります。
AIエージェントからの情報漏えいは、どの経路で起こるのか？
AIエージェントからの情報漏えいは通常、エージェントのコンテキストに機密情報があり、それを別の宛先へ運ぶ手段がある場合に起こります。指示の注入だけでデータが移動するわけではありません。漏えいは、悪意ある入力、データへのアクセス、出力経路の組み合わせに依存します。
出力メッセージやファイル
エージェントは、回答、新しいメッセージ、下書き、ファイル、外部サービスへのリクエストに情報を含める場合があります。システムが制限もユーザーの確認もなく出力を送るなら、攻撃者は機密データを一見普通の形式へ変換しようとする可能性があります。
長期メモリ
一部のエージェントは、会話の要約、好み、過去の結果を後で利用するために保持します。悪意ある指示は、データをメモリに書き込ませたり、別のセッションで取り出させたりしようとすることがあります。保持期間の短縮、ユーザー間の分離、内容を確認して削除できる機能はリスクを減らしますが、モデルの誤りをなくすものではありません。
ツール呼び出し
ツールを備えたエージェントは、検索、ファイルの読み取り、その他の許可された操作を実行できます。ファイル読み取り、メッセージ送信、ネットワークリクエストには、それぞれ独立した権限が必要です。出力中のリンクを自動表示したり、外部リソースを読み込んだりするだけでも、データの流出経路になり得ます。「送信」ボタンがないだけでは不十分です。
侵害された端末
十分なアクセス権を持つマルウェアは、画面上の本文、通知、アプリのメモリ、ユーザーの入力を読み取る可能性があります。この場合、攻撃者は必ずしも暗号を破る必要はなく、エンドポイントを利用して防御を迂回します。OSの保護、更新、アクセス制御、インストール済みアプリの点検は防御の一部ですが、メッセージングプロトコルの機能ではありません。
この脅威に対し、Livaraの暗号化にはどのような境界があるのか？
Livaraのセキュリティ文書では、ダイレクトチャット向けのLVR1と、互換性のある非公開グループ向けのLGS1が説明されています。互換性のない古いグループは、明示的にE2EEの対象外となる場合があるため、その会話の状態を確認しなければなりません。公開チャンネルも、非公開E2EEチャットの範囲には含まれません。
E2EEの会話でも、ユーザーが復号済みの本文をアシスタントに渡せば、メッセージの暗号化は、その後の処理目的を制御しません。セーフティナンバーの確認も、相手の鍵を検証するものであり、相手の文章に含まれる悪意ある指示を検出するものではありません。この記事は一般的なリスクの類型を扱っており、Livaraに特定のAI接続が存在することや、その安全性を確認するものではありません。
これは概念図であり、検証済みのLivaraのアーキテクチャではありません。図中の錠前は、アシスタントが選択された本文にアクセスできないことを証明しません。
メッセージアプリのプロンプトインジェクションを抑えるアーキテクチャとは？
安全なアーキテクチャでは、受信メッセージを信頼できないデータとして扱う必要があります。既知の相手から暗号化チャット内で届いた場合でも同じです。暗号化は経路の真正性を強めますが、送信者の内容が自動実行しても無害であることを証明するわけではありません。
データと指示を分離する
アプリは、開発者の固定指示、ユーザーの明示的な依頼、チャットから読み込んだ内容を別々の層に置くべきです。プロンプトインジェクションに関するNCSCの警告は、SQLインジェクションと同様の決定的な解決策がある問題と考えてはいけないと強調しています。内容に「信頼できないデータ」とラベルを付けることは有用ですが、言語モデルは、この意味上の境界を常に正確に守れるわけではありません。そのため、分離にはモデルの外側での制御を組み合わせる必要があります。
エージェントの権限を減らす
要約エージェントには、メッセージの自動送信や、すべてのファイルを読む権限は必要ありません。ツールには、許可リスト、狭い対象範囲、個別の認証情報、短い有効期限を設けるべきです。選択された内容への一回限りの許可は、恒久的なアクセスより望ましいものです。意図しないアクセスの可能性と、漏えいの範囲の両方を減らせるためです。
決定論的な検査ゲートで出力を確認する
機密データを送るかどうかの最終判断を、モデル自身に委ねるべきではありません。非生成型の層は、決定論的なルールに基づき、宛先、データの種類、出力量、要求された操作を検査できます。構造的ルールと送信先の許可リストはモデルの外で実行すべきであり、意味からすべての機密情報を見抜く処理には、なお誤りがあり得ます。必要最小限のイベント記録、アラート、停止機能も必要です。
機密性の高い操作には人の確認を求める
下書きを読むことと送信することは同じではありません。メッセージの送信、ファイル共有、メンバー追加、アカウント設定の変更、外部サービスへのデータ転送には、明確なプレビューと、内容を理解した上での確認が必要です。曖昧な確認や頻繁すぎる確認は、反射的なクリックにつながります。画面にはデータ、宛先、結果を正確に示す必要があります。
制限された環境でエージェントを実行する
プロセス分離、ネットワークアクセスの既定での無効化、一時ストレージ、狭い範囲の認証情報は、失敗時の影響を抑えます。これらの制御はプロンプトインジェクションをなくしません。逸脱した回答が、そのまま広範なアクセスへとつながるのを防ぐためのものです。
ユーザーと管理者は、AIチャットボットの安全性のために何をすべきか？
ユーザーは、AIへの接続を一つ増やすたびに、私的データの新たな受信者が増えると考えるべきです。管理者も、導入前にデータの流れとエージェントの操作を点検し、実行中は監視する必要があります。
個人で利用する場合：
- 必要なメッセージやファイルだけを選択し、履歴全体へのアクセスは与えないでください。
- 処理場所、保持期間、学習への利用、データの削除方法を確認してください。
- 明確な必要性がない限り、メッセージやファイルの自動送信はオフにしてください。
- 端末、ブラウザ、アプリを最新に保ち、機密性の高い権限を見直してください。
組織の場合：
- 悪意ある送信者、裏切るグループメンバー、モデルのサービス、外部ツール、侵害された端末を個別に扱う脅威モデルを作成してください。
- ツール呼び出し、権限変更、出力先、ユーザーの確認を、必要最小限の機密データで記録してください。
- メッセージ、文書、引用文、文字を含む画像、取得したコンテンツに含まれる敵対的入力をテストしてください。
- 各エージェントに操作数の上限、リクエスト頻度、許可された宛先、緊急停止スイッチを設けてください。
- 安全側に停止することを既定にしてください。ポリシーが曖昧なら、エージェントは推測せず停止すべきです。
どのチェックリストも、完全な安全を実現するものではありません。結果は、実装、モデル、設定、ユーザーの行動、攻撃手法の変化に左右されます。優れた防御の目的は、権限を減らし、逸脱を可視化し、被害を限定することです。
暗号化メッセージアプリとAIは、安全に共存できるのか？
はい。アシスタントに最小限のアクセスだけを与え、確認なしに機密性の高い操作を行わせなければ、暗号化メッセージアプリとAIは、リスクを管理しながら併用できます。ただし、どのモデルであっても私的な内容に接続すれば新しい信頼境界が生まれます。それをE2EEという呼び名の陰に隠してはいけません。
より低リスクな設計では、可能な限り端末上で処理し、ユーザーが明示的に選んだ内容にコンテキストを限定し、メモリの保持期間を短くし、出力ツールを分離します。ローカル処理も絶対的な保証ではありません。侵害された端末、安全でないモデル、広すぎる権限は、依然としてリスクを生みます。
ユーザーは、どのデータがモデルへ渡るのか、モデルはどこで動くのか、何をどの期間保持するのか、どのような操作ができるのかを把握できるべきです。製品がこれらに明確に答えていないなら、「プライベートAI」といった表現だけから安全性を断定してはいけません。
プロトコル文書やアプリのハッシュ値の一致は、接続されたアシスタントのセキュリティテストではありません。接続を有効にする前に、その機能の権限とデータ経路を別途確認してください。一度のテストが成功しても、その結果だけで将来のすべての入力を網羅できるわけではありません。
よくある質問
エンドツーエンド暗号化はプロンプトインジェクションを止めるのか？
いいえ。エンドツーエンド暗号化は、送信者と正規の受信者の間で、メッセージを中継者から隠します。許可されたボット、端末上のアプリ、マルウェアが復号済みの本文にアクセスできれば、それを処理できます。プロンプトインジェクションを抑えるには、エージェントの権限、ツール、メモリ、出力を制限する必要があります。
AIで非公開チャットを要約するのは危険か？
リスクはアーキテクチャに依存します。選択した一つのメッセージを、メモリや出力ツールなしにローカルで要約する場合は、すべてのチャットに常時アクセスするクラウドボットよりも、リスクの範囲が小さくなります。利用前に処理場所、データ保持、権限の範囲、自動送信の可否を確認してください。
知っている相手のメッセージにもプロンプトインジェクションは含まれ得るか？
はい。送信者の身元を信頼することと、その人のすべての内容を信頼することは同じではありません。アカウントが乗っ取られていたり、本人が意図せず悪意ある文章を転送していたりする可能性があります。エージェントが読むあらゆる内容は、認証され暗号化された会話の中でも、信頼できないデータとして扱うべきです。
LVR1とLGS1は、AIアシスタントから情報を隠すのか？
実際にLVR1またはLGS1で保護され、E2EEが有効な会話では、これらのプロトコルは、鍵を持たない中継者から内容を隠すことを目的としています。ユーザーやアプリがアシスタントに復号済みメッセージの閲覧を許可すれば、これらのプロトコルは、その許可されたアクセスを遮断しません。そのため、アシスタントの安全性は、メッセージ転送の安全性とは分けて評価する必要があります。
AIエージェントからの情報漏えいを減らす最初の一歩は？
まず、エージェントのアクセス範囲を減らしてください。選択したメッセージだけ、そのやり取りの間だけとし、自動送信を許可しないことです。その上で、機密性の高い操作にはプレビューと人による確認を設け、出力先を制限し、ツール呼び出しを記録します。これらの層はリスクを減らしますが、絶対的な保証にはなりません。
