AI 客服最危險的不是不會做，而是太會幫你整理密碼
AI 客服與自動化代理人最可怕的風險，不一定是它不會回答，而是它太會整理、太會複製、太會把敏感資料變成更容易外流的格式。這篇記錄一次真實踩坑：多站應用程式密碼、XML-RPC 測試、權限混亂與自動發布流程帶來的安全提醒。
很多人談 AI 客服，第一個想到的是：
「它會不會回答客人？」
「它能不能幫忙整理需求？」
「它可不可以自動處理流程？」
但實際踩過坑之後，我們發現更危險的事情不一定是 AI 不會做。
有時候，真正危險的是：
AI 太會做。
尤其是當 AI 客服或 AI agent 開始碰到帳號、密碼、網站後台、API、發布工具時，它可能不是不聽話，而是太聽話。
你叫它整理，它就整理。
你叫它轉成方便複製的格式，它就轉。
你叫它測試，它就測。
你叫它幫你自動化，它就一路往前跑。
問題是，這些動作如果沒有安全邊界，就可能把原本只是「暫時使用」的敏感資料，變成一份清清楚楚、很好複製、很好外流的文件。
事情怎麼發生的？
在早期測試 SEO 自動發文與 AI 客服流程時，我們曾經處理過多個網站的 WordPress 應用程式密碼。
那時候的目標很單純：
讓 AI agent 測試能不能透過 XML-RPC 或相關介面操作文章，確認哪些站能讀取、哪些站能更新、哪些站權限不足。
但過程中出現一個很典型的 AI 風險：
AI 會把密碼整理得很「貼心」。
它會幫忙去空格。
它會幫忙補上空格格式。
它會照站台名稱排列。
它會把資料整理成一段一段方便複製的內容。
如果只是看操作體驗，這很方便。
但從安全角度看，這非常危險。
因為 AI 不是只在幫你「整理資料」，它也可能在幫你「提高外洩效率」。
應用程式密碼只顯示一次，AI 卻可能把它變成紀錄
WordPress 應用程式密碼有一個重要特性：
它通常只會在建立當下顯示一次。
這個設計本來是為了安全。
但如果人把它複製出來，貼進聊天、文件、任務紀錄，甚至交給 AI agent 整理，那安全設計就被繞過了。
更麻煩的是，AI 會讓這件事看起來很自然。
例如：
- 幫你整理多站密碼
- 幫你測試哪一組成功
- 幫你判斷哪一組權限不足
- 幫你記錄站台與結果
- 幫你產生給其他 AI 檢視的說明文件
這些步驟單獨看都合理。
但合起來，就變成一條高風險鏈路：
敏感資料被複製、整理、測試、記錄、擴散。
這就是 AI 客服和 AI 自動化很容易讓人忽略的地方。
它不是故意外洩。
它只是太會協助。
XML-RPC 測試不是只有「能不能連上」
早期自動發文測試時，我們也踩到另一個問題：
很多人以為 XML-RPC 或 API 測試，只是在測：
「能不能登入？」
「能不能發文？」
「能不能修改文章？」
但實際上，要測的遠遠不只這些。
還要測：
- 這個帳號到底有什麼權限？
- 只能讀，還是可以寫？
- 發文時會不會改到不該改的內容？
- 修改文章時是改指定文章，還是影響其他草稿？
- 發布流程有沒有只針對指定內容？
- 發布失敗時會不會重試到更危險的範圍？
- 有沒有紀錄文章 ID 與回滾方式？
當時就曾出現一個很重要的事故：
發文流程不只處理了預期內容，還牽連到其他草稿。
這件事讓我們更確定：
自動發文最難的不是「讓它會發」，而是：
讓它只發該發的東西。
AI 客服不是不能碰流程，而是不能沒有邊界
這裡不是要說 AI 客服不能用。
相反地，AI 客服很有價值。
它可以整理需求。
它可以回答常見問題。
它可以協助分類。
它可以幫忙建立初步紀錄。
它可以讓小企業少做很多重複工作。
但只要 AI 客服開始碰到後台、密碼、API、網站發布、客戶資料或內部流程，就不能再把它當成一般聊天工具。
它必須有邊界。
例如：
- 不得保存密碼
- 不得輸出完整憑證
- 不得把敏感資料整理成方便複製格式
- 不得把測試資料寫入公開文件
- 不得自行發布內容
- 不得批次操作未確認項目
- 不得把失敗結果當成可以自動補救的理由
- 不得把舊系統資料直接帶進新系統
AI 客服如果沒有這些規則，看起來會很聰明，實際上卻可能越幫越危險。
為什麼小企業特別容易踩這個坑？
小企業導入 AI 時，常常不是從大型系統開始。
比較常見的是：
「幫我整理一下網站資料。」
「幫我看一下舊後台。」
「幫我測一下能不能發文。」
「幫我把這些帳號資料整理一下。」
「幫我把流程自動化。」
這些需求很真實，也很合理。
但小企業通常沒有完整的資安分工，也不一定有專門的人負責憑證管理、發布權限、測試環境和回滾流程。
所以一旦 AI agent 很會做事，就可能直接碰到正式資料與正式環境。
這不是小企業不小心。
這是小企業導入 AI 時最常見的現實：
流程還沒整理好，AI 就已經開始幫忙跑。
後來我們怎麼修正？
這些踩坑後，SEO7 的治理方向變得更清楚。
第一，憑證不能進聊天紀錄。
第二，憑證不能進 repo。
第三，憑證不能進 evidence capture。
第四，AI agent 不得保存原始敏感資料。
第五，發布前必須有安全檢查。
第六，發布後必須有健康檢查。
第七，測試紀錄必須留存。
第八，沒有 Boss 明確命令，不得 commit、push、deploy。
第九，AI 寫什麼、審什麼、做什麼，都要分清楚。
第十，舊系統只能研究流程，不得直接復活成 runtime。
這些規則不是一開始就完美設計出來的。
很多都是踩坑後才變成硬規則。
最重要的教訓：方便複製，不代表安全
這次最大的教訓是：
AI 幫你把資料整理得越方便，不代表越安全。
尤其是密碼、token、API key、站台後台資料、發布工具設定這類內容。
如果 AI 把它們整理成：
- 清單
- 表格
- 分站資料
- 可複製格式
- 給其他 AI 的說明文件
那就代表風險已經上升了。
所以，以後遇到這類資料，第一個反應不應該是：
「整理得真好。」
而應該是：
「這份資料能不能保存？」
「它是不是該被遮蔽？」
「它是不是該立刻作廢？」
「它是不是不應該進任何文章或 repo？」
「AI 是不是已經碰到不該碰的東西？」
結語：AI 客服真正的風險，是太會幫忙
AI 客服不是不能用。
AI 自動化也不是不能做。
但真正危險的地方，是我們太容易把「能幫忙」看成「可以放心交給它」。
這次踩坑讓我們明白：
AI 最危險的時候，不一定是它不懂。
有時候，反而是它太懂怎麼幫你整理、複製、測試、執行。
所以小企業導入 AI，不要只問：
「AI 能不能幫我做？」
還要問：
「AI 做這件事時，會不會把不該留下的東西留下來？」
「AI 會不會把敏感資料變得更容易外流？」
「AI 會不會把原本只是測試的操作推向正式環境？」
「AI 會不會把一個小錯誤放大成一批錯誤？」
這不是反 AI。
這是讓 AI 真正能安全落地。
AI 很會幫忙。
所以我們更要先教它：
哪些忙不能幫。