【2026 最新】Treg 安全實戰：一把 Token 接 3,000+ Agent 工具，先驗證金鑰、費用與撤銷

你把一個 Token 交給 Agent，下一秒它就能搜尋社群、查 SEO、找公司資料，甚至呼叫影像與影片工具。這很像把一張萬用門禁卡交給一位動作很快的新同事：方便是真的，但你更該先問——他能開哪些門、每次刷卡多少錢、出事時要剪掉哪一張卡？這正是 Treg 安全實戰要解決的問題。

本文專為第一次替 AI Agent 串工具的人寫。不假裝 AlphaLab 已用你的帳號跑過 production key，也不要求你先懂資安術語；我們會用一把低權限測試金鑰，帶你看懂 hosted、BYOK 與 self-host 三種路徑，建立費用收據，再演練外洩、超額、上游故障與完整撤銷。想先理解 Agent 為何需要執行層，可搭配 AI Agent Harness 是什麼。

先說結論：Treg 是工具總機，不是免責保險箱

• 它做什麼：Agent 用一個 Treg token 找到並呼叫大量工具；Treg 在伺服器端選定工具、注入憑證，再把請求轉送上游。
• 它改變哪個邊界：使用者端不必持有每個 provider key，但 hosted Treg 會進入請求、回應與計費路徑。
• 最小安全起點：另外建立實驗 team、專用 Agent token、read-only 上游 key、每日額度與可重跑的撤銷清單。
• 什麼時候 self-host：當資料不能經過第三方 proxy、你能自己管資料庫／加密金鑰／更新與監控，而且願意承擔維運責任。

一句話記住：安全接工具＝最小權限憑證＋可對帳收據＋雙重撤銷＋可替代部署。少了任何一項，「一把 Token」都只是把複雜度藏起來，沒有讓風險消失。

Treg 安全實戰第一步：先畫出三條資料流

截至 2026 年 9 月 23 日，Treg 的官方 catalog已是數千個 endpoints 的規模；官方 README、agent 頁與 live catalog 的精確總數並不同步，因此本文只用「3,000+」作穩定概括，不把它當成 inventory contract 或安全認證。真正重要的是同一個指令，在三種部署方式下會經過不同的人。

① Hosted catalog：「Treg 代墊工具帳號」

Agent 把請求送到 treg.to，Treg 使用自己的 provider credential 轉送，再從 team 的 prepaid balance 扣款。官方定價頁表示，價格會在呼叫前顯示，按 provider rate 計費且不加價；符合資格的 verified account 可能取得一次 promotional balance，但它不是每建立一個 team 都重送。白話說：Treg 是付款櫃檯，上游 provider 仍是實際提供資料的人。

② Hosted BYOK：「Treg 保管你的 key」

BYOK（Bring Your Own Key）是把你自己的 provider key 加進 Treg。官方文件指出，secret 會加密保存、在 server side 解密並注入，而且不會透過正常 API 回傳給 caller；這能防資料庫單點外洩直接拿到明文，卻不是 client-held key 或 end-to-end encryption。這類呼叫通常不扣 Treg balance，但 upstream provider 的方案、quota 與帳單照常存在。不扣 Treg 餘額，不等於這次 API 是免費的。

③ Self-host：「你接手整個總機房」

Self-host 讓請求、secret 與 audit database 留在你的基礎設施。官方隱私政策明確區分：self-hosted 資料不會到 Superdesign，但 operator 會變成資料控制者。換句話說，你移除了 hosted broker，卻同時接手 HTTPS、資料庫備份、Fernet encryption key、更新、告警與災難復原。

Hosted 到底看得到什麼？

請求與回應必須經過 proxy，所以 Treg 在傳輸路徑中會處理內容。2026 年 7 月 22 日更新的 Privacy 頁寫著 proxy body 不落盤，只保留 caller、tool、method、path、status 與 timestamp；但現行 source tree 的 archive architecture與 API 已包含保存部分 result body 的路徑，而 hosted production 的 archive 設定不公開。結論不是猜哪份文件才對，而是在 operator 書面確認 archive mode、retention 與刪除範圍以前，不把敏感 body 送進 hosted 路徑。

