アプリは一度も開かれていなかった

実際のモバイルセキュリティテストにエージェント型ハーネスが欠かせなくなりつつある理由

言語モデルにモバイルアプリを渡し、セキュリティをテストするよう依頼してみてください。

返ってくる答えは見覚えのあるものかもしれません。安全でないストレージ、脆弱な暗号、露出したシークレット、過剰な権限、脆弱なSDK、バックエンドの問題、認証の不備、プライバシーのリスクです。

レポートのように構成されているかもしれません。適切なカテゴリに言及しているかもしれません。セキュリティチームがそのまま回覧できそうな内容に読めるかもしれません。

それでも、アプリはまだ一度も開かれていません。

パッケージは調べられていません。権限が実行時の挙動と照らし合わされたこともありません。SDKのトラフィックも観察されていません。ストレージの場所もレビューされていません。バックエンドへの呼び出しも追跡されていません。クラッシュ時の状態も取得されていません。エビデンスは何一つ受け渡されていません。

レポートは存在しました。しかし、対象の状態は何も変わっていませんでした。

手を持たない推論エンジン

セキュリティにおけるAIをめぐる議論の多くは、今もモデルから始まります。どのモデルが賢いか、どのモデルがより優れた推論をするか、どのモデルのコンテキストウィンドウが長いか、どのモデルがベンチマークで最高の成績を出すか、といった議論です。

実際のセキュリティワークフローでは、モデルはシステムの一部にすぎません。

素のモデルでも、指示を理解し、仮説を立て、攻撃経路を説明し、次に何をすべきかを判断することはできます。しかし、対象をテストするには、対象に実際に触れる必要があります。アプリを展開しなければなりません。権限をレビューしなければなりません。SDKを特定しなければなりません。ストレージを調べなければなりません。トラフィックを観察しなければなりません。認証フローをテストしなければなりません。バックエンドへの呼び出しを追跡しなければなりません。ノイズの多い手がかりは捨てなければなりません。そして、残った検出結果は、一段落の文章よりも確かなものによって裏付けられていなければなりません。

モデルの周囲には、こうした手順を可能にするツール、コンテキスト、プロンプト、スキル、メモリ、実行ループ、フィードバックが配置されています。

モデルがアプリに触れられるとき

モデルは「機密データの保存」という言葉を見て、何を確認すべきかを説明できます。SharedPreferences、ローカルデータベース、キャッシュファイル、キーチェーンの使用、暗号化、ログです。言葉としては正しいのですが、アプリは依然としてブラックボックスのままです。

ハーネスを備えたワークフローでは、アプリが展開されます。ストレージの場所が調べられます。設定ファイルが開かれます。実行時の挙動が観察されます。ある値はディスク上に現れるか、現れないかのどちらかです。懸念はエビデンスを得るか、消えていくかのどちらかです。

SDKについても同じことが起こります。

モデルは、サードパーティSDKがプライバシーの露出をもたらす可能性があると警告できます。その警告は聞き慣れたものなので、役に立つように聞こえます。しかし、SDKは特定されていません。その通信先は観察されていません。その権限は実際のトラフィックと比較されていません。ペイロードも一つとして調べられていません。

すると、問いが変わります。もはや「これはリスクになり得るか」ではありません。問いは、何が存在し、何が実行され、何がアプリの外に出ていき、それにどのようなエビデンスが付いているのか、となります。

Anthropicは、長時間稼働するエージェントの作業において同じパターンを示しています。モデルが単独で改善したわけではありません。プロンプト、ツール、コンテキスト管理、フィードバックループといった、モデルを取り巻くワークフローも変わったのです。OpenAIのハーネスエンジニアリングに関する記事も、エージェントを取り巻く同種の作業を指摘しています。受け入れ基準、検証、不足しているツール、ガードレール、ドキュメントです。

これらの例はソフトウェアエンジニアリングに関するものです。モバイルセキュリティでは、同じパターンが成果物、実行環境、ツールの出力、そしてモデルが次に実行できるテストを中心に現れます。

洗練された回答であっても、アプリには一切触れていないことがあり得ます。

ツール箱はハーネスではない

エージェント型セキュリティには、安易なやり方があります。モデルにツールの山を与え、それをエージェントと呼ぶのです。

生の出力が大量にコンテキストへ流れ込みます。早い段階から多すぎるツールが使える状態になります。スキャナーの結果が十分な解釈を伴わずに届きます。弱いシグナルが自信に満ちた検出結果になります。疑わしい文字列がシークレットになります。権限がプライバシー侵害になります。見慣れないエンドポイントが悪用可能なバックエンドの問題になります。

有用なハーネスは、もっと控えめです。モデルが最初に何を見るか、次のステップにどのツールが属するか、何を記憶すべきか、そして何かが検出結果になる前にどの程度のエビデンスが必要かを決めます。

モバイルセキュリティでは、ほぼすべてのシグナルにそうしたコンテキストが必要です。権限があるからといって、自動的にプライバシーの問題になるわけではありません。サードパーティSDKが自動的に悪意あるものになるわけではありません。保存された値が自動的に機密情報になるわけではありません。疑わしいリクエストが自動的に悪用可能になるわけではありません。

権限は検出結果ではない

位置情報へのアクセスを例に取りましょう。

