iT邦幫忙

ai-security相關文章
共有 27 則文章
鐵人賽 AI Security DAY 30

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

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

鐵人賽 AI Security DAY 29

技術 DAY29|CaMeL研究完後,還能往哪裡走

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

鐵人賽 AI Security DAY 28

技術 DAY28|這次做了什麼,哪些沒做

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

鐵人賽 AI Security DAY 27

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

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

鐵人賽 AI Security DAY 26

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

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

鐵人賽 AI Security DAY 25

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

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

鐵人賽 AI Security DAY 24

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

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

鐵人賽 AI Security DAY 23

技術 DAY23|使用者的請求能授權什麼,不能授權什麼

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

鐵人賽 AI Security DAY 22

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

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

鐵人賽 AI Security DAY 21

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

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

鐵人賽 AI Security DAY 19

技術 DAY19|用實際案例,測試設計

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

鐵人賽 AI Security DAY 18

技術 DAY18|確認是換方法還是繞過,這樣設計到底有沒有用?

前言 昨天把被擋之後的重擬接起來了,但只管次數不管內容,模型換一條路只要次數還夠就照樣放行。今天先分辨模型到底是換方法還是繞過,然後加上兩個衡量數字,確認功能有...

鐵人賽 AI Security DAY 17

技術 DAY17|被擋錯的讓它換條路走

前言 昨天列了四項要做的事,今天做回傳給模型的內容,以及重擬的額度怎麼算,想辦法解決擋得住攻擊但任務跟著死的情境。 回傳什麼給模型 CaMeL原本遇到錯誤是把整...

鐵人賽 AI Security DAY 16

技術 DAY16|攔下訊號後該如何做設計?

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

鐵人賽 AI Security DAY 15

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

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

鐵人賽 AI Security DAY 14

技術 DAY14|原來CaMeL沒被打穿??

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

鐵人賽 AI Security DAY 13

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

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

鐵人賽 AI Security DAY 16

技術 AI 黑魔法(16):MCP 把工具接起來,也把風險一起接進來(重啟)

上一篇我們把 Agent 拆成模型、工具、記憶、設定檔與自主迴圈,但當工具越接越多,就碰到一個工程問題:不同的 AI 應用,能不能用一種共同語言去連這些東西?...

鐵人賽 AI Security DAY 10

技術 Day 10|受限訊號與判讀關卡:設計定案

這個系列好難啊,是個好新的主題,感覺光是整理資料就有夠多了,希望接下來的實作來得及XD 今天要開始設計解法,看被Q-LLM讀完資料之後,能不能送出一個「受限的訊...

鐵人賽 AI Security DAY 9

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

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

鐵人賽 AI Security DAY 8

技術 Day 8|其他鄰近研究速讀:Intent-to-Execution Integrity、Consent Integrity

一篇從高處批評的論文 在Intent-to-Execution Integrity這篇中主張安全漏洞的本質是執行結果沒有保留住使用者的意圖,運用語意保留(sem...

鐵人賽 AI Security DAY 7

技術 Day 7|CXI深讀:判讀層怎麼設計

在前面幾天我們整理了CaMeL是管資料流,而ControlValve是管控制流,今天將進入研究CXI(Context-to-Execution Integrit...

鐵人賽 AI Security DAY 6

技術 Day 6|ControlValve深讀 (2):為什麼能擋下alignment-check防禦擋不住的攻擊

昨天判斷「結構化的窄判斷」跟「開放式的alignment判斷」風險本質不同,今天用論文裡的Slack案例,把這個判斷放到具體攻擊上檢驗一遍。 攻擊長什麼樣子 說...

鐵人賽 AI Security DAY 5

技術 Day 5|ControlValve深讀 (1):怎麼產生允許的控制流圖

昨天把CFI這個詞的出處講清楚了。今天正式進ControlValve的原文,看它具體怎麼把「控制流圖」這個抽象概念,變成一套真的能跑在多agent系統上的機制。...

鐵人賽 AI Security DAY 4

技術 Day 4|「控制流完整性」這個詞從哪來:從傳統軟體資安借來的類比

PS:感覺前幾天好嚴肅,和朋友討論之後希望接下來能帶向較輕快的節奏~ 接下來看看控制流的說法,它借自傳統軟體資安裡的Control-Flow Integrity...

鐵人賽 AI Security DAY 3

技術 Day 3|CaMeL的已知代價:plan-then-execute解耦,任務完成率掉多少的背後

昨天留了兩個疑點:P-LLM規劃階段本質上看不到資料,跟任務完成率掉下來,是不是同一件事;還有檢查時機是不是太晚,今天把「代價」這件事攤開來講清楚,探討代價到底...

鐵人賽 AI Security DAY 2

技術 Day 2|CaMeL怎麼設計來擋這個問題:雙模型分工與capability機制

今天延伸昨天所講的,分別說明CaMeL如何把「決定做什麼」和「讀外部資料」拆給兩個分工的模型,看它實際上是怎麼運作的,這也是接下來要加以修改的部分,機制細節先了...