# Requirements: 資料外流警示（Data Exfiltration Warning）

> 2026-05-30 建立（richblack 確認）。資安優先、及早做。
> 判準源：DECISIONS §7（讓 AI 不做歪 + 閉環）、§0（減少不可控依賴 / 風險）；BACKLOG 步驟 5b。

---

## 背景與風險

arcrun 讓「產生 API / 把資料送出去」變很簡單（一堆資料 + webhook trigger = API；recipe = 打某 endpoint）。
**這個「簡單」本身是風險**：簡單到 AI 可能在用戶不知情下，把含個資的東西變成可被呼叫的 endpoint，或把
敏感資料送到非預期對象。

**richblack 的核心情境**：用戶有個 Google Sheets 存所有朋友的個資。正確用法是「call 它查詢」（自用）。
但若 AI 把它變成一個 recipe / workflow，**送資料到非預期對象**（公開 webhook、公司群、外部 endpoint），
且**沒做認證** → 所有資料裸奔。

**關鍵原則（richblack 2026-05-30）：**
1. **不分公私庫都要警示**。私人庫（公司用）一樣會出事（不小心把個資 POST 到公司群）。觸發點不是「推公共」，
   是「這動作會讓資料流向某處」。
2. **不禁止**用戶公開 / 送資料（他要放什麼給誰是他的自由）——**但要確定他自己明示同意了**，不是 AI 替他決定。
3. **兩道防線**：(a) hook 在 AI 動手前警告（防在前）；(b) API 層在資料真送出前攔（防在後）。不論哪條路都攔。

## 需求

### R1 — API 層警示（資料送出前需人類同意，不分公私庫）
任何「把資料送往某目的地」的 API 動作，在執行/儲存前需人類明示同意。涵蓋（待 design 盤準）：
- `acr recipe push`：recipe 定義一個 endpoint（資料去向）。
- `acr push`（workflow）：workflow 可能含「讀敏感源 → 送往某 endpoint」的節點。
- webhook trigger 部署：把 workflow 變成可被呼叫的 API。
- 未來「recipe 貢獻公共庫」路徑（BACKLOG 飛輪項）。

同意內容要讓人看得懂風險：**這個動作會把 [什麼資料] 送到 [哪個目的地]，需不需要 credential 保護？確認？**

### R2 — hook 在 AI 動手前警告
AI 要做這類動作（寫含外部 endpoint 的 recipe/workflow、跑會送資料的指令）前，hook 先警告 + 要人類確認。
這是「防在前」——在 AI 本機動手當下就提醒，不等到 API 層才攔（省一趟、且更早讓人看到）。

### R3 — 誠實的偵測範圍（不假裝能全防）
「敏感資料送到非預期對象」機械上難完整偵測。本系統做**可機械判斷的部分**，誠實標明擋不住的：
- 能偵測：動作含「外部 endpoint」（recipe endpoint / workflow http 節點 / webhook 對外）。
- 難偵測：「這份資料是否敏感」「這個目的地是否非預期」——這需要語境，機器判不準。
- 做法：偵測到「資料 → 外部目的地」的動作就警示，由**人類**判斷該資料/目的地是否該放行（人類同意是判斷點，機器只負責「攔下來問」）。

### R4 — 不擋自用、不製造過度摩擦
- 純自用、不送資料出去的動作（acr run 本機、查詢類）不該被警示淹沒。
- 警示要精準在「資料外流」動作，不是每個動作都問（否則用戶會盲目按 yes，警示失效）。

### R5 — 與既有閘門一致
- 與「建零件人類閘門」（component-gatekeeping）同精神：AI 不可替人類決定有外洩風險的動作。
- 與「arcrun 不做授權判斷」一致：不判斷「該不該送」，只「攔下來讓人類明示同意」。

## 非目標
- 用戶自己的 API 保護機制（入站認證：發 key 給別人 / 權限 / 限流）—— 另列 BACKLOG 待決策。
- 完整 DLP（資料外洩防護）系統 / 內容掃描判斷敏感度 —— 機器判不準，不做。
- recipe 公共貢獻路徑本身 —— 未實作（飛輪項），本系統只要求它未來內建同意閘門。