アプリの保護：エージェント型機能によるリスクの軽減

こんにちは Willyです。 今日は 識別方法について アプリのエージェント機能への 新たなリスクの軽減方法をお伝えします。 後ほど 同僚のAkshayが 具体的な実行手順を提供します。 プラットフォームのAPIを使って アプリを保護するための方法です。 大規模言語モデル(LLM)が普及するにつれ、 多くのアプリがLLMを活用して 新たなインテリジェント機能を模索しています。 LLMをシステムの 重要なコンポーネントにしています。 アプリ内では 指示とプロンプトを 送信できます。 ユーザーのリクエストと 追加コンテキストを含む形で LLMに 1つまたは複数の アクションを実行させます。 中間結果を取得しながら 最終的にユーザーへの レスポンスを提供します。 プラットフォームでは エージェント機能を構築できます。 Foundation Modelフレームワークで 独自のエージェントを設計するか、 App IntentフレームワークでSiriと 連携させることができます。

新たな機能には 新たなセキュリティリスクが伴います。 LLMはアプリ内に 新たな確率的エンジンをもたらします。 強力である一方、 騙される可能性もあります。 このトークの目的は エージェント機能の新たなリスクを 強調することです。 ユーザー保護に使用できる 技術とAPIもご紹介します。 アプリが意図した通りに 動作することが重要です。 ユーザーのセキュリティを 念頭に置いて。 最初に このトークで扱わない内容を 明確にします。 モデルの安全性については説明しません。 モデルの出力が安全かどうかを 確保する内容です。 モデルのガードレールについても 説明しません。 迂回への対策についてもです。 これから説明する原則の一部は そういったケースへの対応にも 使えますが、 アプリへの侵害を試みる外部の攻撃者に 焦点を当てます。 モデルの安全性を確認したい方は 下記のリンクをご覧ください。

エージェントシステムにおける 新たなリスクについて説明します。 まず 攻撃者がアプリを狙う理由を 考えてみましょう。 アプリには攻撃者が興味を持つ機能があります。 例えば: 機密ユーザーデータの保管や 金融取引の実行、 マイクやカメラなどの システムリソースへのアクセス、 または物理デバイスの制御などです。 攻撃者はアプリを悪用して 目的を達成しようとします。 攻撃と対策を説明するために Loose Leafアプリを 例として使用します。 次世代ソーシャルネットワークになり得る サンプルアプリです。 ホット、コールド、タピオカなど お茶全般に特化しています。 Loose Leafはソーシャルネットワークの 未来だと確信しています。

Loose Leafにはすでに 魅力的な機能が搭載されています。 お茶のレシピを友達にメッセージで 送る機能や、 撮影したお茶パーティの写真を 共有する機能などです。 以前は 従来の機能の 脅威モデリングについて 軽減策も含めて説明しました。 エッセンシャルを忘れないために そのビデオを見ておくことをお勧めします。 さて Loose Leafのデベロッパたちは 準備を進めており、 刺激的な新機能の発表を 楽しみにしています。 「Organize a tea party」です。 Foundation ModelとApp Intent フレームワークを使用します: カレンダーを確認してお茶パーティに 最適な時間を見つけ、 招待すべき友人を特定し、 プロフィールに基づいて 提供するお茶を決め、 全員が好むお茶を注文します。 すごい！

この新機能はLoose Leafの エージェントループを利用しており、 2つの特性があります。 第1に 複数の場所からコンテキストを 取得します。 エージェントが意思決定を 行うためです。 第2に エージェントはユーザーに代わって 1つ以上のアクションを呼び出せます。 さまざまな副作用が 生じる可能性があります。

第1の特性から始めると 新たなリスクをご紹介します: 間接プロンプトインジェクションです。 間接プロンプトインジェクションとは 追加コンテキストに埋め込まれた指示で、 制御フローをリダイレクトする 意図があります。

エージェントループでは プロンプト内の指示を指します。 プロンプトの最初の追加コンテキストや ツール結果内に 埋め込まれた指示です。

