預設 Redaction Rule

SDK 內建的 redaction rule 覆蓋最常見的敏感欄位模式。開發者不需要設定就能獲得基本保護。

欄位名稱比對

以下欄位名稱（不分大小寫）的值自動替換為 [REDACTED]：

• password、passwd、secret、token、api_key、apiKey
• authorization、auth、credential
• ssn、social_security
• credit_card、card_number、cvv、cvc

欄位名稱比對用 substring match — user_password 包含 password 會被 redact，password_reset_token 包含 password 和 token 也會。

值格式比對

以下格式的值無論欄位名稱為何都自動替換：

• Email 地址格式（user@domain.com → u***@domain.com）
• 信用卡號碼格式（連續 13-19 位數字 → 保留末四碼）
• Bearer token 格式（Bearer xxx → Bearer [REDACTED]）

值格式比對用正則表達式。正則的效能影響在大量事件時需要注意 — 預設 rule 的正則保持簡單，避免 catastrophic backtracking。

自訂 Pattern

應用可能有自己的 secret 格式，預設 rule 覆蓋不到。SDK 提供 API 讓開發者註冊自訂 redaction pattern。

 1monitor.addRedactionRule(
 2  name: 'internal-api-key',
 3  pattern: RegExp(r'sk_live_[a-zA-Z0-9]{24}'),
 4  replacement: '[REDACTED:api-key]',
 5)
 6
 7monitor.addRedactionRule(
 8  name: 'database-url',
 9  fieldNames: ['database_url', 'db_url', 'connection_string'],
10  replacement: '[REDACTED:db-url]',
11)

自訂 pattern 的設計考量：

Pattern 在 init 時註冊。Redaction rule 在 SDK 初始化時設定，之後所有事件都通過這些 rule。不支援動態修改 — 避免「中途加 rule 導致之前的事件沒被 redact」的困惑。

Pattern 順序無關。所有 rule 獨立執行，不依賴順序。一個欄位可以匹配多個 rule，以第一個匹配的 replacement 為準。

Replacement 可以保留部分資訊。[REDACTED] 完全遮蔽，[REDACTED:api-key] 保留類型資訊，u***@domain.com 保留結構。保留類型資訊對 debug 有幫助 — 看到 [REDACTED:api-key] 至少知道這裡原本有一個 API key。

Redaction 的適用範圍

Redaction 應用在 SDK 送出事件前的最後一步 — 在序列化（JSON encode）之前。適用範圍包括：

• Event 的 data 欄位（自由欄位，開發者可能放入任何內容）
• Error 的 stack trace（檔案路徑可能包含使用者名稱或部署路徑）
• Error 的 message（例外訊息可能包含 query string 或參數值）
• Lifecycle 的 metadata（連線 URL 可能包含認證資訊）

Redaction 不應用在 SDK 的內部欄位（timestamp、event type、session ID）— 這些是 SDK 自己產生的，不包含使用者資料。

下一步路由

• 資料離開 client 後的保護 → Transport 安全
• 去識別化策略 → 去識別化策略
• IME 個人化學習的 secret 洩漏風險 → ux-design 模組三 IME 安全 checklist

IP 截斷

IP 位址是最常見的個人識別欄位。完整的 IPv4 位址（192.168.1.50）可以定位到特定的網路和裝置；截斷後的 IP（192.168.1.0）保留網段資訊但無法定位到特定裝置。

截斷策略

IPv4 末八位清零：192.168.1.50 → 192.168.1.0。保留 /24 網段資訊，足以判斷「使用者在哪個網段」但無法定位到特定裝置。Google Analytics 採用這個策略。

IPv4 末十六位清零：192.168.1.50 → 192.168.0.0。更強的去識別化，但地理定位精度降低到城市級。

IPv6：截斷更多位元。IPv6 的後 80 位通常包含 MAC 位址衍生的 interface ID — 截斷到 /48 前綴保留 ISP 資訊，移除裝置識別。

實作位置

IP 截斷應在 collector 收到事件後、寫入儲存前執行。SDK 端不做 IP 截斷 — SDK 通常不知道自己的外部 IP（知道的是 NAT 後的內部 IP），外部 IP 是 collector 從 HTTP request 的 source IP 取得的。

User Agent 簡化

User agent 字串包含瀏覽器版本、OS 版本、裝置型號 — 組合起來可能形成唯一的 fingerprint。簡化 user agent 保留有用的分類資訊（「iOS 17 上的 Safari」），移除可用於 fingerprinting 的細節（「iPhone 15 Pro Max, Build/22A3354」）。

簡化規則

保留：平台（iOS / Android / Windows / macOS）、主要版本號（iOS 17、Android 14）、瀏覽器類型（Safari / Chrome / Firefox）。

移除：minor version、build number、裝置型號、CPU 架構、語言設定。

1原始：Mozilla/5.0 (iPhone; CPU iPhone OS 17_4_1 like Mac OS X)
2簡化：iOS/17 Safari

Stack Trace 路徑清理

Error 事件的 stack trace 包含檔案路徑。檔案路徑可能洩漏部署結構（/home/deploy_user/app/v2.3.1/src/...）或開發者的個人資訊（/Users/alice/projects/...）。

清理規則

移除使用者目錄前綴：/Users/alice/projects/app/src/main.dart:42 → src/main.dart:42。保留 source file 相對路徑和行號，移除使用者名稱。

移除部署路徑前綴：/opt/deploy/releases/20260619/app/lib/... → lib/...。保留程式碼結構，移除部署細節。

