Can Agents Secure Hardware? 論文閱讀分析：當 Agent 開始替你自動長出硬體保護機制，真正該驗的就不只是它有沒有做出來，而是攻擊者拆不拆得掉

論文基本資訊

• 論文標題：Can Agents Secure Hardware? Evaluating Agentic LLM-Driven Obfuscation for IP Protection
• 作者：Sujan Ghimire、Parsa Mirfasihi、Muhtasim Alam Chowdhury、Veeramani Pugazhenthi、Harish Kumar Dharavath、Farshad Firouzi、Rozhin Yasaei、Pratik Satam、Soheil Salehi
• 年份：2026
• 來源：arXiv:2604.13298
• 論文連結：https://arxiv.org/abs/2604.13298
• 主題：Hardware Security、IP Protection、Logic Locking、Agentic AI、LLM Agent、SAT Attack、EDA Security

如果最近這波 AI security 論文一路在談 prompt injection、tool boundary、web agent takeover 與 runtime control plane，那這篇 Can Agents Secure Hardware? 則把問題切到另一個更少人真正在意、但其實同樣危險的地方：當 agent 不再只是分析安全問題，而是開始自動替你「製造安全機制」本身，該怎麼驗它到底有沒有真的做對？

這篇 paper 談的是 hardware IP obfuscation / logic locking。換句話說，它不是在防 LLM agent 被攻擊，而是在問：能不能讓 agent 自動幫硬體設計插入 key-controlled 保護邏輯，降低 reverse engineering、piracy、tampering 與 overbuilding 的風險？

但我認為這篇真正值得看的，不是「又一個 LLM for hardware」demo，而是它把驗證標準講得很清楚：在這類高風險安全設計問題裡，生成成功不代表安全成功；真正該驗的是 correct-key functionality、wrong-key corruption、以及在 SAT-based attack 下到底能不能撐住。

這篇論文想解決什麼？

作者開場其實抓得很準。IC 設計與製造全球化之後，硬體 IP 會暴露在更多不可信供應鏈環節，風險包括：

• reverse engineering
• piracy
• tampering
• overbuilding
• counterfeiting

對應的經典防線之一，就是 logic locking / IP obfuscation：把 key-controlled logic 插進電路裡，讓設計只有在正確 key 下才會維持原本功能；沒有 key 或 key 錯，就故意讓輸出被破壞。

問題是，這件事並不是「把 XOR gate 插幾個上去」那麼簡單。真正可用的 obfuscation 至少得同時滿足幾件事：

• 網表仍然合法、可編譯、可進工具鏈
• 正確 key 下功能必須完全正確
• 錯誤 key 下要有可觀測的 output corruption
• 不能輕易被 SAT / SMT 之類的分析攻擊還原

這也就是作者真正想問的問題：

當任務不只是文字生成，而是要在硬體安全約束下完成 planning、synthesis、verification 與 attack evaluation，LLM agent 真的能把這條鏈串起來嗎？

為什麼這不能只靠單次 prompt？

整篇論文最重要的前提之一，就是作者很明白地拒絕把這件事當成「一個 prompt 叫模型吐出 obfuscated netlist」的問題。

原因很簡單：硬體安全不是寫得像樣就好，而是要經得起 deterministic compilation、functional verification 與 adversarial evaluation。

也就是說，單次 prompt 最大的問題不只是容易 hallucinate，而是它缺少對中間狀態的控制。你很難相信一段直接生成的網表，同時滿足：

• 訊號名稱不亂掉
• gate basis 合法
• 正確 key 功能不變
• 錯誤 key 下有足夠破壞效果
• 在 SAT solver 面前不會一秒被打回原形

所以這篇論文真正站的立場其實跟最近很多 agentic security paper 很像：高風險任務的關鍵，不是讓模型一次講完，而是把模型放進一條可驗證、可回饋、可修正的 workflow 裡。

作者提出的核心方法：把 IP obfuscation 拆成一條 agentic workflow

這篇提出的是一個 agentic, LLM-driven IP obfuscation framework。它不是讓模型直接生最後結果，而是把整件事拆成幾個專門階段：

• circuit analysis：先解析輸入 .bench 電路結構
• retrieval-grounded planning：蒐集相關 benchmark 與硬體安全脈絡
• structured lock-plan generation：用結構化方式指定要鎖哪些位置、用哪種 lock style、key bit 怎麼分組
• deterministic netlist compilation：把 lock plan 編譯成合法網表
• functional verification：驗 correct-key 是否仍正確、wrong-key 是否造成 corruption
• SAT-based security evaluation：直接跑攻擊評估可恢復性
• iterative refinement：如果不夠好，再根據驗證結果修 plan

如果用白話講，這篇論文不是要證明 LLM 會設計安全硬體，而是要證明：

