做一個 Agent 安全產品：從 moto 17 個安全鉤子到企業採用障礙

如果你睇過 Motorola 手機嘅 Android kernel 源碼，你會發現一個好有趣嘅設計：security/security.c 入面定義咗超過 17 個安全鉤子（LSM hooks），由 binder_transaction、ptrace_access_check 到 inode_create、sb_mount，每個系統操作嘅關鍵路徑都有一個鉤子，俾 SELinux、Yama、LoadPin 呢啲安全模組插入去執行政策。呢個唔係偶然——Linux Security Module（LSM）嘅設計哲學係「政策無關、可疊加、喺執行路徑上攔截」。今日我哋講 AI agent 安全產品，其實面對緊同一個問題：你點樣喺 agent 嘅決策同執行路徑上落鉤，攔截、檢查、控制，而唔影響個 agent 本身嘅行為邏輯？

由 LSM 到 Agent Security：同一個 pattern，唔同嘅層

LSM 嘅 call_int_hook macro 背後嘅原理好簡單：喺 kernel 嘅關鍵路徑上預留 hook list，每個安全模組可以註冊自己嘅 handler，執行完一個就 chain 去下一個，任何一個 reject 就中止。呢個 pattern 其實就係今日 AI agent security 產品要做嘅嘢——agent 嘅 tool call、prompt 輸入、MCP 請求、file access、network call，每一點都係 potential hook point。

但問題係：LSM 嘅鉤子係 kernel 層面定義好嘅，agent 嘅執行路徑係點？今日嘅 AI agent runtime（無論係 LangChain、CrewAI 定係 AutoGPT）冇一個標準化嘅 hook interface。每個 framework 有自己嘅 middleware / callback 機制，但冇共通協議。呢個就係第一個產品機會——定義 agent security 嘅「LSM 等價物」，一套可以橫跨唔同 agent framework 嘅安全鉤子介面。

2026 年嘅數據話畀我哋知，54% 嘅企業已經出過 AI agent 安全事故，但得 32% 會俾每個 agent 一個獨立嘅 scoped identity。仲有 71% 嘅企業係用緊冇專為 autonomous system 設計嘅安全控制——佢哋用緊嘅係 provider-native guardrail（OpenAI、Anthropic、Google）嚟頂住先。滿意度仲要高達 4.2/5，但同時 59% 話一年內會換工具。呢個矛盾本身就係信號：market 知道有問題，但未準備好買單。

產品定位嘅陷阱：做 platform 定做 protocol？

我最怕見到嘅係潮州佬式嘅 agent security product——乜都想做，由 agent discovery 到 runtime monitoring 到 compliance reporting 到 identity management，一個 platform 包晒。呢個 approach 有兩個致命問題：

第一，agent ecosystem 仲未定型。今日嘅 MCP protocol、Agent-to-Agent 通訊、tool calling 標準全部喺度變緊。你做一個 monolithic platform 去 intercept 呢啲嘢，半年後 protocol 一改你就重寫。第二，企業買 security product 嘅決策週期好長（6-12 個月），而你作為 startup 冇咁多 runway 去等。

Okta 嘅 Agent Gateway 嘅 approach 值得參考——佢哋唔係做另一個 gateway，而係喺現有 MCP gateway 上面加一層 identity enforcement。佢哋知道自己嘅 core competency 係 identity，所以專注做「broker credentials at runtime」呢一件嘢。Palo Alto Networks 嘅 Prisma AIRS 都係類似思路——AI Gateway 做 control plane，但 runtime security 係另一層。

對於 indie builder 嚟講，最 real 嘅切入點可能係做「agent behavior baseline 同 anomaly detection」嘅 niche product。唔需要 intercept 所有 traffic，只需要做一個 sidecar / proxy 去觀察 agent 嘅 tool call pattern，build baseline，detect deviation。呢個 approach 嘅好處係 protocol-agnostic，唔需要同每家 agent framework 做 integration，而且 anomaly detection 嘅 value proposition 好直接——你唔需要解釋「為什麼要安全」，你只需要 show 俾佢睇「你嘅 agent 做咗啲你唔知嘅嘢」。

企業採用嘅真正障礙

我同幾個用緊 agent 嘅企業傾過，佢哋嘅痛點唔係「冇安全產品」，而係「安全產品會拖慢我哋出嘢」。CISO 想要 control，但 AI team 想要 speed。今日嘅 reality 係：AI team 喺 shadow IT 模式下行先，CISO 係事後先知道有 agent 喺 production。任何要喺 agent 同 tool 之間加一層 proxy/gateway 嘅產品，都會被 AI team 視為「friction」。

Forrester 嘅 AEGIS framework 提醒咗一個重要嘅點：agent security 唔係一個工具問題，而係一個 governance 問題。好多企業連 agent inventory 都做唔到——佢哋唔知自己有幾多個 agent、每個 agent 有咩 permission、連咗咩 tool。所以先要做嘅唔係 runtime control，而係 observability 同 discovery。

另外一個障礙係 compliance 唔明朗。NIST 嘅 COSAiS（Control Overlays for Securing AI Systems）overlay 最快 2027 年先出到 final version。即係今時今日，冇一個標準話你知「agent 安全點做先合規」。冇標準，CISO 就冇 budget justification。冇 budget justification，你就 sell 唔入。

畀 indie builder 嘅實戰建議

如果你真係想做 agent security 呢個賽道，我會建議三個方向：

第一，做 agent observability 嘅 lightweight tool。幫企業答三條問題：我有幾多個 agent？佢哋連咗咩 tool？邊個授權嘅？呢啲係最 basic 嘅 inventory 問題，但大部分企業答唔到。做一個可以 15 分鐘 deploy 嘅 agent，唔係一個要 SI 團隊搞三個月嘅 platform。

第二，target EU 市場先。VentureBeat 嘅 research 顯示歐盟企業受 EU AI Act、DORA 制約，security control 採用率（34%）明顯高過北美（23%）。有 compliance pressure 嘅 market，buyer intent 強好多。而且歐盟嘅 startup ecosystem 對新 vendor 嘅開放度比北美高。

第三，唔好追 platform play。唔好自己做 gateway，唔好自己做 identity provider。專注做一層 middleware——plug into existing gateway（無論係 Envoy、Kong、定係 Okta Agent Gateway），加 anomaly detection 同 behavior analysis。呢個 approach 嘅 sales cycle 短好多，因為你 sell 俾嘅係 AI team 而唔係 CISO，AI team 嘅 budget 同決策速度都快好多。

Agent security 係一個 real market，2026 年嘅數據已經證明咗 gap 嘅存在。但 product-market fit 唔係靠做大 platform 達到嘅，係靠 pinpoint 一個痛點、解決好、先展出去。Android kernel 嘅 LSM 架構花咗十年先成熟——agent security 都係一樣。如果你今日開始做，2027 年 NIST overlay 出嘅時候，你就係最有經驗嘅 vendor。