權限該寫在代碼裡，不是寫在防火牆

AI Agent 的安全問題不該靠運行時防守，而該在語言設計層鎖定權限邊界。

問題不在防守，在設計

Docker 容器、沙箱、系統調用過濾——這些都是事後補救。你給 AI Agent 開放網路權限，再聰明的運行時監控也會有漏洞。根本問題是：我們一直在問「怎樣防止 Agent 越權」，而不是「怎樣讓 Agent 生來就沒有越權的能力」。

Peter 在 Threads 提到的 Mog 反轉了這個思路。不是運行時防守，而是編譯時鎖定——權限不是策略層的約束，而是語言層的約束。代碼寫出來的時候，就已經決定了它能做什麼、不能做什麼。這對部署 AI Agent 的團隊很關鍵。

傳統安全模型的假設是：我信任這段代碼，所以我給它權限。但 AI 生成的代碼，你怎麼信任？你可以 review，但 Agent 每天生成幾百行代碼，review 會成為瓶頸。

如果權限寫在語言設計裡，問題就變了。你不需要信任每一行代碼，你只需要信任這個語言的設計——信任它的結構本身會強制執行權限邊界。一個 Agent 再怎麼聰明，在一個沒有文件系統訪問權限的語言裡，就是生不出訪問文件系統的代碼。

這是微核心架構的邏輯：人類維護 3-5% 的核心權限層，其餘 95% 的功能由 Agent 生成。改壞了停用，改好了直接上線，無需重啟。這對需要快速迭代但要保證安全邊界的團隊，是實質的效率提升。

Mog 把完整語言規格壓在 3200 tokens 以內。這很克制。為什麼？因為 LLM 在一次 context 裡完全理解一個語言的語法，生成代碼的出錯率會大幅下降。

但代價是什麼？必然是表達力受限。你不能用通用語言那樣靈活地寫複雜邏輯。這不是技術問題，這是一個選擇——你要用一個「夠用但受限」的語言換取更高的生成準確率，還是寧可出錯率高一點，也要用通用語言的靈活性？

答案取決於你的 Agent 任務複雜度。如果任務是「調用幾個 API，組織返回結果」，受限語言綽綽有餘，而且更安全。如果任務是「實現複雜的業務邏輯」，你可能會覺得受限。

現在有很多團隊在試 Agent，但還在用傳統的安全思路——給 Agent 權限，然後想辦法防守。我的看法是：如果你的 Agent 要長期跑在生產環境，值得認真考慮權限內建於語言這個方向。

不是說 Mog 本身一定是答案。但這個思路——從「信任代碼」轉向「信任結構」——對 AI Agent 的工程化是一個重要的轉折。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。