權限不應該在運行時防守，應該在語言層鎖死
不要在運行時防守 AI Agent 越權，應該在語言設計層鎖死權限，讓未授權操作物理上不可能執行。
信任結構，不信任代碼
現在的 AI Agent 架構有個根本的假設漏洞：我們假設沙箱、Docker、權限清單這些運行時防護能擋住 Agent 越權。但只要開放網路或檔案系統權限，Agent 就能在邊界內找到突破口。問題不在防守的規則寫得不夠嚴，而在於我們把權限決策放在了錯誤的時間點。
Peter 在 Threads 提到的 Mog 有個不同的思路：把權限控制內嵌到語言本身。不是編譯期檢查代碼格式，而是讓 Agent 生成的代碼在物理上無法執行未授權操作。這不是加一層防守，是改變遊戲規則——權限不存在，就沒有越權的可能。
這挑戰了我們習慣的分層模式。我們習慣說「框架定規則，代碼在框架內執行」。Mog 說的是「語言本身就是規則」。差別在於：前者是事後審計，後者是先天不可能。
聲明式權限的工程成本
Mog 要求 Agent 代碼顯式聲明 requires http; requires fs;，host 才能授權。聽起來很清爽，但實務上有兩個磨損點。
第一，Agent 必須準確預測自己的權限需求。如果 Agent 在推理過程中發現需要某個權限但沒有聲明，就會卡住。這對現在的 LLM 來說不是小問題——模型往往不知道自己會用到什麼。預測錯誤的成本是執行失敗，不是警告。
第二，Host 需要建立細粒度的授權策略。「允許 http」太寬泛，所以要寫「只允許 youtube 域名」、「只允許讀檔案不允許寫」。這對運維來說是新的認知負擔——你需要理解 Agent 的業務邏輯才能定出合理的邊界。定太寬等於沒防守，定太窄 Agent 動不了。
這套模型適合對安全性要求極高的場景——金融、醫療、基礎設施。但可能限制 Agent 的探索性。如果 Agent 需要臨時調用一個新的 API，它要麼聲明失敗，要麼需要人工介入重新授權。
邊界定義的品質決定天花板
Mog 還提出了一個架構模式：微核心 agent。人類寫核心的權限管理邏輯，其他功能完全由 Agent 用 Mog 生成和更新，無需重啟。
這改變了傳統的分工。以前是「人類寫框架 → Agent 在框架內執行」。現在變成「人類守住安全邊界 → Agent 在邊界內自由演化」。
實務價值很清楚：降低迭代成本。你不用每次改需求都重新部署，Agent 自己生成新功能。但這裡有個隱藏的風險：人類邊界定義的品質決定了整個系統的可控性上限。邊界定義錯誤，Agent 無法自動發現。這不像代碼 bug 會在執行時報錯，這是架構級別的盲點。
換句話說，你的安全性只能和你對業務邊界的理解一樣好。Agent 再聰明也彌補不了這一點。
這是一個架構選擇，不是技術選擇
我看 Mog 的思路時，不是在評估它的技術完整度，而是在想它代表什麼。它說的是：與其在運行時追著 Agent 防守，不如在設計時就讓某些操作物理上不可能。
這需要付出代價。Agent 的靈活性會降低，運維的思維成本會上升，系統的可預測性會提高。適合什麼場景，不適合什麼場景，取決於你對「控制」和「自主」的權衡。
我後來決定換一個問題：不管工具怎麼換，我能不能維持同樣的判斷品質？答案是，語言層的權限控制讓判斷變得更透明——因為邊界被迫寫成了代碼，而不是隱藏在運行時的策略裡。這本身就有價值。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。