—— LLM 可以「建議」，但所有「執行」都必須經過閘道。

對象：平台工程 / 資安 / 內部應用負責人 / LLMOps
關鍵機制：Allowlist → JSON Schema → Justification → JIT 提權 → Dry‑run → 審計

💬 開場：回答是文字，工具是現實

多數事故不是「模型答錯」，而是工具被誤用：寄錯信、刪錯資料、把機密傳到外網。
今天把「工具閘道（Tool Gateway）」做成系統級控制點，讓 AI 只能在護欄內「動手」。

🏗️ 參考架構：Tool Gateway（系統級護欄）

[Client / LLM]
   │ function call
   ▼
[Tool Gateway / Proxy] ──► [Policy Engine (OPA/Cedar)]
   │          │
   │          ├─ Param Validator (JSON Schema / Regex / Allowlist)
   │          ├─ Idempotency / Replay Guard / Budget / Rate
   │          ├─ Risk Scoring → Justification → JIT 提權（雙人核可）
   │          └─ Dry‑run / Diff Preview（雙階段：prepare → execute）
   ▼
[Connectors] ──► [Target APIs/DB]
   ▼
[Audit / SIEM / Metrics]

🧱 十條硬規則（先上就先安全）

1. 預設拒絕：角色 × 工具白名單（RBAC + ABAC）
2. 嚴格結構：所有工具參數以 JSON Schema 驗證，additionalProperties=false
3. 用途說明：中高風險工具必填 justification + ticket_id
4. JIT 提權：高風險動作需臨時提權 + 到期時間 + 雙人核可
5. 雙階段執行：寫入類工具預設 prepare → confirm → execute
6. 冪等鍵：同 idempotency_key 僅執行一次，防重放/重複提交
7. 速率與預算：user/session/tenant 維度的 rate + token/費用上限
8. 外呼治理：對外 domain/IP 白名單；禁止未註冊端點與匿名儲存
9. 資料最小化：工具只接收必要欄位；拒絕將 RAG 原文整段轉發外部
10. 全量審計：事件化記錄（人、身分、參數、理由、決策、結果、憑證）

🧰 JSON Schema（參數護欄示例）

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "send_email",
  "type": "object",
  "properties": {
    "to": { "type": "string", "format": "email" },
    "cc": { "type": "array", "items": { "type": "string", "format": "email" }, "maxItems": 5 },
    "subject": { "type": "string", "maxLength": 120 },
    "body": { "type": "string", "maxLength": 5000 },
    "attachments": { "type": "array", "items": { "type": "string", "pattern": "^file://[a-zA-Z0-9/_.-]+$" }, "maxItems": 3 }
  },
  "required": ["to", "subject", "body"],
  "additionalProperties": false
}

⚙️ 工具呼叫前置授權（TypeScript Pseudo）

type Verdict = "allow" | "ask" | "deny" | "elevate" | "dryrun";

export async function gateTool(user, tool, params, ctx) {
  // 1) 白名單
  if (!allowlist(user.role).includes(tool)) return { verdict: "deny", reason: "not_allowed" };

  // 2) Schema 驗證
  if (!validateJson(schemaOf(tool), params)) return { verdict: "deny", reason: "bad_params" };

  // 3) 敏感分級與用途說明
  if (isHighRisk(tool) && !ctx.justification) return { verdict: "ask", ask: "請填用途說明與工單編號" };

  // 4) JIT 提權（需核可與到期）
  if (needsJIT(tool) && !await approved(user, tool, ctx)) return { verdict: "elevate", next: "等待二人核可" };

  // 5) 寫入類工具 → 先 Dry‑run
  if (isWrite(tool)) {
    const diff = await preview(tool, params);
    return { verdict: "dryrun", diff };
  }
  return { verdict: "allow" };
}

🧪 Dry‑run / Diff Preview（先看差異再執行）

• run_sql.update：回傳將更新的列數/條件/示例差異
• send_email.bulk：回傳收件群組、主旨與前三行內文預覽
• create_ticket：回傳標題/標籤/受理人，確認後才寫入

預設不直接「一鍵送出」，而是可審核的變更提案。

🔐 JIT 提權與雙人核可（零信任版本）

• 提權只對單次、單工具、單組參數有效；逾時作廢（如 15 分鐘）
• 第二人（≥ SRE/Team Lead）於審核面板核可
• 核可憑證（簽章/憑證序號）與執行事件綁定，寫入 SIEM

🧲 Egress 與 Secrets 治理

• 執行容器不暴露 LLM 的 System Prompt/使用者上下文/其他工具憑證
• 使用 短期憑證（STS） 與 精細範圍（scope）
• 外呼目標必須在 egress-allowlist.yaml 註冊；未註冊一律擋

# egress-allowlist.yaml
destinations:
  - name: corp-mail
    host: smtp.corp.local
    protocol: smtps
  - name: ticketing
    host: jira.corp.local
    protocol: https

🧪 測試與紅隊（最小集）

• 參數注入：在 Prompt/文件夾帶 to:"external@evil.com" 應被 Schema 擋下
• 重放攻擊：重送同 idempotency_key，應僅執行一次
• 無用途說明：對 run_sql.prod 應被「要求填寫用途」或「提升核可」
• 越權工具：角色無 send_email.bulk 應被拒並告警

📊 指標與告警（SLO/SIEM）

• Blocked tool calls / day（理由分類：not_allowed / bad_params / missing_justification / jit_required）
• Dry‑run → Execute 比率（過低＝未真正審核；過高＝流程摩擦）
• JIT approval median time（核可延遲）
• Idempotency violations / Replay blocked
• Egress violations（外連/外傳被擋）

✅ 落地檢核清單

• [ ] 工具 × 角色白名單已審核並上線
• [ ] JSON Schema 驗證（additionalProperties=false）
• [ ] justification 與 ticket_id 為必填（中高風險）
• [ ] JIT 提權 + 到期時間 + 雙人核可
• [ ] 寫入類工具預設 Dry‑run（差異預覽）
• [ ] Idempotency／防重放（nonce + 時間窗）
• [ ] Egress 白名單 + DLP 掃描
• [ ] 全量審計接 SIEM；監控儀表板就緒

🎭 工程師小劇場

PM：可以幫我寄封信給所有客戶嗎？
你：可以，請先填「用途說明」與「受眾群組」，等核可通過我再按下執行鍵。
PM：……那我先把名單與工單號開好。

🎯 小結

工具閘道的價值，不是限制，而是可控。
讓模型去「想」沒關係；要「動手」就過閘道。你的系統，才會既聰明又守規。

🔮 明日預告：Day 12｜API 與 Webhook 安全：簽章、重放、租戶隔離

把「外部介接」這條命脈做厚：簽章驗證、時間窗、nonce、租戶邊界。