攻擊面邊界是什麼？

你不是在保護一個 port。你是在管理整個系統對外露出的所有入口。

Hook

你在家裡跑了一個 mk-brain RAG server。 平常用來查自己的技術筆記。

為了方便拿手機做 LAN 內測，

你把它綁在：

0.0.0.0:8000

你心裡想的是：

「反正只是家裡網路。」 「反正只是我自己用。」

「反正之後記得關。」 問題通常不是你故意開洞。

問題是你把這個洞， 暫時當成合理。

隔天你去咖啡廳。 電腦連上公開 Wi‑Fi。

RAG server 還開著。 你正在另一個視窗 debug prompt。

隔壁那個拿 MacBook 的人， 剛好在掃同一個 subnet。

他不需要知道你是誰。 也不需要知道你的系統有沒有什麼 fancy CVE。

只要看到一個開在 LAN 上的 endpoint， 先打再說。

而你的 RAG API， 就這樣被掃到了。

這個事故最值得怕的地方， 不是它有多高深。

而是它非常日常。 你沒有把 production secret 貼到網路上。

你也沒有主動把防火牆關掉。

你只是做了一個工程師很常做的選擇：

圖方便。 這時候你真正需要的概念，

不是某個單點漏洞名稱。

而是一個更上位的問句：

我到底把哪些洞開出去了？

這個總和， 就叫 attack surface boundary。

Learn

一句話定義

攻擊面可以先用最工程的方式理解：

attack surface = 你讓外部有機會碰到、影響、觸發、濫用的所有入口總和。

這個入口不只是一個 port。 也不只是一個 API route。

它可以是：

• 一個對外開的 TCP port
• 一個 agent 可以呼叫的 tool
• 一個會自動安裝的 skill
• 一個會被模型信任的外部依賴
• 一個被你默認放進 allowlist 的 shell command

很多人一看到 attack surface， 腦中先出現的是掃 port。

那只對了一部分。 在 agent 時代，

只看 network 已經太窄了。

這門課為什麼放在第五門

前四門 boundary， 其實都已經在講「邊界」。

只是每一門切的是不同維度。

邊界	它在問什麼
trust	哪些輸入可以信
data	哪些資料可以流、來源可否追
privilege	agent 到底能做什麼
context	什麼內容可以進模型 prompt
attack surface	以上這些洞，加總起來對外露出多少面

所以 attack surface 不是要推翻前四門。 剛好相反。

它是把前四門抽象成一張總帳。

你可以把它想成：

• trust boundary 在看來源面
• data boundary 在看資料流面
• privilege boundary 在看能力面
• context boundary 在看 prompt 面
• attack surface boundary 在看系統總暴露面

前四門比較像局部切片。 第五門開始看整體輪廓。

Attack surface 不是「有漏洞才算」

這裡很容易有一個誤解。

很多工程師會問：

「可是那個 endpoint 又沒有已知漏洞， 也算 attack surface 嗎？」

算。

因為 attack surface 講的是：

外界有沒有機會碰到它。 不是它今天有沒有被打穿。

把這兩件事分開很重要。 exposed

不等於 exploited

但如果一個東西根本沒有暴露， 它就少了一條被利用的路徑。

所以縮小 surface 的價值， 常常不是修一個 bug。

而是直接把某條路封掉。

Surface area 的三個維度

這門課先用三維模型就夠。

維度	你在問什麼	常見例子
network exposure	哪些介面、port、endpoint 對外可達	0.0.0.0:8000、公開 /admin route、LAN WebSocket
tool availability	agent 有哪些 tool / API / shell capability 可調用	run_shell、deploy_preview、send_email
trust delegation	你把多少信任外包給外部供應鏈	第三方 skill、未審核 MCP server、可疑套件、latest 依賴

這三維有一個重點：

它們不是彼此獨立的。 它們會互相放大。

例如：

• network 開出去
• tool 權限又大
• 供應鏈來源又沒 audit

那就不是三個小風險。 而是同一個系統上，

三個面同時疊加。

先看總圖，不要只看單點

想像這個 LLM app 架構：

• nginx 對外開 443
• 反向代理到 127.0.0.1:8000 的 Python API
• Python API 會呼叫外部 LLM provider
• Python API 也能呼叫兩個 MCP tools
• 第一個 tool 是 search_docs
• 第二個 tool 是 deploy_preview
• deploy_preview 背後其實會執行 shell
• 開發者另外把一個 debug RAG server 綁在 0.0.0.0:8001
• 團隊還裝了一個昨天才上架的社群 MCP server

如果你只用傳統 API 安全視角，

你可能只會看：

443 有沒有 auth。

但 attack surface 視角會逼你把整張圖攤平：

• 443 是一個 surface
• 8001 也是一個 surface
• deploy_preview 也是一個 surface
• 新裝的 MCP server 也是一個 surface
• LLM provider 的 outbound 路徑也是 surface 的一部分

這就是這門課想讓你建立的反射。 不要只看一條 URL。

要看整個系統， 有哪些洞被你自己打通。

預設允許，才是最常見的攻擊面放大器

