Cognitive Firewall 論文閱讀分析：真正能保住 Browser Agent 的，也許不是把所有風險都丟給雲端模型，而是把防線拆成 edge 看得快、cloud 看得深、boundary 卡得硬

論文基本資訊

• 論文標題：The Cognitive Firewall: Securing Browser Based AI Agents Against Indirect Prompt Injection Via Hybrid Edge Cloud Defense
• 作者：Qianlong Lan、Anuj Kaul
• 年份：2026
• 來源：arXiv:2603.23791
• 論文連結：https://arxiv.org/abs/2603.23791
• DOI：10.48550/arXiv.2603.23791
• 主題：Browser Agents、Indirect Prompt Injection、Split Compute、Execution Boundary、Edge-Cloud Security、Deterministic Guard

如果前幾篇 agent security 論文，一路都在問「怎麼辨識惡意內容」、「怎麼判斷下一步 action 有沒有被帶偏」，那這篇 Cognitive Firewall 想補的是另一個很實際的問題：browser agent 的防線，到底該放在哪裡，才能同時兼顧速度、隱私與真的擋得住事。

我會把這篇的主線濃縮成一句話：真正能讓 browser agent 比較敢碰真實網站的，不是把所有判斷都丟給雲端大模型，而是把防禦拆成 edge 看得快、cloud 看得深、execution boundary 卡得硬的三段式控制鏈。

這篇論文真正要打的，不只是 prompt injection，而是 browser agent 的 control plane collapse

作者一開始抓到的點很準。當 LLM 被放進 browser agent 之後，系統 prompt、user instruction、網頁 HTML、CSS、甚至畫面上根本看不到的隱藏文字，常常都一起進到同一個 context window 裡。這表示：

• 本來屬於控制面的東西，例如 system prompt、使用者任務
• 本來屬於資料面的東西，例如網頁內容、工具回傳、外部網站文字

在 agent 的腦內其實被混成同一坨 token。

這種 control plane / data plane collapse，正是 browser agent 特別容易被 indirect prompt injection 打穿的原因。因為網站不需要入侵你的系統，只要把惡意語意藏進 agent 會讀的內容裡，模型就可能自己把錯的東西當成更高優先級的指令。

所以這篇論文真正想守的，不只是某一段隱藏 prompt，而是：browser agent 從「看到頁面」到「決定行動」再到「真的送出 side effect」這整條鏈，有沒有被切出夠清楚的安全層次。

Cognitive Firewall 的核心設計：不是一個 detector，而是一個 defense funnel

作者提出的不是單一模型，而是一個三層架構：

1. Edge Sentinel：本地端快速檢查 DOM / CSS / rendered view，先擋 presentation-layer 攻擊
2. Deep Planner：雲端大模型做較深的 semantic / intent 分析，處理 role override、developer mode、urgent coercion 這類語意型攻擊
3. Origin Guard：最後在 execution boundary 用 deterministic policy 同步攔截實際要送出的請求與動作

這個設計我認為最有價值的地方，在於它不是在問「哪個模型最會抓 injection」，而是在問：哪些風險應該在最靠近來源的地方就處理掉，哪些才值得送去貴又慢的雲端推理，而哪些事情不管前面判得多漂亮，最後都還是得靠 deterministic policy 硬卡。

作者把這套哲學叫做 Defense Funnel。這名字很貼切，因為它本質上是在做分流：

• 便宜、明顯、局部的問題，盡量在 edge 先砍掉
• 模糊、語意型、需要上下文的問題，再往 cloud 送
• 真正會產生副作用的行為，最後一律回到本地 execution guard 決定能不能做

Layer 1：Edge Sentinel 真正要守的，是「Agent 不該看見使用者看不見的控制訊號」

這篇最 browser-native 的部分，就是第一層的 Edge Sentinel。它不是先做大型語意分析，而是先看網頁的 DOM 與 CSSOM，檢查 agent 讀到的內容，是否其實不在使用者的可見範圍內。

作者把這件事上升成一個安全不變式：

Visual Consistency：Agent 不應該根據使用者看不到的內容做推理。

這其實非常重要。因為很多 browser agent 風險，不是來自很高明的長篇語意操控，而是來自極低成本的 presentation-layer tricks，例如：

• opacity: 0
• font-size: 0
• 把內容推到 viewport 外面
• 利用 z-index、off-screen positioning 把惡意文字藏起來

這些技巧對人類幾乎不可見，但對讀 DOM 的 agent 卻完全可見。作者的主張很乾脆：這種攻擊根本不值得送進 cloud 做昂貴語意判斷，應該直接在 edge fail fast。

我很同意這條線。因為它把 prompt injection 問題往前推回到「rendered reality」：如果使用者根本沒看到，那它就不該有權影響 agent 行為。

