【2026 最新】OpenBot 安全實戰：Policy、Audit 與每 Bot 隔離驗收

如果一個 AI 同事有自己的瀏覽器、檔案與 Shell，你看到「Docker 已啟動」還不算驗收完成。真正要問的是：它和另一個 Bot 是否用了不同容器與 Volume？危險動作是否在送出前被 Policy 擋下？就算 Policy 放行、底層執行失敗，Audit Trail 能不能分辨「允許」與「真的完成」？

OpenBot 很適合把這些問題做成一座小型實驗室。它在 2026 年 8 月 17 日建立公開儲存庫；截至 8 月 26 日 08:08（台北時間）的 GitHub API 快照為 2,897 stars，這只代表開源關注度，不是安裝或企業採用數。但官方同時明確標示為 Alpha、持續開發中。所以本文不是部署背書，而是教你在一次性 VM／隔離私網先做一輪可否證的安全驗收。

先記住本文唯一的核心式：Agent 安全驗收＝每 Bot 資源分離 × 動作前 Policy × 執行結果 Audit × 可復原拆除。任何一項沒有證據，就只能寫「未通過」；不同 container／Volume 是必要證據，但不能單獨升格為強安全隔離。

先做版本判讀：v0.0.4 Digest 不等於每 Bot 隔離

截至本文查核日，最新正式版是 v0.0.4。官方確實提供可核對的容器 Digest，但該版 all-in-one 映像尚未包含 supervisor；官方部署文件也說明，單體部署中的 Bots 會共用同一個 browser、workspace 與登入狀態。換句話說，固定 Digest 只能證明你拿到哪一包 bytes，不能替不存在的拓撲創造隔離。

更重要的是，v0.0.4 之後的 Unreleased changelog 才補上幾個與本 Lab 直接相關的修正：Bot computer 不再與 PostgreSQL 共用網路、資料庫與 supervisor 的 host port 改綁 loopback、Production 不再接受 AGENT_COMPUTER_ALLOW_PRIVATE_HOSTS=true，以及失敗動作的 Audit Row 補回原始 command／key。本文因此固定在官方 commit a6bada954e4a2bc696c6617d3f4c7a1512230990；它仍是未發布快照，不要把它解讀成已經通過完整安全審計。

這座 Lab 要驗收什麼？先寫 Pass／Fail 標準

