デジタルガーデン

最近の更新

OSSエージェントハーネスのセキュリティ

Properties4
typeconcept
confidencemedium
statusdraft
descriptionOpenCodeやDeepSeek HarnessなどOSSのAIエージェントハーネスが持つ攻撃面と、信頼境界・間接プロンプトインジェクション・スキル供給網・自動承認モードのリスクを整理する。

9 min read

概要

AIコーディングエージェントや自律エージェントは、LLMそのものだけで動いているわけではない。モデルに「何を見せるか」「どんなツールをどう呼ばせるか」「どこまで実行を許すか」を決める ハーネス（Harness） という実行基盤が、モデルとファイル・シェル・ネットワークの間に挟まっている。

OpenCode、Cline、DeepSeek Harness（DSH）など、このハーネスの多くはOSSとして公開されている。中身を監査でき、ベンダーにデータを預けずに済むという利点がある一方で、信頼境界（trust boundary）の実装点がハーネス側に集約されているため、設定や設計を誤ると一気に攻撃面が広がる。

本ノートでは、OSSハーネスを使ううえで押さえるべき論点を整理する。モデル側の話は 中国製LLMのセキュリティとオンプレ運用、外部Webを読ませるリスクは Web検索・Web取得を介したプロンプトインジェクションと情報漏洩 を参照。

ハーネスが決めていること

ハーネスの役割は、おおまかに次の要素で構成される。

  • システムプロンプトとツール定義: どのツールをどんなJSONスキーマで見せるか
  • コンテキスト管理: 何を読ませ、何を記憶し、履歴をどこまで積むか
  • ツール実行: read / write / edit / bash / webfetch などの実行
  • 権限・承認ゲート: allow / ask / deny の制御
  • サンドボックスと外部送信（egress）の制御

攻撃者にとっては、モデルを説得するよりも ハーネスの実行経路に untrusted な指示を流し込む 方がはるかに現実的である。ここが本ノートの出発点になる。

主要な攻撃面

1. 間接プロンプトインジェクション（Indirect Prompt Injection）

エージェントが読むファイル・Issue・メール・Webページなどに攻撃命令を仕込み、本来の目的から逸脱させる手法。モデルは「システムからの指示」と「取得したただのコンテンツ」を本質的に区別できないため、外部コンテンツがそのまま行動指示として作用しうる。

Tencent Zhuque LabによるDeepSeek Harness（OSSのプラグイン型エージェントフレームワーク）の評価では、通常のコンテンツ読取経路だけで、テキストモードでの偽完了攻撃が攻撃成功率17.0%、ファイルモードの不可視Unicode混入が25.5%、スキル経由が16.0%に達したと報告されている（攻撃先はサンドボックス化された安全な擬似シンク）。

2. ツール実行と信頼境界

ハーネスはツール結果をそのままコンテキストに戻す。このとき、untrusted なコンテンツが「ツール結果」という信頼できる形式に昇格してしまうと、権限ある操作（書き込み・外部送信・コマンド実行）に直結する。ファイル読取1つとっても、入力元がローカルか外部取得かで危険度はまったく異なる。

3. スキル・プラグインの供給網

Markdownなどで配布される「スキル」やプラグインは、第三者が自由に作れる拡張点である。

  • 白背景に白文字、1ptフォント、行間0.1などで 不可視の命令 を埋め込む手口が知られており、ユーザーは中身を精査せずスキルを取り込みがちである。
  • 命令を暗号・エンコードして隠す Ciphered Skill Injection では、最大47.5%／40.3%の攻撃成功率が報告され、既存のスキルスキャナはこうした注入をほとんど検知できなかったという。
  • HarnessRisk や SkillSafetyBench のように、ハーネスそのものの安全性を評価するベンチマークも登場している。

「スキャナが通したから安全」とは言えない点に注意したい。

4. 永続状態への注入（Cross-Session Stored Prompt Injection）

エージェントがメモリ・ファイル・ベクトルストアなどの セッションをまたいで残る状態 を持つようになると、注入は一度きりの攻撃では終わらない。悪意ある指示が永続状態に保存され、元の攻撃者が去ったあとの将来の実行で発火する。XSSにおけるstored XSSのアナロジーで、入力フィルタより 状態のガバナンス が本質的な課題になる。

5. モデルファイル・ランタイム依存の供給網

OSSハーネスはモデル重みや多数の依存を外部から取り込む。

  • 従来の pickle 形式のモデルファイルは、重みだけでなく 実行コード も格納できるため、読み込むだけで任意コード実行につながりうる（Hugging Face等で悪意あるpickleの報告が続く）。safetensors への移行が緩和策となる。
  • 正当な機能に見せかけた微調整モジュール（LoRA）を適用させ、バックドアや情報流出機構を仕込む「LoRA-as-an-Attack」も報告されている。

6. YOLO（自動承認）モード

--auto や permission: allow による自動承認は、利便性と引き換えに 間接プロンプトインジェクションの最終防波堤（人間の承認）を外す。明示的な deny だけは残るが、それ以外の ask がすべて allow になるため、上記の攻撃が「確認待ち」で止まらず素通りしやすくなる。

運用の観点

  1. 承認ゲートを安易に外さない: 特に bash・外部送信・ファイル書込みは ask を維持する。YOLOは隔離された使い捨て環境に限定する。
  2. サンドボックスと egress 制御: コンテナ分離、ネットワーク許可リスト、外向き通信の監視で「持ち出し先」を塞ぐ。
  3. プロベナンス（由来）の記録: どの指示・リンク・文書に由来して行動したかを記録し、信頼できるユーザー意図と敵性入力を切り分けられるようにする。
  4. スキル・プラグインは出所とレビューを徹底: 信頼できる配布元のみ。スキャナ依存は危険。
  5. バージョン固定と変更レビュー: OWASPは、エージェントの挙動を変えるPRと同時にセキュリティテストを弱体化させる攻撃を警戒するよう求めている。テストも差分レビューの対象にする。

まとめ

OSSハーネスのセキュリティは「モデルが賢いかどうか」では決まらない。untrusted なコンテンツが、権限ある行動へと変換されるのを止められるか で決まる。だからこそ、ハーネス側の承認ゲート・サンドボックス・egress制御・プロベナンスといった「地味な制御」が主役になる。

関連ノート

参考資料

最近の更新

グラフビュー

バックリンク

目次