2026年DeepSeek Harness提示注入研究発表後にすべきことは？

📋 目次

2026年8月17日に提出された研究では、DeepSeek Harnessを14,560回の管理下実行で評価しています。これは外部コンテンツから敏感なツールへ至る経路を、あなたのチームが直ちに絞るべき根拠になります。ただし、論文の攻撃成功率をすべての環境へそのまま当てはめてはいけません。まず不可信な入力を隔離し、敏感な操作を独立承認に切り替え、自分のバージョンと設定で代表ケースを再実行してください。(arXivの論文本文と版履歴)

症状： Webページ、ファイル、Skills、MCPの内容を読んだAgentが、命令の出所を区別しないままツール実行へ進む。
最短解決策： 高リスク経路だけを先に止め、モデルの判断とは別に承認・権限・監査を置きます。

この内容は、Webページ、文書、ログ、コードコメントを読んだ後にツールを呼び出すAgent開発者向けです。安全担当者は研究結果を統制へ変換し、技術責任者は試験継続、機能制限、権限付き導入の延期を判断できます。

最終更新：2026年8月19日。論文本文、版履歴、公開再現コード、DeepSeek Harnessの対応コミットと最新Releaseを確認しています。論文は2026年8月17日のv1提出後、2026年8月18日にv2へ改訂されています。(arXivの版履歴)

発表当日：研究結果と自社の脆弱性を分けて読む

まず確認すべきなのは、研究が「DeepSeek Harness全体」を無条件に調べたものではない点です。対象は特定のDeepSeek Harness修訂、特定のモデルバックエンド、1つのAgent人格、追加のプロンプト強化を有効にしていない基準設定です。さらに、ソースツールと敏感なシンクはローカルの検証用器具で、実際のメール送信、コマンド実行、資金移動などの外部副作用は発生しない設計でした。

数値として確認できるのは、16種類の間接コンテンツ経路、テキストとファイルの搬送形式、35種類のペイロード目的、12種類の攻撃手法、未変更の基準設定を含む14,560回の管理下実行です。代表的な結果は、テキスト形式の偽完了攻撃でLLM判定17.0％、ファイル形式の隠しUnicodeでルール判定25.5％、ファイル形式のSkills経路でルール判定16.0％でした。これは「その設定で試行された挙動」の記録であり、すべての導入環境における通用脆弱性率ではありません。(研究の測定条件と結果)

ここでの評価は次のように分けます。

研究から直ちに採用する判断： 外部コンテンツと敏感な操作の間に、追加の制御を置く。
研究からは判断できないこと： 自社のモデル、コミット、Skills、MCP、承認設定で同じ割合になるか。
運用上の危険： モデルが「これはユーザーの命令ではない」と認識しても、最終的なツール権限が別経路で残っていれば副作用を止められないこと。

「DeepSeek Harness提示注入研究は安全ではないのか」という問いへの答えは、高リスク経路には不十分な防御が残る可能性を示したが、製品全体の安全性を一言で断定する研究ではないです。

第一日：全面停止ではなく、外部内容から敏感な操作を切り離す

最初に止めるのは、DeepSeek Harnessそのものではありません。Web閲覧、メール本文、取得文書、共有ログ、Skills、MCPの戻り値、コードコメントなどを読んだ直後に、確認なしで次の操作へ進める経路です。

優先して制限する操作は、次の3群です。

シェルコマンド、パッケージ導入、設定変更。
ファイルの新規作成、上書き、削除、認証情報を含む読み出し。
メール送信、IssueやPull Requestの送信、外部APIへの登録や更新。

一方、読み取り専用のローカル資料の要約や、外部副作用を持たない計画作成まで一律に停止する必要はありません。ソースと操作を次のように分けると、試験を継続しながら危険な境界だけを狭められます。

低リスク： 信頼済みリポジトリの固定版文書 → 要約、分類、差分確認。
中リスク： 公開Web、共有フォルダー、未知のMCP応答 → 読み取り専用、認証情報なし。
高リスク： 未検証のSkillsや添付ファイル → 敏感なツールを無効化し、手動承認を必須化。
最高リスク： 外部送信、決済、権限変更 → Agentから直接呼び出さず、別の承認者または固定ワークフローへ渡す。

この段階で「研究の成功率が高かったから全機能を止める」と判断すると、検証可能な経路まで失います。逆に「シミュレーションなので無視する」と判断すると、外部内容がコンテキストへ入り、その後の計画やツール呼び出しへ影響する境界を放置します。

「間接プロンプトインジェクション」はなぜSkillsやファイルから伝播するのか

SkillsやWebページが危険なのは、単なる文章だからではありません。Agentにとっては、取得した内容が次の推論材料として同じ会話状態へ入るためです。そこに「この操作を実行してください」「前の承認は完了しています」といった命令風の内容が混ざると、ユーザー指示、システム方針、外部データの境界が曖昧になります。

特にファイル経路では、見た目に表示されないUnicode、メタデータ、変換後のテキスト、埋め込みコメントを確認対象に含めてください。今回の研究でも、隠しUnicodeを使ったファイル形式のケースがルール判定で25.5％と、代表的な高い値を示しています。数字は攻撃成功率の一般値ではなく、論文の管理下設定に限った観測値です。

AI-Infra-Guardは、テスト行列の作成、汚染データの投入、実行トレースの収集、判定までを支援する再現用基盤です。公開コードはAI-Infra-Guardの公開リポジトリで確認できます。論文の数値を自社の結論に置き換えるのではなく、同じ発想で「どの入力がコンテキストへ入り、計画を変え、ツール呼び出しへ進んだか」を記録する用途に使います。

3日目：モデルの警告文より、独立承認と実行ゲートを優先する

