跳轉到主要內容
如果你執行一個支付支援代理、一個退單分流機器人,或任何位於主要帳號號碼附近的 LLM 工作流程,問題不是「我的模型有 PCI 認證嗎」——沒有任何模型有。問題是你的應用與模型之間的資料平面,能否防止一個 PAN、一個卡片密鑰,或一個破壞性工具呼叫抵達模型或對你的持卡人資料環境執行。那就是 PCI DSS 套件給你的:一組對應到 PCI DSS 4.0 的閘道控制項,一次呼叫即可安裝,產生簽署證據——並在最前面明確聲明組織性邊界。
你的持卡人資料環境（CDE）——分段、實體存取與你的資訊安全政策——是你組織的責任,而非閘道能強制執行的控制項。 OrcaRouter 能遮罩 PAN、封鎖卡片密鑰、拒絕危險工具並簽署證據——但 CDE 方案是你的。套件把那些條款揭露為你證明的組織性控制項,絕不作為自動化涵蓋。參見下方邊界。

​
1. 「PCI DSS AI」治理在閘道上意味著什麼

PCI DSS 套件（pci_dss,PCI DSS 4.0）把標準的要求對應到即時閘道控制項。像每個 合規套件 一樣,安裝它會在你的工作區中具現化真實、可編輯的 防護欄 與 防火牆 政策——它不加上新的執行期引擎。三個可強制執行的控制項做持卡人資料工作:
pci.pan_block（PCI DSS Req 3.4,讓 PAN 不可讀）在提示中的 Luhn 驗證卡號抵達模型之前封鎖它們,並把它們與銀行路由工具——IBAN 與 SWIFT/BIC 代碼——配對,以它們的字面情境詞守護,因此一個僅僅共享結構形狀的大寫發票或追蹤 ID 不會被誤拒。PAN 偵測搭乘 credit_card PII 實體,因此 Luhn 檢查內建其中。
pci.secret_hygiene（PCI DSS Req 8.3,憑證的強密碼學）封鎖 API 金鑰與私鑰通過閘道,因此一個憑證無法被洩漏進一個提示或回應。這是 Secrets Blocker 防護欄——在每個請求上攔截密鑰的同一個控制項。
pci.dangerous_tools（PCI DSS Req 2.2,安全設定）是一條 防火牆 規則,橫跨每個命名慣例拒絕 shell 與 exec 類工具呼叫——在 inbound 與 MCP 介面上——因此一個代理無法執行一個觸及持卡人資料的破壞性命令。其他一切停留在政策的 audit 預設值。
前兩個控制項存在於內容平面（Guardrails）;第三個存在於工具呼叫平面（Firewall）。安裝把它們合併進一個你擁有並可調校的防護欄與一個防火牆政策。
框架還出貨兩條條款,但它們被標記為組織性:維護一份資訊安全政策（Req 12.1）與限制對持卡人資料的實體存取（Req 9）。那些是代理伺服器永遠無法強制執行的人員與流程控制項——報告把它們揭露為被證明或為缺口,而非自動化涵蓋。誠實就是重點。

​
2. 安裝 PCI DSS 套件——一個具體例子

合規設定使用你的主控台工作階段,絕非中繼 sk-orca-… 金鑰。瀏覽目錄與檢查就緒度對任何工作區 Member 免費;安裝是付費方案上的工作區 Admin 動作,兩個方向都受伺服器門檻。
1

開啟 PCI DSS 套件

在工作區主控台中,前往 Compliance → Catalog 並開啟 PCI DSS 4.0（它存在於 financial 類別下）。每個控制項列出它的平面、它的要求,以及一個通往官方 PCI SSC 文件庫的深層連結。
2

以觀察模式安裝

以付費方案上的工作區 Admin 身分,點擊 Install。套件立即以觀察模式具現化——防護欄標記而非封鎖,防火牆以影子模式執行——因此你先對照真實流量收集「本來會封鎖」的證據。
3

觀看,然後上線

