OpenClawのプロンプトインジェクションとは？危険性と対策方法を徹底解説

OpenClaw でいうプロンプトインジェクションとは何か

OpenClaw では外部コンテンツがそのまま文脈汚染の入口になりえます

generic な プロンプトインジェクションとは？ の記事でも、indirect prompt injection は URL、docs、tool metadata のような間接入力から成立すると説明しました。OpenClaw でその危険が高まるのは、gateway が channels、browser / web tools、外部 docs、agent workspace、tool descriptions をまとめて扱うからです。つまり operator が直接書いた指示と、外から取得した content が近い位置で処理されるため、外部コンテンツの汚染を運用設計で抑えないと境界が曖昧になります。

OpenClaw 公式の security docs でも、何が利用主体の信頼境界で、何が未信頼の channel / content なのかを明確にする前提が繰り返し出てきます。web tool docs が示すように OpenClaw は Web 取得や browser control に近い経路を持てるので、URL 先の content や page 上の文言を「見に行く情報」ではなく「agent へ混ぜる文脈」として扱った瞬間に、prompt injection の条件が揃いやすくなります。

ここでの主役は jailbreak のコツではありません。OpenClaw を使う実務では、どの content は operator の意思で、どの content は外部から混ざったものか を分けることが最初の防御線です。これを曖昧にしたまま「危険な指示語を遮断する」程度で済ませると、構造的な危険は残ります。

危険なのは DM だけではなく URL と web tool の結果も同じです

OpenClaw の prompt injection を DM や group chat の問題だけとみなすのは不十分です。browser / web tools を有効にしている環境では、URL のリンク先、取得した HTML、要約対象の docs、サポート画面、公開 FAQ、外部の troubleshooting guide などが agent の判断材料になります。ここで「Web から持ってきた説明文」を operator 指示に近いレイヤーへ混ぜると、たとえ明示的な exploit を説明しなくても、agent の優先順位をずらす indirect effect が起きます。

Microsoft の indirect prompt injection guidance や NIST AI 100-2 も、外部 content を通じた context contamination を AI system の設計課題として扱っています。OpenClaw 固有の記事で重要なのは、これを「MCP が危ない」「AI が危ない」で終わらせず、OpenClaw の browser / web tool / URL input / セッション境界へ落とし込むことです。

なぜ外部コンテンツが攻撃面になるのか

OpenClaw の便利さは『広い文脈を読めること』であり、それがそのまま攻撃面にもなります

OpenClaw の便利さは、多様な content を agent が読めることにあります。しかし security の観点では、その便利さが attack surface でもあります。public docs、ticket、本人以外が編集できる knowledge、web page、サポート画面、channel message のような content は、利用者にとっては参考情報でも、agent にとっては「判断材料」です。ここに曖昧な指示や優先度を変える文言が混ざると、必ずしも exploit でなくても、agent が operator の意図からずれる きっかけになります。

既存の シャドーAPIとは？ や 外部接続点は見えているか？ が外部接点を扱うように、OpenClaw でも「何を外から読ませるか」は管理対象です。retrieval や web fetch の元になる host が雑に残っていると、それだけ文脈汚染の出所が増えます。だから OpenClaw の prompt injection 対策は、モデル側の prompt 設計だけでなく、agent が参照しうる公開面の整理 と一緒に進める必要があります。

セッション境界を曖昧にすると、汚染された文脈が別操作へ伸びやすくなります

prompt injection の影響が大きくなるのは、一つの session や同じ browser profile の中で、参照・要約・実行・送信が連続しているときです。OpenClaw の security docs でも sandbox scope や workspace access を細かく扱っているのは、shared scope や広い workspace が state の持ち越しを生みやすいからです。shared な state が増えるほど、汚染された context が別の操作へ転用されやすくなります。

たとえば「読みに行った public page の instructions を、そのまま次の browser action や tool invocation の判断に使う」構成は危険です。ここで必要なのは魔法の防御語ではなく、参照専用の content と、権限を伴う action を分けることです。OpenClaw の prompt injection を本当に抑えたいなら、session と tool の責任境界 を意識して設計する必要があります。

DM / group / web / URL input でどこが危険か

channel message は operator input と同じ trust で扱わない方が安全です

OpenClaw を DM や group で使う場合、message は operator input に見えますが、実際には channel 側の混入や forwarding、mention、引用、貼り付けによる文脈汚染が起きえます。channel 側の input をそのまま trusted command source とみなすと、OpenClaw broad security の前提である利用主体の信頼境界が崩れます。だから pairings や許可リストだけでなく、channel content 自体を未信頼寄りで扱う姿勢 が必要です。

特に group 運用では、operator 本人の意図と、他参加者の文脈、bot mention、URL preview が混ざります。ここを broad な「チャットが危ない」にせず、session ごとに何を実行判断に使ってよいかを細く決めると、安全性はかなり上がります。

web / URL input は『見に行く』だけでも境界を増やします

browser や web tool で URL を開かせる構成では、「読むだけだから安全」と考えがちです。しかし OpenClaw では page content が agent の文脈へ入り、場合によっては browser action や tool choice の判断に影響します。つまり navigation そのものではなく、取得した content がどの層へ流れ込むか を見なければなりません。