実際にはどう見えるかというと ユーザーがカレンダーを含む お茶パーティの開始をリクエストし、 カレンダーにモデルへの 指示を含むイベントがあり、 機密ユーザーデータの削除など 別のアクションを実行させます。 大変です！ 脅威モデリングの一部として 信頼されないコンテキストのソースを すべて特定します。 エージェントシステムの第2の特性は アクション呼び出し機能です。 これには潜在的に副作用があります。 アクション実行の 意図しない結果です。

間接プロンプトインジェクションと 組み合わさると、 攻撃者は副作用のあるアクションを 実行させることができ、 目的を達成できます。 ユーザーデータの外部流出や 金銭の窃取、 物理デバイスの制御や データ削除などです。

間接プロンプトインジェクションが 意図しないアクションにつながると、 インジェクションには2つの 異なる効果があります。 第1はデータポイズニングです。 実行されるアクションのパラメータを 攻撃者が操作することです。 例えば ユーザーがお母さんに メッセージを送ろうとするとします。 しかし攻撃者が自分自身へのメッセージ 送信をインジェクトします。

第2はアクションポイズニングです。 攻撃者が実行するアクションを 操作します。 ユーザーはメールの要約を 求めているだけなのに、 攻撃者がLLMを誘導して 悪意あるウェブページを開かせます。 攻撃者が選んだURLにメールを 追加した形でです。

Simon WillisonのLethal Trifectaを 参考にリスクを概念化できます。 ユーザーが最も危険にさらされるのは エージェントシステムが 以下を持つ時です: プライベートデータへのアクセス、 信頼されないコンテンツへの露出、 そして外部通信の能力です。 最後の点はさらに一般化して 副作用を伴うアクションのリスクとして 考えられます。

このセクションをまとめると、 間接プロンプトインジェクションの解決は 強調しておきたい点ですが、 現在も活発に研究されている分野です。 現時点での最善のアプローチは アプリのリスクをどの程度把握するかです。 そしてそのリスクの軽減を目指すことです。

エージェントシステムのリスクを説明したところで、 脅威モデリングの演習を行います。 アプリで実施することで 信頼されないデータソースを特定し、 潜在的にリスクのあるアクションを特定します。 エージェントループの入力のデータフロー分析から始めます。 つまりプロンプトです。 プロンプト構築に使用する データソースを特定します。 この演習では 信頼されないコンテキストの ソースを特定します。 プロンプトインジェクションが 含まれる可能性があるものです。 Loose Leafアプリに戻ると、 プロンプト構築に使われる データソースがいくつかあります。 第1は LLMにガイダンスを提供する指示で、 目的と役割についてのものです。 次はユーザーのプロンプトです。 LLMが取り組むタスクと 達成しようとする目標です。 プロンプトにはLLMの目標達成を助ける 追加コンテキストも含められます。 過去のお茶の注文履歴や ユーザーが保存したお茶のレシピ、 お茶パーティの最適な時間を決めるための 今後のカレンダーイベント、 友達が共有しているコンテンツを 組み込むフレンドフィードなどです。 プロンプトに入力するデータソースを把握したら、 信頼されないと見なされるものを特定します。 一般的なルールとして 外部エンティティからの入力は 攻撃対象として考えることができます。 今回はカレンダーコンテンツを フレンドフィードとともに 信頼されないと特定します。 誰でもユーザーへのカレンダー招待を送ることができ、 それがモデルに入力される 可能性があるからです。 またユーザーの「友達」がフィードに何でも投稿でき、 プロンプトに入力される可能性があります。 実行アクションを操作する インジェクションを含む恐れがあります。

信頼されないコンテキストのソースを特定したら、 エージェントが利用できるアクションを検討します。 そしてそれらの副作用についてです。 まず OrderTeaTool()があります。 お茶パーティのためにお茶を取得する 重要なアクションです。

PostAndFetchPublicFeedTool()は ユーザーのフィードに投稿し、 モデルが生成したメッセージで 友達への告知に役立ちます。

BrewingTimerIntent()は お茶パーティ中に役立ちます。 お茶が適切な時間で 蒸らされるようにします。 最後に Delete Photoは ユーザーのフィードから写真を削除します。 茶葉の見栄えが 良くなかった場合などです。 これらのアクションをすべて考慮する際には、 各アクションの副作用を特定します。

