OpenClawのセキュリティとは？危険性と安全に使う方法を徹底解説

OpenClaw セキュリティとは何を守る話なのか

OpenClaw は『何でも多人数で共有する基盤』ではなく利用主体の分離を前提にします

OpenClaw の official security guidance が最初に強調しているのは、1つの gateway を 1つの利用主体で扱う という前提です。これは単なる運用の好みではなく、OpenClaw が相互に不信な複数人の共有基盤を想定していないことを意味します。つまり、相互に不信な複数人が同じ gateway と同じ credentials を共有し、その上で agent に browser や exec を広く渡す構成は、製品が前提とする安全境界と合っていません。

この前提を誤解すると、「gateway に password auth を付けたから安全」「sandbox を有効にしたから多人数共有してよい」という判断に流れやすくなります。しかし OpenClaw の docs では、host state や「~/.openclaw」の config を変更できる主体は、利用主体そのものとみなされます。つまり security の中心は、単に UI へ誰が入れるかではなく、誰が gateway host と config の信頼境界を握るかです。

既存の AIエージェントの過剰権限とは？ が broad な agent の権限肥大化を扱うのに対し、本記事は OpenClaw 固有の gateway 運用へ話を絞ります。OpenClaw では gateway、tool profile、browser node、remote access、credentials が一体で動くため、信頼境界を雑にすると個別の防御だけでは取り返しにくいのが特徴です。

守る対象は会話履歴だけでなく config、credentials、workspace、外部操作です

OpenClaw の security を chat transcript の保護だけと見ると、かなり危険です。公式 docs にある credential storage map を見ると、channel credentials、pairing 許可リスト、auth profiles、optional secrets payload、agent sessions など、disk 上に残る要素が多くあります。OpenClaw を安全に使うとは、こうした state と config を守ること、そして browser や exec のような外部操作を最小化することを意味します。

特に「~/.openclaw」は実質的に運用の中心です。permissions が甘ければ、第三者が config drift を起こしたり、credentials を持ち出したり、tool policy を書き換えたりできます。つまり OpenClaw の security は「agent が何を考えるか」の前に、host 上の state が誰から読まれ、誰から変更できるか を押さえる必要があります。

ここで既存の サービスアカウントのセキュリティとは？ とつながるのは、OpenClaw でも model provider key や remote token、tool 連携先の認証情報が non-human identity として振る舞うからです。AI agent の security を broad に語るより、OpenClaw に載せた credentials と tools がどこへ届くか を具体的に見る方が、実運用では効果的です。

利用主体の分離を誤解すると何が危険か

1 gateway に複数の相互不信ユーザーを混ぜると、責任境界が消えます

OpenClaw の security docs が mixed-trust teams では separate gateways or separate OS users / hosts を勧めているのは、責任境界が曖昧になるからです。もし同じ gateway を複数部門や複数案件で共有すると、どの tools を誰のために許したのか、どの credentials がどの operator に必要なのか、どの session が誰の責任かが混ざります。これは権限の広さだけでなく、監査と事故切り分けの失敗に直結します。

実際、browser control や exec を伴う agent では、operator boundary の崩れはそのまま実害になります。ある利用者には harmless な tools でも、別の利用者から見れば過剰です。共有 gateway のまま「都度 careful に使う」運用では、human process に依存しすぎます。OpenClaw は personal assistant model を前提にしているので、便利さのために shared gateway へ寄せるほど、製品前提から外れます。

既存の シャドーAIとは？ が未承認利用を主役にするのに対し、ここでの論点は承認済み導入でも boundary を混ぜると危険という点です。導入済みであっても、誰の agent か、誰の host か、誰の browser profile かが曖昧なら、安全な導入とは言えません。

sandbox だけでは shared boundary の問題は解消しません

Sandboxing は強力ですが万能ではありません。OpenClaw の sandboxing docs でも docker / firejail / none の違い、filesystem・network・resource limits を説明していますが、これらは主に tool execution の隔離です。つまり sandbox は「agent がどこまで host や network に触れられるか」を絞る手段であり、誰のための gateway かという信頼境界を作り直す手段ではありません。