システムプロンプトに「外部文書の命令を無視する」と書くだけでは、最終防線として弱すぎます。モデルは外部内容を解釈する主体であり、承認者ではないからです。敏感なツールの認可は、モデルが自分で安全と判定したかどうかから切り離してください。

実装位置は、次のように考えます。

ツール呼び出し前に、入力元、信頼区分、対象資産、操作種別を検査する。
書き込みや送信では、Agentの提案と実行許可を別イベントにする。
承認画面には、外部入力の出所、変更対象、送信先、差分を表示する。
実行環境には、許可された作業ディレクトリ、資格情報の非公開化、ネットワークの許可先制限を設定する。
実行後は、入力からツール結果、承認者、実行結果までを同じ識別子で監査する。

MCPの前段にゲートウェイを置く場合は、ToolGuardの公式ドキュメントにある認証、ポリシー確認、脅威分析、資格情報注入、監査ログという分離モデルが参考になります。これはDeepSeek Harnessの標準設定を意味するものではなく、外部のツール実行経路を独立層で制御する設計例です。

第一週：Skills、MCP、ファイル表現を棚卸ししてから試験を広げる

研究で目立ったSkills経路やファイル経路だけを確認して終わらせないでください。次の情報を資産台帳へ追加します。

Skill、プラグイン、MCPサーバーの所有者。
取得元、固定した版、更新経路。
読み取り対象と書き込み対象。
利用できる資格情報とネットワーク先。
変更時の承認者とロールバック方法。
Markdown、HTML、PDF、画像OCR、アーカイブ展開などの変換経路。

特に確認したいのは、同じ名前のパッケージやCLIを別の配布元から導入していないかです。インストール経路、実行ファイルのハッシュ、対応コミットを固定し、DeepSeek Harnessの公式リポジトリとRelease情報を基準に照合してください。

回帰試験は、実際の顧客ファイルや本番の送信先では実施しません。偽の認証情報、ローカルの受け皿、送信しないモック、書き込み可能範囲を限定した作業ディレクトリを用意します。

初週の可否判定チェック

[ ] DeepSeek Harnessの実行版、対応コミット、モデルバックエンドを記録した。
[ ] Web、文書、メール、Skills、MCP、コードコメントを入力元として分類した。
[ ] 各入力に出所、信頼区分、形式、所有者を付けた。
[ ] コマンド、ファイル書き込み、外部送信、権限変更を敏感な操作として分離した。
[ ] 敏感な操作にモデル単独の承認を許可していない。
[ ] 汚染内容がコンテキストへ入ったかをログで確認できる。
[ ] 汚染内容が計画を変えたかを記録できる。
[ ] ツール呼び出しが発生したか、ポリシーが遮断したかを分けて記録できる。
[ ] 失敗時に同じ環境を破棄し、再現用の隔離環境を作り直せる。

試験拡大前：論文の割合ではなく、自社の4段階ログで判断する

代表ケースを少数選び、実際に使う入力元、Skills、MCP、承認方針を合わせて再実行します。最低限、各ケースで次の4点を別々に記録してください。

悪意のある内容がコンテキストへ入ったか。
Agentの計画や説明が変わったか。
敏感なツール呼び出しが発生したか。
ポリシー、承認、サンドボックスのどこで止まったか。

この4段階のどこで止まったかが分からないと、「ブロックできた」のか「たまたまツールを選ばなかった」のかを区別できません。論文の17.0％、25.5％、16.0％という値は、試験の優先順位を決めるリスク信号として使い、自社の合否判定には使わないでください。

また、2026年8月17日公開のv0.1.0-rc.7を利用している場合は、論文で使われた2026年8月13日のソーススナップショットと同一かを別途確認します。Release名が近くても、ツール呼び出し方針、Skillsの読み込み順、提示境界、初期権限が変わっていれば、研究結果との比較条件は同じではありません。

後続Release：続ける、制限する、延期するを版ごとに更新する

次のReleaseや安全告知が出たら、記事や社内判断を固定文書にしないでください。論文の改訂、公開再現コードの変更、公式コミット、既定権限、ツール実行管路の差分を追い、代表ケースを再実行します。

判断は次の3段階で十分です。

試験継続： 外部入力は記録され、敏感な操作は独立承認または実行ゲートで止められる。
機能制限： 読み取りは許可するが、書き込み、送信、認証情報利用を停止する。
高権限導入延期： 外部入力から敏感な操作までの因果関係を監査できない、または承認をモデルに依存している。

共有ワークステーションや既存CIで急いで再試験すると、権限の残存、資格情報の混入、環境差分、ログ不足が結果を曖昧にします。短期の検証なら、macOSのベアメタルと仮想化環境の違いを確認し、作業単位で分離した実行場所を選んでください。複数のMac実行環境を比較する際は、CPUやメモリだけでなく、作業ディレクトリ、資格情報、ネットワーク許可先、破棄手順まで同じ条件で記録します。継続的に環境を分ける場合も、共有環境の権限と資格情報をそのまま使い回さず、案件ごとに作業場所、承認経路、破棄手順を定義してください。

現在の共有ワークステーションを使い続ける場合、権限が他案件へ引き継がれる、資格情報がローカルへ残る、失敗後の状態を完全に戻せない、チームごとに設定がずれるという欠点があります。対してMacDateのMac環境を一時的な回帰試験用に使えば、案件単位で作業場所を切り替え、実行環境を分けた検証を組みやすくなります。ただし、長期の安定した高負荷処理や物理インターフェースが必要な業務では、自前のMacや専用環境の方が適しています。研究公開後の第一週は、導入を急ぐより、隔離された環境で自社の入力元と権限方針を再現できるかを確認する段階です。