統一 path separator：Windows 路徑（C:\Users\...）和 Unix 路徑（/home/...）統一處理。

清理規則用正則表達式匹配常見的路徑前綴模式，替換為空字串。自訂的部署路徑格式需要在 collector 設定中額外註冊。

Session UUID

Session ID 用於關聯同一次使用中的多個事件。UUID v4（隨機產生）作為 session ID，沒有可預測性、沒有順序性、無法回推使用者身份。

Session ID 的生命週期

SDK 在初始化時產生一個 UUID v4 作為 session ID，所有事件附帶這個 ID。App 重新啟動時產生新的 session ID — 前後兩次使用的事件無法關聯。

這個設計讓分析粒度限制在「一次使用」而非「一個使用者」。如果需要跨 session 關聯（例如計算 DAU），需要另一個 persistent ID — 但 persistent ID 本身就是可識別資訊，需要使用者同意。

避免使用可識別的 ID

裝置 ID（IDFA / GAID）、安裝 ID、使用者帳號 — 這些可以關聯到特定個人，不適合作為監控系統的 session ID。使用 UUID v4 確保 session ID 的唯一性來自隨機性而非身份。

去識別化是資料保護的一環，另一環是在資料離開 client 之前就處理 — SDK Redaction API 設計從 SDK 端攔截敏感欄位。法規層面的具體要求見 GDPR 最小化原則的工程落地。去識別化完成後的資料才能用於行為分析 — 這是商業利用的入場條件。

資料最小化：只收集需要的欄位

資料最小化的工程落地是「每個收集的欄位都要能回答：這個欄位用來做什麼決策？」。如果一個欄位只是「可能有用」但沒有明確的消費場景，就不應該收集。

正面表列 vs 負面排除

正面表列（allowlist）是列出「收集哪些欄位」— 只收集清單上的欄位，其他全部不收。

負面排除（denylist）是列出「不收集哪些欄位」— 預設收集所有欄位，排除清單上的。

GDPR 的精神更接近正面表列 — 每個收集行為需要有正當理由（lawful basis）。工程上的實作方式是：事件 schema 定義哪些欄位是允許的，不在 schema 中的欄位在 collector 端丟棄。

SDK 端的最小化

SDK 端的最小化更主動 — 在事件產生時就只包含必要的欄位，而非送到 collector 再過濾。

設計 SDK 的 event API 時，不提供「送任意 key-value」的 free-form API，而是提供結構化的 API：

1// free-form（難以控制收集了什麼）
2monitor.event('login', data: {'email': email, 'ip': ip, 'device': device, ...})
3
4// 結構化（schema 控制收集範圍）
5monitor.event('login', loginMethod: 'biometric', success: true)

結構化 API 的參數在 SDK 設計時就決定了收集範圍，code review 時可以檢查「為什麼這個 event 需要這個參數」。

目的限制：收集的資料只用於聲明的目的

目的限制要求資料只用於收集時聲明的目的。監控系統收集事件的目的通常是 debug 和效能監控 — 如果之後要用同一份資料做行為分析或廣告投放，需要額外的法律基礎（通常是使用者同意）。

工程落地

目的限制在工程上的實作是「不同目的的資料分開儲存、分開授權」。

Debug 用的 error 事件和行為分析用的 event 事件存在不同的儲存位置（不同的 JSONL 檔案或不同的資料庫 table）。Debug 用途的 access 不需要使用者同意（legitimate interest）；行為分析用途的 access 需要使用者同意。

分開儲存讓「使用者撤回行為分析同意」的工程操作變簡單 — 刪除行為分析的儲存，不影響 debug 儲存。

儲存限制：不保留超過必要期間的資料

儲存限制要求資料只保留達成目的所需的最短期間。監控資料的合理保留期間依用途不同：

自動清理

Collector 的儲存清理應該自動化 — 手動清理依賴人記得執行，最終會被遺忘。

JSONL 儲存用「一天一檔」的命名（events-2026-06-19.jsonl），清理腳本每天刪除超過保留期限的檔案。Cron job 或 systemd timer 定期執行。

下一步路由

• 去識別化技術 → 去識別化策略
• 監控資料洩漏的威脅分析 → 監控資料洩漏的 threat model
• Collector 的儲存設計 → 模組四 Collector 設計

預設 redaction rule

SDK 內建一組預設 rule，處理常見的敏感資訊 pattern：

密碼欄位

匹配 data 物件中 key 包含 password、passwd、secret、token、api_key、apiKey、authorization 的欄位。匹配方式是 key 名稱的子字串比對（case-insensitive）。

URL 中的認證資訊

匹配 https://user:password@host 格式的 URL，把 user:password 部分替換為 [REDACTED]。

Stack trace 中的檔案路徑

匹配 stack trace 字串中的使用者目錄路徑（/Users/username/、/home/username/、C:\Users\username\），替換為 [USER_HOME]/。避免使用者名稱從 stack trace 洩漏。

自訂 redaction rule

業務特定的敏感資訊（信用卡號、身分證字號、醫療資料）不在預設 rule 的範圍內。SDK 提供 API 讓開發者在 init 時註冊自訂 rule。

1Monitor.init({
2  redactionRules: [
3    { pattern: /\b\d{4}[-\s]?\d{4}[-\s]?\d{4}[-\s]?\d{4}\b/, replace: '[CARD]' },
4    { keyPattern: /^ssn$/i, replace: '[REDACTED]' },
5  ],
6})