たとえば、shared gateway 上で各利用者に異なる外部コンテンツ、browser tabs、credentials、plugins を触らせる構成では、sandbox があっても policy drift や config drift の問題は残ります。OpenClaw security audit でも、sandbox mode off のまま docker settings だけ定義しているケースや、「tools.exec.host=「sandbox」」を期待していて実際には host execution になっている runtime expectation drift が注意点として挙げられています。つまり重要なのは、sandbox の存在そのものではなく、実際に有効な境界として働いているかです。

最初に置くべき基本防御線は何か

公開経路は bind、remote access、pairing 許可リストから締めます

OpenClaw の security audit checklist では、open な DM / group と tools enabled の組み合わせ、public network exposure、browser control remote exposure が高優先度で並んでいます。これは「まず model を変える」より、「誰が話しかけられるか」「どこから gateway に届くか」を締める方が先という意味です。gateway が LAN bind、public exposure、Funnel / Serve、proxy misconfiguration で広く開いていれば、他の hardening は弱くなります。

とくに reverse proxy を置く場合は「trustedProxies」の扱いが重要です。OpenClaw docs でも、proxy headers を信頼する相手を明示しないと、local client 判定が崩れるリスクを避ける設計になっています。ここは単なるインフラ詳細ではなく、auth bypass を防ぐ境界として扱うべきです。

sandbox は docker を基準に、workspace と network の広げ方を慎重に決めます

OpenClaw sandboxing docs は docker を recommended としており、filesystem、network、resource limits を組み合わせられます。ここで重要なのは、sandbox を on にすることだけでなく、「workspaceAccess」、scope、allowed hosts、browser mode の広げ方を慎重に決めることです。特に「rw」mount や shared scope は便利ですが、誤操作や prompt contamination が広がる面も増えます。最初は 読み取り不要なら none、共有不要なら agent / session 単位 から始めた方が安全です。

また、OpenClaw docs が強調するように「tools.elevated」は global baseline escape hatch です。これを「必要なときだけ使うから大丈夫」と運用で吸収しようとすると、いつの間にか常設ルートになります。高権限 escape hatch は、存在するだけで review の手間が増え、scope creep の入口になります。最小構成では、elevated path をなるべく常設しない 方が無難です。

security audit を初期導入後の定期運用へ組み込みます

OpenClaw には「openclaw security audit」があり、「--deep」では best-effort live probe まで試みます。これは導入直後だけでなく、設定 drift を見つける定期運用へ載せるべきです。許可リストのつもりが wildcard 化している、plugin が追加されている、sandbox mode が off なのに docker profile だけ残っている、といったズレは長く運用すると起きやすくなります。

既存の 公開資産 是正 SLA とは？ が remediation governance を扱うように、OpenClaw でも「設定不備を見つけたら何日で閉じるか」を決めると運用が安定します。security audit をログだけ残して放置すると、警告が平常化しやすいため、指摘を運用タスクへ変換する仕組みまで必要です。

運用で崩れやすいポイント

便利さのための例外が積み上がると security は急に弱くなります

OpenClaw の運用でよくある失敗は、最初は最小構成でも、後から browser、exec、plugins、remote access の例外が積み上がることです。たとえば「一時的に public bind にした」「検証用に DM 許可リストを広げた」「sandbox 外で一度だけ動かした」ような例外が戻されないまま残ると、基本防御線は急速に崩れます。特に AI agent は便利になるほど operator が例外を足しやすいので、許可した例外を戻す手順まで運用設計に含める必要があります。

OpenClaw broad hub として重要なのは、すべての危険を exploit 観点で見るのではなく、運用 drift 観点で見ることです。誰が gateway を再起動できるか、誰が config を変えられるか、plugins を誰が足せるか、public exposure を誰が開けられるか。このあたりを明確にしないと、セキュリティは設定ではなく「覚えている人の善意」で支えられてしまいます。

OpenClaw の危険性を『AI が危険』に雑に一般化しない方が実務に効きます

OpenClaw を話題にすると、AI agent は危険、browser control は危険、prompt injection は怖い、と broad な話に流れやすいです。しかし実務で効くのは、OpenClaw が前提とする model を理解し、どこを境界として使うかを明確にすることです。OpenClaw 公式も、1つの gateway を 1つの利用主体で扱う考え方、public exposure の制御、disk permissions、sandboxing、tool policy を軸に説明しています。つまり、危険性を抽象化しすぎるより、設計前提を運用へ落とす方が強いです。