Treg 安全實戰第二步：只用 read-only 測試 key 上線

最小權限不是把工具命名為 readonly，而是讓真正的 upstream credential 沒有寫入能力。Treg 的 tool access 決定「能不能叫這個工具」；API key scope 則由上游 provider 決定「叫了以後能做什麼」。兩層都要縮小。

步驟 1：建立隔離的實驗環境

1. 另外建立 lab team，不要直接加入 production team。
2. 在 provider 端建立可撤銷、read-only、短效或低 quota 的測試 key。
3. 替 Agent 建立獨立 Treg key，只開放這一個 tool，設定 call cap 與 HTTP method deny rules。
4. 準備一筆不含個資與商業機密的固定查詢，作為 smoke test。

先安裝 CLI，再登入實驗 team。官方 quickstart 是：

curl -fsSLo /tmp/treg-install.sh https://treg.to/install.sh
less /tmp/treg-install.sh
sh /tmp/treg-install.sh
treg login
treg catalog search "backlinks for a domain"
treg balance

若你不想讓 scanner 上傳任何東西，先跑 read-only preview：treg scan env --env-file .env.treg-lab。官方 CLI 文件把 scan 定義為只列出可能註冊的 keys／skills，資料不會離開本機；真正會註冊的是後續的 upload。

步驟 2：註冊專用工具，不共用 production key

下面以 read-only GitHub fine-grained token 為例。請在 provider 端先把 repository access 與 permissions 縮到最低，再把 placeholder 換成測試值；不要把真實 token 寫進文章、issue 或聊天紀錄。

# .env.treg-lab 只放可撤銷的測試 key
treg secret add GITHUB_READONLY \
  --env-var GITHUB_READONLY_TOKEN \
  --env-file .env.treg-lab
treg tool add github-readonly \
  --base-url https://api.github.com \
  --secret <SECRET_ID>
treg call github-readonly user
treg calls --limit 10

通過條件不是「拿到 200」而已，而是四件事同時成立：client 只持有 Treg token；secret inventory 不回傳完整 provider key；只讀查詢成功；用同一把 provider key 嘗試寫入時被 provider scope 拒絕。最後一項才是在驗證 read-only，不能用工具名稱代替。

步驟 3：先限制 Agent，再擴大工具

Treg 的角色是 owner、admin、member、viewer，並支援 per-member tool access、call cap 與 deny rules。要注意：viewer 只是不能改 registry，不代表 upstream 只能讀。別把人類 owner token 複製給 Agent；替每個 Agent 建獨立 key、單一 team、最少 tool list，並先拒絕 POST、PUT、PATCH、DELETE。這和 Skill Router 的原理相同：能力很多沒關係，真正載入與可執行的集合必須小。

treg org agent-new audit-bot \
  --role viewer \
  --tools github-readonly \
  --local-run off \
  --cap 100

treg org deny --method POST   --user <USER_ID> --note 'read-only bot'
treg org deny --method PUT    --user <USER_ID> --note 'read-only bot'
treg org deny --method PATCH  --user <USER_ID> --note 'read-only bot'
treg org deny --method DELETE --user <USER_ID> --note 'read-only bot'

HTTP method fence 仍是第二層：有些讀取 API 使用 POST，少數設計不良的 GET 也可能有 side effect。最強邊界仍是 provider-issued read-only key／OAuth scope；Treg rules 用來縮小誤用與外洩半徑。

同一任務怎麼比較：直接 API、獨立 MCP、Treg

沒有帳號與合法測試 key，就不該捏造延遲或費用數字。因此這裡提供一個可重跑的驗收方法：固定同一個 read-only GET、同一份輸入、同一 provider 與同一網路，三條路各跑 10 次；記錄 p50／p95 latency、成功率、錯誤原文、client 是否持有 key、收據能否對回 request。

