為什麼 AI workflow builder 出現暴露風險後，第一件事不是急著輪替憑證？

先把問題問對：你要找的不是產品名，是流程裡的鑰匙

很多團隊在看到 workflow builder 出事時，會先問：「我們有沒有用 Langflow？版本有沒有修？」

這題當然要問，但它只解掉第一層。更重要的是接下來四個問題：

• 哪些 flow 曾經對外、對內網、對測試帳號或對不明使用者開放？
• 哪些 flow 內含憑證、環境變數、連線字串或可代入的 secret？
• 哪些 flow 能讀到客戶資料、內部文件、CRM、ticket、資料庫或檔案系統？
• 哪些 flow 曾被執行、重放、匯出、複製，或被不該碰的人看過？

如果你以前處理過 CRM 串接 token 外洩，這裡的邏輯很像：不要只問「哪一把鑰匙漏了」，要先畫出它能開哪些門。可以參考這篇相鄰情境：CRM 串接 token 外洩後，先畫出資料邊界。

AI builder 多了一個麻煩：憑證可能不只放在一個設定頁。它可能藏在節點設定、環境變數、測試 input、prompt 範例、connector 設定、匯出的 JSON、舊版 flow、副本 flow，或某個「暫時先用 admin token」的測試節點裡。

所以第一步先別猜哪個 token 最危險，先把「流程曾經怎麼跑」還原出來。

40 分鐘第一輪盤點：不要靠大家在群組裡回憶

如果團隊只有兩三個工程師、一個產品負責人、一個懂系統串接的人，第一輪盤點不需要開成大型 war room。你可以用 40 分鐘做出可行版本。

第 1 步：先止血，並凍結會改變證據的動作

先做四件事：

1. 暫停公開分享連結、可疑 webhook、對外 API route，或任何未知帳號可觸發的入口。
2. 對可疑期間曾被觸發、或內含 production token 的高風險 flow，先停用執行，不急著刪除設定。
3. 匯出或截圖目前的 flow 清單、connector 清單、環境變數名稱與權限頁面。
4. 保全 builder access log、flow execution log、API gateway log、outbound webhook log。

這裡要小心：不要一看到 secret 就把所有畫面貼進共享文件。共享文件可以記「token 類型、權限範圍、owner、最後使用時間」，不要記 token 原文。

API 可以先理解成「系統和系統之間交換資料的接口」。如果 builder 背後有 API gateway 或 reverse proxy，請把那邊的 log 一起保留，因為 builder 介面裡的紀錄常常不夠完整。

第 2 步：列出所有 flow，不只列正在用的

請把 flow 分成四群：

• production 正在跑：會影響客戶、內部營運或正式資料。
• staging / sandbox：理論上只碰測試資料，但仍可能拿到正式 token。
• archived / disabled：已停用但設定還在，可能仍能被複製或匯出。
• personal / experiment：個人測試、demo、臨時接的 PoC，最常藏著未命名 token。

很多事故漏查的點都在後兩群。因為它們不在監控圖上，也沒被寫進正式架構文件，可是當初測試時可能為了快，直接貼了有權限的 key。

第 3 步：替每條 flow 標四個欄位

這裡用一張表就夠了，避免把盤點變成表海。

這張表有兩個用法。第一，它讓工程師不要憑印象說「那只是測試 flow」。第二，它讓非工程的 owner 看得懂為什麼某個 token 要先換、某個 flow 要先停。

如果你的團隊已經在設計 agent 授權，也可以把這裡接到另一張更早期的檢查表：AI agent 授權四問表：身份、權限、理由、後果。那篇偏向事前設計，本文偏向事後盤點；兩者合起來，才不會讓 agent 只靠「看起來有登入」就拿到過大的權限。

第 4 步：先處理可被執行的 flow，再處理只被看見的 flow

不是所有暴露都同等嚴重。你可以用這個順序排隊：

1. 可疑期間內被執行，且內含 production token 的 flow。
2. 可疑期間內被讀取或匯出，且設定中可見 secret 名稱、connector、內部 endpoint 的 flow。
3. 沒有執行證據，但曾公開分享、權限過大或 owner 不明的 flow。
4. 已停用但仍可複製、匯出或被 admin 帳號重新啟用的 flow。

queue 是待處理清單／排隊中的任務。這裡的 queue 不要只寫「換 token」。請把每一項拆成：哪條 flow、哪個 credential、哪個 owner、哪個系統、哪個驗證方式。

例如不要寫：

• 換 Salesforce token。

改成：

• Flow lead-summary-prod 使用的 Salesforce OAuth app（讓 flow 代表某個授權身分存取 Salesforce 的連線設定）：暫停 refresh token，改發最小權限 app，確認最近 100 次 flow execution 沒有未知執行者，owner：RevOps，驗證：Salesforce Login History + builder execution log。

這種寫法才方便追蹤，也方便事後交接。

production token 邊界要重設，不只是換同一把鑰匙

credential rotation 常見失誤，是把舊 token 換成一把權限一樣大的新 token。短期看起來處理完了，長期風險沒有下降。

輪替時請順手做四件事：

1. 把 production token 從個人帳號改成 service account。
2. 把讀寫權限拆開；摘要 flow 不應同時有刪除資料的權限。
3. 設到期日與 owner；沒有 owner 的 token 不進 production。
4. 把 builder 可用的 secret 名稱改成用途導向，例如 crm_read_contacts_prod，不要叫 admin_key 或 test_key。

owner 是負責最後判斷與收尾的人。這裡的 owner 不是「當初建立 flow 的人」，而是能決定這把 credential 是否該保留、縮權、輪替或停用的人。

如果你只完成 rotation，沒有重設邊界，下次 builder、agent 或 connector 出事時，團隊還是會回到同一個問題：到底哪一條 flow 拿過哪一把過大的鑰匙？

第一個最小起步動作

如果你現在只能做一件事，請先把仍可能被外部觸發的入口暫停：公開分享連結、可疑 webhook、對外 API route、外網 admin 入口，以及含 production token 的高風險 flow 執行。不要刪除 flow、connector 設定或日誌。

入口先收回受控範圍後，再開一份「AI flow credential inventory」，優先列出 production 與最近 30 天內執行過的 flow。

每條 flow 只填五欄：

1. flow 名稱與 ID。
2. owner。
3. 連到哪些外部或內部系統。
4. 使用哪些 credential 名稱，不填 secret 原文。
5. 最近一次執行時間與日誌位置。

這份 inventory 不需要等事故才做。平常每月更新一次，出事時就能直接變成 incident response 的起點。

用日常來理解

1. 團隊看到 AI workflow 的入口敞開，先停在門口，不急著把所有鑰匙重配一遍。
2. 他們先把入口收回受控範圍，保留日誌和設定，避免證據被刪掉。
3. 接著沿著 flow 盤點哪些 connector、資料來源和 token 真的可能被碰到。
4. 最後只輪替或停用真正受影響的鑰匙，並確認入口已關、舊憑證已失效。