OrderTeaTool()には金銭的リスクがあり、 意図せず呼び出された場合 ユーザーが損失を被る可能性があります。

PostAndFetchPublicFeedTool()は 一方で データ外部流出のリスクがあります。 モデルが公開投稿を通じて 機密情報を漏洩させる可能性があるためです。

BrewingTimerIntent()はそれ単独では 副作用がないかもしれませんが、 ラベルを受け取る場合 プロンプトインジェクションが可能になり、 後続の攻撃のための指示を 書き込まれる可能性があります。

Delete Photoはデータ損失リスクがあります。 特に元に戻す機能がない場合は深刻です。

悪意ある入力がLLMに入る場所と アクションが持つ可能性のある副作用を特定したので、 軽減策の設計と実装を開始できます。 ユーザーを保護するためのものです。 決定論的な軽減策に 注力することを強調したいと思います。 セキュリティ保証の監査と推論が 容易なためです。

モデル能力の急速な発展を踏まえ、 確率論的な保証を持つ 他の軽減策も検討できます。 ここではいくつかの軽減策を紹介します。 アプリを保護するために使用できるもので、 プロンプトレベルでのチェックや アクション実行段階でのチェックを追加します。 これらの一部はSiri AIの設計時にも使用しました。 これらを順に見ていきましょう。 まず プロンプトを見直して プロンプトの軽減策を追加します。 機密データを削除できます。 個人識別情報(PII)などです。 過去の注文履歴に保存されている可能性があるものです。 そうすることで機密データがLLMに届かず 外部流出を防げます。 次に スポットライティングを モデルに組み込めます。 このコンテンツが信頼されないと 示すためです。 これは確率論的な軽減策です。 プロンプトインジェクションが スポットライティングを無効化するように 構築される可能性があるためです。 それでも組み込むことをお勧めします。 異なるモデルがこれらの制限を より効果的に適用できるためです。

では 実装できるアクションの軽減策を 確認してみましょう。

ユーザー確認が必要な アクションを検討します。 続行前に人間が確認する価値がある アクションです。 含まれる副作用があるためです。 次に デバイスが認証済みの場合に またはロック解除時にのみ 動作するツールを検討します。 エージェントはロック画面から アクセス可能なため、 ユーザーへの重大なリスクがあるアクションは アクセスできないようにすべきです。

さまざまな種類の軽減策を 説明してきました。 システムへの適用方法とともに、 他にも多くの種類の軽減策が存在するので、 ぜひそれらを探求していただきたいです。 アプリのリスクを軽減するためです。

脅威モデリングで覚えておくべき重要なこと: 攻撃者がアプリから何を望んでいるかを特定し、 プロンプトレベルのリスクに対処する 軽減策を適用することです。 またはアクション実行段階でのリスクにです。 ではAkshayが具体的なツールを紹介します。 アプリを保護するために使用できるものです。 どうぞ Akshay！ ありがとう Willy。

こんにちは Akshayです。 エージェントアプリを保護する方法を Willyが説明したガードレールで ご紹介します。

Foundation Modelフレームワークで アプリを構築している場合は、 エージェント実行にセキュリティチェックポイントを 注入する方法をご紹介します。 エージェントの実行に組み込みます。

App IntentでApple Intelligenceと 統合する場合は、 利用可能なセキュリティ軽減策を 説明します。 Foundation Modelから始めましょう。 Foundation Modelフレームワークは エージェント構築の強力なAPIを提供します。 ライフサイクルイベント モディファイアAPIを取り上げます。 セキュリティガードレールの注入に使用します。 フレームワークの基本的な知識を 前提とします。 詳細については 下記のリンクのトークをご覧ください。 Foundation ModelでLoose Leafアプリ向けの シンプルなエージェントを構築しましょう。 私にはわかりませんが ダージリンティーなしでは エージェントは構築できません。 そこでまず お茶を注文するツールを構築します。 ツールを定義するには Toolプロトコルに準拠します。 ツールの名前、説明、 Argumentsを指定します。 モデルはこのメタデータを使って ツールの目的と呼び出し方を理解します。 次にツールが呼び出された際に 実行される実際のImplementationを提供します。