その意味で OpenClaw security は、generic な AI 議論より、gateway 運用、host 管理、公開面管理、権限設計に近いテーマです。ここを外さなければ、今後「OpenClaw プロンプトインジェクション」や「OpenClaw 過剰権限」の個別記事とも綺麗につながります。

OpenClaw の導入判断を ASM診断 PRO で支えるなら

ASM診断 PRO は OpenClaw の sandbox や tool policy を直接設定する製品ではありませんし、gateway hardening の代替でもありません。ただ、OpenClaw を安全に使う前提には「agent が触れうる公開面を先に把握する」ことが含まれます。たとえば公開 docs、古い staging、用途不明の API host、管理画面、サポート画面が外から見えていると、それらは retrieval や browser 操作の入力面になります。つまり OpenClaw を安全に使うには、AI の内側だけでなく外側の公開接点も整理する必要があります。

OpenClaw security を broad な hardening で終わらせず実運用に落とすなら、どの host を browser で触ってよいか、どの docs を retrieval 対象に入れてよいか、どの login page が外から見えているかを先に揃えた方が速いです。ASM診断 PRO は外部公開資産の棚卸しと優先度整理を通じて、OpenClaw に渡す公開面の整理を始める土台になります。ここで把握した host を基準に、browser 許可リスト、retrieval 対象、監査対象を決めると、AI 導入の信頼境界を実際の公開面に合わせて設計しやすくなります。

既存の 外部接続点は見えているか？、シャドーAPIとは？、公開リポジトリの情報漏えいとは？ と合わせて見ると、OpenClaw の hardening を AI 製品単体の議論で終わらせず、外部接点、公開 docs、API host、古い admin 面まで含めて見直せます。OpenClaw を本当に安全に使うには、まず 何が外から見えていて、agent に何を触らせるつもりか を整理してください。

よくある質問（FAQ）

OpenClaw は複数人で共有しても安全ですか

相互に不信な利用者を同じ gateway に混ぜる構成は公式の前提と相性が良くありません。共有したいなら gateway や host を分ける方が安全です。

sandbox を有効にすれば browser や exec を広く許してよいですか

いいえ。sandbox は重要ですが、tool policy、workspace access、network access、browser exposure を最小化しないと、運用 drift で危険が残ります。

OpenClaw の最初の hardening は何から始めるべきですか

まず信頼境界、public exposure、DM / group 許可リスト、disk permissions、sandbox mode の5点を最小構成で固めるのが有効です。

security audit は導入時だけ回せば十分ですか

十分ではありません。tool 追加、plugin 変更、browser mode 変更、config drift が起きるため、月次などの定期運用へ載せるべきです。

OpenClaw の security は AI の一般論と同じですか

重なる部分はありますが、OpenClaw では gateway、credentials、browser、tools、disk state の boundary をどう運用するかがより直接的な論点です。

まとめ

OpenClaw のセキュリティは、AI agent が危険かどうかという抽象論ではなく、gateway を誰のために置くのか、どの tools を許すのか、どの公開経路を残すのか、host 上の state を誰が触れるのかを明確にする問題です。OpenClaw 公式も 1つの gateway を 1つの利用主体で扱う考え方を明示しており、ここを外すと sandbox や auth を足しても設計前提から外れていきます。だから broad hub としてまず押さえるべきは、OpenClaw の security model が何を前提にしているかです。

そのうえで基本防御線は、public exposure の最小化、DM / group 許可リスト、sandbox の有効化、tool policy の最小構成、disk permissions の監査、security audit の定期運用で組み立てます。個別に見れば難しくない項目でも、便利さのための例外が積み上がると境界はすぐ崩れます。したがって OpenClaw の security は、設定値の暗記ではなく、例外を増やしすぎない運用設計として扱う必要があります。

さらに実務では、OpenClaw の内側だけ見ても不十分です。agent が触れうる公開 docs、staging、API host、管理画面、browser 導線がどう残っているかを一緒に見なければ、信頼境界は現実の公開面とずれます。OpenClaw を安全に使いたいなら、gateway・tools・browser の設定に加えて、外から見える接点を整理し、何を agent に触らせ、何を隔離するかを継続的に見直してください。そこまで含めて初めて、便利さと安全性の両方を取りやすくなります。