目錄

重點速讀 2 分鐘｜7 分鐘深讀
  1. 先定義：隔離主機不是萬能保險箱
  2. 第一層：帳號和資料夾隔離
  3. 第二層：密鑰和 API key 管理
  4. 第三層：命令白名單與審批
  5. 第四層：網路與入口暴露面
  6. 第五層：audit log 與回復能力
  7. 新手最小安全清單
  8. 大家都在問

AI 隔離主機的安全重點，不是裝一個工具就結束，而是把「誰能進來、能碰哪裡、能執行什麼、密鑰放哪、出事怎麼追」全部分層。新手最少要做到：專用帳號、專用資料夾、低權限執行、API key 限權、危險任務審批、完整 audit log。

  • 不要用私人日常帳號跑 AI agent。
  • 不要讓 Telegram、LINE、Slack 或 Web Console 直接變成任意 shell。
  • API key 要最小權限、可撤銷、可輪替，不要貼進 prompt。
  • 會寫檔、部署、刪除、金流、下單的任務要進審批。
  • audit log 要能回答：誰、何時、要求什麼、系統做了什麼、結果是什麼。
  1. 先定義：隔離主機不是萬能保險箱
  2. 第一層：帳號和資料夾隔離
  3. 第二層：密鑰和 API key 管理
  4. 第三層：命令白名單與審批
  5. 第四層：網路與入口暴露面
  6. 第五層：audit log 與回復能力
  7. 新手最小安全清單

先定義：隔離主機不是萬能保險箱

隔離主機的意思，不是「AI 在這台機器裡就絕對安全」。它真正的作用，是把風險關在一個比較小、比較容易重建、比較不會連到私人資料和主力帳號的範圍內。

如果 AI 主機同時登入你的私人 Google 帳號、交易所主帳號、公司後台、日常瀏覽器 profile，還有完整磁碟權限，那它其實不算隔離。它只是另一台風險更高的日常電腦。

如果這台主機未來會接到交易所通知、行情、自動整理或策略回測，請先從只讀資料開始。像 OKX 或 Bybit 這類平台，API key、KYC、所在地限制、費率、槓桿和下架規則都要分開檢查；正式 API key 不要一開始給下單或提領權限。

第一層：帳號和資料夾隔離

最小做法是建立一個專用使用者，讓 AI agent 只在專用工作資料夾內活動。

mkdir -p ~/ai-host/{work,jobs,logs,secrets,backups}
chmod 700 ~/ai-host
chmod 700 ~/ai-host/secrets

建議資料夾分工：

資料夾 用途 權限建議
work/ Codex 或 runner 的工作區 可讀寫，但限制在這裡
jobs/ Hermes 任務 JSON 可讀寫
logs/ 執行紀錄、錯誤、審批紀錄 可追加、可備份
secrets/ 本機 .env 或密鑰參考 chmod 700，不要進 repo
backups/ 任務前後快照 可讀寫，定期清理
AI 隔離主機安全分層圖，包含專用帳號、密鑰管理、命令白名單、人工審批與 audit log
AI 隔離主機安全分層圖，包含專用帳號、密鑰管理、命令白名單、人工審批與 audit log

新手先不要追求最複雜的容器化。先把「AI 只能在某個資料夾工作」做好，再談 Docker、VM、Tailscale、systemd、queue worker。安全是分層，不是一個名詞。

第二層：密鑰和 API key 管理

OWASP 的密鑰管理原則可以用很白話的方式理解：密鑰要能限制、能輪替、能撤銷、不要硬編碼，不要出現在 log、repo、prompt 和截圖裡。

最小規則如下：

規則 做法
不進 repo .env 加進 .gitignore
限權 只給任務需要的 scope
可撤銷 每個服務用獨立 key，不共用主 key
可輪替 設定 key 建立日期與輪替提醒
不進 prompt Claude / Codex 只拿到任務，不拿原始 secret

不要這樣寫：

OPENAI_API_KEY = "sk-..."
TELEGRAM_BOT_TOKEN = "123456..."

比較好的第一版：

TELEGRAM_BOT_TOKEN=只放在本機 .env
ALLOWED_TELEGRAM_USERS=123456789
OPENAI_API_KEY=只給必要權限並可撤銷

然後：

chmod 600 .env

第三層：命令白名單與審批

真正危險的不是 AI 會寫錯字，而是它可以把錯誤變成真實操作。Hermes 應該把任務分成三層：

風險等級 例子 處理方式
低 查狀態、讀 log、整理摘要 可自動
中 寫文章、改設定、跑測試 建議先產生 preview 或 diff
高 刪檔、部署、改資料庫、下單、提領 必須人工 approve

