AIエージェント技能とiOSアプリで認証情報漏えい、Wake Forest大が大規模調査

AIを組み込んだアプリや、再利用可能なエージェント技能（skill）の普及に伴い、APIキーやトークンが「見える場所」に置かれるリスクが急速に広がっている。Wake Forest大学の研究では、17,022件のサードパーティー製エージェント技能を調査した結果、520件に計1,708件のセキュリティ問題が確認された。関連するiOSアプリの調査でも、LLM機能を持つ444件のうち282件が、認証情報またはバックエンドへのアクセス経路を露出していた。124

問題は、文字列としてキーが漏れることだけではない。流出したキーやトークンによって、非公開データ、エージェントの権限、開発者アカウントで実行される有料のモデル推論まで、攻撃者に利用される可能性がある。

エージェント技能17,022件で見つかった問題

研究チームは、オープンソースの技能マーケットプレイスSkillsMPに登録された170,226件のアーティファクトから、17,022件を抽出して調査した。検査には、正規表現やAST解析による静的な秘密情報検出、ダミー認証情報を使ったサンドボックスでの動的テスト、技能の説明と実際の実行内容の照合が用いられた。34

確認された主な結果は次の通りだ。

• 520件の技能で、10種類の認証情報漏えいパターンに分類される1,708件のセキュリティ問題が見つかった。416
• 520件のうち466件は、特権を追加で取得しなくても利用できる認証情報を露出していた。研究では、**即時悪用可能率89.6%**と報告されている。14
• 漏えい事例の**76.3%**は、プログラムコードだけでなく自然言語の指示も合わせて調べなければ発見できなかった。
• **3.1%**は、実行可能なコードを使わず、自然言語によるプロンプトインジェクションだけで発生していた。4

つまり、従来型の「コードだけを読む」レビューでは不十分な場合がある。正当な目的に見える説明文でも、指示や補助スクリプトが実行時に秘密情報を露出させる可能性があるためだ。

デバッグ出力がモデルに読まれる危険

特に重要な漏えい経路が、デバッグログだった。エージェント基盤によっては、標準出力がそのままモデルのコンテキストに渡される。その場合、print や console.log で出力された認証情報が、通常の自然言語による要求を通じてモデルや利用者から取得可能になる。研究概要では、標準出力を通じたLLMへの露出が漏えいの73.5%を占め、デバッグログが主要な経路とされている。4

リスクは、ソースコードにハードコードされたAPIキーに限らない。スクリプト、環境変数の扱い、ログ、プロンプト指示、そしてコードと自然言語の組み合わせによって、通常の実行中に認証情報が露出することもある。

悪意ある開発者だけが原因ではない

研究は、認証情報漏えいの原因を大きく2つに分けている。

• 悪意ある開発：認証情報や非公開データを収集し、場合によっては外部サーバーへ送信する指示やペイロードを、技能に意図的に組み込む。
• 不注意による開発：安全なコーディングや秘密情報管理を徹底しなかった結果、認証情報やアクセス経路を攻撃者が利用できる状態にしてしまう。1

この違いは対策にも関わる。悪意あるコンテンツには審査と削除が必要だが、意図しない露出には、より安全なログ設計、認証・認可、秘密情報の管理、配布前のテストが欠かせない。

研究チームがSkillsMPに報告した後、Wake Forest大学は、特定された悪意ある技能をすべて削除し、脆弱な技能の大半を修正したと説明している。ただし、元のリポジトリを修正するだけでは不十分だ。フォークされた複製には、修正前の認証情報が残り続ける可能性がある。14

iOSアプリではLLMアカウントの乗っ取りにつながる可能性

別の研究では、LLM機能を搭載したiOSアプリ444件を調査。そのうち282件、約64%が、ネットワーク通信中に悪用可能なLLM認証情報またはバックエンドへのアクセス手段を露出していた。25

報告された主なパターンは次の通りだ。