自訂 rule 和預設 rule 一起執行。如果同一個值被多個 rule 匹配，第一個匹配的 rule 生效（rule 的執行順序：預設 rule 先，自訂 rule 後）。

Redaction 的執行時機

Redaction 在事件進入 flush payload 的那一刻執行 — buffer 中的事件保持原始內容，flush 時複製一份並在複製上執行 redaction。

在 buffer 中保持原始內容的理由是 debug：開發者在本地 console 看到的 log 應該包含完整資訊（開發環境不需要脫敏），只有離開 SDK 時才脫敏。SDK 可以提供 debugMode flag — debugMode 開啟時 console log 印出原始內容，HTTP POST 仍送出脫敏後的內容。

Redaction 和模組七的關係

SDK redaction helper 是模組七 資安與隱私中 redaction 策略的實作層。模組七定義「什麼資訊需要被保護」（策略），本章定義「SDK 如何在程式碼中實現這個保護」（實作）。

兩者的分工：

Collector 端可以做第二道檢查（re-scan 收到的事件是否仍包含敏感 pattern），作為 SDK 端 redaction 的備援。但主要的脫敏責任在 SDK 端 — 資料離開 SDK 後經過網路，已經暴露在傳輸風險中。

下一步路由

• SDK 公開 API → SDK 公開 API 設計
• 資安與隱私的完整策略 → 模組七 資安與隱私
• 自動攔截的 error 也需要 redaction → 自動攔截機制

讀完本章後、你應該能對自己的 IDE 工作流回答：每個 LLM provider 收到什麼 prompt、雲端服務的資料政策大致長怎樣、哪些任務該分到本地、哪些可以送雲端、配置誤送的常見路徑跟對應防護。

本章目標

1. 認識「prompt 邊界」在多 provider 工作流的位置。
2. 區分本地 LLM 跟雲端 LLM 在資料流上的差異。
3. 認識主流雲端 LLM 服務的資料政策大致分類。
4. 用「敏感度 × 任務類型」軸把工作流分流到本地或雲端。
5. 認識多 provider 設定下、prompt 誤送的常見路徑跟對應防護。

prompt 邊界在哪

在多 provider 工作流下、prompt 邊界長這樣：

 1                ┌───────────────────────────┐
 2                │  使用者 + 本機 codebase   │ ← trust zone A：完全本地
 3                └───────────────────────────┘
 4                            ↓ prompt
 5        ┌─────────────────────────────────────────┐
 6        │  IDE LLM client（Continue.dev）         │
 7        │   ↓ route by config                     │
 8        │   ├── 本地 model（Ollama / llama-server）│ ← trust zone B：仍在本機
 9        │   ├── 商業雲端（Anthropic / OpenAI）     │ ← trust zone C：雲端 vendor
10        │   └── 第三方 LLM 聚合（OpenRouter etc.） │ ← trust zone D：聚合層 + 上游 vendor
11        └─────────────────────────────────────────┘

每跨一條邊界、prompt 都會被另一個主體看到。trust zone B 是本機 process（包括其他可能 dump 流量的工具）、C 是商業 LLM vendor、D 是聚合層加上游 vendor、複雜度跟洩漏面隨層數增加。

本地 LLM vs 雲端 LLM 在資料流上的差異

混用的好處：

1. 敏感任務留本地：機密 codebase、PII、合約等不送雲端。
2. 能力受限任務送雲端：跨檔案重構、複雜推理用旗艦雲端模型。
3. 離線可用：本地當 fallback、雲端不可用時仍能基本運作。

混用的風險：配置稍微錯一步、原本想留本地的 prompt 被誤送到雲端。

主流雲端 LLM 服務的資料政策（大致分類）

各家雲端 LLM 服務的資料政策依方案跟版本變化、大致可以分成幾類：

事實查核註：上面是 2026 年 5 月主流商業 LLM 服務的常見政策分類、具體條款依 vendor、地區、方案、版本快速變化、且各家詞彙不一致（如「training」「improve our services」「abuse review」可能指不同範圍）。引用前以對應 vendor 的當前官方資料政策頁面、OpenAI Data Policy 等為準。

判讀重點不是「哪家最嚴」、是「我送進去的內容、貼合我的預期嗎」。

按敏感度 × 任務類型分流

把工作流分流到本地或雲端的兩軸：

1敏感度軸：
2  公開 / 一般 / 機密 / 高機密（PII、合約、未公開 codebase）
3
4任務類型軸：
5  補完 / 解釋 / 重構 / 設計討論 / 端到端 agent

對應的分流建議：

實務上的常見模式：

1. 預設本地、特定任務開雲端：日常工作走本地、需要旗艦能力時手動切。
2. 預設雲端、敏感任務切本地：日常走雲端旗艦、開機密 repo 時切本地。
3. 依 repo 切：用 Continue.dev / IDE 工具的「per-workspace config」、每個 repo 自己決定。

選哪種模式取決於工作流的敏感度分布。多數寫 code 個人 dev 屬於「一般 / 機密混合」、值得用模式 1 或模式 3。「哪個任務適合本地、哪個適合雲端」的任務面判讀見 1.5 期望管理、本章補上「分流之後的資料邊界」面。

Continue.dev 多 provider 配置範例