もう1つツールを定義しましょう。 PostAndFetchPublicFeedToolは メッセージを公開フィードに投稿し、 新たに投稿されたメッセージを取得します。 エージェント構築の次のステップは Profileの作成です。 Profileにはまず モデルのInstructionsを追加し、 先ほど定義したツールも追加します。 次にセッションプロパティを設定します。 使用するモデルなどです。 ここではオンデバイスモデルを使用します。

このProfileを使って LanguageModelSessionをインスタンス化します。 エージェントループ内で使用できます。 基本的なエージェントができたので セキュリティポリシーを注入します。 そのためにライフサイクル イベントモディファイアを使用します。 これらのモディファイアは 決定論的にトリガされるコールバックです。 セッション実行の特定の ライフサイクルポイントでトリガされます。 このライフサイクルイベントを チェックポイントとして使用し、 セキュリティポリシーを実装します。 これらのモディファイアのうち 2つを見ていきます。

シンプルなエージェントループに 戻りましょう。 シシュポスのように LLMは各イテレーションで アクションを出力します。 このアクションはExecutorが実行し、 その出力が次のイテレーションのために LLMに返されます。 第1のモディファイアはツールコールを 実行前にインターセプトします。 これが.onToolCallモディファイアです。 LLMがツールコールを出力すると 必ずトリガされます。 Executorがツールを実行する前です。 重要な点は このコールバックがエラーをthrowすると、 ツールは実行されません。 制御が即座にループに戻ります。 確認を強制するのに最適な場所です。

Loose Leafエージェントに戻ると、 OrderTeaToolには金銭的な影響があり、 それが少し心配です。 そのため常にユーザー確認を 求めたいと思います。 ツールを実行して 支払いを行う前にです。

そのためにProfileに .onToolCallコールバックを追加します。 このコールバックはすべてのツールコールの 前に実行されるため、 まず現在のツールが OrderTeaToolかどうかを確認します。 そうでなければ すぐに返して ツールを実行します。 そうであれば ユーザーに確認を求めます。 ユーザーが確認しない場合 エラーをthrowし、 ツールの実行を停止します。 confirmWithUser()関数は 独自の実装で置き換えてください。 重要な点は 確認ロジックを コードのこの1か所に追加するだけで、 すべてのツールコールを 完全にカバーできることです。 まとめると このモディファイアはすべての ツール実行前に実行されます。 このコールバックが返るまで ツール自体は実行されません。 エラーをthrowすることで ツール実行をブロックできます。 概念的には .onToolCallモディファイアは モデルの出力に対して実行されます。 次に モデルへの入力チェックを助ける モディファイアを見てみましょう。 .historyTransformは トランスクリプトが推論のために モデルにレンダリングされる前に実行されます。 新しいユーザーリクエストが届いた時と ループの各イテレーションで実行されます。 変換はトランスクリプトの末尾を修正します。 スポットライティングとPIIの削除に使用します。 例に戻ると PostAndFetchPublicFeedTool()は 公開フィードから投稿を返します。 攻撃者はそのフィードに プロンプトインジェクションを簡単に投稿できます。 このフィードの出力は 疑念を持って扱う必要があります。 この出力を特別なタグで区切ることで 信頼されないデータであることを モデルに伝えます。

Spotlightingデリミタを追加します。 .historyTransformの内部にです。 コールバックではまずエントリをイテレートし、 ツールからのtoolOutputエントリに 集中します。 他のすべてのエントリは 未修正のまま出力トランスクリプトにコピーします。 次にtoolOutputエントリを修正します。 セグメントをイテレートし 各関連セグメントに対して デリミタタグを追加します。 この例では山括弧 「<>」を使用しています。 モデルに適したタグを使用してください。 delimit()関数の実装は省略しますが、 テキストセグメントをデリミタ付きコンテンツに 変換します。 次は削除(リダクション)を見てみましょう。 実は全く同じアイデアを 機密データの削除にも使用できます。 delimit()関数を 削除関数に置き換えるだけです。 機密データを置き換える関数で、 プレースホルダー文字列リテラル 「」に置き換えます。