• 再利用可能なJWTベースのトークン：48%
• 認証不要のバックエンドプロキシ：33%
• APIキーの平文送信：19%3

これらは、アプリを通常利用している際の通信を観察するだけで見つかる場合がある。攻撃者がキーを取得したり、トークンを再利用したり、公開されたプロキシを発見したりすると、開発者のLLMアカウントを経由してリクエストを送信できる可能性がある。その結果、有料の推論処理や関連するクラウド資源を不正利用され、身に覚えのない利用料金が発生しかねない。25

アカウントの上限額や侵入が続く期間によっては、請求額が深刻な水準、あるいは実質的に制御不能な水準まで膨らむ可能性がある。一方、提供された証拠だけから、「数十万ドルの損失が発生した」といった具体的な金額を独立に裏付けることはできない。正確には、漏えいした認証情報が、開発者アカウント上で大規模な課金対象利用を可能にするリスクがある、ということになる。

修正の進み方も遅かった。責任ある情報開示から3か月後の追跡調査では、影響を受けたiOSアプリのうち修正済みだったのは28%にとどまり、72%はなお悪用可能な状態だった。311

AI機能の追加で広がる攻撃面

2つの研究を合わせると、AI機能の追加やエージェント技能の導入は、単なる機能拡張ではなく、アプリの攻撃対象領域を広げる行為だと分かる。具体的には、次のようなリスクがある。

• アプリ本体やエージェントのコンテキストに埋め込まれたプロバイダーキー
• ファイル、外部サービス、非公開データにアクセスできる高権限ツール
• モデルが読み取れるコンテキストに意図せず取り込まれるログ
• 十分な認証なしにリクエストを受け付けるバックエンド
• 攻撃者が再利用できるトークン
• 開発者アカウントで発生するLLM利用料金

AIにコード生成や統合を任せる「バイブコーディング（vibe coding）」が広がるほど、実装速度が脅威モデルの検討に取って代わらないよう注意が必要になる。認証、秘密情報の扱い、認可、ログ、依存関係の確認は、生成コードであっても人間が意図的に設計・検証しなければならない。

エージェント技能の研究では、ハードコードされた認証情報を含む事例の72%に、AI支援開発の痕跡が見られたとも報告されている。これは、生成されたコードや短期間で組み立てられたコードに含まれる安全でないパターンが、規模を伴って拡散する可能性を示唆する。4

研究結果が示す「セキュリティ・バイ・デザイン」

AI製品を開発するチームやエージェント技能を配布するプラットフォームにとって、研究結果から導ける基本的な対策は明確だ。

1. 長期間使うプロバイダーキーをクライアント端末やモデルのコンテキストに置かない。 機密性の高いモデル呼び出しは、認証済みのサーバー経由にする。
2. 短期間かつ用途を限定した認証情報を使う。 最小権限を適用し、トークンを持っているだけで認可済みとみなさず、内容と有効性を検証する。
3. ログと標準出力から秘密情報をマスキングする。 エージェントのコンテキストに渡った情報は、モデルや利用者から回収され得るものとして扱う。
4. コード、設定、プロンプト、依存関係を横断して秘密情報をスキャンする。 エージェント技能の調査結果は、自然言語の指示と実行コードを一体でレビューする必要性を示している。
5. ネットワーク通信とバックエンドの認可をテストする。 傍受されたリクエストを再利用できないか、認証不要のプロキシとして悪用できないかを確認する。
6. 露出した認証情報をローテーションし、フォークや複製も確認する。 元リポジトリから秘密情報を削除しても、配布済みのすべての版が修正されたとは限らない。
7. 配布前にプラットフォーム側の審査を行う。 マーケットプレイスの検査、開発者向けガイダンス、責任ある情報開示、自動チェックを組み合わせる。34

結論はシンプルだ。AIのセキュリティ対策を、製品のリリース後に追加するだけでは遅い。認証情報、エージェントの権限、モデルのコンテキスト、利用料金の制御は、企画と設計の段階から製品セキュリティの中核として扱う必要がある。