OpenAI 近日將雙向的 TLS 與 X.509 工作負載身份正式開放給 API 組織。過去，伺服器會向客戶端出示證書，調用方再攜帶 API 密鑰或短期令牌來完成身份驗證；啟用 mTLS 後，客戶端也必須在 TLS 握手階段出示被組織信任的證書。即使攻擊者取得了普通的 Bearer 凭證，沒有對應的私鑰和有效證書鏈，請求仍不能通過指定的 mTLS 入口。

這並非替代 API 密鑰的新登錄方式，而是在原有的授權之前增加一層機器身份驗證。官方文檔明確指出，mTLS 不會取代 API 密鑰、服務帳戶憑證或工作負載身份令牌。X.509 的聯合也不只是「單純依靠證書來調用 API」：證書交換首先會獲得短期 Bearer 令牌，後續請求仍須同時發送令牌和可接受的客戶端證書。

該功能可在組織或項目級別啟用，證書管理受 RBAC 權限控制。api.mtls.read 用於查看和測試設定，api.mtls.write 允許上傳、激活、停用和刪除證書。正式可用意味著產品不再處於測試預覽階段，但並不代表企業只需打開一個開關就能完成零信任轉型；證書簽發、輪換、撤銷和故障恢復等流程都需由調用方納入運行體系中。

密鑰回答「你能做什麼？」，證書則先回答「是哪臺工作負載在連線」

普通的 API 密鑰一旦出現在錯誤日誌、代碼庫或被入侵的主機上，持有者通常可以從其他網絡位置重新使用該密鑰。 IP 白名單可以縮小範圍，但雲工作負載的地址可能會變化，共享出口也很难精確地指向某個服務。 mTLS 將驗證綁定到由企業證書發行體系管理的私鑰，這使得權限憑證和機器身份必須同時成立。

配置時，組織需上傳 PEM 格式的信任錨，之後在非關鍵項目中激活測試。客戶端證書需要適用於 TLS 客戶端認證、在請求時有效、包含 Authority Key Identifier，並能沿完整證書鏈回到已激活的組織級或項目級信任錨。如果存在中間證書，客戶端必須在握手時一併提供；OpenAI 不會從 AIA 地址主動下載缺失的證書鏈。

企業還可以使用 CEL 表達式來限制證書屬性，例如要求特定的組織單元，或僅接受某個 DNS 名稱空間下的 Subject Alternative Name。這樣，同一內部 CA 領發的證書不必全部獲得同等的訪問權。OpenAI 會先檢查項目級證書，再檢查組織級證書；證書鏈通過後才執行屬性過濾，任何一環失敗都會拒絕請求。

呼叫地址也發生變化。預設入口是 mtls.api.openai.com，另有美國和歐盟地區的入口。路徑仍沿用 /v1 接口，但地區主機的模型和路由可用性可能不同，因此不能只測試一次模型列表就直接切換生產流量。官方建議逐一驗證實際使用的 API 表面和模型，并在啟用前準備可測試的恢復路徑。

mTLS 提高盜用的門檻，卻將證書的生命周期變成新的生產責任

雙重憑證能有效降低「單獨密鑰洩露」所造成的跨環境濫用，但無法修復已被完全控制的伺服器。如果攻擊者同時獲得客戶端私鑰和 Bearer 令牌，仍可能以合法工作負載身份發起請求。私鑰必須放在密鑰管理服務、硬體安全模組或受控的 Secret 存儲中，不能寫進鏡像、源碼或調試輸出。

證書輪換需要重疊窗口。合理的順序是先上傳並激活新的信任錨，讓工作負載逐步切換到新證書，確認所有入口正常後再停用舊錨，最後刪除。如果先撤銷舊證書再發布新證書，API 將會整體中斷；如果新旧證書長期共存，又會擴大受信任範圍。項目級灰度測試能將這類事故限制在較小的範圍內。

官方文件還給出了重要限制：OpenAI 目前不執行 CRL 或 OCSP 的吊銷檢查，也不會自動補充中間證書。當發生私鑰洩露時，企業需要通過停用、輪換和自身證書治理來快速處置。每個組織最多可上傳50個證書對象，如果證書層級設計過細，可能很快就會遇到數量上限。Private Link 與 mTLS 也不兼容，需要私有 Azure 網路路徑的團隊應該選擇不同的方案。

對於審計而言，mTLS最大的價值在於讓「哪個服務發起了調用」這一點更加可驗證。它可以與短期身份令牌、項目隔離、最小權限和用量告警結合使用，將靜態密鑰從唯一的「門鎖」降低為多層控制中的一環。但它不會判斷請求內容是否安全，也不會阻止擁有合法證書的程序被誘導進行注入。內容策略、工具權限和資金上限仍需獨立設定。

這次正式開放反映出企業 AI 正在從試用工具變成關鍵基礎設施。當模型開始讀取內部數據、修改代碼和觸發外部動作時，API 的接入不能再僅依賴於一組長期密鑰。mTLS 提供了更強的機器身份邊界，也將證書運營的複雜度交還給企業。它值得啟用的前提是，團隊已能安全保管私鑰、自動輪換證書，並在認證故障時迅速回退，而不是為了「更安全」而一次性的鎖定所有生產調用。