Layer 2：Deep Planner 處理的是「看起來像正常文字，但其實在重寫 authority」

當內容通過第一層後，才會送到雲端的 Deep Planner。這一層要處理的不是隱藏字，而是更麻煩的 cognitive / semantic 攻擊，例如：

• 偽造 prompt hierarchy，例如「— END SYSTEM INSTRUCTIONS —」
• 要求 agent 切換人格或進入 unrestricted / developer mode
• 用緊急語氣壓過正常驗證程序
• 透過文字設計改寫 agent 對 authority、intent、urgency 的理解

換句話說，這層不是檢查「這段話有沒有奇怪字串」，而是檢查：這段內容是不是在試圖重寫 agent 對任務目標與指令優先級的理解。

作者把這層的任務描述成 Goal Integrity，也就是：

不可信的外部內容，不應該改寫 agent 從 system prompt 與 user instruction 得到的高階控制目標。

這點和最近很多強調 runtime causality、intent consistency 的論文其實很接近。只是這篇走的不是 purely causal attribution，而是防禦 placement：語意級風險可以交給雲端判，但不能把最後的生殺大權也一起交出去。

Layer 3：真正讓這篇成立的，其實是最後那個 deterministic Origin Guard

如果只看到前兩層，這篇會有點像「edge filter + cloud judge」的常見組合。但它真正比較值得寫的地方，在於第三層：Origin Guard。

作者的核心主張很明確：只要會產生 side effect，就不應該只靠 probabilistic model judgement 決定。 所以最後一層不是再找另一個模型來評分，而是用 deterministic policy 直接攔 browser API 執行。

它會檢查兩件事：

• target origin 是否在允許集合內
• HTTP verb / action type 是否符合使用者當前任務的 safety scope

例如使用者只是要「讀取並摘要 Jira ticket」，那就算前面 planner 被帶偏，最後冒出一個 POST、DELETE、或往陌生 domain 送 request，Guard 也應該同步擋下。

這層其實是在把另一個安全不變式做成硬規則：

Execution Safety：沒有明確符合 intent 與 policy 的 side-effecting action，不准出站。

這件事非常關鍵，因為它等於承認了：語意模型會失手，但出站動作不能跟著一起 probabilistic。

這篇論文最值得記住的，不是 ASR 數字，而是 defense placement 的邏輯

論文結果當然很吸睛。作者在 1,000 個 adversarial samples 上報告：

• edge-only defenses 對 semantic attacks 幾乎擋不住，86.9% 會漏掉
• 完整 hybrid architecture 把整體 ASR 壓到 0.88%（static）與 0.67%（adaptive）
• 本地 presentation-layer 過濾延遲約 0.02 ms 到 0.06 ms
• 相對 cloud-only baseline 有大約 17,000x latency advantage

但如果只記這些數字，我覺得反而會錯過這篇最有價值的地方。真正重要的是它把防禦位置講清楚了：

• 視覺層攻擊 → 該在瀏覽器本地擋
• 語意層操控 → 可以交給雲端做重分析
• 具副作用的執行 → 必須回到 deterministic boundary enforcement

這比「再做一個更聰明的 guard model」更像真正可部署的系統工程思路。

我怎麼看這篇？

我認為這篇論文最值得肯定的，是它很務實地承認了一件事：browser agent 安全不可能只靠一個地方贏。

如果全部丟給 edge model，語意操控太深、太容易漏；如果全部丟給 cloud judge，延遲與隱私成本太高；如果最後沒有 deterministic action guard，那前面所有聰明判斷都可能在最後一步輸掉。

所以這篇真正提出的是一種更成熟的 agent security 觀：

不要問哪個檢測器最強，而要問哪一類風險應該在哪一層被處理，才能讓整條控制鏈既快、又深、又硬。

這個方向我覺得是對的。尤其對 browser agents 來說，rendered content、semantic intent、execution side effects 本來就是三種不同層級的問題，硬要用同一個 LLM classifier 全包，本來就很不合理。

當然，這篇也不是沒有侷限。它的評估集規模還有限，很多 policy 依賴 allowlist 與 verb-level intent mapping，對更開放、更長鏈、更會跨站組裝任務的 agent 而言，後面還需要更細的 provenance 與 state-aware policy。可是至少它已經把方向往前推了一步：把 browser agent security 從「內容辨識」推向「分層控制與 execution boundary engineering」。

---

如果你在做的是 browser agent、computer-use agent、企業內部網頁自動化，這篇很值得看。 因為它提醒你的不是「網站上可能有髒 prompt」這種大家已經知道的事，而是：真正決定 agent 會不會出大事的，往往是你把視覺檢查、語意判斷、與出站動作控制，分別放在哪裡。

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