前言
大家好！先簡單介紹一下自己，我是輔大醫資系的學生，這次我選擇將主題訂在醫療產業中必不可少的AI Security，且聚焦在醫療場景下的 AI 資安。

我發現大家在討論 AI 的時候，常常把「AI Security」跟「AI Safety」混著講，但這兩件事其實差很多。第一天，先來跟大家介紹兩種不同觀念。

AI Safety 跟 AI Security，到底差在哪?
簡單說:

• AI Safety(AI 安全性) 關心的是「這個模型的行為本身會不會造成傷害」。例如模型會不會產生有害內容、會不會給出錯誤的醫療建議、會不會被誤用去做壞事。這比較偏向模型「本身」的價值觀跟行為對齊問題。

• AI Security(AI 資安) 關心的是「這整套系統會不會被外部攻擊」。例如有沒有人可以用特殊的輸入，讓模型講出不該講的話、洩漏不該洩漏的資料、或是被操控去執行原本設計之外的行為。這比較偏向「系統防禦」的問題，概念上更接近傳統資安裡的攻防思維。

舉例來說，AI Safety 像是在問這個人本性善不善良，AI Security 則是在問這個人的房子門窗鎖得夠不夠牢，會不會被闖空門。兩者都重要，但這個系列 30 天，我會專注在後者。

為什麼一個 Chatbot 會變成新的攻擊面?
過去我們談資安，防守的目標很明確：網站有沒有 SQL Injection、伺服器有沒有補好漏洞、資料庫的存取權限設得對不對。這些都是規則明確的系統，輸入跟輸出之間的邏輯是工程師寫死的。

但大型語言模型不一樣。它的行為不是寫死的規則，而是根據輸入的文字去生成回應。這代表：

1. 攻擊者不需要寫程式碼，只需要用自然語言就可能操控模型的行為，這就是後面幾天會深入談的 Prompt Injection。

2. 模型有可能在對話中不小心記得或洩漏它不該講的資訊，像是系統設定，或是它處理過的敏感資料。
   因為模型的輸出本質上是機率性的，同一句攻擊 prompt不見得每次都成功，這讓防禦跟測試都變得比傳統資安更複雜。

3. LLM 應用把攻擊面從程式碼層級，拉到了語言跟語意的層級。這也是為什麼像 OWASP 這種傳統資安社群會特別為 LLM 應用另外整理一份 Top 10 風險清單，而不是直接套用舊有的 Web 資安框架。

我會怎麼做這個系列?
我打算用一個貫穿 30 天的實驗，而不是零散地介紹知識點。整體架構是:

建立一個虛構的「醫療 AI Chatbot」
        ↓
先攻擊它，找出真正的漏洞(Red Team)
        ↓
針對找到的漏洞，一層一層加上防禦(Blue Team)
        ↓
用自動化工具(Promptfoo)大量測試，量化防禦前後的差異
        ↓
整理成一份 Medical AI Security Checklist

會選醫療當實驗場景，是因為醫療資料的敏感程度高、監理要求嚴格，一旦 AI 系統被攻擊後果比一般聊天機器人嚴重得多。這讓整個實驗更有現實意義，也剛好呼應我自己的系所背景。

今天的產出：第一版威脅模型(Threat Model v0)
在還沒開始寫程式碼之前，我想先畫出這個系統可能被攻擊的路徑，這樣後面每一天的攻擊測試才有明確的目標，而不是亂槍打鳥。

使用者(可能是病患，也可能是攻擊者)
        ↓
    網頁前端
        ↓
  Express 後端 API
        ↓
   Gemini 大型語言模型
        ↓
（未來可能串接的病患資料 / 工具）

初步標出來，幾個值得關注的節點:
使用者輸入 → 後端：這裡是 Prompt Injection 最主要的入口。
後端 → LLM：System Prompt 有沒有被妥善保護，是這一段的重點。
LLM → 病患資料：未來如果串接真實資料查詢功能，這裡會是資料外洩風險最高的地方，這也是我全系列最重視的一塊。

這張圖只是起點，之後每次找到新的攻擊手法，我都會再重新更新它，讓它變成一張真正反映系統風險的地圖。

明天預告
Day 2 會談「為什麼選醫療 AI 當實驗場」，並且開始設計這個系列會用到的虛構病患資料結構。

本系列所有病患資料皆為人工生成之虛構資料,不涉及任何真實病患。GitHub Repo:medical-ai-security-lab