重要な点を覚えておいてください。 変換されたエントリのスコープは 現在の推論イテレーションのみです。 これらの変更は次の推論呼び出しには 表示されません。 再度適用する必要があります。 永続化したい高コストの変換には @SessionPropertyアノテーションを使用します。 セッション履歴にステートフルな変換を 適用できます。 詳細はドキュメントをご参照ください。 ライフサイクルイベントモディファイアが どのように セキュリティポリシーを注入するための 決定論的なフックを提供するかを確認しました。 ただし すべてのモディファイアを説明したわけではありません。 フレームワークにはさらに多くのものがあり、 エージェントループの他の重要なポイントで トリガされます。 フレームワークでは独自のプロファイル モディファイアも構築できます。 再利用可能なコンポーネントとして パッケージ化できます。 Foundation Modelのドキュメントで これらについて詳しく確認してください。 他にも多くの強力な機能があります。

ではApp Intentの話に移りましょう。 App Intentを使用すると アプリをApple Intelligenceと統合できます。 Siri、Spotlight、ショートカットなど 豊かなシステム体験と連携できます。 このトークの残りでは App IntentとApp Schemaの 基本的な知識を前提とします。 詳細は下記リンクの 優れたセッションをご確認ください。 簡単に復習すると App Intentが インテントスキーマを採用すると、 Siriモデルのツールとして 利用可能になります。 例えば DeletePhotoIntentは photosドメインのdeleteAssetsスキーマを 採用しています。 概念的には Delete PhotoアクションがSiriの ツールボックスに追加されます。 これによりSiriがツール定義を 推論できるようになり、 ユーザーのクエリに応じて呼び出せます。 ただし どのインテントを呼び出すかを 決定するのはモデルのため、 プロンプトインジェクション攻撃によって 攻撃者がアプリを悪用できます。 データ外部流出や その他の悪意ある目的のためにです。 例えばここでは 外部コンテキストで実行しており、 ユーザーの意図なしに Delete Photo機能を実行しようとする可能性があります。 このような攻撃が成功し、 決定論的なガードレールがなければ、 Willyの強い警告にもかかわらず データ損失の 現実的なリスクがあります。 外部から見える副作用があるか 破壊的なアクションは 攻撃者にとって魅力的な標的です。 App Intentシステムには いくつかのガードレールがあります。 デベロッパがこのような攻撃を 軽減するためのものです。 ここでは確認とロック画面認証の 2つを見ていきます。 確認から始めましょう。 システムはリスクベースの コンテキスト確認メカニズムを使用します。 アプリの高リスクなアクションに対して 確認を自動的にトリガします。 アクションのリスクは静的なアクション メタデータを考慮して決定されます。 そしてシステムの動的な状態もです。 インテントが選択されると 実行前に システムがインテントのリスク メタデータでリスク評価システムを呼び出します。 このメタデータについては後で説明します。 リスク評価コンポーネントは システムの動的状態も入力として受け取ります。 両方を組み合わせて インテントの全体的なリスクを判断します。 リスクが高いと判断された場合 ユーザーに確認が求められます。 ユーザーがアクションを確認すると 通常の制御フローが続き、 インテントが実行されます。

一方 ユーザーが拒否すると 実行がブロックされ インテントは呼び出されません。 リスクメタデータに戻りましょう。

リスクメタデータはすべてのインテントに 割り当てられた内部リスクデータです。 インテントの副作用に基づいています。 特定の副作用は 他のものよりリスクが高いとされます。 例えば デバイス状態を削除するインテントは DeletePhotoIntentなど 高リスクとみなされます。 データを外部流出させるインテントも 破損したコンテキストで実行されると 損害を引き起こす可能性があります。 共有コンテンツを操作する 更新インテントもリスクがあります。 システムは高リスクのツールに対して 確認をトリガしやすくなっています。 では リスクメタデータは App Intentとどのように関連するのでしょうか

