Allowlist vs. Denylist Permission Design

白名單制 vs 黑名單制授權設計是什麼，跟本系列前面談過的最小權限範圍有什麼不同？

本系列前面談過的最小權限範圍，處理的是「授權範圍應該設定得多窄」這個程度問題——不管是白名單制還是黑名單制，都可以搭配「範圍設得很窄」或「範圍設得很寬」的具體參數。白名單制 vs 黑名單制談的是更根本的架構問題：面對一個當初設計授權規則時完全沒有被考慮到的全新情境，這套系統的預設反應是「拒絕」還是「允許」。

這代表最小權限範圍是「在已知的授權範圍裡，怎麼設定得更精確」，白名單制 vs 黑名單制則是「面對未知的情境，這套系統的預設立場是什麼」——後者處理的是更根本的架構安全問題，前者則是在這個架構確立之後，具體參數該怎麼微調。

為什麼會有這兩種截然不同的授權設計哲學，各自解決了什麼問題？

黑名單制的設計動機，通常是為了提供更大的操作彈性——如果一個 Agent 需要處理的情境本身變化多端、難以窮舉列出所有合法動作，採用黑名單制能避免因為漏列了某個合法但罕見的操作，導致 Agent 在正常運作時被不必要地卡住。這種設計適合那些「合法動作種類極多、難以完整列舉」的情境。

白名單制的設計動機，則是把安全性放在最優先的位置——即使犧牲一定程度的操作彈性，也要確保任何沒有被明確允許的動作，都會被系統直接拒絕。這種設計特別適合 DeFAI 這種涉及真實資金的情境，因為這裡「一個未被預期到的動作被意外執行」帶來的後果，通常遠比「一個合法動作被誤擋」的後果嚴重得多——後者頂多是操作上的不便，前者可能直接造成資金損失。

這兩種授權設計實際上怎麼運作，具體的差異會在什麼情境下顯現出來？

假設一個 Agent 被授權可以在借貸協議裡執行「存入」跟「提領」這兩種操作。如果這個協議後來新增了一個「質押」功能，在黑名單制底下，因為「質押」這個新功能沒有被明確列入禁止清單，Agent 理論上會被允許執行這個從未被評估過的新操作；在白名單制底下，因為「質押」沒有被明確列入允許清單，Agent 會被系統直接拒絕執行，直到使用者主動把這個新功能加進白名單為止。

這個差異在協議快速迭代、經常新增功能的 DeFAI 生態裡特別關鍵——黑名單制會讓 Agent 自動獲得存取任何新功能的權限，你完全不知道自己的 Agent 什麼時候會開始執行一個你從未評估過風險的新操作；白名單制則會讓任何新功能預設被擋下，你需要主動介入才能讓 Agent 使用它，這個「主動介入」的過程，本身就是一個讓你重新評估風險的機會。

白名單制 vs 黑名單制授權設計對一般用戶有什麼實際影響，該怎麼應用在評估 DeFAI 產品上？

如果你正在評估一個 DeFAI Agent 產品，值得直接詢問這個團隊：授權系統採用的是白名單制還是黑名單制的底層設計哲學，而不只是問「授權範圍設定得多精細」。這是一個比範圍大小更根本的問題——即使兩個產品當下展示給你看的授權範圍看起來一樣精確，如果底層設計哲學不同，未來面對協議更新或新功能上線時，實際的安全反應會完全不同。

實際應用時，對於管理真實資金的 DeFAI 產品，白名單制通常是更保守、更值得優先考慮的設計，因為它確保任何你沒有主動評估過的新情境，預設都會被擋下，而不是預設被允許。如果你發現一個產品採用的是黑名單制，不代表這個產品一定不安全，但代表你需要更頻繁地主動檢查，這個 Agent 的實際操作範圍有沒有因為協議更新，而悄悄擴大到你原本沒有預期的地方。