我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。

如果 AI 可以正常運作，但它真的安全嗎？

Day 27 我談到 Production Reliability：服務故障時，系統能不能發現、隔離並恢復？

但即使 AI Service 穩定運作，還有另一個不能忽略的問題：

它真的安全嗎？ AI Service 沒掛，但不該使用的人進來了怎麼辦？

我以前接觸 Cloud 與 Kubernetes Security 時，會關注 Authentication、Authorization、Secrets 與 Least Privilege。但開始研究 LLM 與 AI Agent 後，我發現 AI Application 又多了一層新的攻擊面。

例如使用者輸入的 Prompt 本身可能是不可信任的；AI 可能讀取外部文件、RAG 資料或網頁；如果 Agent 又能呼叫 API、資料庫或其他 Tools，一次惡意的 Prompt Injection，影響的可能就不只是「回答錯誤」。

OWASP 目前仍把 Prompt Injection 列為 GenAI Application 的重要安全風險，並建議限制模型與工具的權限、採用 Least Privilege，以及對高風險操作加入人工確認。OWASP 最新 GenAI Security guidance 則持續把 Prompt Injection、敏感資訊洩漏，以及 Agent 權限過大等列為重要風險。

這讓我開始理解：AI 能正常回答，不代表 AI Service 是安全的。AI Security 不能只靠 System Prompt 告訴模型「不要做危險的事」。

OWASP 甚至明確提醒，System Prompt 不應被視為秘密或安全控制，Credentials、Connection String 等敏感資訊更不應放進 System Prompt。真正的安全邊界仍然必須建立在 Application 與 Infrastructure，例如 Identity、Authorization、Secret Management、Tool Permission 與 Audit。

Kubernetes 本身也是相同概念：官方建議只提供使用者與 Service Account 完成工作所需的最小 RBAC 權限，Secret 的存取同樣應遵循 Least Privilege。從Google Cloud / Kubernetes Security 接觸到 LLM / Agent 後，發現傳統的 Authentication、Authorization、Secrets、Least Privilege 並沒有因為 AI 出現而消失，反而因為 Agent 能操作工具而更加重要。

所以問題來了：

如果 AI Agent 被 Prompt Injection 誘導做出錯誤決策，我們的 Infrastructure 能不能阻止它執行真正危險的操作？

這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我認為 Production AI 必須面對的安全問題。LLM 只產生答案；Agent 開始產生「行動」。Agent 讓 Production 更複雜、更重要危而 險、更重要，而 AI Agent 真的安全嗎？在haggingface被攻擊事件，Agent 被騙了，Agent能自我判斷決定為其他Agent犧牲，你能不能阻止它？

關於作者

我是一名 AI × Infrastructure Solution / Integration 技術實作者，專注於 AI、MLOps、Cloud、Docker、Kubernetes、GPU、LLM 與 AI Agent 等技術的整合與落地，跨足 LLM、GPU、Docker、Kubernetes、MLOps 與 AI Agents，持續研究企業 AI 從 Prototype 到 Production 所需要的工程能力。協助企業理解 AI 從 Prototype 到 Production 所需要的技術能力。

本系列同時是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》的延伸實戰筆記。如果想完整理解這些更深的技術問題，未來可以去看這本書(書中包含了一些的範例與提示詞，特別是AMD W7900 48G的使用技術心得，這些是外面很少有的獨家踩坑經驗，還有Production Checklist，未來買書真的賺到！)。敬請期待唷~