• 版本：Git HEAD 等於指定 40 碼 commit；實際 Bot container 的 image ID 與你保存的 SHA-256 相同。
• 身分：OPENBOT_SINGLE_USER 與舊名 OPENBOT_DEV_NO_AUTH 都沒有啟用；一般使用者無法進入 /admin/*。
• 資源分離：Bot A／B 有不同 container、profile Volume、workspace Volume 與 openbot.bot-id label；兩者都沒有連上資料庫網路。
• 認證隔離：不同 Bot 不應能拿同一憑證驅動對方 computer；若程式碼或 runtime 無法證明，就明記未通過。
• 決策：Policy mode 是 enforce；受控刪除與 MCP write 在執行前留下拒絕 Row，且沒有副作用。
• 硬限制：即使 Policy 特意放行測試輸入，私有 IP 與 workspace 越界仍在下一層失敗。
• 接管：help requested、control taken、control released 三個事件可串成同一段人工介入；browser 與 file／shell 分開測。
• 拆除：容器、profile、workspace、Secret 與測試帳號都有清單；清理後重新查詢為空。

這種分層驗收與 Agent Runtime Controls 的原則相同：Policy 是可變的業務規則，container／network／path confinement 才是 Policy 出錯後仍應站著的底線。如果你第一次接觸沙盒差異，可先讀 Docker、Sandbox 與 MicroVM 比較；OpenBot 的預設 supervised computer 是普通容器，不是每 Bot 一個 VM。

步驟一：在拋棄式主機鎖定原始碼與本機 Image ID

準備一台不存放日常帳密、沒有 inbound port-forward 的拋棄式 VM，安裝 Docker 與 Bun 1.3+。官方 Quick Start 還需要 CopilotKit Intelligence project／license 與模型 API key。不要在公司 Production 主機直接做故障注入，也不要讓測試 browser profile 沿用真實工作登入。

git clone https://github.com/CopilotKit/openbot.git
cd openbot
git checkout --detach a6bada954e4a2bc696c6617d3f4c7a1512230990
test "$(git rev-parse HEAD)" = "a6bada954e4a2bc696c6617d3f4c7a1512230990"

cp .env.example .env
docker compose build agent-computer
docker image inspect openbot-agent-computer:latest \
  --format '{{.Id}}' | tee openbot-computer-image-id.txt

openbot-computer-image-id.txt 應該是 sha256:…。為了讓 supervisor 使用這個已解析 ID，而不是日後可能移動的 tag，在專案根目錄建立只供本 Lab 使用的 docker-compose.override.yml：

services:
  supervisor:
    environment:
      COMPUTER_IMAGE: $OPENBOT_COMPUTER_DIGEST

接著把剛才的完整 sha256:… 寫入 .env 的 OPENBOT_COMPUTER_DIGEST。這個 override 只改 supervisor 要啟動的 computer image，不改 Compose 自己建立的範例服務。啟動後仍要以 docker inspect 回讀實際 ID；「我有設定」不是「它真的採用」。

同一份 .env 再設定 COMPOSE_PROJECT_NAME=openbot-security-lab-20260826 與 COMPUTER_NAMESPACE=openbot-security-lab-20260826，避免清理時碰到其他部署。還有一個容易被啟動訊息誤導的網路事實：目前 Bun API 只指定 port，預設可能監聽 0.0.0.0；畫面印出 localhost 不代表只綁 loopback。啟動後用 lsof -nP -iTCP:3001 -sTCP:LISTEN 查實際 listener，並從同網段另一台機器做負向連線測試；若 VM／firewall 沒有阻擋 inbound，Lab 先判 Fail。

步驟二：關閉單一管理員捷徑，建立低權限使用者

目前的官方變數是 OPENBOT_SINGLE_USER=true；它會把每個 request 都當成同一位 administrator。舊變數 OPENBOT_DEV_NO_AUTH=true 在相容程式碼中也仍會啟用相同行為，而且 NODE_ENV=production 不會自動關掉它。請從 .env 刪除或註解兩者，再選 Google、Microsoft 或 Okta 其中一種 OAuth。以下只列共同欄位，Client ID／Secret 依你選的 provider 補齊：

NODE_ENV=production
BETTER_AUTH_URL=http://localhost:3001
BETTER_AUTH_SECRET=用 openssl rand -base64 32 另行產生
TRUSTED_ORIGINS=http://localhost:3010
INITIAL_ADMIN_EMAILS=admin@example.com

# 保持未設定
# OPENBOT_SINGLE_USER=
# OPENBOT_DEV_NO_AUTH=
# AGENT_COMPUTER_ALLOW_PRIVATE_HOSTS=

INITIAL_ADMIN_EMAILS 是永久的管理員底線；其中的地址不能在 People 畫面降權。用第二個瀏覽器 Profile 登入另一個測試帳號，保持角色為 user，確認它開啟 /admin/boundaries、/admin/audit 與 /admin/computers 都被拒絕。這一步若沒有可用的 OAuth 測試帳號，請在收據寫「Identity boundary：未測」，不要以 localhost 單人模式冒充低權限驗收。

Secret 要放在 .env 或 OpenBot 的 write-only credential store，不要放進 Bot prompt、workspace 或教學截圖。更完整的分層做法可參考 AI Agent Secret 安全指南。

步驟三：先把最小 Policy 寫進環境，再啟動

OpenBot 的 Policy engine 是 default-deny：沒有 Policy、allow 為空，或 allow 規則壞掉，都不會產生權限。但 fresh install 另有一個明確的 shipped default：{"mode":"enforce","deny":[],"allow":["true"]}，也就是「所有沒有被 deny 的動作都允許」。不要把引擎的 fail-closed 與產品的初始 allow-all 混為一談。

在第一次啟動的 fresh database，將下面 JSON 壓成一行放進 AGENT_COMPUTER_POLICY。它拒絕所有 Shell、所有 activate、名為 .env 的檔案與 MCP write；只允許 httpbin 與刻意加入的 loopback 測試位址、一般 workspace file action，以及 MCP read。把 mode 固定為 enforce，因為 dry-run 雖然會記錄「本來該拒絕」，卻仍會把動作送去執行。

{
  "mode": "enforce",
  "deny": [
    "intent == \"run_command\"",
    "intent == \"activate\"",
    "file.name == \".env\"",
    "mcp.effect == \"write\""
  ],
  "allow": [
    "(intent == \"navigate\" || intent == \"read\") && (page.host == \"httpbin.org\" || page.host == \"127.0.0.1\")",
    "intent == \"type\" && page.host == \"httpbin.org\"",
    "intent == \"read_file\" || intent == \"write_file\" || intent == \"list_files\"",
    "mcp.effect == \"read\""
  ]
}

為什麼 allow 中故意放入 127.0.0.1？因為這次要驗證第二道 target guard：Policy 先允許這個合成測試，下一層仍應拒絕 private／loopback address。它不是日常 Policy 範本；Lab 結束後應拿掉。官方 Policy source 也提醒，command 字串過濾不是安全邊界，因此我們直接拒絕整個 run_command intent。

npx --yes copilotkit@latest login
npx --yes copilotkit@latest project select
npx --yes copilotkit@latest license --write

# 完成 .env 其餘必要金鑰後
bun install
bash scripts/start.sh

打開 http://localhost:3010/admin/boundaries 回讀 mode、deny 與 allow。若這個 database 先前已保存 Policy，資料庫版本會優先於環境；最簡單的 Lab 做法是用全新的 Compose project／database，而不是猜目前套用哪一份。

步驟四：建立 Bot A／B，驗證資源分離與認證缺口

用一般使用者在 /agents 建立兩個 private coworkers：lab-a 與 lab-b。分別請它們開啟 https://httpbin.org/forms/post，觸發 computer 建立。然後在 host 保存下列收據：

docker ps --filter label=openbot.namespace=openbot-security-lab-20260826 \
  --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

for id in $(docker ps -q --filter label=openbot.namespace=openbot-security-lab-20260826); do
  docker inspect "$id" --format \
  'name={{.Name}} bot={{index .Config.Labels "openbot.bot-id"}} image={{.Image}} security={{json .HostConfig.SecurityOpt}} caps={{json .HostConfig.CapDrop}} mounts={{range .Mounts}}{{.Name}}:{{.Destination}} {{end}} networks={{range $name, $_ := .NetworkSettings.Networks}}{{$name}} {{end}}'
done | tee openbot-isolation-receipt.txt

合格輸出要看到兩個不同的 openbot-computer-<botId>、不同的 openbot-profile-<botId> 與 openbot-workspace-<botId>，image ID 都等於第一步保存值，並帶有 no-new-privileges:true、CapDrop=["ALL"]。還要確認 Networks 沒有 PostgreSQL 所在的 data network。

到這裡只能判定「資源分離」。在這個 pinned commit，supervisor 會把同一個 process-level COMPUTER_TOKEN 交給每個 computer，而 computer 的 Bot ID header 也不是和該 Token 做一對一綁定。不要把 Secret 或它的 hash 印進收據；直接把「per-Bot 認證隔離」標為未成立，直到你能以修正版與 runtime negative test 證明 Bot A 不能驅動 Bot B。

這也不是 VM 等級隔離：預設 Docker container 共用 host kernel，standalone computer image 內的程序不是以非 root Unix user 執行，Chromium sandbox 也只有設定 COMPUTER_SANDBOX=on 且 host 相容時才啟用。若 host 支援 gVisor，可設定 COMPUTER_RUNTIME=runsc 再重做收據；否則只在拋棄式低價值主機上測，不能因為 Volume 分開就讓任意不受信任程式碰 Production。想理解 workspace 為什麼仍要再做路徑限制，可搭配 Agent Workspace 完整指南。

步驟五：注入 5 種故障，逐一對 Audit 與副作用

每次測試前先記時間、Bot ID、actor，測完立刻到 /admin/audit 篩同一個 Bot。不要只看聊天文字；模型可能用另一個工具完成相似目標。以下每一列都要同時滿足「Row 形狀」與「外部副作用」才算 Pass。

1. 受控刪除：證明 Policy-before-action

先用允許的 file tool 建立 lab/canary.txt，再要求 Bot 執行 rm -f lab/canary.txt。這不是刪真實資料，而是只碰拋棄式 workspace 裡的 canary。預期只有 computer.action_refused：decision.allowed=false、source=deny、rule=intent == "run_command"、carriedOut=false；重新讀檔時 canary 仍存在。

2. 私有 IP：證明 Policy 之外還有 target floor

要求 Bot 開啟 http://127.0.0.1:5432。因為 Lab Policy 刻意允許這個 host，第一 Row 會是 computer.action_allowed；transport 接著應拒絕 loopback，寫入第二個 computer.action_failed，failure 說明該位址位於 deployment 內部。這個案例也揭露重要限制：官方 target checker 明說它不做 DNS resolution，也不檢查 Chromium 後續 redirect hop，因此它不是完整 SSRF 防護；Production 還要有 egress proxy／network allowlist。

3. 路徑越界：證明 workspace confinement

要求寫入 ../escape.txt，再測一個指向 workspace 外的 symlink。這次 allow 規則接受一般 write_file，但 computer workspace layer 會拒絕 absolute path、.. 與解析後在 root 之外的 link。預期同樣是 allowed Row 加 failed Row，且 host／其他 Bot Volume 都沒有新檔。

4. 人工接管：證明控制權有起點與終點

讓 Bot 遇到測試登入頁並請求協助，按 Take control，做一個無敏感資料的輸入，再 Release。Audit 應依序出現 computer.help_requested、computer.control_taken、computer.control_released，actor 與時間能界定人類接管區間。接管中再測一次 browser action，預期被拒絕而不是排隊補做；另外測 file action。Pinned commit 的 open issue #246 指出 Take control 尚未涵蓋 file／exec，因此這一版只能把 browser handover 判 Pass，不能把「接管時所有 Bot 動作都停止」判 Pass。本文 Policy 已另行拒絕 Shell，但那是 Policy 補償，不是 handover 本身的保證。

5. MCP write：證明 grant 不是最後一道門

這項只在你已用 throwaway account／workspace 完成官方 connector、Refresh tools 並授權該 Bot 時測。先呼叫一個 read tool，預期通過；再要求一個明確 write tool，但不要確認任何外部寫入。預期 grant 先成立，接著 mcp.effect == "write" 命中，留下 mcp.call_rejected 與 rule，vendor 不收到 call。沒有合適的拋棄式 connector 就寫 N/A；不要為了把格子塗綠而連結真實公司資料。

最容易看錯的是 decision.carriedOut。在目前程式碼裡，它表示 gateway 是否把 action 往下送；allowed action 後來仍可能失敗。因此「allowed + carriedOut=true」不是完成證明，要再看 failure Row、目標頁面、檔案或 vendor 端的可觀察結果。反過來，dry-run 的 refused Row 也可能是 carriedOut=true，因為 dry-run 本來就會放行。

Audit 覆蓋面也要分清楚：computer 的 acting calls 先寫決策，失敗再補 Row；被 Policy／grant 拒絕的 MCP call 會在停止前寫 mcp.call_rejected，但獲准的 MCP call 是 vendor 回應後才寫 succeeded／failed。Screenshot、snapshot、page read 與人類接管期間的每個鍵鼠動作也不逐筆走同一套 Policy Audit。本文驗收的是明列的 governed action，不是宣稱所有觀察與輸入都有完整事件。

步驟六：量每 Bot 的 Chromium 成本，不抄別人的 RAM

官方 arm64 測量提供一個量級參考：單一 Bot 約 409 MB idle、載入三頁後 498 MB、snapshot 後 548 MB，映像約 5.3 GB；每多一個並行頁面約再加 100～200 MB。這些是官方指定環境的樣本，不是你的容量保證。請在 A/B 都 idle、各開一頁、各 snapshot 三個時間點執行：

date -Iseconds | tee openbot-resource-receipt.txt
docker stats --no-stream --format \
  '{{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.PIDs}}' \
  $(docker ps -q --filter label=openbot.namespace=openbot-security-lab-20260826) \
  | tee -a openbot-resource-receipt.txt

docker system df -v | tee openbot-disk-receipt.txt

若 RAM 接近 host 上限，結果不是「再加 swap 就好」；應減少同時運作的 Bots／tabs、設定 supervisor memory limit，或把高風險執行移到更強的 sandbox。資源耗盡也是隔離失敗的一種：Bot A 能讓 Bot B 與資料庫一起失去回應，就不算可用的多租戶邊界。

步驟七：先列清單、再拆除，最後做空集合驗證

OpenBot 的 per-Bot computers 是 supervisor 建立，不屬於 Compose；因此 docker compose down -v 不會自動移除它們，browser profile 與 workspace Volume 也會留下。先把精確 label 查詢結果存檔，人工確認只包含這次 Lab 的 namespace，再執行清理：

docker ps -a --filter label=openbot.namespace=openbot-security-lab-20260826 \
  --format '{{.ID}} {{.Names}}' | tee cleanup-containers-before.txt
docker volume ls --filter label=openbot.namespace=openbot-security-lab-20260826 \
  --format '{{.Name}}' | tee cleanup-volumes-before.txt

# 逐行核對上面兩份清單後才執行
docker ps -aq --filter "label=openbot.namespace=openbot-security-lab-20260826" \
  | xargs -r docker rm -f
docker volume ls -q --filter "label=openbot.namespace=openbot-security-lab-20260826" \
  | xargs -r docker volume rm
docker compose -p openbot-security-lab-20260826 down -v --remove-orphans

最後重跑兩個 label query，保存空輸出；再撤銷模型 key／OAuth test secret、刪除測試 connector grant 與測試帳號。若曾連外部 vendor，還要在 vendor 端撤銷 OAuth；本機 People revoke 不等於 vendor revoke。CopilotKit Intelligence 的 thread／memory 與模型供應商資料也不在這些本機 Volumes，須依各自 retention／刪除機制另外處理。若你保留 Audit export 作為收據，先確認不含 command 以外的敏感輸入；file body 或 secret-supply value 不放進 computer Trail，但 command 本身會完整記錄，所以測試命令也不要夾帶 Token。

完整示範：一個 canary 為何需要看兩種證據

假設 Bot A 已用 file tool 寫入 lab/canary.txt，內容是 keep-me。你要求它以 Shell 刪除。聊天畫面回覆「Policy 不允許」，Audit 也有 refused Row，這仍只完成一半；再以 read file 讀回 keep-me，才證明沒有副作用。接著 Bot B 讀取同一路徑應找不到檔案，才補上跨 Bot Volume 隔離。

這個例子把三個常被混在一起的問題拆開：Policy Row 回答「gateway 做了什麼決定」，canary 回答「目標狀態是否改變」，Bot B 的結果回答「另一個隔離域能否看到」。在 AI Agent Harness 裡，這正是把 guardrail 變成 regression test 的方式：每個控制都要有故意讓它失敗的案例。

最常見的 6 個誤判

1. 看到 Digest 就宣布安全：Digest 證明版本，不證明 supervisor、network 或 Volume 拓撲。
2. 把不同 Volume 當完整跨 Bot 隔離：目前 computers 共用一個 COMPUTER_TOKEN，資源分離不等於認證分離。
3. 看到 localhost URL 就以為只綁 loopback：目前 API 可能監聽 wildcard；要查 listener 並用 VM／firewall 阻擋 inbound。
4. 把 default-deny 當成 fresh install 行為：引擎沒有 allow 會拒絕，但 shipped Policy 明確是 allow:["true"]。
5. 用 dry-run 做阻擋驗收：它會記錄拒絕，也會 forward。
6. 把 private-host guard 當完整 SSRF 防護：目前不解析 DNS，也不驗 Chromium redirect hop。

常見問題 FAQ

1. 可以直接使用 v0.0.4 的官方 Digest 做這個 Lab 嗎？

不適合驗收每 Bot 隔離。v0.0.4 all-in-one 沒有 supervisor，Bots 共用 browser／workspace。可把 Digest 當 release provenance，但本文的隔離 Lab 要用固定的後續官方 commit 與 supervisor。

2. localhost 就可以保留 OPENBOT_SINGLE_USER 嗎？

只做單人功能冒煙可以；低權限驗收不行。該模式所有 request 都是同一位 administrator，無法證明一般 user 的管理頁與權限邊界。

3. Policy 寫錯會不會意外放行？

壞掉的 deny 會拒絕，壞掉的 allow 不會授權。但 shipped Policy 本身是 allow-all，而且過寬的合法規則仍會照寫法放行；所以必須做 fault injection。

4. action_allowed 代表網站或檔案已經改成功嗎？

不代表。它是執行前的 Policy 決策。底層若失敗會再有 action_failed；若要證明成功，還要檢查目標狀態或 vendor 結果。

5. 拒絕 127.0.0.1 就沒有 SSRF 風險了嗎？

沒有這麼簡單。目前 checker 處理 literal private／metadata address，但不解析 DNS 或 Chromium redirect hop；Production 仍需 network egress control。

6. 每個 Bot 一個 container 就能放任它跑任何 Shell 嗎？

不能。普通 Docker container 共用 host kernel，image 內程序也可能是 root，而且目前 computers 共用控制 Token。Shell 要由 Policy、capability drop、network、resource limit 與更強 runtime 一起限制。

7. 沒有 Notion 或 Google Drive 測試帳號，MCP 那格怎麼辦？

填 N/A，不要接真實資料。其餘 browser、file、shell 與 handover 仍可驗；等有 throwaway connector 再補 MCP regression receipt。

8. Lab 完成後可以直接搬到 Production 嗎？

不能只靠這份結果。還要補 TLS、正式 IdP、API bind／firewall、egress、secret rotation、外部資料 retention、備份、監控、資源限制、升級回歸與 incident response；而且 OpenBot 目前仍是 Alpha，open issue #236 也仍在質疑 replacement／multi-replica 的 stale reference 行為。

給新手的 5 個重點

1. 先鎖 Git commit 與實際 image ID；版本收據不能替代拓撲驗收。
2. 不同 container／Volume 只證明資源分離；共用 Token 讓強跨 Bot 隔離在此版仍未成立。
3. 關閉 single-user admin 捷徑，Policy 固定用 enforce，deny／allow 都要故障注入。
4. Audit decision、failure Row 與目標副作用要成套閱讀。
5. 最後清掉 supervisor containers、Volumes、Secrets、grants 與帳號，再用空集合查詢收尾。