—— 不是每個人都該問模型所有事，尤其是財務預算跟老闆薪水。

💬 開場：PM 的一句話，讓你頭皮發麻

PM：「我們把 AI 助理開給全公司用吧，越多人用越有價值！」
你（心裡 OS）：越多人用，越多人能把資料搬走。

昨天我們談了「要把 AI 行為記錄下來」。
今天要談的是——先決條件：誰可以做什麼？
沒有權限控管，Log 只會變成事後悔恨錄影帶。

🔐 為什麼 AI 需要「權限控管」？

傳統系統是 CRUD；AI 系統是 問 + 找 + 調 + 做：

• 問：對模型提問（Prompt）會帶出意圖與敏感上下文
• 找：RAG 從向量庫取資料（可能含 NDA / PII）
• 調：呼叫外部 Tools / Functions（寄信、下單、開工單…）
• 做：模型可能自動執行動作（Agent、多步任務）

結論：AI 的「權限」不是只有讀寫資料，而是能不能讓模型「代表人」做事。

🧭 要控什麼？從資源視角列清單

原則：Deny by default，沒有白名單就不執行。

🧩 RBAC 只是底座：RBAC、ABAC、PBAC 三段進化

• RBAC（Role-Based）：以角色授權（User、Analyst、Admin）
• ABAC（Attribute-Based）：以屬性判斷（部門、國別、資料等級、目的）
• PBAC（Policy-Based）：用策略語言執行複雜判斷（OPA / Cedar 等）

實務建議：RBAC 做骨架，ABAC 加條件，PBAC 負責落地引擎。

🧱 RAG 權限：把 ACL 寫進「每一個 chunk」

RAG 最容易漏：取到了不該看的文件。
把文件分級與租戶資訊寫進向量 metadata，查詢時強制過濾：

// 檢索 Wrapper（示意）
{
  "query": "招標合約條款",
  "filter": {
    "must": [
      { "key": "tenant_id", "match": { "value": "${user.tenant}" } },
      { "key": "department", "match": { "value": "${user.department}" } },
      { "key": "classification", "in": ["public","internal"] },
      { "key": "clearance", "gte": "${user.clearance}" }
    ]
  },
  "limit": 5
}

不要把過濾交給 Prompt。一定要在檢索層做硬控。

🧰 Tool/Function 權限：先問「為什麼」，再決定「要不要」

工具是最危險的地方（會改變真實世界狀態）。
三道門檻：

1. Allowlist：每個角色的可用工具清單
2. Justification：高風險動作要求用途說明（purpose-of-use）
3. JIT Elevation：臨時提高權限，但要過期 + 要審計

// 伪代碼：工具前置授權
function authorizeTool(user, tool, context) {
  if (!roleAllows(user.role, tool)) return DENY("Role not allowed");
  if (isHighRisk(tool) && !context.justification) return ASK("請提供用途說明");
  if (requiresJIT(tool)) return REQUEST_APPROVAL("SRE值班核可");
  return ALLOW();
}

🧪 Prompt 不是防線，但可以是「提醒」

System Prompt 可以寫入拒答範圍與角色上下文，但不可依賴它：

你是內部 AI 助理。你只可存取標記為 public/internal 的文件。
不得洩露任何包含 PII、密級為 confidential/secret 的內容。
遇到工具呼叫，請先產生「行動計畫與用途說明」，等待系統審核通過再執行。

真的執行權限，必須在後端 Gateway/Policy Engine 判斷。

🧱 參考策略（Cedar/OPA 思路）

Cedar 語意示例（簡化）：

permit(
  principal in Role::"Analyst",
  action in [Action::"rag.read", "tool.search"],
  resource in Doc
)
when {
  resource.classification in ["public", "internal"] &&
  resource.tenant == principal.tenant &&
  resource.clearance <= principal.clearance
};
forbid(
  principal,
  Action::"tool.send_email",
  resource
) when { true }; // 預設禁止發送外信

🧱 架構藍圖：把權限安在「最中間」

[Client]
   │  AuthN (OIDC / SSO)
   ▼
[API Gateway]──►[Policy Engine (OPA/Cedar)]
   │                        │
   │                  [Decision: Allow/Deny/Ask]
   │                        ▼
   ├──►[LLM]──►[RAG Retriever with Metadata Filter]
   └──►[Tool Proxy (Allowlist + JIT + Justification)]
                          │
                      [Audit Log / SIEM]

✅ 落地檢核清單（開箱即用）

• [ ] 角色矩陣（人 × 資源 × 動作）完成並評審
• [ ] 向量庫每個 chunk 具備 tenant/department/classification/clearance
• [ ] Gateway 強制過濾；Prompt 不負責權限
• [ ] 工具層有 Allowlist、JIT、用途說明
• [ ] 高風險動作有「雙人核可」與到期時間
• [ ] 每一次拒答/拒權，都有可追溯的 Log
• [ ] 例行紅隊測試：權限繞過 / Prompt Injection 升權
• [ ] 監控指標：被阻擋的工具呼叫數、越權檢索嘗試數、政策漂移告警

🎭 工程師小劇場

你寫了一個寄信工具 send_email()，預設 everyone 可用。
有人問 AI：「幫我把最新財報寄給客戶」。
AI 很聰明，真的寄了。
你也很聰明，把它關掉了。
PM 更聰明：「那我們把權限開回來，但先問為什麼。」
—— 這就叫 JIT + 用途說明。

🎯 小結

權限不是文件，而是執行路徑上的阻斷點。
把 RBAC/ABAC/PBAC 放在 Gateway，把 ACL 放在檢索，把審核放在工具前。

AI 不是黑箱，但你的權限如果是黑箱，事故就會是公開的。

🔮 明日預告：Day 9｜資料分級與 DLP：讓機密不再「被模型記住」

分級標籤怎麼定義？DLP 在 LLM/RAG 中怎麼落地？我們明天拆給你看。