• 直接 API：路徑最短，但 client／Agent runtime 必須能取得 provider key；audit、重試與費用歸戶要自己做。
• 獨立 MCP：可以把 key 留在 MCP server，並用 tool schema 約束輸入；但每個 MCP 的 auth、log、更新與故障復原各自不同。上 production 前可用 MCP Production 7 關做驗收。
• Treg：用一套 token、catalog、policy 與 call log 統一工具；代價是多一個 broker、額外 latency、hosted 服務可用性，以及更集中的權限 blast radius。

Treg 的 treg calls 是 metadata audit log，不是完整 request／response replay，也不是 cryptographically signed receipt。現行 source 的 audit writer 是 fire-and-forget，壓力過高時允許丟 row，所以它適合日常追查，不應單獨承擔法遵證據。Catalog call 可從 call ID、cost response 與 treg balance --json對帳；BYOK 不扣 Treg balance，需再對上 upstream bill。若你的 Agent 同時暴露幾百個 schema，還可搭配 Lazy Schema Loading，避免「能找到很多工具」變成 context 爆量。

四場故障演練：外洩、超額、provider 掛掉、broker 掛掉

演練 1：Treg token 外洩

先 disable 或 revoke 該 agent key，再查它的 Activity／call history，確認外洩窗口內呼叫了哪些 tool；接著 rotate replacement key，更新唯一使用者，最後用舊 token 重跑 harmless request，必須得到拒絕。Treg token 外洩不代表 provider key 已被讀出，但攻擊者可在 token 的角色、tool list 與 cap 範圍內代你呼叫。公開文件沒有承諾 revoke 會取消已在途請求或已送出的 async job，這兩類要另查 provider。

演練 2：費用超額

關掉 auto top-up，將 lab team 與 agent key 的 daily cap 主動設到你願意損失的上限，先用 treg catalog get <endpoint-id>看單價，再用 treg balance --json記錄前後差額。Support 頁仍寫著 US$5 default ceiling，但現行 source config 的 shipped default 是 0，代表沒有預設上限；所以驗收時要讀回實際設定，不能把宣傳頁當成已生效的煞車。餘額不足是 HTTP 402，Treg 自有 provider capacity 不足則是 503，兩者處置不同。

演練 3：上游 provider 故障

普通 vendor endpoint 不會默默換 provider；只有明確的 treg.* routed endpoint 才會依規則嘗試候選 provider，並在 response 中列出 served-by、tried 與 charged amount。驗收時要故意模擬 401、429、503 與 timeout，為每種錯誤定義「停止、稍後重試、切自己的 key、改用替代 provider」其中一個動作。

演練 4：Treg hosted 故障

官方條款把 hosted service 定位為 early access，沒有 uptime SLA。因此 production workflow 要先定義 bypass：低風險流程可以排隊重試；關鍵 read-only 查詢可保留 direct API；涉及寫入的動作則應停下來等待人工確認。先畫好 fallback，比故障時臨時把 production key 貼進 prompt 安全得多。

Hosted、BYOK、Self-host 怎麼選？

• 選 Hosted catalog：你在做公開資料、低敏感工作，需要先用小額、按次計費驗證工具價值。
• 選 Hosted BYOK：你已有 provider 合約與 quota，願意讓 Treg 代管 key，並需要 team policy、統一 audit 與集中撤銷。
• 選 Self-host：資料政策不允許第三方 broker 經手，而且團隊已有 secret management、database、TLS、backup、monitoring 與 on-call 能力。
• 先不要接：你無法把 production key 降權、無法限制費用、沒有上游撤銷權，或寫入動作沒有人工 gate。

