HopBase先說答案:企業接入大模型 API 的安全評估,濃縮成四層——密鑰治理(最小權限、可即時吊銷)、數據鏈路(內容是否落盤、日誌留什麼)、審計對賬(每次調用可回溯、失敗不收錢)、供應商可驗證性(口頭承諾不算數,行為才算)。本文是一份逐項標注「怎麼驗證」的清單,可以直接拿去評估任何供應商,包括我們自己。
第一層:密鑰治理
安全事故的第一現場幾乎都是密鑰。合格的治理只有一個原則:任何一把 key 的洩露,損失都要被限制在最小範圍。
- 一應用一 key、一團隊一 key:洩露只廢一把,吊銷不影響其他業務;
- 模型白名單:key 綁定分組,只能調用分組內授權的模型,拿到 key 也調不了範圍外的資源;
- 獨立配額:每把 key、每個分組配額獨立,失控調用燒不穿全局預算;
- 服務端只存哈希:HopBase 的 API Key 以單向哈希存儲,明文密鑰不進數據庫——即使數據庫被拖走,也還原不出你的 key。
第二層:數據鏈路
把這三個問題拋給任何供應商,要書面回答:
- 請求與響應內容是否落盤?
- 日誌裡保存哪些字段、保存多久?
- 數據是否可能被用於訓練或二次使用?
HopBase 的公開口徑:內容零留存——prompt 與輸出從不落盤,只保留計費所需的元數據(模型、token 用量、耗時、狀態)用於賬單與審計;全部流量走 TLS 加密傳輸。內容不落盤的連帶含義很直接:網關側不存在內容庫,也就不存在內容被二次使用的物理可能。上游側則按通道屬性適用各官方平台的條款,而我們的通道屬性在定價頁全部公開,你可以按通道逐條評估。
第三層:審計與對賬
沒有審計的安全是空話:出事後你需要回答「誰的 key、什麼時間、調了什麼模型、用了多少量」。
- 每個請求的模型、用量、耗時、狀態全程留痕,異常調用可回溯;
- 用量明細可導出對賬,賬單金額等於實際消耗;
- 失敗不計費:錯誤碼非空的請求不收錢,這一條在導出明細裡逐行可驗。
第四層:供應商可驗證性
「不偷換模型、不降智、不存數據」這類承諾,市面上人人都說,但承諾不可驗證,行為才可驗證。要求你的供應商:
- 通道屬性公開——每條通道是什麼渠道、什麼倍率,寫在明面上;
- 錯誤碼透傳——上游報什麼就是什麼,不吞不改;
- 歡迎檢測——供應商如果不歡迎你跑保真檢測,這本身就是答案。
一頁清單:逐項怎麼驗證
| 檢查項 | 合格標準 | 怎麼驗證 |
|---|---|---|
| 密鑰粒度 | 一應用一 key,可即時吊銷 | 建兩把 key 吊銷其一,另一把應不受影響 |
| 模型白名單 | key 只能調用授權範圍內的模型 | 用 key 調未授權模型,應被明確拒絕 |
| 配額隔離 | key/分組配額獨立 | 打滿測試組配額,其他組應不受影響 |
| 內容留存 | 請求與響應內容不落盤 | 要求書面說明留存策略與字段清單 |
| 傳輸加密 | 全鏈路 TLS | 檢查證書鏈;仍有明文 HTTP 的直接淘汰 |
| 密鑰存儲 | 服務端只存單向哈希 | 問一句:數據庫洩露後能否還原明文 key |
| 審計粒度 | 每請求留痕:模型/用量/耗時/狀態 | 導出用量明細,抽樣對賬 |
| 失敗計費 | 失敗請求不計費 | 製造失敗請求,核對賬單是否有金額 |
| 錯誤透傳 | 上游錯誤碼原樣透傳 | 觸發限流,對比官方錯誤行為 |
| 保真可驗證 | 歡迎第三方檢測 | 跑一遍保真檢測五項,看供應商反應 |
常見問題
我的數據會被 HopBase 存儲或用於訓練嗎?
不會。內容零留存是產品設計而不是口頭承諾:prompt 與輸出不落盤,只保留計費元數據。網關側沒有內容庫,自然不存在被訓練或二次使用的物理可能。
經過網關比直連官方多一跳,是不是多一層風險?
多的這一跳換來的是集中治理:統一的密鑰分級、統一的配額與白名單、統一的審計與吊銷。直連模式下 N 個團隊各自持有官方 key,洩露面和治理成本反而更大;而鏈路本身全程 TLS 加密。
能簽合同、走對公嗎?
可以。企業客戶的合同條款、對公流程與商務合規事項,聯繫顧問對接。
這份清單怎麼用?
拿著它同時評估幾家供應商,每一項都要求演示或書面確認,再配合保真檢測方法驗證模型側;兩份都過,再談價格。