命令白名單不是形式，而是安全邊界。例如：

{
  "allowedCommands": {
    "status": ["python3", "tools/status.py"],
    "preview": ["python3", "tools/preview.py"],
    "test": ["npm", "test"]
  },
  "blockedByDefault": true
}

最小審批流程：

  1. 使用者送任務。
  2. Hermes 建立 job。
  3. Claude 或 Codex 產生 plan / diff。
  4. 高風險 job 進入 waiting_approval。
  5. 使用者送 /approve jobId。
  6. runner 才執行。
  7. Hermes 寫入 audit log 並回報。

第四層：網路與入口暴露面

第一篇用 Telegram long polling，是因為它不用把主機公開到網路上。只要你改成 webhook、Web Console 或 API，就要開始處理入口暴露面。

入口 最少要做
Telegram long polling bot token 保護、allowlist、不要加群組
Telegram / LINE webhook HTTPS、secret token 或簽章驗證、重送去重
Slack / Teams OAuth scope 最小化、workspace allowlist、事件快速 ACK
Web Console 登入、2FA、CSRF、防暴力嘗試、VPN 或內網
REST API HMAC 簽章、idempotency key、rate limit、IP allowlist

如果你不確定怎麼保護公開入口，就先不要公開。用 long polling、SSH tunnel、VPN、Tailscale 或只在內網測試，都比把一個半成品控制台丟到公網安全。

第五層：audit log 與回復能力

audit log 不只是 debug，它是事後保命繩。至少要記：

欄位 說明
jobId 每個任務唯一 ID
actor 誰發起任務
entrypoint Telegram、LINE、Slack、Web 或 API
intent 原始意圖
approvedBy 誰批准
executor Claude、Codex、runner 或人工
changedFiles 改了哪些檔案
exitCode 執行結果
startedAt / completedAt 時間

OWASP 的 logging 建議核心精神是：紀錄要能支援安全事件分析，但不要把敏感資料寫進 log。這一點很重要。log 裡不應該出現完整 API key、密碼、cookie、私鑰、KYC 文件或交易所完整 token。

新手最小安全清單

先做到這 12 項，再談全自動：

項目 是否完成
AI 主機使用專用帳號
工作資料夾和私人資料分開
.env 不進 repo
.env 權限設為 600
API key 最小權限
Telegram / LINE / Slack 使用者 allowlist
命令預設拒絕，只有白名單可跑
高風險任務需要 approve
每個任務有 jobId
stdout / stderr / exit code 有紀錄
log 不寫入完整密鑰
有停止服務與撤銷 key 的流程

這篇的結論很簡單：先把 AI 的手縮短，再慢慢給工具。你可以讓 AI 很能幹，但不要讓它一出生就拿著所有鑰匙。

延伸閱讀

大家都在問

脆上快聊，群裡慢慢拆。

剛入坑群友問AI 隔離主機一定要用 Docker 或 VM 嗎？

老群友答 不一定。Docker 或 VM 很有用，但新手第一步可以先做專用帳號、專用資料夾、低權限和命令白名單。等任務變多，再升級容器或 VM。

剛入坑群友問API key 可以直接交給 Claude 或 Codex 嗎？

老群友答 不建議。模型和執行器應該透過 Hermes 或工具層使用必要權限，不要把完整密鑰貼進 prompt、聊天訊息或程式碼。

脆友問audit log 會不會太麻煩

脆上怎麼說看脆 不會。最小版就是每個 job 寫一份 JSON，記錄 actor、intent、command、exitCode、stdout、stderr 和時間。之後再接 database 或 dashboard。

剛入坑群友問什麼操作一定要人工 approve？

老群友答 刪檔、部署、改資料庫、改權限、下單、提領、發送大量訊息、提交 KYC 或影響外部使用者的任務，都應該人工確認。

脆友問如果 token 洩漏怎麼辦

脆上怎麼說看脆 立刻撤銷舊 key、建立新 key、檢查 audit log、停用相關入口、檢查是否有異常任務，再逐步恢復服務。可撤銷和可輪替，就是一開始要分 key 的原因。

資料查證：2026-06-13。本文參考 OWASP Secrets Management Cheat Sheet、OWASP Logging Cheat Sheet、Telegram Bot API、LINE Messaging API webhook 文件、Slack Events API 與 GitHub Webhooks 文件；實際平台規則、API、簽章與安全要求仍以官方最新資訊為準。

延伸閱讀

隨機文章