Self-host 還有一個容易漏看的現況：官方 SECURITY.md 目前把 server-side CLI run 的完整 filesystem／network isolation 列為已知限制；resource limit 與 allow-list 不等於完整 jail。若你只用 HTTP proxy，風險面不同；若要開 treg run --server，就必須另外驗收容器隔離與 egress policy。

完整撤銷與卸載：要拆兩把鎖，不是一把

1. 停止 Agent：先停 scheduler、MCP connector 與所有 background job，避免邊刪邊重試。
2. 撤銷 Treg 身分：disable／revoke agent key，移除 member access，確認舊 token 不能再呼叫。
3. 刪除工具與 secret：先刪除綁定的 tool，再刪 secret；官方 CLI 是 treg tool rm <id> 與 treg secret rm <id>。
4. 撤銷 upstream：回 provider console rotate／delete 真正的 API key 或 OAuth grant。官方條款也建議 broker 與 source 兩邊都撤銷。
5. 清理本機：移除 MCP 設定、Treg config 中的 token 與自動啟動項；保留一份不含 secret 的 audit export。
6. 若是 self-host：停止服務，依內部 retention policy 處理 database、backup 與 Fernet key；最後從乾淨 client 驗證舊 token、舊 provider key 與舊 URL 都無法完成呼叫。

要把這套流程變成可自動重跑的 Agent Harness，可接著看 最小 AI Agent Harness 實作：把「成功」定義為每一個撤銷 gate 都回傳預期結果，而不是 Agent 說「清理完成」。

常見問題 FAQ

1. 一把 Treg token 等於能用全部工具嗎？

不一定。Token 綁定 user／org membership，實際範圍還受角色、per-member tool access、agent key 設定與 call cap 影響；但同一把 token 可橫跨多工具，所以仍要當成高價值憑證。

2. Hosted Treg 會看到我的資料嗎？

會經手；是否保存 body 目前不能只靠公開頁下定論。Privacy 頁說 proxy body 不落盤，但現行 source 已有 archive result 的能力，production 設定未公開。敏感資料要等 operator 確認 archive mode／retention，或改走你能控制的 self-host／direct path。

3. BYOK 呼叫真的免費嗎？

只是不扣 Treg balance。Provider 仍可能依你的訂閱、credits、quota 或 per-call 規則計費，所以收據要同時查 Treg audit 與 upstream billing。

4. Treg 可以取代 MCP 嗎？

不是二選一。Treg 有 MCP surface，也能直接 proxy HTTP；MCP 解決 Agent 如何發現與呼叫 tool，Treg 更偏向 catalog、credential injection、policy、metering 與 audit。

5. 把工具叫做 read-only 就夠了嗎？

不夠。真正邊界在 upstream API key／OAuth scope、Treg tool access、HTTP method 與 provider authorization。一定要用寫入負向測試證明它被拒絕。

6. Self-host 一定更安全嗎？

不一定。它能移除 hosted broker，但把 patch、TLS、database、encryption key、backup、logging 與 incident response 全部交給你；維運能力不足時，風險只是換位置。

7. 刪掉 Treg secret 就算完全撤銷嗎？

不是。還要到 provider 端撤銷 API key／OAuth grant，並測試舊 Treg token 與舊 provider key 都失效；兩層缺一不可。

8. 「3,655 個 endpoints」明天也一樣嗎？

不保證。官方不同頁面的總數本來就不同步；「3,000+」只描述量級。實際呼叫前用 treg catalog get <id>確認該 endpoint、輸入限制與價格。

給新手的 7 個重點

1. 先分清楚 hosted catalog、hosted BYOK、self-host。
2. 用 provider 端的 read-only key，不靠工具名稱想像權限。
3. Agent 與人類分開 token、team、tool list 與 cap。
4. Broker 一定經手 body；保存範圍要以 production archive 設定驗收。
5. Catalog 費用看 Treg ledger；BYOK 費用看 upstream bill。
6. 撤銷要同時拆 Treg token 與 provider credential。
7. 先用 harmless 固定任務跑完故障演練，再擴到 production。