Continue.dev 基礎安裝跟單一 provider config 見 1.3 VS Code + Continue.dev 整合、本節聚焦多 provider 共存下的安全性設計。下面是一個合理的 Continue.dev 配置範例、把本地 + 雲端混用、清楚標出每個 model 的走向：

 1{
 2  "models": [
 3    {
 4      "title": "Local 30B MoE (default)",
 5      "provider": "ollama",
 6      "model": "qwen3-30b-a3b",
 7      "apiBase": "http://localhost:11434"
 8    },
 9    {
10      "title": "Local 14B (fast)",
11      "provider": "ollama",
12      "model": "qwen3-14b",
13      "apiBase": "http://localhost:11434"
14    },
15    {
16      "title": "Cloud Claude (premium only)",
17      "provider": "anthropic",
18      "model": "claude-sonnet-4-6",
19      "apiKey": "${env:ANTHROPIC_API_KEY}"
20    }
21  ],
22  "tabAutocompleteModel": {
23    "title": "Local autocomplete",
24    "provider": "ollama",
25    "model": "qwen3-14b"
26  }
27}

關鍵設計：

1. 預設模型是本地：list 第一個是 local、tabAutocomplete 也是 local。
2. 雲端模型 title 明確標記：「Cloud Claude」開頭、避免選錯。
3. autocomplete 永遠本地：補完的 prompt 流量大、autocomplete 屬於高頻、留本地。
4. API key 從環境變數：不寫死在 config 裡、避免 commit 進 git。

事實查核註：Continue.dev 的 config 格式跟 provider 支援度依版本變化、本範例為示意、實際引用以當前 Continue.dev 官方文件為準。

prompt 誤送的常見路徑

個人 dev 場景下常見的 prompt 誤送路徑：

1. 預設 model 設成雲端、按了 hotkey 沒看到當前 model：把寫到一半的機密 prompt 送到雲端。對應防護：預設改本地、雲端 model 用名稱前綴明確。
2. autocomplete 設成雲端：補完每幾秒就觸發、prompt 包含當前游標附近 code、流量大且持續。對應防護：autocomplete 必定本地。
3. codebase RAG 索引到 .env / secrets：RAG 把 secret 加進 prompt、再送雲端。對應防護：IDE search exclude 加上 .env、*.key、secrets/、.aws/。RAG 把外部內容引入 prompt 的整體機制與失敗模式見 4.1 RAG 原理。
4. 多 client 同時跑、key 共用：Cursor / Continue.dev / Claude Code 等多 client 共用 API key、難追是哪個 client 的流量。對應防護：給每個 client 各自的 API key、有問題能追溯。
5. 聚合服務不知道實際送到哪：用 OpenRouter / together.ai 等聚合層、prompt 經過聚合層後送到上游 vendor、上游可能是不同 region 不同政策。對應防護：個人 dev 場景傾向不用聚合、直接接 vendor。
6. forgot prompt history 含 sensitive content：某次貼了機密內容後、後續同 conversation 都帶著、不知不覺重複送。對應防護：機密 prompt 用獨立 conversation、用完清空。

個人 dev 場景的最低防護建議

1. 預設模型設成本地：避免誤觸發雲端。
2. autocomplete 必定本地：流量大、持續、適合本機處理。
3. API key 從環境變數讀、不寫死 config：dotfile commit 不會洩漏。
4. codebase search exclude .env / secrets 路徑：避免 RAG 索引到 secret。
5. 看完 prompt 內容再送雲端：對重要任務、value 不大但風險高時 prefer 本地。
6. 不同 client 用不同 API key：流量追溯。
7. 機密 prompt 用獨立 conversation：用完清空、不污染後續。

雲端 vendor 的 enterprise plan 選擇

當個人 dev 工作流穩定後、若要把雲端 LLM 用得更深、可以評估 enterprise plan：

選擇判讀：個人 dev 主要看「API key 預設政策」、若不夠用、再評估升級。

給讀者的跨邊界判讀流程

每次設新工作流 / 換 LLM client / 加新 model 時的判讀流程：

1. 盤點 model 列表：每個 model 是本地還是雲端、走哪家 vendor。
2. 看 vendor 的當前政策：別憑印象、看當前官方文件。
3. 設定 default model + autocomplete model：default 跟 autocomplete 是高頻路徑、優先本地。
4. 加 codebase RAG exclude：把 secret / sensitive path 排除。
5. 跑簡單測試：開個假機密 prompt（如「我的 SSH key 是 fake-key-test」）、觀察 client log 跟 vendor dashboard、確認流量去向符合預期。

下一章

靜態網站 / 沒 backend 場景的 prompt 邊界（API key 暴露、CORS、SaaS 信任、client-side abuse）見 4.16 靜態 / serverless RAG deployment 的資安段。

下一章：6.5 跨進 production 的 routing 中樞、整合本模組到 backend/07 production 場景的路由。

待寫章節

• SDK redaction API 設計（預設 redaction rule + 自訂 pattern）
• Transport 安全（HTTPS / basic auth / 同區網也要加密的理由）
• Collector access control 實作（認證 / 授權 / access log）
• 去識別化策略（IP 截斷 / user agent 簡化 / stack trace 路徑清理 / session UUID）
• GDPR 最小化原則的工程落地
• 「監控資料洩漏」的 threat model
• Client-side SDK 認證的根本限制（credential 必然暴露、多層緩解策略）

跨分類引用

• → backend 07 資安：server-side 的 secret management 跟本模組的 redaction 互補
• ← ux-design 模組三 輸入機制：IME 個人化學習 = secret 洩漏
• ← testing 模組二 客戶端可觀測性：log 內容可能含 secret，需要 redaction
• → monitoring 模組八：去識別化是商業利用的入場條件
• 待建連結 → compliance/（隱私法規教學分類）