讓影子控制項累積匹配、檢視它們,然後把套件上線以開啟宣告的 block / deny 動作。參見 觀察 vs 強制執行。
主控台在你的 Admin 工作階段權杖下驅動一個端點——在此顯示讓你能稽核或腳本化它,而非作為你用中繼金鑰呼叫的東西: 
POST /api/compliance/packs/pci_dss/install
Authorization: Bearer <your-console-session-token>
Content-Type: application/json

{ }
空的主體會安裝套件中的每個控制項。回應是安裝記錄——釘住的版本、mode: observe,以及兩個具現化政策的 guardrail_id 與 firewall_policy_id,因此你可以立刻開啟它們。
因為安裝產生的是標準防護欄與防火牆物件,你可以透過 firewall_policy_id 把具現化的防火牆政策附加到一個代理金鑰上、透過 guardrail_id 把防護欄附加到一個金鑰上（或把它設為工作區預設值）,並逐實體調校 PAN 規則——正像一個你親手撰寫的政策。

​
3. 誠實的邊界——CDE 是你的

一個 PCI 方案遠不只是一個編修過濾器。閘道涵蓋一個資料平面實際能強制執行的控制項;其他一切仍歸你的組織。這是拆分,以與 共同責任地圖 相同的方式繪製:
控制領域閘道強制執行你的組織擁有
流量中的 PAN封鎖提示中經 Luhn 檢查的 PAN、IBAN、SWIFT/BIC界定哪些欄位是持卡人資料
卡片密鑰封鎖通過閘道的 API / 私鑰閘道路徑之外的金鑰保管
危險工具拒絕 CDE 附近的 shell / exec 呼叫保護繞過閘道的工具
CDE 與政策—（揭露為被證明／缺口）分段;實體存取;資訊安全政策
閘道是被稽核的路徑,而非一個核心層級的攔截器。一個你的代理完全在行程內執行的工具——一個永不跨越 https://api.orcarouter.ai 且永不回報 egress 目的地的工具——在防火牆的視野之外。把觸及持卡人資料的工具與 MCP 呼叫透過閘道路由（經由 防火牆 MCP 閘道）,好讓危險工具控制項能看見它們,或在你的 CDE 內自行保護它們。

​
4. 證明它——簽署、蓋印地區的證據

套件上線後,產生一份 PCI DSS 報告。報告是 Ed25519 簽署且 SHA-256 蓋印的,可匯出為 CSV / JSON / PDF,並可公開驗證——一位評鑑員無需登入即可確認一份報告的真實性。每一列把一條要求追溯到強制執行它的確切防護欄或防火牆政策,以及它本期產生的匹配;兩個組織性條款渲染為已揭露的缺口或擁有者證明。 你也為報告產物宣告一個資料駐留地區（us / eu / uk / ap / cn / global）——簽署報告只在你宣告的地區下儲存與提供,而跨地區讀取會被扣留。這蓋印的是證據產物,而非推論的地理位置。
安裝一個套件與上線需要付費方案上的工作區 Admin,在伺服器端強制。報告產生是 Admin（免費方案:一份 PDF;CSV/JSON 與額外報告是付費）;設定駐留地受 Admin 控管。瀏覽目錄與檢查就緒度保持免費。參見 方案門檻。

​
5. 下一步去哪裡

安裝一個套件

完整的安裝流程——控制項選擇、觀察模式與上線。

簽署報告

Ed25519 簽署的 PCI DSS 證據報告包含什麼。

驗證一份報告

一位評鑑員如何無需登入確認一份報告真實。

防護欄參考

套件具現化的內容平面——PII 實體、Secrets Blocker、動作。

危險工具呼叫

防火牆控制項所防禦的威脅。

資料駐留地

宣告你的簽署證據被儲存與提供所在的地區。
PCI DSS 套件把你能放在一個資料平面上的 4.0 要求變成 PAN 遮罩、密鑰封鎖、危險工具拒絕,以及你能交給一位評鑑員的簽署證據——同時明確聲明 CDE、分段與你的資訊安全政策仍是你的。目錄的其餘部分參見 框架。