Guarding the Safe - From Guardrail to Policy Engine

Safe 智能帳戶原本有兩種交易流程：一是用戶直接與 Safe 帳戶互動並執行協議操作，二是透過 Module（可插拔的自訂邏輯合約）進行交易。兩種流程都依賴 owner 的多簽授權作為唯一的安全屏障，本身缺乏更細緻的邏輯層防護。為此，Safe 引入了 Guard 機制——一個在簽名驗證之後、協議互動之前插入的可程式化檢查層，無論是原生交易或 Module 交易皆適用。

第一套工具 Guardrail 是最輕量的解決方案，核心思路是「預設拒絕 delegate call」。由於 delegate call 會將被呼叫合約的邏輯執行在呼叫方的 storage 上，風險相對較高，Guardrail 將其全部封鎖，只有明確列入白名單的例外（如官方 Safe Migration 合約用於版本升級）才能通過。這種設定方式幾乎是一次性的，啟用後無需持續維護，適合對 delegate call 沒有特殊需求的帳戶。

第二套工具 Fiducia 更進一步，引入了「access selector」機制。每筆交易都由目標地址、function selector 與操作類型三者組合成唯一識別符；若某個組合未被預先配置，交易不會直接失敗，而是進入時間延遲佇列，給予 owner 足夠的反應窗口，即便交易已經簽名也可以及時攔截。Fiducia 還支援接入第三方 co-signer 服務，對特定交易做額外的人工或自動化審核，適合需要彈性配置又兼顧安全緩衝的場景。

第三套工具 Policy Engine 是三者中功能最完整的。它同樣採用 access selector 機制，但不再只是時間延遲——每個 access selector 都可以掛載一個獨立的 Policy 合約，其中寫入任意自訂邏輯。演講者舉例：若要實現「每月員工薪資支出不得超過 X 額度」，只需撰寫對應的 Policy 合約，即便 owner 已完成多簽，超額的交易依然會被阻斷。Policy 合約設計上刻意保持小而精簡，方便測試、審計與形式化驗證；搭配內建的 fallback 機制與 co-signer，可構建多達三層的安全縱深。三套工具目前均處於 beta 階段，官方建議先在 testnet 上充分驗證後再考慮主網部署。