本章寫的是「無論工具怎麼演變、隱私設計都該這樣思考」的原理層。具體合規法規條文（GDPR、HIPAA、各地新法）、特定工具的 telemetry 設定（每家半年一變）不在本章——這些隨時間變、用本章建立的 framework 重新評估就好。本章是 framing；落地操作見 模組六 本地 LLM 的安全與權限、把這些框架拆到推論伺服器綁定、tool use 權限、prompt injection、跨雲端邊界等具體決策。

本章目標

讀完本章後、你應該能：

1. 用資料流圖描述自己的 LLM 工作流、辨識每個 hop 的信任邊界。
2. 區分「物理保證」與「合約保證」兩種隱私模型的取捨。
3. 把零信任原則套用到 LLM 系統設計。
4. 對 NDA / 企業合規場景做出有條理的判讀、不只看「是否本地」。

從「位置 Thinking」到「資料流 Thinking」

「跑在本地、所以隱私」這個直覺假設「位置」是隱私的唯一變數。實際上隱私風險來自整條資料流的每個節點、位置只是其中一個維度。

把問題從「我的 prompt 是否離開機器」改成「我的 prompt 從打字到最終結果、經過哪些 process、儲存在哪、誰能看到」。後者覆蓋面廣得多：

• prompt 在 IDE 內被 cache？
• IDE 有沒有開雲端同步？
• 推論伺服器 log 留多久？
• 對話歷史存到哪？
• 第三方 plugin 有沒有偷 access prompt？
• 結果寫到磁碟後、有沒有被自動備份到 iCloud / Dropbox？

「位置 thinking」對所有這些都看不到——只要推論在本地就覺得安全。「資料流 thinking」把整條 hop 攤開、每個節點單獨評估。

這個 shift 是隱私設計的根本前提。沒做這個 shift、其他設計都建立在錯誤假設上。

信任邊界的定義

LLM 工作流通常跨多層信任邊界（IDE / 推論伺服器 / 雲端同步 / 第三方 plugin / LAN）、隱私設計的第一步是把這些邊界明確畫出來。信任邊界（trust boundary）的概念來自系統安全設計：「誰能看到什麼資料」的明確分隔。穿越邊界的資料需要明確的授權跟稽核；同邊界內的資料假設安全。

本地推論的天然信任邊界是「我的 Mac」——資料在這個邊界內預設安全（除非機器本身被入侵）。但實際 LLM 工作流會穿透這個邊界：

• 雲端同步穿透：VS Code 同步 settings、Notion 備份對話、iCloud 同步文件——資料從 Mac 走到雲、信任邊界被擴展到供應商。
• Telemetry 穿透：IDE plugin、推論伺服器、作業系統都可能送遙測資料、含 prompt 片段 / metadata。
• 第三方 plugin 穿透：裝的 VS Code extension、瀏覽器 plugin 都可能 access 同個 prompt context。
• 網路 expose 穿透：OLLAMA_HOST=0.0.0.0 把本地伺服器暴露到 LAN、信任邊界從「我的 Mac」擴展到「整個區網」。

LLM 工作流通常有多層信任邊界、跟「我在本地跑」的單純直覺不一定一致。設計隱私時、先把所有信任邊界畫出來、再評估每個邊界的「誰能看到、能看到什麼」。

信任邊界的判讀問題：

• 這個 process 屬於哪個邊界內？
• 跨邊界傳資料需要什麼授權？
• 邊界外的 component 如果被入侵、能 access 到什麼？

這幾個問題答得清楚、隱私設計就有 ground truth；答得模糊、設計就建立在假設上。

本地 vs 雲端的合約模型

本地推論跟雲端推論的隱私保證來自不同模型：

物理保證（本地）

本地推論的隱私保證是「物理上資料留在這台機器」、可技術觀察：

• 用 lsof（list open files、看 process 持有的網路 socket）看推論伺服器的網路連線、確認沒對外送資料。
• 用 tcpdump（系統封包擷取工具）監聽流量、確認 prompt 沒外洩。
• 看磁碟 IO、確認對話歷史沒被寫到雲端同步資料夾。

這些工具的能力邊界：lsof / tcpdump 給的是「常態流量觀察」、不是完整安全證明。編譯期注入、kernel-level exfiltration、DNS tunneling 等繞過手法仍可能規避這些觀察視角。國家級威脅模型或高 stakes 合規場景下、要再加程式碼簽章驗證、SELinux / EndpointSecurity policy、出口防火牆等更深的控制；個人 / 中小企業場景下、這三個工具的觀察通常足以建立日常的信心。

物理保證的特性：

• 可單機驗證：不需要信任供應商、能用本地工具觀察流量。
• 能力上限受硬體限制：本地模型受 Mac 算力跟記憶體限制、能力比雲端旗艦低一個量級。
• 不依賴合約承諾：供應商有沒有承諾「不訓練」「zero-retention」都跟本地推論無關——資料本來就沒去那裡。

合約保證（雲端）

雲端推論的隱私保證是「供應商承諾不留資料、不訓練、合規 X 規範」、技術上單機不可驗證、靠合約與 audit 支撐：

• Anthropic、OpenAI 的企業方案明示 zero-retention、不訓練選項（2026 年 5 月當時的 ToS、雲端 ToS 半年一變、實際採用前以最新版為準）。
• SOC 2、ISO 27001、HIPAA BAA 等合規認證提供第三方 audit。
• 供應商的 ToS / privacy policy 是法律承諾、違反可訴訟。

合約保證的特性：