LLM agent 至少可以開始當一個 workflow-level coordinator，協助做「分析 → 生成 → 驗證 → 攻擊測試 → 修正」這條閉環。

這篇最值得注意的設計：structured lock plan

我覺得這篇最有技術味、也最值得拿來和一般「AI 幫你自動做安全」論文對照的地方，是它沒有讓模型直接吐最終網表，而是先要求模型產出 structured lock plan。

這個 lock plan 會描述：

• 選了哪些 target nodes
• 採用什麼 lock style
• 需要哪些 helper signals
• key bits 的群組與配置

這看起來像個小設計，但其實很關鍵。因為它等於把最容易出錯的部分分離開來：

• 模型負責規劃與選擇
• deterministic compiler 負責把規劃落成合法網表

這種切法的意義非常大。它讓 LLM 從「直接對結構化安全產物負全責」退回到「提出受約束的設計方案」，再由工具鏈去保證語法與基礎結構正確。這其實是把 agent 放在比較合理的位置。

它怎麼決定鎖哪裡？不是亂挑

論文流程一開始會先解析輸入 .bench circuit，抽出像是：

• gate count
• logic depth
• fanout
• output-cone influence

作者接著用 topology-aware heuristic 去排序 candidate lock locations。背後邏輯很直白：如果你要讓錯 key 真的能污染輸出，就得把鎖放在對下游輸出比較有影響力的位置。

因此，系統偏好那些：

• 有較強 downstream influence 的節點
• 深度較高、較可能影響傳播路徑的節點
• observability / output-cone coverage 較好的節點

這讓整個流程不是單純文字生成，而比較像「LLM + heuristic + deterministic toolchain」的混合式安全設計。

支援哪些 obfuscation styles？

論文提到實作上支援多種 lock styles，包括：

• xor_xnor
• perturb_restore
• mux_lock
• pairwise_subgraph
• hybrid

這點很重要，因為它表示作者不是只在單一固定模板上做 prompt demo，而是至少讓 agent 在不同 lock 策略之間做選擇與規劃。當然，後面結果也很清楚說明：會選 lock style 不等於就真的能對抗現代 SAT 攻擊。

評估設計很值得學：不是只看生成成功，而是把攻擊者拉進來

這篇 paper 我最欣賞的一點，就是它沒有把「產生了有效網表」當成結案，而是把評估拆成四組指標：

• functional validity：parse success、correct-key match、wrong-key corruption
• structural cost：gate overhead、key-input count 等
• security metrics：SAT success、runtime、DIPs、remaining key space
• workflow metrics：整體 runtime 與 LLM 使用情況

這裡最關鍵的是 security metrics。因為很多 AI-for-security 論文最大的問題，就是只證明系統能產生東西，卻沒證明那個東西在攻擊者面前到底能不能活。

這篇至少有把 SAT-based distinguishing-input-pattern attack 拉進來，而且直接用 oracle-guided constraints 去做 key recovery。換句話說，作者不是只問「看起來像不像一個 lock」，而是問：

如果真的有攻擊者拿 SAT solver 來拆，你這個 agent 幫你做出來的保護到底能拖住多久？

實驗怎麼做？

作者使用的是經典 ISCAS-85 combinational circuits，包括：

• c432
• c499
• c880
• c1355
• c1908
• c3540
• c5315
• c7552

模型方面，作者比較了三個：

• GPT-5
• LLaMA-3.1-8B
• Qwen-2.5-Coder-14B

每個 benchmark 會搭配 8-bit、16-bit、32-bit key，並做 SAT-based evaluation。這樣的設計至少能讓我們看到三件事：

• 不同模型是否都能穩定生出合法結果
• 不同 key size 是否真的提高安全性
• 不同 benchmark 電路拓樸是否對 corruption 與 recoverability 造成明顯影響

核心結果一：它真的能生成合法、correct-key 正確的 obfuscated netlist

先講好消息。作者的結果顯示，三個模型都能在這套 workflow 下產生：

• syntactically valid obfuscated netlists
• correct-key functionality preserved
• non-zero wrong-key corruption

也就是說，從「能不能把 workflow 跑通」這件事來看，答案是可以的。這代表 agentic workflow 至少在硬體安全這種高結構約束領域，也開始能做出一點像樣的事情，而不只是會寫自然語言報告。

但真正有意思的是，這個好消息只代表它開始像個設計工具，不代表它已經像個可靠安全工具。

核心結果二：wrong-key corruption 有，但幅度有限，而且高度依賴電路拓樸

論文報告 wrong-key corruption 大約落在 0.01 到 0.23 之間，不同 benchmark 差異很明顯：

• c432 的 corruption 較高
• c5315 的 corruption 較低

這裡有兩個關鍵訊號。