OpenClaw docs の browser SSRF policy や browser control 注意事項は、network 到達性だけでなく、browser profile が operator access に近いことを示しています。ここに prompt contamination が重なると、単なる content mix-up では済みません。OpenClaw の prompt injection 記事では、この「browser は便利だが operator access に近い」という性質を前提に、URL input を安易に trusted にしないことが重要です。

tool policy / sandbox / 許可リストをどう効かせるか

prompt contamination をゼロにできなくても、重大操作への接続は細くできます

OpenClaw の prompt injection 対策で現実的なのは、汚染された文脈が入る可能性を認めつつ、重大操作へ繋がる経路を細くすることです。sandbox、tool policy、許可リスト、workspace access、browser mode、network 許可リストは、そのための制御点です。ここで大事なのは、「安全な prompt を書く」より、agent が失敗しても何が起きるかを小さくする設計です。

たとえば browser を使うなら host browser control を常設せず、必要なときだけ限定 profile で使う。exec を使うなら elevated path を常設せず、sandbox 内の参照中心から始める。workspaceAccess は最小から始める。こうした設計を先に置くと、indirect prompt injection の被害は「変な回答」で止まりやすくなり、host side effect や外部送信へ伸びにくくなります。

これは generic prompt injection の対策を OpenClaw に持ち込むだけでは足りません。OpenClaw の tool inventory と runtime を前提に、どの action を絶対に自動化しないか を決める必要があります。そこまで決めて初めて、prompt contamination を broad な恐怖ではなく、管理できるリスクへ変えやすくなります。

OpenClaw の入力面整理を ASM診断 PRO で始めるなら

ASM診断 PRO は OpenClaw の prompt injection を直接防ぐ製品ではありませんし、MCP policy engine の代替でもありません。ただ、OpenClaw の prompt injection を実務で減らすには、agent が参照しうる外部 content の出所を整理する必要があります。公開 docs、古いサポート画面、用途不明の API host、staging、login page が外から見えているなら、それらは retrieval や browser 操作の候補になります。つまり対策の第一歩は、agent が何を読める状態にあるか を外から揃えることです。

OpenClaw の入力境界を作るとき、model prompt だけ見ても十分ではありません。どの host は browser 許可リストへ入れるのか、どの docs は retrieval 対象から外すのか、どの admin page はそもそも公開状態をやめるべきかを決める必要があります。ASM診断 PRO を起点に外部公開資産を棚卸しすると、OpenClaw の prompt contamination を broad な概念ではなく、具体的な host と docs の整理へ落とし込みやすくなります。

既存の 外部接続点は見えているか？、シャドーAPIとは？、公開リポジトリの情報漏えいとは？ と組み合わせると、OpenClaw へ入る未信頼コンテンツの出所を host 単位で見直せます。OpenClaw の prompt injection を真正面から抑えたいなら、まずは 何が外から見え、何を agent に読ませるつもりか を整理してください。

よくある質問（FAQ）

OpenClaw の prompt injection は一般的な prompt injection と同じですか

基本原理は同じですが、OpenClaw では gateway、browser、web tool、channel input、tool policy が絡むため、どの content が文脈へ混ざるかを具体的に追う必要があります。

危険な単語を block すれば防げますか

それだけでは不十分です。OpenClaw の場合は外部コンテンツと operator input を分け、tool 実行経路を細くする方が効果的です。

browser や web tool を切れば安全ですか

リスクは下がりますが、channel message、docs、tool metadata など別の入力面は残ります。単一の機能を切るだけでなく、入力境界全体を見る必要があります。

最初に見るべき設定は何ですか

sandbox、tool 許可リスト、browser mode、workspace access、DM / group exposure、remote access、trusted proxies を優先して確認してください。

OpenClaw の prompt injection は auth bypass と同じですか

同じではありません。主な問題は未信頼コンテンツの混入による判断ずれであり、必ずしも認証回避そのものを意味するわけではありません。

まとめ

OpenClaw のプロンプトインジェクションは、入力欄に危険な文を入れられることだけではありません。URL、web tool、channel message、docs、tool metadata のような外部コンテンツが operator 指示に近い層へ混ざることで、agent の判断がずれることが本質です。したがって対策も、「危険語を消す」ではなく、何を trusted input とし、何を参照専用の未信頼コンテンツとして扱うか を設計するところから始まります。

そのうえで OpenClaw 固有の実務として重要なのは、browser / web tool / セッション境界 / tool policy を一緒に見ることです。browser で読んだ page をそのまま action の根拠にしない、sandbox と workspace access を最小にする、shared state を増やしすぎない、外部送信や書き込みを常設しない。こうした制御を置くと、prompt contamination が起きても重大操作まで伸びにくくなります。

さらに、OpenClaw の prompt injection は model の内側だけでは終わりません。agent が参照する公開 docs、staging、サポート画面、API host の整理まで含めて初めて、入力境界は実装に落ちます。だから OpenClaw の prompt injection 対策は、AI 一般論ではなく、外部接点、tool 権限、session 設計をつなぐ運用課題として見るべきです。そこまで整理できれば、OpenClaw を便利さのためだけでなく、安全な業務基盤として扱いやすくなります。