• 不可單機驗證：要信任供應商沒違反承諾、加上第三方 audit 補強。
• 能力沒上限：能用上雲端最強模型（GPT-5、Claude Sonnet 4.6、Opus）、沒有硬體限制。
• 受法律管轄影響：供應商所在管轄區的法律、未來變動會影響保證強度（如政府要求供應商交資料）。

兩種模型的取捨

兩種模型不是「誰比較好」、是「在什麼情境下哪個適合」：

• 隱私要求極高 + 模型能力夠用：本地。物理保證可驗證、不需信任供應商。
• 能力要求極高 + 隱私要求中等：雲端 + 合約保證。Claude / GPT 旗艦的能力本地短期內追不上。
• 合規場景：看具體規範要求。HIPAA、PCI-DSS 等場景雲端 + BAA / DPA 合約 + technical control 是主流方案、不一定要本地。
• NDA + 客戶明示不得送雲：本地是預設、合約保證對「不得送雲」這條沒幫助。

判讀「該選哪邊」不是 binary、是 spectrum：許多場景混用、敏感任務本地、需要能力的任務雲端 + 合約保證。混用模式有一個隱形 leak 風險：同一個 IDE 同時接本地與雲端 backend、prompt routing 設錯就會把該走本地的內容送到雲端。實作時要明確隔離（不同 workspace / 不同帳號 / 不同 plugin set）、用配置強制路由、而非依賴每次手動切換。Continue.dev 多 provider 設定的具體路由判讀見 6.4 跨雲端 / 本地的資料邊界。

零信任原則套用到 LLM 工作流

零信任（zero trust）的核心是「不假設任何 component 是 trusted、每個 hop 都重新驗證」。傳統信任模型假設「邊界內安全」、零信任假設「邊界本身可能被穿透」、每次 access 都驗證。

套用到 LLM 工作流的具體實踐：

不信任預設配置

每個 component 的預設配置往往不是「最隱私」、是「最方便」。OLLAMA_HOST 預設 127.0.0.1 還算安全、但很多工具預設打開 telemetry、預設同步到雲端。在 NDA / 合規場景下、所有 component 的隱私相關設定通常需要逐項 review、預設值會根據場景調整。

每個 hop 都評估

不只是「我用 Ollama 所以隱私」、要評估從打字到結果的每個 hop：IDE telemetry、plugin 行為、推論伺服器 log、對話歷史儲存、檔案系統位置、雲端同步範圍。任何一個 hop 預設設定「外洩」、整條鏈的隱私就破。

最小權限

每個 component 只給它必要的 access：

• 推論伺服器：不需要存 prompt 歷史就關 log。
• IDE plugin：不裝沒驗證的 third-party plugin。
• 雲端同步：個人場景白名單同步是低成本 default、NDA / 合規場景直接排除整個 LLM 相關目錄。

「最小權限」需要主動設計、不會自動發生——預設都是「方便優先」。

認假設、不認直覺

「跑在本地所以安全」是直覺、不是已驗證的事實。零信任要求每個假設都跑一次 audit 確認、用觀察取代感覺。

資料流分析的具體做法

把抽象原則落地、要做資料流分析：把整個工作流畫成 graph、每個 node 是 process、每個 edge 是資料流動、標示資料類型跟流向。

具體步驟：

1. 列出所有節點：使用者、IDE、IDE plugin、推論伺服器、模型、磁碟、雲端服務、第三方 service。
2. 畫出所有 edge：誰送資料給誰、什麼類型的資料、什麼觸發。
3. 標示信任邊界：哪些節點屬同一個邊界、邊界之間的 edge 標出來。
4. 每個跨邊界 edge 評估三個問題：
   • 誰能看到流過這條 edge 的資料？
   • 儲存多久？
   • 會不會再轉送出去？
5. 找出風險集中點：常見集中點是 IDE telemetry、雲端同步、第三方 plugin。

這個分析做完、隱私風險不再是抽象的「會不會洩漏」、是具體的「哪個 edge 在洩漏什麼」。修補策略也跟著具體：關 telemetry、移除特定 plugin、改設定。

實務做這個分析、第一次通常會發現預期外的 edge——例如「我以為對話歷史只在本地、結果發現 IDE 的 sync settings 把它送到雲」、「我以為這個 plugin 只 access code、結果它也送 prompt 給自家 analytics」。

NDA / 企業合規場景的判讀框架

NDA 跟企業合規場景的隱私要求比個人使用嚴格、判讀方式：

NDA 場景

• 核心要求：客戶明示「不得送第三方 AI 服務」、本地是預設選擇。
• 不夠的地方：本地推論只保證模型呼叫不出去、要 audit 整條資料流（IDE telemetry、雲端同步、plugin 行為）。
• 常見的事故：以為 Ollama 跑就安全、但 Cursor / Copilot 同時開著還送 prompt 給自家 service、NDA 已穿透。
• 強化做法：NDA 客戶程式碼專案開獨立 IDE workspace、停雲端同步、移除第三方 plugin、明確隔離。

企業合規場景

不同規範保護的核心點不同、每條規範需對應到該規範要求的 control、避免用單一 mitigation 一網打盡的做法：

判讀流程：列合規要求 → 對應資料流節點 → 找出缺哪個保護 → 補上技術或合約控制。本地推論滿足「資料留在內部」這條、但通常仍需要 audit log、access control、retention policy 等補強；雲端 + BAA / DPA + zero-retention 是另一條合規路徑、看規範允許哪條再做選擇。

個人 + 一般工作場景

