AI Agent 保安全景圖

Let me check if there are any relevant assets or directory structures first. No existing assets to worry about — this is a standalone blog post. I’ll write the full article directly.

title: “AI Agent 保安全景圖” date: “2026-07-10” slug: “ai-agent-security-landscape” summary: “從 46 個安全威脅條目提煉出 AI Agent 專屬安全評估框架，對照攻防兩端實用工具，為開發者提供可操作的 Agent 安全建構指南。” tags:

build
ai-security
agent-safety
llm-security
security-framework
prompt-injection draft: false lang: zh-Hant

AI Agent 嘅安全問題，同傳統軟件安全本質上係兩回事。傳統安全係防範人為錯誤同漏洞——SQL injection、XSS、buffer overflow，全部有幾十年累積嘅 playbook。Agent 安全唔同：你唔係防緊漏洞，你係防緊一個有推理能力、可以郁手做嘢、仲要俾咗工具嘅系統被第三者操控。呢個唔係 security patch 搞得掂嘅問題，而係成個信任模型需要重新諗過。當你嘅 agent 可以收 email、碌 database、執行 code，一條 prompt injection 嘅攻擊鏈可以喺幾秒之內由「你好」變成「成個 production database delete 晒」。

從 46 個威脅條目提煉安全框架

security-threats wiki 嘅 46 個 entry 覆蓋咗 agent 安全嘅九成戰場，但唔係個個 threat 都同等緊要。將佢哋歸納之後，其實得三個核心維度：

第一係授權濫用（Authorization Abuse）。Agent 攞到咗嘅權限點樣防止佢被騎劫使用？典型情況係 agent 有權限去 call API，但攻擊者透過 prompt injection 叫 agent call 咗唔應該 call 嘅 API。呢個唔係 OAuth 或者 RBAC 搞得掂嘅——因為 agent 係「合法用戶」，佢發出嘅 request 係「合法 request」，但個 intent 被 hijack 咗。解決方向係 dual-layer authorization：user-level 同 tool-level 分開審計，每條 tool call 都要對返原本嘅 user intent。

第二係資料隔離（Data Isolation）。Agent 喺 multi-turn conversation 入面會 accumulate context，而呢個 context 就係攻擊面。Indirect prompt injection 嘅經典玩法就係：你個 agent fetch 咗個網頁，網頁入面 embedded 咗一條 injection instruction，agent 讀完就照做。解決方法唔係 stop fetching——而係要喺 data ingestion layer 做 content safety boundary，將 untrusted content 同 agent 嘅 system prompt 喺語義層面隔離。

第三係執行沙箱（Execution Sandbox）。Agent 有 code execution、shell access 或者 browser automation 嘅時候，點樣確保佢做嘅嘢唔會超出預期範圍？呢個位最接近傳統安全，但挑戰在於 agent 需要合理嘅靈活性去做嘢，太 tight 嘅 sandbox 會令 agent 廢咗武功。關鍵係 capability-based sandboxing，逐個 tool 定義佢嘅執行邊界，而唔係一刀切 allow/deny。

攻防兩端嘅工具對照

講完框架，睇返實際工具層面。攻擊者嗰邊嘅 arsenal 呢一兩年成熟得好快——從最基礎嘅 prompt injection payload generator、到可以自動化 scan agent endpoint 嘅 red-teaming framework、再到專門針對 tool-calling agent 嘅 adversarial attack suite。Anthropic 出咗嘅 vulnerability discovery framework 係少數由防守方主導、有系統性嘅方法論：佢將 agent vulnerability 分類成七個 attack surface（工具層、記憶層、規劃層、執行層、回饋層、輸出層、協調層），每層都有對應嘅測試用例同評估指標。

防守方嘅工具相對滯後，但都有幾個值得留意嘅方向。Guardrails 類嘅工具（唔係指 Nvidia 嗰個 hardware guardrail）開始出現 agent-specific 嘅 security policy engine，可以喺 tool call 之前做 policy check。另一邊廂，runtime monitoring 開始有 agent-specific 嘅 logging 同 auditing framework——唔係傳統嘅 log 啲 HTTP request，而係 log 每個 agent 嘅 reasoning trace、tool call decision 同埋 intermediate output，咁樣先可以 detect 到 anomalous 嘅 agency 行為。

兩邊嘅落差在於：攻擊工具係通用嘅，一個 prompt injection payload 可以打你十個 agent endpoint；防守工具係 specific 嘅，每個 agent 嘅 architecture、tool set、pipeline 都唔同，無得一套 framework 通殺。呢個 asymmetry 係 agent 安全最棘手嘅結構性問題。

香港開發者應該點樣開始

同 silicon valley 唔同，香港嘅開發團隊多數係 lean team，無專屬嘅 security team，亦無 budget 去行 full-scale red teaming。但正正因為咁，你需要將 security 嵌入 development workflow 而唔係甩俾 security team。

實戰建議有三個。第一，喺 agent 嘅 system prompt 落 invariant：每條 tool call 執行之前，agent 必須自己檢查個 call 係咪對應返用戶嘅原始意圖。呢個係成本最低、效果最大嘅防線。第二，建立 tool-level audit log：唔係 log 啲 high-level 嘢，而係 log 每個 tool call 嘅 input、output、reasoning trace，方便出事之後 reconstruct attack chain。第三，做 prompt injection 壓力測試：用 open-source 嘅紅隊工具（例如 Garak、PromptInject）定期掃你嘅 agent endpoint，當係 regression test 咁行。

AI Agent 仲喺好早期，安全標準都未成形。而家開始認真對待呢個問題嘅團隊，一兩年之後呢方面嘅經驗就會變成真正嘅 moat。等 standards 出晒先郁手嘅，到時已經係追落後。