AI Engineer onepage / Formal verification for agents
Erik Meijer, Leibniz Labs · 21:13
這支影片在講：Agent 要先證明能安全執行，才准碰工具
當 agent 能發信、付款、刪資料庫，錯誤就不再能靠「事後修正」。Erik Meijer 的主張是：把策略檢查搬到副作用之前，要求每個執行計畫都附上機器可驗證的安全與正確性證明。
Published: 2026-07-13 · Video ID: -CnA2lGfymY
01 / 問題
執行不可逆
訊息送出、款項匯出、資料刪除後，不能靠下一輪 prompt 把副作用收回；允許不安全行動的代價遠高於拒絕安全行動。
02 / 反轉
Guardrail 不在模型裡
prompt、RLHF 與 runtime 的「盡量小心」都不足以構成保證。信任邊界應縮小到可審計的驗證器。
03 / 解法
Proof-carrying execution
Agent 交出計畫與證明；checker 驗證 policy、正確性與安全性，通過後才允許第一個 tool call 發生。
Key signals
影片的四個關鍵設計轉折
Trust boundary
Agent → Checker
不信 proposal 或 proof 本身；只信任小型、可稽核的 proof checker。
Policy timing
Before action
合規從 runtime 補救改為靜態屬性：第一個副作用前就已成立。
Risk pattern
Lethal trifecta
私密資料、未信任內容與對外操作能力結合時，prompt injection 的破壞性會放大。
Language
Universalis
以人可讀、機器可驗證的 literate logic programming 撰寫計畫與證明。
Core story
為什麼「模型很聰明」仍不是執行授權
風險 1
把自然語言意圖直接接上不可逆工具
模型可能被 prompt injection 或錯誤推理帶偏；一旦工具具有外部寫入權限，可靠度不是回答品質問題，而是存取控制問題。
風險 2
把 policy 留給執行中的臨場判斷
runtime guardrail 通常只能攔截已知形狀的輸出。演講提出把「此計畫是否允許」在執行前變成可判定命題，避免先做再補救。
風險 3
讓龐大系統成為唯一信任根
越大的 agent、模型與 orchestrator 越難完整稽核。更好的目標是讓信任縮到一個小 checker：它只接受能證明符合規則的計畫。
Practical implications
這不是「多一層審核」，而是改變 agent loop
把 plan 當作可驗證程式先把 agent 打算做的多步操作具體化，再檢查資料流、權限、前置條件與結果是否符合既定 policy。
讓 proof 成為隨計畫附帶的 artefactproof-carrying code 的概念不是要人逐行手寫數學，而是要求系統提供足以由 checker 驗證的依據。
區分「模型提案」與「系統授權」模型可負責探索與起草；真正的執行權只能由獨立的 policy 與 verifier 授與。
先選高代價副作用導入付款、刪除、發佈、權限變更最值得先做 pre-execution proof；低風險讀取可保留較輕的流程。
Use this checklist
要把 agent 接進真實系統，先回答五個問題
哪些 tool call 有不可逆或高額副作用？列出發信、付款、刪除、部署、改權限等行動；它們不應只依賴 prompt 規範。
每種行動可被表達成明確計畫嗎？若不能把步驟、讀寫資源與預期結果說清楚，就無從驗證它是否符合策略。
policy 能否在第一個 side effect 前判定？把資料邊界、權限、收件者、金額上限與批准條件改成可檢查規則。
驗證器是否足夠小、可獨立稽核？核心不是多做一個 agent review，而是減少必須信任的程式碼與決策面。
拒絕安全行動的成本，是否低於放過不安全行動？針對高風險流程，答案通常是肯定的；這就是先驗證再執行的經濟理由。
Source video