技術 DAY30｜三十天的反思與心得感想

先跑再寫，它的代價？ 開賽時我是希望每天先把該跑的實驗跑完，再依據跑出來的結果寫當天的文章，但實作的內容真的跑太久了，常跑到深夜或是需不間斷的時間才會出來結果，...

技術 DAY29｜CaMeL研究完後，還能往哪裡走

最後的樣子 整體是包在CaMeL外面的一層，原本的政策引擎還在裡面，每個工具呼叫都先問它一次，拿到的答案當作起點，再決定要不要改。 最底下是訊號累積，每當一個呼...

技術 DAY28｜這次做了什麼，哪些沒做

前言 「讓Agent邊讀邊決定」是我最初的目標，和現在所做出來的東西跟當初想的不太一樣，在過程中也發現很多有價值的思考點。今天分四段整理做了什麼、驗證到什麼、沒...

技術 DAY27｜這套動態權限做了哪些事

全貌 使用者請求 │ ├─ 從請求文字抽出授權範圍（email、IBAN、動作詞）───┐ │...

技術 DAY26｜靜態政策的代價，現階段動態做到哪些事

前言 今天要跑的是全suite的主數字，workspace全部40個任務、banking全部16個任務，不開攻擊，看這套機制在完整樣本上的誤殺代價與觸發率。 先...

技術 DAY25｜複製既有行程的參與者，被自己昨天的方法擋掉

前言 昨天封住send_money的漏洞，字面值不該冒充使用者授權、使用者授權不該蓋過與它無關的檢查、沒有真實資料時檢查不該當作通過。 九個乾淨任務裡有兩個被昨...

技術 DAY24｜可讀者檢查在沒有真實資料時形同虛設

前言 昨天列的待辦是把授權範圍延伸到banking的send_money，實際去補的時候先撞到格式問題，還有發現可讀者檢查本身有問題，發生在不同的檢查上。 格式...

技術 DAY23｜使用者的請求能授權什麼，不能授權什麼

前言 昨天把「使用者在請求裡指名的目的地」當成一個授權來源，用它補上靜態政策的一個漏洞，今天處理同一個來源的兩個問題，能不能涵蓋沒有目的地的工具，以及它有資格推...

技術 DAY22｜新的權限格補上靜態政策的洞

前言 昨天重新設計權限層級，把「乾淨時比靜態政策寬」形狀做出來，今天驗證結果讓昨天賠掉的utility全部補回來了，而且找到一個靜態政策真的會漏、新設計擋得住的...

技術 DAY21｜拿對照數字，重新規劃權限層級

前言 昨天把任務挑對了，今天終於跑出三格對照。數字指出結構性的問題，不是調參數能解的，所以今天後半段重新設計了權限層級。 三格數字 user_task_32，跑...

技術 DAY20｜跑對照之前，先把任務挑對

前言 昨天把測試設計定下來了，今天本來要直接跑 bounded 跟 permissive 的對照，但在可能要花兩小時跑六輪之前，得先確認一件事：挑的那個任務，到...

技術 DAY19｜用實際案例，測試設計

前言 Day15到Day18做的東西全部只在假模型的demo上驗證過，今天嘗試跑banking，看是否能解決DAY14 utility 判斷的問題，今天這篇在做...

技術 DAY16｜攔下訊號後該如何做設計？

昨天的收集點只看不動，今天把分數接進政策檢查，嘗試讓權限會隨執行狀態更改。 收回權限能做什麼 顧名思義，我們只能拿掉權限，不能給出權限，原本的政策引擎照樣先跑，...

技術 DAY15｜將CaMeL訊號攔截下來

前言 昨天講到CaMeL的每個檢查都是無狀態的，那接下來先在直譯器裡插一個訊號收集點，讓執行裡發生過的可疑事件被累積起來，在動態判斷上這是第一步，今天先以只收集...

技術 DAY14｜原來CaMeL沒被打穿？？

一、先把兩層的職責分清楚 結果原來昨天測完發現CaMeL是兩層機制疊起來的，原本想說CaMeL就是用capabilities來防止prompt injectio...

技術 DAY13｜CaMeL實測失敗的資料外洩案例

前言 昨天我們換成gemini-3.5-flash-lite搞定了API額度問題，並在銀行系統（banking）看到CaMeL把注入攻擊擋下。但其實前面討論時就...

技術 DAY12｜CaMeL實戰落地篇：解決API額度問題與驗證提示詞注入防禦

昨天把CaMeL跑起來之後replan迴圈失控把20次免費API額度全部燒光，今天來想辦法解決然後繼續做吧。 原本以為免費API根本撐不住benchmark，甚...

技術 Day 9｜鎖定CaMeL任務失敗案例分析

CaMeL自己怎麼定義這類失敗 CaMeL論文把這類失敗定名為「Data requires action」，採取什麼行動，取決於還沒讀到的資料。論文舉的官方例子...