リスクメタデータはインテントがスキーマを採用すると 自動的に割り当てられます。 追加の作業は不要です。 技術的には リスクメタデータを持つのは スキーマ自体です。 例えば deleteAssetsスキーマは 写真の削除に使用されます。 そのため破壊的な副作用があります。 DeletePhotoIntentも この破壊的な副作用が割り当てられます。 ただしリスクは微妙です。 お茶の蒸らしタイマーを設定する 新しいインテントを定義しましょう。 このインテントはcreateTimerスキーマを採用します。 このスキーマのリスクについて どう思いますか。 表面上は タイマーを作成しても 攻撃者が大きな損害を与えられないように見え、 このアクションの確認は 不要かもしれません。 しかし詳しく見ると スキーマには タイマーのラベル用のオプションのString プロパティが定義されています。 インテントの引数を決定するのは モデルであることを 思い出してください。 プロンプトインジェクションによってこのラベルが 攻撃者が制御する値に設定される可能性があります。 タイマー一覧を取得する後続のクエリで 攻撃者が制御するデータが そのコンテキストに混入し 新しいコンテキストも汚染されます。 createTimerのような場合に 確認を完全にスキップするのは 安全ではありません。 システムはこのような中間的な 状況を理解しています。 ここで先ほど説明した システムの動的状態が役割を果たします。 この情報は現在のシステムコンテキストで 確認が必要かどうかを判断するために使用され、 現在のシステムコンテキストで アクションの動的リスクを 捉えます。 まとめると 確認システムは コンテキストに基づくリスクベースです。 インテントは採用するインテントスキーマから 副作用を継承します。 リスクのある副作用があるアクションは 確認されやすくなります。 次にロック画面認証を見てみましょう。 ご存知のように ロック画面でSiriと 会話できます。 デバイスのロックを解除せずにです。 素早いタスクを実行するのに便利です。 手がふさがっている時にも役立ちます。 ただし ロックされたデバイスを物理的に 所持する攻撃者が Siri経由でインテントを 呼び出せる可能性があります。 注意しないと このような攻撃者がアプリを使用して データ外部流出や 悪意あるアクションを実行できます。 このような脅威への主な対策は リスクのあるアクションを実行する前に ユーザーにデバイスのロック解除を 求めることです。 App Intentで認証ポリシーを定義する方法を 見てみましょう。 カスタムのApp Intentでは authenticationPolicyプロパティを設定することで 認証動作を 明示的に設定できます。 例えば DeletePhotoIntentは 破壊的なので、 ロックされたデバイスで 実行されないようにします。 そのため authenticationPolicyプロパティを 明示的に設定します。 .requiresAuthenticationに設定します。 @AppIntentがインテントスキーマを採用する場合は 状況が少し異なります。

スキーマには独自のデフォルト authenticationPolicyがあります。 このポリシーは各スキーマの機密性と 扱うデータに基づいて 内部的に設定されます。 副作用と同様に インテントにはスキーマのデフォルトポリシーが 自動的に割り当てられます。 ただし必要に応じて デフォルトを明示的にオーバーライドできます。 唯一の制約は ポリシーをより厳格にすることです。 例えば deleteAssetsスキーマのデフォルトポリシーが .requiresAuthenticationだとします。 ここでポリシーを明示的に設定しない場合、 @AppIntentに同じポリシーが割り当てられ、 実行前に認証が 必要になります。

より弱いポリシーを設定しようとすると、 ビルドエラーが発生して 許容される最小ポリシーを 親切に教えてくれます。 まとめると 認証はロック画面攻撃への 重要な軽減策です。 スキーマには独自のデフォルト認証ポリシーがあり、 App Intentに割り当てられます。 スキーマポリシーはオーバーライドできますが より厳格にする場合のみです。 ロック画面の動作を念頭に置いて インテントを見直してください。 Willyに戻します！ 素晴らしい内容でした Akshay！ まとめると エージェントアプリの 次のステップは 脅威モデルを作成することです。 プロンプト内の信頼されない コンテキストのソースを見つけ、 各アクションのリスクレベルを 判断することが必要です。 副作用に基づいてです。 Akshayのガイダンスにより いくつかのステップが明確になりました。 アプリに最適な軽減策を 実装する方法です。 Foundation Modelレームワークと App Intentフレームワークを使用します。 さあ基準を高めて 防御をすばやく注入しましょう！