對事件中的敏感資料進行脫敏
最安全的敏感值是永遠不會進入事件管道的敏感值。從顯式白名單建置結構化事件，而不是序列化請求、異常、模型回應或資料庫物件，然後嘗試刪除危險鍵。
預設排除的資料
請勿記錄 API 金鑰、密碼、會話 cookie、授權標頭、Webhook 簽名、付款詳細資訊、完整請求正文、資料庫連線字串或原始提示和完成。自由格式文字可以包含個人或機密資料，即使其欄位名稱看起來無害。
與電子郵件地址相比，更喜歡內部不透明識別符號。用受控的 error_type 替換原始異常，並透過適當的存取和保留將完整的堆疊追蹤保留在診斷系統中。使用穩定的路由範本替換包含識別符號或查詢字串的 URL。
在邊界處應用控制
逐個欄位建立事件物件：
const event = {
route_template: request.routeOptions.url,
method: request.method,
status_code: response.statusCode,
latency_ms: elapsedMs,
account_id: account.internalId,
};
await telemetry.log("api_request_completed", event);
當需要可重複使用的消毒劑時，請將其視為深度防禦。測試巢狀物件、陣列、備用大寫和意外型別。合約之外的繫結字串長度和拒絕欄位。當原始值具有較小或可猜測的集合時，雜湊不是匿名化。
審查並回應
為每個大容量活動合約分配一個所有者。在啟用生產排放之前檢查開發中的樣本行。新增新識別符號時重新審視保留和存取需求。
如果發現敏感資料，請停止發出路徑，識別受影響的資料表和時間範圍，輪換任何暴露的機密，並在適當的情況下使用支援的刪除工作流程。然後新增一個迴歸測試來練習實際的事件建構函式。