終於來到第 30 天，這 30 天從 AI Security 到底是什麼開始，一路介紹到 Prompt Injection、RAG、AI Agent、MCP、Red Team 與 Blue Team，最後一天我們來整理這 30 天到底學到了什麼？

一開始我以為 AI Security 是保護 AI，剛開始接觸 AI Security 時，很容易把它想成不要讓 ChatGPT 被駭，但一路研究下來才發現 AI Security 真正要保護的其實是整個 AI Application，一個現在常見的 AI 系統可能包含：LLM、System Prompt、RAG、Knowledge Base、Memory、Tool、MCP Server、API、Database，所以攻擊者也不一定要真的破解 LLM，只要其中一個環節存在問題，就可能影響整個系統，這也是第一週介紹 Attack Surface 與 Threat Modeling 的原因，在開始防禦之前，必須先知道到底在保護什麼？有哪些地方可能被攻擊？

第二週開始真正進入攻擊，其中最重要的一個概念就是 Prompt Injection，因為 LLM 會處理自然語言，攻擊者可能把惡意指令藏在 Prompt、網頁、Email、文件，甚至其他外部資料裡，試圖影響模型原本應該執行的任務，接著又看到：
Jailbreak：繞過模型原本的安全限制。
Hidden Context Exposure：原本不打算直接提供給使用者的 Context 被暴露。
Sensitive Information Disclosure：AI 洩漏個資、公司文件等敏感資訊。
Data & Model Poisoning：從訓練資料或模型本身下手。
RAG Poisoning：污染 AI 搜尋的 Knowledge Base。
Excessive Agency：Agent 被賦予超過任務需要的權限與自主能力。
這些攻擊雖然方式不同，但讓我開始意識到一件事情，不能因為 AI 看起來很聰明，就把它當成可信任的安全邊界。

第三週開始從攻擊轉向防禦，這也是我覺得 AI Security 很重要的一個觀念轉變，假設 System Prompt 寫：不要洩漏公司機密、不執行惡意操作等等，這些規則當然有用，但它們不能取代真正的 Security Control。
所以我們開始加入：
Input Validation：進入 LLM 前先檢查輸入。
Output Filtering：模型輸出後再次檢查。
Least Privilege：只給 AI 完成工作真正需要的權限。
Human-in-the-loop：高風險操作需要人工確認。
Secret Management：API Key、Token 等 Secret 不直接交給 LLM。
Logging & Monitoring：留下紀錄並持續偵測異常行為。
重要的是 Prompt 可以告訴 AI 不要做，但真正的 Security Control 應該讓它做不到，例如 AI 不應該查看其他使用者的資料，就應該由 Backend Authorization 阻止，而不是只在 Prompt 裡寫：「請不要查看其他人的資料。」

到了最後一週，AI Security 又多了一層，因為現在的 AI 已經不一定只是 User 問問題然後 AI 回答，AI Agent 可以使用 Tool、讀取文件、搜尋資料，甚至操作其他系統，我們也因此介紹了：
Tool Calling Security：LLM 要求使用 Tool，不代表 Application 就應該直接執行
MCP Security：MCP 提供標準化的外部工具與資料連接方式，但連上的 MCP Server 與 Tool 仍然需要考慮信任與權限
Agent Memory Security：惡意內容如果被保存進 Memory，可能在未來再次影響 Agent
AI Supply Chain Security：Model、Dataset、Package、MCP Server 等第三方元件也可能成為攻擊入口

到了這裡 AI Security 已經不只是：「AI 會不會回答錯誤的內容？」
而是：「如果 AI 判斷錯誤或被攻擊者控制，它到底有能力造成什麼影響？」
當 AI 只能聊天時，錯誤可能只是一段文字；當 AI 可以寄 Email、修改資料、操作帳號或呼叫 API 時，同樣一次錯誤判斷的影響就可能完全不同。

最後我們又從兩個不同角度看 AI Security，Red Team 站在攻擊者角度，主動測試要怎麼讓自己的 AI 出問題？
Blue Team 則站在防守者角度思考要怎麼發現、阻止並處理這些問題？Red Team 找到新的攻擊方式後，Blue Team 加入防禦與監控，再交給 Red Team 重新測試，Security 因此不是做完一次就安全了，而是一個持續測試與改善的過程。

寫完這 30 天，我覺得 AI Security 最重要的不是記住所有攻擊名稱，而是建立一個習慣，以後看到一個新的 AI Application，可以開始問：
AI 可以看到什麼資料？
AI 可以使用哪些 Tool？
AI 擁有哪些權限？
哪些外部資料可能影響 AI？
如果 AI 被 Prompt Injection 騙了，最嚴重能做到什麼？
真正的 Authorization 是誰負責？
如果真的出事，我們能不能發現與追查？

如果開始會問這些問題，其實就已經開始用 Security 的角度思考 AI 系統，30 天結束，但 AI Security 還沒有結束，這 30 天從 LLM 最基本的運作方式開始，一路走到 AI Agent Security，我最大的收穫不是學會怎麼破解 AI，而是逐漸理解 AI Security 並不是找到一個完美的方法讓 AI 永遠不犯錯，而是假設 AI 有可能犯錯、被欺騙甚至被攻擊，再設計其他安全機制限制它能造成的影響，這也是為什麼我們最後回到了 Defense in Depth，沒有任何一道防線可以解決所有問題，Prompt、Application、Tool、API、Database、權限與監控，都需要一起考慮，30天到這裡結束，但對我來說這30天比較像是把 AI Security 的地圖畫出來了，接下來真正值得繼續研究的會是如何把這些概念實際放進 AI Application，並透過 Red Team、Security Testing 與實際攻防，不斷驗證自己的系統到底安不安全，題外話我最喜歡第二週的案例部分，可以在真實案例中看到很多很酷的操作，可以學到很多新知識。