每個平台都說自己非常重視安全性。但沒有一家會在資安事件的事後檢討報告裡也這麼說——因為那時候他們終於會描述架構本身，而不只是用形容詞帶過。那我們就直接跳到架構。解釋租戶隔離最簡單的方式，就是看團隊通常會犯的三種錯誤，以及一旦犯錯會出什麼問題。
錯誤一：在應用程式程式碼裡用租戶 ID 做篩選
這是預設做法，因為它看起來是最直覺的寫法：每個查詢都加上一個 WHERE user_id = ? 子句，只要每個開發者都記得加，每個請求就都會停留在自己的邊界內。但問題往往在稍後才會浮現，那時程式庫已經有四百個端點，而不是四個。有人新增了一個聯結兩張表的報表查詢，卻忘了在第二張表加上篩選條件。又有人建了一個「只給內部用」的管理工具，完全沒加任何租戶範圍限制，因為當下感覺很安全。這兩個錯誤都不會觸發任何測試失敗，因為查詢依然回傳有效的資料列——只是回傳了錯的租戶的有效資料列。
我們不會仰賴每一次查詢都「記得」要禮貌地加上篩選條件。列級安全控管是在資料庫層級強制執行的，所以無論呼叫端的程式碼要求什麼，資料庫本身都會拒絕回傳其他租戶的資料列。這裡也沒有留下什麼特權後門——這個政策永遠適用，包括那些我們可能會忍不住認為「可信任」的路徑。
錯誤二：把沙箱當成一種最佳化，而不是一道邊界
這裡的智慧代理會執行真正的程式碼——這正是這個產品的核心所在——而容易讓人妥協的做法，是先在方便的地方執行這些程式碼，等「有空再說」再來鎖定安全性。這種版本的災難，看起來會像是建構過程中引入了一個被入侵的相依套件，並對外連上開放網際網路；或是某個租戶的智慧代理執行任務時讀取了原本不該看到的工作區檔案，因為檔案系統預設是共用的，只有在特殊情況才會被限制。
智慧代理的工作任務會改在隔離環境中執行：
- 鎖定的檔案系統。
- 對外連線採用白名單制度，而不是完全開放。
正在處理你建構專案的智慧代理，看得到的就只有你的工作區，僅此而已。不受信任的程式碼——包括你自己應用程式的建構過程——都會在容器內編譯，而這種隔離是結構性的，不是某個誰記得去開啟的設定選項。
錯誤三：把憑證直接交給智慧代理
這是最不容易察覺的一點，我猜也是最容易讓團隊措手不及的一點。如果智慧代理需要部署到你的主機，或發布到你的商店，最快的做法就是把 OAuth 權杖或 SSH 金鑰放進它的上下文，讓它直接使用。但這也是通往災難最快的路徑：一個被提示注入的指令、一個幻覺出來的動作、一組不小心留在某個不該出現的對話紀錄裡的憑證。智慧代理不需要惡意，只要出錯一次、又剛好握有真實金鑰，就足以出事。
所以，智慧代理永遠不會握有金鑰。已連結的憑證會限定範圍存放在你的租戶內，並且只用於你當初連結時指定的那個動作：
- 商店帳號
- 社群平台 OAuth 權杖
- 部署金鑰
- Google 服務帳戶
當智慧代理需要部署或上傳內容時，它會請求平台代為執行；憑證由平台持有並實際執行動作，智慧代理本身永遠看不到它要求使用的機密資訊。而在數據分析方面，由於 Google 資源有時會跨多個網站共用，每一次 GA4 資料擷取都會依主機名稱進行篩選，確保你的儀表板不會意外顯示到別人的數據，即使背後的 Google 資源本身涵蓋多個網域。
在任何內容上線前，實際會被檢查的項目
有兩條規則適用於這個平台上的一切，而且在這裡格外重要：
- 智慧代理不能替你花錢。
- 智慧代理不能以你的名義發文。
這兩件事都需要你親自點擊確認。也就是說，任何自動化元件即使出了最糟的狀況，也碰不到你的錢包或名譽——影響範圍是由設計限定的，而不是靠智慧代理自己的判斷力。關於資料保留與刪除的完整說明，請參閱隱私政策；刪除請求會在 30 天內生效。
