先決定 AI 到底需要做什麼

假設公司希望做一個內部 AI Assistant，員工可以詢問：
「今年特休有幾天？」
「公司的報帳規定是什麼？」
「幫我找專案 A 的文件。」
因此我們決定讓 AI 具有三個能力：
-使用 RAG 搜尋公司文件
-查詢目前登入員工的資料
-建立 IT Support Ticket

第一件事情不是馬上接 LLM，而是先思考完成這些工作 AI 最少需要哪些資料與權限？用前面介紹的 Least Privilege 去做權限控制。

第一層：不要直接相信 User Input

使用者輸入：「幫我找公司的請假規定。」時，在送進 LLM 之前可以先經過 Input Validation，例如：

function validateInput(input) {
  if (!input || typeof input !== "string") {
    return false;
  }
  if (input.length > 2000) {
    return false;
  }
  return true;
}

實際系統還可能加入 Prompt Injection Detection、檔案格式檢查或 Content Moderation。

第二層：RAG 要先做權限控制

假設員工問：「幫我找公司今年的薪資資料。」
Knowledge Base 裡可能真的存在：一般員工手冊、財務報表、主管薪資資料、HR 員工資料，如果只是單純搜尋最相關的文件，AI 可能真的把 HR 文件找出來，因此 RAG 需要 Relevant + Authorized，例如：

const documents = await searchDocuments({
  query: userInput,
  userId: currentUser.id
});

searchDocuments() 在搜尋資料時，就必須限制目前 User 有權限讀取的文件，Authorization 不應該交給 LLM 判斷。

第三層：LLM 想用 Tool 不代表真的可以執行

接著假設使用者說：「我的電腦壞了，幫我建立 IT Ticket。」
LLM 判斷需要：

{
  "tool": "createTicket",
  "arguments": {
    "title": "Computer problem"
  }
}

這只是 LLM 提出 Tool Call，Application 還是要檢查：

if (!allowedTools.includes(toolName)) {
  throw new Error("Tool not allowed");
}

以及 Tool 的 Arguments 是否符合規則。

第四層：危險操作加入人工確認

假設未來公司又希望 AI 可以：sendEmail、modifyDocument、deleteTicket，這些操作的風險明顯比查詢文件高，因此可以加入 Human-in-the-loop，例如：

if (toolName === "deleteTicket") {
  return {
    status: "pending_approval"
  };
}

讓 AI 可以提出建議刪除 Ticket，但實際操作由人確認。

第五層：LLM Output 也不能直接相信

就算前面的 Input、RAG、Tool 都處理好了，最後還有 LLM Output，例如模型意外輸出了員工 Email、Access Token 或其他敏感資訊，因此回傳給 User 前還可以經過 Output Filtering：

const safeResponse = filterOutput(llmResponse);
return safeResponse;

如果 AI 的 Output 接下來還會被其他程式使用，就更需要驗證格式與內容，因為 LLM Output 也是 Untrusted Data。

第六層：Secret 不要交給 LLM

假設 createTicket 需要公司的 API Key，不要這樣做：

System Prompt:
Our API Key is abc123...
Use this key when calling the API.

而是讓 Application 自己管理：

async function createTicket(data) {
  const apiKey = process.env.TICKET_API_KEY;
  return callTicketAPI(data, apiKey);
}

LLM 只需要知道自己可以使用 createTicket，它根本不需要知道 API Key 是什麼。

最後：全部都要留下可以調查的紀錄

就算我們做了很多防禦，也不能假設現在一定不會被攻擊了，因此重要操作還是需要 Logging & Monitoring，如果突然出現：某個 User 一分鐘呼叫 Tool 500 次、大量 Prompt Injection Detection、Agent 不斷嘗試讀取沒有權限的文件，系統就可以產生 Alert，讓 Blue Team 進一步調查。

如果今天真的要設計一個 AI Assistant，就像前面所說要問這個 AI 需要甚麼，它可以看到什麼等等，從 Input Validation、RAG Authorization、Tool Calling、Least Privilege、Human Approval、Secret Management，到最後的 Logging & Monitoring，這些防禦組合起來就是一個比較完整的 AI Security Design。

下一篇：Day 30｜30 天 AI Security 總結：從完全不懂到建立自己的 AI Security 思維