xAI API 新增 safety_identifier：多使用者應用怎麼避免一個使用者連累整個 API Key
xAI 開發者 release notes 在 2026 年 9 月新增了一個可選請求欄位 safety_identifier。你的應用把每個終端使用者的不透明標識放進請求，xAI 在處理違反使用政策的請求時，就能把它歸到具體的終端使用者，而不是整個 API Key。如果你做的是 SaaS、機器人或團隊內部工具，多個使用者共用一個 Key，官方文件建議為每個使用者單獨設定這個欄位。
時間口徑：以下內容基於 xAI 官方文件截至 2026 年 10 月 17 日的頁面。release notes 的條目列在 9 月標題下，頁面未給出具體日期，請以官方頁面為準。
safety_identifier 到底是什麼？
按 xAI release notes 的說法，它是“由你的應用分配的、代表終端使用者的不透明標識”，請求欄位可選。目的是讓違規歸因落到具體使用者，一個使用者的濫用不再牽連整個賬號。
官方 Security FAQ 補充了幾點：
- 標識應當穩定，同一個使用者每次請求都用同一個值，並且由你的應用分配，終端使用者不能自己指定。
- 如果請求違反使用政策，xAI 可以把它歸到這個標識，並在聯絡你時引用它。
- 建議傳送內部使用者 ID 或其他不透明值的雜湊。不要傳送郵箱、手機號、暱稱。頁面說明該欄位的格式不做校驗，並提到長度上限為 96 個字元。
- 如果你讓很多終端使用者共用一個 API Key，應為每個使用者設定它，讓濫用報告落到使用者而不是 Key 上。
哪些介面支援？舊的 user 欄位還能用嗎？
兩篇官方文件列出的支援範圍：Chat Completions、Responses API（FAQ 提到包含流式和 WebSocket 模式）、延遲補全（deferred chat completions）、Batch API，以及 gRPC 的 GetCompletionsRequest。
原有的 user 欄位仍然被接受，但 FAQ 寫明 safety_identifier 是今後文件推薦的欄位。如果兩個欄位同時傳會怎樣，文件沒有說明，所以別依賴這種行為：新程式碼只傳 safety_identifier，舊程式碼遷移時替換掉 user。
不傳會怎樣？
文件沒有寫不傳的後果，也沒有說 xAI 會因為沒傳而拒絕請求。能確定的只是它的設計意圖：沒有標識時，違規請求只能歸到 Key 這一層。所以對多使用者應用，補上它的成本很低，收益是出問題時影響範圍可以收窄。是否真的能避免 Key 被限制，取決於 xAI 的處理，官方沒有做這個承諾。
標識該怎麼生成？
原則是穩定、不可逆、不含個人資訊。一個常見做法是對內部使用者 ID 做帶金鑰的雜湊（HMAC），這樣別人無法從標識反推出你的使用者 ID。下面是示例，不是官方程式碼：
import hmac, hashlib, os
SECRET = os.environ["SAFETY_ID_SECRET"].encode()
def safety_id(internal_user_id: str) -> str:
return hmac.new(SECRET, internal_user_id.encode(), hashlib.sha256).hexdigest()
注意：
- 金鑰不要隨意輪換，換了以後同一使用者的標識會變，歸因就斷了。
- 用內部 ID，不要用郵箱。使用者改郵箱不應該改變標識。
- 機器人場景裡，一個群或一個頻道不等於一個使用者，儘量落到真實的終端使用者。
請求裡怎麼寫？
欄位放在請求體裡。下面以 Responses 介面為例，模型名用佔位符，按你在官方模型頁看到的名稱填寫：
curl https://api.x.ai/v1/responses \
-H "Authorization: Bearer $XAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "<model>",
"input": "你好",
"safety_identifier": "a1b2c3d4e5f6..."
}'
如果你用 OpenAI 相容的 SDK，SDK 的型別定義裡可能還沒有這個欄位，可以透過它的“額外請求體引數”傳入（OpenAI Python SDK 裡是 extra_body），具體以所用 SDK 版本為準：
client.chat.completions.create(
model="<model>",
messages=[{"role": "user", "content": "你好"}],
extra_body={"safety_identifier": safety_id(user.id)},
)
Batch 和 gRPC 的欄位位置請以官方 API 文件為準，這裡不展開。
上線前的檢查表
- 所有呼叫 xAI 的程式碼路徑都傳了欄位：聊天、批處理、後臺任務、定時任務都算。
- 值是雜湊或隨機 ID，沒有郵箱、手機號、暱稱。
- 同一使用者每次請求值一致，不同使用者值不同。
- 日誌裡記錄“請求 ID、標識、時間”，但不要把使用者的原始內容長期明文存放。出了問題時，你能用標識定位到是哪個使用者。
- 前置內容稽覈：標識只負責歸因，不會替你攔截違規內容。入口處的稽覈、頻率限制和異常使用者封禁，仍然是你自己的責任。
- 在服務條款裡寫明：違規使用可能導致你限制該使用者的訪問。
怎麼跟蹤 xAI 文件後續的改動？
這類欄位的語義以後可能補充細節。可以看 cdnping 的 官網動態，它監控各家官方更新日誌與價格頁的增刪；呼叫本身的健康狀況看 xAI API 狀態。更多思路見 大模型 API 價格變了怎麼第一時間知道。
如果你正在比較直連官方、雲廠商託管或經由閘道器接入，可以讀 AI API 接入方式怎麼選。透過中間層轉發請求時，上游看到的是中間層的 Key，終端使用者歸因更要自己做好，評估方法見 api中轉站怎麼選。出現報錯時，怎麼看 OpenAI 狀態頁和 Claude 狀態頁 裡的方法同樣適用於判斷是不是上游事件。