• 多數場景隱私風險中等、合理控制就夠。
• 預設關掉明顯外洩管道（telemetry、雲端同步敏感內容）、敏感任務本地、其他雲端、就 cover 90% 場景。
• 過度設計反而生產力大幅下降、得不償失。

判讀框架的核心不是「該不該做隱私」、是「該做到什麼程度」。NDA / 合規場景要做到嚴、個人場景做到合理、過度都是浪費。

常見的隱私邊界穿透

下列五個穿透模式都符合「位置看似安全、資料流卻外洩」的 pattern、即使用本地推論仍會破隱私：

IDE 雲端同步

VS Code、JetBrains 系列預設可能開 settings sync、把對話歷史、recent files、command history 同步到雲。對話歷史尤其敏感——可能含 prompt 跟 LLM 回應全文。

判讀訊號：登入帳號後、跨機器 settings 自動同步——這條 pipe 通常也帶其他資料。

緩解：明確查看 sync 範圍、敏感場景關閉 sync 或開選擇性 sync（只同步配置、不同步歷史）。

第三方 plugin 偷送 prompt

裝 VS Code extension 時、權限模型較寬：理論上 plugin 能 access 整個 workspace、含 prompt 跟 LLM 回應。多數 plugin 安全、但供應鏈攻擊或惡意 plugin 存在。

判讀訊號：plugin 不是 verified publisher、下載量少、permission 列表廣。

緩解：敏感場景只用 verified plugin、定期 audit 已裝 plugin、移除不必要的。完整 tool use / MCP server 信任邊界見 6.2 tool use 與 MCP server 的權限模型、IDE 場景的 prompt injection 攻擊面（codebase / 外部文件 / 剪貼簿）見 6.3。

Open WebUI 對話歷史備份

Open WebUI（常見的本地 Web 對話介面、通常以 Docker 部署）把對話歷史存本機 SQLite、預設安全。但很多人把 ~/.openwebui 放在 Dropbox / iCloud 同步目錄、歷史間接同步到雲。

判讀訊號：home directory 整個被雲端服務同步。

緩解：明確排除 LLM 相關目錄、或把 LLM 資料移到不被同步的位置。

OLLAMA_HOST=0.0.0.0 暴露區網

把 Ollama 從 127.0.0.1 改成 0.0.0.0 是常見配置（讓區網其他機器接）、但等於把本地 LLM 暴露在 LAN 上。風險視 LAN trust level 而定：純自家信任裝置的家用網路風險低、有 IoT / 訪客機 / 公共 Wi-Fi 的 LAN 環境風險顯著上升（IoT 裝置常被植入、預設要放在 untrusted segment、用 VLAN 或 firewall 隔離後再評估能否互通）。

判讀訊號：能從另一台機器 curl <你的 Mac IP>:11434 成功。

緩解：純自家信任裝置的 LAN 接受、混合 trust LAN 用防火牆規則限定 source IP、公共 Wi-Fi 改回 127.0.0.1 或用 SSH tunnel 隧道到遠端機器。完整綁定模式（loopback / LAN / reverse proxy + auth）跟誤開放後的後果見 6.1 推論伺服器的綁定與暴露範圍。

IDE Plugin 同時送雲

Cursor 預設 telemetry 強、Copilot 本來就送 prompt 給 GitHub。即使在這些 IDE 內用 Continue.dev 接本地 Ollama、IDE 本身可能仍送 prompt 給自家 service。

判讀訊號：IDE 是「雲端 AI 為主」的工具、本地 LLM 接入只是附加功能。

緩解：敏感場景用「本地 AI 為主」的 IDE（如 VS Code + Continue.dev）、不用混合的雲端 IDE。跨 provider 切換的具體 routing 設計見 6.4 跨雲端 / 本地的資料邊界。

何時過時 / 何時不過時

不會過時的部分：

• 「資料流 thinking」對「位置 thinking」的優越性。
• 信任邊界的定義跟畫法。
• 物理保證 vs 合約保證的雙模型 framing。
• 零信任原則的四個套用實踐。
• 資料流分析的 5 步驟方法。
• NDA / 合規 / 個人三類場景的判讀框架。

會變的部分：

• 具體合規法規（GDPR、HIPAA、CCPA、各國新法會持續更新）。
• 特定工具的隱私行為（IDE / 雲端服務的 ToS、telemetry policy 會調整）。
• 雲端供應商的合約細節（BAA / DPA / SCC 條款會 evolve）。
• 「常見穿透模式」的具體例子（會隨工具生態變）。

新工具、新法規、新雲端服務出來時、回到本章的方法重新跑一遍資料流分析、信任邊界評估——framework 不變、實例更新。

下一步

下一步：模組一：本地 LLM 服務的安裝與應用（Apple Silicon Mac）或 模組五：Windows / Linux + 獨立 GPU 把心智模型落到實際操作。模組一 / 五跑穩之後、回到 模組六：本地 LLM 的安全與權限 把本章建立的「資料流 thinking」「信任邊界」「物理 vs 合約保證」三組框架落到具體決策（伺服器綁定、tool use 權限、prompt injection、跨雲端 routing）。

本章寫作邊界

本章聚焦 production LLM 服務的 log / cache / context 中的 PII 治理特殊性。個人 dev 場景的隱私資料流見 0.7 隱私資料流；通用資料保護見 7.4；資料居住地與刪除證據鏈見 7.8。

本章 threat scope

In-scope：prompt log 累積的 PII、response log 中模型 hallucinate 出的 PII、context cache 跟 KV cache 中的殘留、跨地區資料居住地對應、log 保留期限與刪除證據。

