Least Privilege 的概念其實很簡單，就是只給完成工作所需要的最低權限，AI 也是一樣，一般程式的執行流程通常是開發者事先寫好的，例如：

if (userRole === "admin") {
  deleteUser();
}

什麼情況執行 deleteUser()，是程式碼決定的，但 AI Agent 不太一樣，開發者可能把多個 Tool 提供給 LLM，再由 LLM 根據使用者的自然語言判斷應該呼叫哪個 Tool，例如：

const tools = {
  getOrder,
  cancelOrder,
  refundOrder
};

這時候如果 AI 因為 Prompt Injection、錯誤理解或其他原因做出錯誤判斷，它可能真的呼叫 refundOrder()，所以我們要思考這個 AI 為什麼一開始就有這個 Tool？如果它根本不需要退款功能，就不要給它 refundOrder()。

不過只限制 AI 可以使用哪些 Tool 還不夠，假設 AI 確實需要 getOrder()，我們也不能因此讓它可以查詢公司的所有訂單，例如可以讓 Backend 再次確認目前登入的 User 身分：

async function getOrder(orderId, userId) {
  const order = await db.getOrder(orderId);
  if (order.userId !== userId) {
    throw new Error("Unauthorized");
  }
  return order;
}

也就是在查詢訂單時也檢查使用者編號是不是有對上，不是的話就拒絕，不要讓 LLM 去決定 Authorization，真正的權限檢查應該由 Backend / API / Database 等系統層執行。

Least Privilege 很重要的概念就是就算 AI 被騙，也要讓它做不到，假設攻擊者真的成功使用 Prompt Injection 操控 AI 給出所有客戶訂單，如果 AI 本身就沒有讀取整個 Database 的權限，攻擊者能造成的影響仍然會受到限制，所以我們不一定能保證 AI 永遠不被騙，但可以限制它被騙之後能做多少事情，我們前面其實介紹過 Least Privilege 其實是傳統 Cybersecurity 很早就存在的原則，只是到了 AI 時代它又變得更加重要，以前我們可能只要在意 user 的權限範圍，現在需要一路限制到 AI、Tool、API 與 Database，不過 AI 可以大幅縮短我們平常工作效率，所以其實資安做好的話 AI 真的無疑是利大於弊。

說到最後 Least Privilege 的核心其實就是 AI 不需要的權限就不要給，因為 AI 擁有的每一個 Tool、API 與系統權限，都可能在模型被操控或判斷錯誤時，變成可以造成實際影響的能力。但有些功能 AI 確實需要使用，又具有一定風險時，就跟上面一樣加入另一道控制，就可以做到很好的防禦了，我覺得大部分還是人工確認一下比較好啦，就是你要輸出前或是 AI 在完成某個東西時你先卡個人工確認再讓他繼續執行也可以，人工確認會多很多保障。

下一篇：Day 19｜Human-in-the-loop：AI 要執行重要操作以前，要不要先問人？