セキュリティの強化 / Security Hardening
- 日本語
- English
- 简体中文
🔐 AIの暴走と情報漏えいから身を守る
AIエージェントに「あなたの代役」としてファイルシステムやインターネットへのアクセス権を与えると、非常に強力な恩恵とともに深刻なセキュリティリスクが生じます。
このガイドでは、ホストシステム(あなたのパソコンやサーバー)を安全に保つための「鉄の掟(ベストプラクティス)」を詳述します。
1. 秘密鍵(APIキー)は絶対に直書きしない
AIに対する指示書(Markdownファイル)や、実行スクリプト内に sk-123456... のようなAPIキーを直書き(ハードコード)してはいけません。
AIが要約を作った際、誤ってそのキーを含んだままGitHubやSNSにアップロードしてしまう事故(漏洩)が起こります。
- 正解: 必ず
auth-profiles.jsonに設定するか、環境変数マネージャー(1Password CLIなど)を通じて暗号化されたシークレットを渡してください。
2. コマンド実行の「承認システム」を無効化しない
OpenClawには、AIがターミナルでコマンドを叩こうとしたとき、実行前に人間に 「これを実行してもいいですか? (Y/n)」 とストップをかける機能(exec-approvals.json)が備わっています。
{
"commands": {
"ask": "on",
"whitelist": ["ls", "cat", "echo"]
}
}
- あなたの生PC(Macなど)で動かす場合、絶対に
ask: "on"(確認する)を維持してください。 - AIのハルシネーション(幻覚)によって、突如
rm -rf /のようなファイルをすべて消し飛ばすコマンドが生成されるリスクはゼロではありません。 - 例外: 完全に隔離されていて「壊れてもいい」DockerコンテナやVM環境(開発用サンドボックス)でのみ、
ask: "off"(しつもん不要・完全自律実行)を自己責任で許可します。
3. Docker(コンテナ)での隔離を検討する
もしAIに「Pythonプログラムを書いて、それを実行してみて」というような高度な仕事(コーディング補助)をさせるなら、ホスト環境に直に触らせず、Dockerコンテナの中で活動させるのが最も安全(ベスト)です。
🔐 Protecting Yourself from AI Sprawl and Data Leaks
Granting an AI agent "proxy" access to your file system and the internet provides immensely powerful benefits, but also introduces severe security risks.
This guide details the "Iron Rules (Best Practices)" to keep your host system (your PC or server) bulletproof.
1. Never Hardcode Secret Keys (API Keys)
Never hardcode API keys like sk-123456... inside your instructions (Markdown files) or execution scripts.
If you do, the AI might accidentally include that key in a summary and upload it straight to GitHub or Twitter (a catastrophic leak).
- Correct Protocol: Always configure keys in
auth-profiles.jsonor pass encrypted secrets via a safe environment variable manager (like 1Password CLI).
2. Do Not Disable the Command "Approval System"
OpenClaw features a built-in safety net (exec-approvals.json) that forces the AI to stop and ask the human, "Are you sure you want me to execute this command? (Y/n)" before running anything in the terminal.
{
"commands": {
"ask": "on",
"whitelist": ["ls", "cat", "echo"]
}
}
- If running directly on your host PC (like your Mac), absolutely keep
ask: "on". - The risk of AI hallucination suddenly generating a destructive command like
rm -rf /(wiping all files) is never zero. - Exception: You may enable
ask: "off"(full, unprompted autonomy) only if the agent operates inside a completely isolated, disposable Docker container or restrictive VM (sandbox environment) where damage is contained.
3. Consider Docker Sandboxing
If tasking the AI with advanced operations like "Write a Python program and execute it to test," it's vastly safer to have it operate securely inside a Docker container rather than touching your core host environment directly.
🔐 防范 AI 失控与数据泄露的护城河
当您将文件系统和整个互联网的访问权限赋予一个作为您“代理人”的 AI 助手时,在享受极其强大便利的同时,也会引入极其严峻的安全风险。
本指南将为您详细阐述保卫您的主干系统(个人电脑或服务器)的“铁律(最佳实践)”。
1. 绝不将密钥(API Key)明文硬编码
请绝对不要在 AI 的指令手册(Markdown 文件)或执行脚本中直接写死如 sk-123456... 这样的 API 密钥。
否则,极有可能发生这样的事故:AI 在为您生成摘要报告时,不慎将该密钥裹挟在内,并自动发布到了 GitHub 或是社交媒体上(毁灭级的泄露)。
- 正确做法:务必将其配置在安全的
auth-profiles.json中,或者通过环境变量管理器(如 1Password CLI)加密传递这些机密信息。
2. 请勿关闭终端命令的“拦截审批系统”
OpenClaw 标配了一道安全防线(exec-approvals.json),即当 AI 试图在终端执行某项命令前,会立刻暂停并向人类主管请求: “请问可以执行这行命令吗?(Y/n)”。
{
"commands": {
"ask": "on",
"whitelist": ["ls", "cat", "echo"]
}
}
- 如果您是在自己的物理主机(如 Mac)上运行它,请无论如何都要保持
ask: "on"(要求确认)。 - AI 产生“幻觉”并毫无征兆地生成类似
rm -rf /(清空电脑上所有文件)这样极度危险的命令的风险,永远不可能降到零。 - 唯一例外:如果您是在一个完全隔离的、“就算炸掉也无所谓”的 Docker 容器或云端虚拟机沙盒中,您可以自行担责,将拦截关闭设定为
ask: "off"(完全无人值守的全自动运行)。
3. 强烈考虑进行 Docker 沙盒化
如果您吩咐 AI 执行诸如“帮我写一段爬虫 Python 脚本,并在本地跑跑看”这种高权限的探索性任务(编程辅助),最安全的底线就是绝不让它触碰宿主系统,而是将它塞进 Docker 容器里去执行各项活动。