Out-of-scope（路由到他章）:

• 通用資料保護與 masking → 7.4 data-protection-and-masking-governance
• 資料居住地與刪除證據鏈 → 7.8 data-residency-deletion-and-evidence-chain
• 通用 audit log → 通用 audit-log knowledge-card
• multi-tenant log 隔離 → llm-multi-tenant-isolation
• 偵測訊號 → llm-as-service-detection-coverage

從本章到實作

• Mechanism：問題節點表 → knowledge-card。
• Delivery：交接路由 → 05-deployment-platform / 08-incident-response。

LLM 服務的 log 載體

LLM 服務累積的 log / cache 比一般 service 多幾類載體：

跟一般 service 的差異點：Prompt log / Response log 是新類別、它們含的不是 API meta-data、是使用者實際的「想法 / 內容」、隱私敏感度遠高於一般 API log。

分析模型

LLM log 治理依四個階段分析：

1. 累積階段：哪些載體會累積什麼內容、累積速率多大。
2. 儲存階段：儲存位置（DB / S3 / SIEM）、加密、訪問權。
3. 保留階段：保留期限、保留期內的訪問規則。
4. 刪除階段：刪除觸發條件、刪除證據鏈、合規對應。

判讀流程

判讀流程的責任是把「LLM 服務的 log」轉成「合規可審計的 log」。

1. 先盤點所有 log / cache 載體跟對應內容。
2. 再確認 PII 偵測 / masking 在累積階段是否生效。
3. 接著確認儲存跟訪問權跟一般資料保護一致。
4. 最後確認保留期限跟刪除證據鏈跟資料居住地對齊。

問題節點（案例觸發式）

常見風險邊界

風險邊界的責任是界定何時 LLM log 治理已進入高壓狀態。

• Prompt log 含未 mask 的 PII 時、代表 PII 治理在累積階段失效。
• KV cache / context cache 跨 tenant 共用時、代表 isolation 失效（亦見 llm-multi-tenant-isolation）。
• log 保留期限跟資料居住地政策不一致時、代表治理流程不收斂。
• 客戶刪除請求無法產生證據鏈時、代表合規對應失效。

LLM 場景的特殊判讀

LLM log 治理相對一般資料保護的特殊性：

1. Prompt 跟 Response 比 API log 隱私敏感度高一個量級：一般 API log 主要記 endpoint / status / latency、prompt log 記的是使用者實際「在問什麼」、Response log 是模型「在說什麼」。
2. 模型 hallucinate 的 PII 也是 PII：LLM 生成虛構的姓名 / 電話 / 地址、即使不對應真人、也屬於 PII 處理範圍、需要對應的 masking 跟保留政策。
3. KV cache 是非典型 log 載體：傳統 log 治理工具不掃 GPU memory / RAM cache、但這些 cache 可能跨 request / 跨 tenant 殘留 PII；需要 inference engine 配合做 cache 清理。
4. RAG context 是雙向載體：RAG 既把 corpus 注入 prompt（corpus 中的 PII 進 log）、也把 user query 注入 corpus（user query 變 future retrieval 的對象）；治理範圍要覆蓋雙向。
5. vendor 政策直接影響合規承諾：用雲端 LLM 時、vendor 的 log 保留政策（如 30 天 abuse log）直接限制自家對下游客戶能承諾的最短保留期、合約鏈要對齊。
6. abuse detection 跟 PII 治理的張力：abuse detection 需要 log prompt（看 abuse pattern）、PII 治理要求 minimize、兩者要在 mask 後 detection 跟全文 detection 中找平衡。

防禦設計的核心原則

1. 累積階段做 PII detection + masking：log 寫入前過 PII detector、敏感欄位 mask 或不 log。
2. 儲存階段加密 + 訪問權對齊 IAM：跟一般敏感資料一致。
3. 保留期限明確 + 自動刪除：用 policy-driven 自動 lifecycle、不依賴人工。
4. KV cache / context cache 跨 tenant 清理：inference engine 配合、tenant boundary 明確。
5. 刪除證據鏈：客戶刪除請求觸發時、產生 audit trail、能證明已刪除所有副本（包含 backup / log archive）。
6. vendor 政策對齊：用雲端 LLM 時、vendor 的條款拉進自家政策一致審視。

案例觸發參考

LLM log 治理的公開案例累積中、值得追蹤的方向：

• 大型 LLM vendor 的 log 政策變更引發的合規震盪
• 模型 hallucinate 出真人 PII 的訴訟案例
• KV cache 跨用戶洩漏的 incident 報告

LLM-specific 案例累積後會補入 red-team/cases/llm-log-pii/。一般資料保護案例見 7.4 data-protection-and-masking-governance 跟 7.8 data-residency-deletion-and-evidence-chain。

事實查核註：LLM log / PII 議題的具體 incident 跟法律判例累積還在早期、各 vendor 政策跟監管要求依時段快速變化、建議引用前以最新的監管文件（GDPR、CCPA、AI Act 等）跟 vendor 當前政策為準。

引用標準

引用版本與 cadence 規則見 security-citation-currency-and-precision。Last reviewed: 2026-05-12。

下一步路由

• 通用資料保護：7.4 data-protection-and-masking-governance
• 資料居住地與刪除：7.8 data-residency-deletion-and-evidence-chain
• 多租戶 isolation：llm-multi-tenant-isolation
• 偵測訊號：llm-as-service-detection-coverage
• 事件案例工作流：7.10 incident-case-to-control-workflow