Leo
3e92d4acf6
新 SDD .agents/specs/data-exfil-warning/（richblack review 過）。
觸發策略：只在「資料變成可被外部呼叫」時警示（webhook 部署 / recipe push），
不管出站打別人 API（高頻低風險）。
- C 同意憑證（exposure-consent.ts）：ExposureConsent{confirmed_by_human, understood,
confirmed_at, suppress_future}；同意=法律憑證，存 record 可審
- A API 層：webhook 部署 + recipe push 首次需 consent，缺→403；首次問記住（server 端）
- B CLI（exposure-warning.ts）：仿 GCP 刪 project，要打資源名確認（比 y/n 硬）；
--confirm-exposure（非互動）/ --suppress-warning（不再警示，本選擇也 log）；
非 TTY 無旗標→拒絕（AI 不替人類確認暴露）；本機 config 記住已同意（不重問）
- H hook：pre-bash 偵測 acr push/recipe push 無旗標→exit 2（creds push/run 不誤擋）
- 警示是「保護措施入口」：提示 arcrun 可幫加認證/權限/限流（資安優勢）
驗收：非 TTY 拒絕未送出(exit1)、hook 精準擋放、tsc 雙邊綠。
⚠️ A+B 必須一起 deploy（API 層擋 + CLI 帶 consent），否則 push 中間狀態壞。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.9 KiB
3.9 KiB
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）：
- 不分公私庫都要警示。私人庫（公司用）一樣會出事（不小心把個資 POST 到公司群）。觸發點不是「推公共」， 是「這動作會讓資料流向某處」。
- 不禁止用戶公開 / 送資料（他要放什麼給誰是他的自由）——但要確定他自己明示同意了，不是 AI 替他決定。
- 兩道防線：(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 公共貢獻路徑本身 —— 未實作（飛輪項），本系統只要求它未來內建同意閘門。