モデルは、位置情報へのアクセスがなぜプライバシーリスクを生み得るのかを説明できます。それは有用な背景知識です。しかし、検出結果ではありません。

権限は実行時に確認しなければなりません。SDKを特定しなければなりません。トラフィックを観察しなければなりません。通信先のドメインをレビューしなければなりません。ペイロードを調べなければなりません。アプリが宣言している目的と、アプリが実際に送信している内容を比較しなければなりません。

そうして初めて、問いが意味を持つようになります。

位置情報はいつ収集されるのか。どのコンポーネントが収集するのか。どこへ送られるのか。識別子と一緒に送信されるのか。分析SDK、広告SDK、バックエンドのエンドポイント、あるいはユーザーが実際に起動した機能のいずれに結び付いているのか。

外から見ると、アプリは一つのまとまりに見えていました。調べていくと、それはコード、権限、SDK、ストレージ、トラフィック、バックエンドへの呼び出し、プラットフォームの挙動という層になっていきます。

カテゴリは最初から見えていました。検出結果が現れるのは、エビデンスが動いた後だけです。

GEFがハーネスを具体的なものにする

同じパターンは、ネイティブコードの悪用においてさらに分かりやすく見えます。

汎用のLLMは手順を説明できます。ネイティブライブラリをリバースエンジニアリングし、安全でない算術演算を調べ、クラッシュのトリガーを作り、レジスタを確認し、プリミティブを洗練させる、という手順です。方法論が正しくても、対象には一切触れていないことがあり得ます。

あるAndroid JNIのケースでは、モデルがGDBを基盤とするエクスプロイトツールであるGEFに接続されていました。

エージェントはネイティブライブラリをリバースエンジニアリングし、画像サイズの計算において64ビットから32ビットへの整数の切り詰めを発見しました。切り詰められた値がヒープの割り当てサイズを決めていました。元の64ビットの値がコピーの長さを決めていました。

割り当てはコピーよりも小さかったのです。

入力が細工されました。クラッシュが再現されました。間接関数ポインターが、識別可能な64ビットのマーカーで上書きされました。そのマーカーがクラッシュ時の状態に現れました。

このプリミティブは、攻撃者が制御する最初の引数を伴う、制御されたネイティブ関数呼び出しへと洗練されました。実行はAndroidのネイティブライブラリローダーへとリダイレクトされました。専用に作成された共有ライブラリが、アプリケーションのプロセス内で実行されました。

ログには実行の記録が残りました。ライブラリの初期化ルーチンが実証用の成果物を作成しました。

この経路は「ヒープオーバーフローの可能性」で止まりませんでした。計算、割り当て、クラッシュ、制御、呼び出しプリミティブ、ローダー、実行、実証と、対象の中を進んでいったのです。

推論を提供したのはモデルです。その推論を実行中のプロセスに結び付けたままにしたのはGEFでした。

作業はレビュー可能でなければならない

エージェントが行動できるようになると、別の問いが生まれます。

何を調べたのか。どのツールの出力が結論を変えたのか。どのようなエビデンスが収集されたのか。どのような前提が置かれたのか。調査はどこで止まったのか。

攻撃的セキュリティやモバイルテストにおいて、検出結果が役に立つのは、システムがどのようにしてそこに到達したのかを誰かが理解できる場合だけです。エージェントが機密データの露出を報告するなら、レビュー担当者にはその経路が必要です。アプリの挙動、ストレージの場所またはリクエスト、ペイロード、影響を受けるデータ、そしてエビデンスと検出結果を結び付ける推論です。

エージェントが何かを報告しないと判断した場合も、その判断には経路が必要です。権限は宣言されていたものの一度も使われていなかったのかもしれません。SDKは存在していたものの動作していなかったのかもしれません。エンドポイントは見慣れないものだったものの、機密性の高い挙動を露出させてはいなかったのかもしれません。

悪用についても同じです。エージェントがコード実行を主張するなら、レビュー担当者に「悪用に成功した」という一文だけが残されるべきではありません。脆弱な計算から実行時の実証に至るまで、エビデンスの連鎖が見えている必要があります。

そうした可視性がなければ、出力を擁護することは難しくなります。正しいかもしれませんが、チームには追跡できる記録がありません。間違っているかもしれませんが、それでも説得力があるように見えるほど流暢な形で届くかもしれません。

ハーネスは、何が起きたかを記録します。権限、ツールの境界、承認ポイント、エビデンスのログ、再現可能な手順、そして停止条件です。

調査するのはエージェントです。それでもチームには、その調査が見えている必要があります。

レポートの体裁をしたテキストから、擁護できるテストへ

モデルはもはや、確認すべき項目を列挙するだけではありません。アプリのエビデンス、ツールの出力、実行時の挙動、トラフィック、依存関係のシグナル、悪用のトレース、再現可能な手順を順に処理していきます。一つのステップの結果が、次のステップを変えます。

出力の形も変わります。より整ったチェックリストの代わりに、対象を貫く経路があります。もっともらしい段落の代わりに、レビュー担当者が調べられる成果物があります。「これはリスクになり得る」の代わりに、異議を唱えることのできる連鎖があります。

セキュリティチームは成果物を開くことができます。トレースを追うことができます。手順を再現できます。実行時の実証を調べられます。

ペンテスターのように語るモデルではありません。

ペンテスターの検証にも耐えるトレースです。