第一，錯 key 確實會讓輸出被污染，但污染不是自然隨 key size 線性上升。 作者明確指出，key size 增加並沒有穩定帶來更高 corruption。這意味著，真正決定效果的更像是 lock placement 與 circuit topology，而不是你把 key 拉得多長。

第二，電路結構差異非常重要。 某些電路因為拓樸與訊號傳播特性，錯誤比較容易擴散到輸出；某些則不那麼容易。這其實直接打臉一種常見幻想：不是你把 obfuscation 模板自動化了，就會自動得到穩定安全性。

核心結果三：SAT 攻擊在所有案例都成功，這是全文最重要的一句話

如果只能記住這篇 paper 一句結論，我會選這句：

雖然 key size 增加會提高攻擊成本，但在作者評估的所有案例裡，SAT solver 最終都成功恢復正確 key。

這句話非常重要，因為它直接把整篇論文從「LLM agent 幫你成功做硬體保護」拉回「LLM agent 幫你做出一個目前仍然擋不住現代分析攻擊的保護雛形」。

也就是說，這個 framework 的價值不是證明「問題解了」，而是證明：

• agent 能開始參與這種安全設計工作流
• 但現有 lock templates 本身仍然不夠強
• workflow-level automation 無法替代真正的 security hardness

這是一個很成熟、也很值得尊重的結論。作者沒有把 AI 包裝成 magic，而是坦白承認：自動化可以幫你把設計做出來，但不保證幫你把對抗強度做出來。

不同模型有什麼差異？

論文結果指出：

• GPT-5 通常帶來較高的 SAT attack effort，但 runtime 也較高
• LLaMA-3.1-8B 以較低 runtime 達到可比 corruption 表現
• Qwen-2.5-Coder-14B 則落在中間

但真正重要的不是誰多拿幾分，而是三者都共同指向同一件事：模型差異會影響效率與部分品質，但無法改寫 lock template 本身在 SAT attack 面前普遍脆弱這個結構性事實。

這篇論文真正的價值：把 AI-for-security 從「會生成」拉回「要驗安全性」

我認為這篇 paper 的最大價值，不是硬體安全這個特定題目本身，而是它替整個 agentic security 研究補上一個很該有的態度：

當 agent 開始替你產生安全控制項，評估標準就不能停在輸出看起來合理，而要拉到 adversarial evaluation 這一層。

這個道理其實可以外推到很多領域：

• agent 幫你寫 detection rule，不代表 rule 有 coverage
• agent 幫你寫 guardrail，不代表 guardrail 擋得住 adaptive attack
• agent 幫你做 obfuscation，不代表 obfuscation 經得起 SAT solver

所以這篇論文其實很像在替整條 AI security pipeline 補上一句該被一直重複的話：security artifact generation 和 security guarantee 是兩回事。

和最近幾篇文章相比，這篇新在哪？

如果把這篇放回最近 sectools.tw 的脈絡裡，它的定位很清楚：

• 它不是在談 prompt injection，也不是 memory poisoning。
• 它也不是再做一個 SOC / CTI benchmark。
• 它談的是 agent 直接參與安全機制合成這件事，而且要求用攻擊者視角驗證結果。

這讓它跟最近幾篇 indirect prompt injection / web agent / runtime control 題材拉出明顯區隔，也把「agentic security」這條線擴到更底層的 supply-chain / hardware IP protection 問題。

這篇論文的限制也很值得一起看

當然，這篇 paper 也有明確限制：

• 只評估 ISCAS-85 combinational circuits，沒有碰 sequential circuits。
• 每個 benchmark-key pair 只生成一個 candidate，搜索空間仍然有限。
• 目前 lock styles 雖然多樣，但整體仍未對 SAT attack 形成真正抗性。
• 結果主要顯示 feasibility，而不是 production-grade robustness。
• 論文自己也提醒，logic locking 並不能消除 side-channel leakage 等其他硬體攻擊面。

也就是說，這篇的價值在於證明「這條路開始可以走」，而不是證明「這條路已經走完」。

總結

Can Agents Secure Hardware? Evaluating Agentic LLM-Driven Obfuscation for IP Protection 最值得看的地方，不是它證明 AI 已經會做出真正強壯的硬體保護，而是它很誠實地把問題拆開：

• Agent 可以幫你把 workflow 跑起來
• 可以生成合法、功能正確、錯 key 會產生污染的 obfuscated netlist
• 但只要 SAT 攻擊仍能全面恢復 key，這些成果就還不能被當成真正可靠的 security win

如果要把這篇濃縮成一句話，我會這樣說：

這篇論文提醒我們，當 agent 開始替人設計安全機制時，真正該驗的早就不是它有沒有生成出東西，而是那些東西在攻擊者手上到底能不能活下來。

這個提醒，不只對硬體安全成立，對整個 agentic security 領域都成立。

---

本文由 AI 產生、整理與撰寫。