很多事故不需要高明攻擊者。 只需要系統充滿 default allow。

例如：

• 沒特別寫 deny，就先開給所有 interface
• 沒特別寫 allowlist，就先讓 agent 叫任何 tool
• 沒特別 pin version，就先裝 latest
• 沒特別設 gate，就先讓自動化直接跑完

這些都不是單點 bug。 它們是工程習慣。

而工程習慣， 最終會長成 attack surface。

Default deny vs default allow

這裡先把最重要的 operational 習慣講死：

production 必須 default deny。

也就是：

沒有被明確允許的東西， 一律不應該先開。

這個規則應該體現在：

• host binding
• firewall
• reverse proxy route
• tool allowlist
• dependency install
• skill / plugin enable flow

相反地，

開發最常犯的模式是：

先讓它能跑，再說。

這句話本身沒錯。 但如果翻成設定，

通常就會變成：

• 0.0.0.0
• admin token hardcode
• read/write tool 全開
• 第三方 MCP 直接裝
• 沒有 audit log

這整包加起來， 就是 default allow。

而 default allow， 通常就是 attack surface 最大的放大器。

什麼叫「你開出去的洞」

有些洞是主動開的。 例如你真的把 port 綁到所有介面。

有些洞是被動長出來的。

例如：

• 某個 skill install script 幫你多寫了一個 cron
• 某個 plugin 讓 agent 多了一個沒 review 的 command
• 某個 dependency 幫你偷偷多做 outbound request

所以這門課的語氣會故意很不客氣：

attack surface 不是「駭客開的洞」。 很大一部分，

是你自己為了方便開的洞。

跟 lethal trifecta 的關係

trust-boundary-101 的 Lesson 02， 以及 privilege-boundary-101 的 Lesson 03，

已經講過 lethal trifecta。 這裡不重講定義。

這裡只補一個升維觀念：

lethal trifecta 是單一 agent 的高危險組合；attack surface 是整個系統暴露面的總帳。

如果某個 agent 同時具備：

• tools
• sensitive data
• full autonomy

那它自己就是一大片 surface。

但系統層還要再往外看：

• 它綁在哪個網路面上
• 它有哪些 plugin 可以擴權
• 它信任哪些第三方 MCP

也就是說， lethal trifecta 是 surface 裡最兇的那一塊。

不是全部。

權限就是安全模型，暴露面就是風險地圖

本系列前面一直在講：

permissions ARE the security model 這句話到這門課，

可以再延伸成另一句：

exposure map IS the risk map。

你把什麼暴露出去， 外界就會從那裡進來。

所以很多時候， 最好的 hardening 不是把 prompt 寫更長。

也不是找更會拒絕的模型。

而是先問：

• 這個東西真的要對外嗎
• 這個 tool 真的要出現在 agent 手上嗎
• 這個 skill 真的要現在啟用嗎

只要答案是「不一定」， 你的預設就應該是先關。

一個最小 surface inventory 長什麼樣子

你不需要先做成大型資產管理平台。 一個最小可用版本，

至少先列出：

欄位	要記什麼
surface	這是什麼入口
type	network / tool / trust
default_policy	deny 還是 allow
owner	誰維護它
reason_to_exist	為什麼非開不可

很多暴露面一被你要求填 reason_to_exist， 就會開始顯得很尷尬。

因為不少設定其實只是：

「測試比較方便。」 這種理由在 dev 可以存在。

在 production 不夠。

一個很小，但很有用的盤點 demo

下面這段不是安全產品。 只是把思路寫成最小資料結構。

這段 code 的價值不在於它多聰明。

而在於它提醒你：

很多時候， 安全的第一步不是偵測。

是命名。 先把洞列出來，

你才有機會一個一個決定：

它該開， 還是不該開。

這門課真正要你養成的反射

以後你看到一個 AI 系統，

不要先只問：

「模型用哪一家？」 「prompt 長什麼樣？」

「能不能做更多自動化？」

先問：

• 它開了哪些網路面
• 它給了哪些工具面
• 它把多少信任委外給供應鏈

這三題答完， 你才算真的在看 attack surface。

後面四課，

我們會把這三面拆細：

• Lesson 02 看 network surface
• Lesson 03 看 tool surface
• Lesson 04 看 supply chain / trust delegation
• Lesson 05 把三面組成一個最小 secure MCP server

AI 協作：學了這個，跟 AI 怎麼配合？

這個技能在 AI 協作中的定位， 是讓你要求 AI 先幫你做整體 attack surface inventory，

而不是一上來就只討論某個 endpoint 的修補。 你的人類優勢：

• 只有你知道哪些暴露面真的是產品需求，哪些其實只是為了開發方便留下來的臨時洞。
• 只有你能決定某個 surface 的體驗收益，值不值得它帶來的風險成本。

可以這樣跟 AI 說：

我有一個 LLM app，包含 nginx、Python API、LLM provider、兩個 MCP tools，以及一個 debug server。請你先不要提解法，先把所有 attack surface 按 network exposure、tool availability、trust delegation 三類列成表格。每一項都要標記目前是 default allow 還是 default deny，最後指出最不合理的一個暴露面。

Do