如何設定支付環境 AI 代理權限：資料、核准與責任

替 AI 代理加上登入權限，還不足以判斷支付流程是否安全。團隊還要先確認代理會讀取哪種資料、能呼叫哪些工具、能否送出或改變交易，以及每個動作由誰核准、記錄與負責。PCI SSC 於 2026 年發布《Security Considerations for AI Systems》，補充支付環境部署 AI 的安全考量，當中最需要落到設計上的問題，是明文持卡人資料的存取與操作如何由人員把關。

PCI SSC 新增 AI 指引，支付環境要先釐清什麼？

這份文件是協助部署與評估的補充指引，不是新增的強制 PCI DSS 條文。 團隊應先依實際資料流與系統功能判斷適用的 PCI 標準，再把指引當作設計和風險檢視參考。

PCI SSC 將新文件定位為資訊補充指引，內容涵蓋 AI 部署、AI 可能被惡意利用時的防護、AI 與 PCI 標準的關係，以及支付環境的使用案例。官方也明確說明，若指引與正式 PCI 標準有差異，應以標準為準。AI 系統在適用要求的範圍判定上，原則上按其他技術系統看待；是否納入評估，要看它處理哪些資料、部署在哪裡、連接什麼系統，以及能否影響持卡人資料環境的安全。PCI SSC 新指引公告；PCI DSS 標準說明

這也延續了 PCI SSC 先前發布的 AI 原則：遵守適用標準、只給系統工作所需的最低權限、留下可追溯的操作紀錄，並指定負責的人員。新補充指引進一步把這些原則放回 AI 代理的實際操作情境，讓團隊得以逐項檢查代理的權限和核准點。PCI SSC AI 原則

明文持卡人資料為何需要人工核准？

若代理能接觸明文持卡人資料，指引建議涉及該資料的操作要有明確的人員核准。 遮罩資料會隱去部分欄位；截短 PAN 會移除部分卡號；加密 PAN 需透過金鑰還原；token 則以代碼替代原始資料。團隊應分別檢查代理能看到的內容，以及能否呼叫解密或 detokenize 工具還原資料，不能只憑欄位名稱判定風險已消失。Help Net Security 對指引內容的報導

團隊可先把資料欄位分成幾類：可直接辨識完整帳號的明文資料、只保留部分號碼的截短資料、經加密後需金鑰還原的資料，以及由代碼替代的支付 token。代理若同時持有密文與解密工具，實際上仍可能讀到明文；同理，能呼叫代碼化平台還原資料的代理，也不能只因提示詞裡看不到完整卡號就被當成無法存取。

PCI SSC 先前的原則鼓勵在工作流程可行時採用支付 token 或一次性 PAN，限制 AI 接觸完整卡號的必要性。對不需要完整 PAN 的用途，可評估截短號碼或保留明文 BIN 的加密 PAN。BIN 是銀行識別碼（Bank Identification Number），也稱發卡機構識別碼，通常指卡號開頭用來辨識發卡機構的數字；保留它不等於代理可讀取完整卡號。這些做法有助降低資料暴露面，但不會自動排除 PCI 範圍，也不能取代正式範圍判定。

核准畫面也應讓人看懂正在核准什麼：資料種類、目的、代理即將執行的工具動作、收件系統與資料保留方式。只按一次「允許 AI 使用」的廣泛授權，難以涵蓋後續新增的讀取、傳送或寫入能力。權限宜依用途拆分，並設定到期時間、撤回方式及異常時的停用條件。

支付決策、資料核准與安全防護各由誰負責？

代理可以提供支付授權判斷的輸入，或在核准後執行限定動作，但正式責任仍須由適任人員承擔。 防護系統在攻擊進行時可按預先界定的條件自動隔離或限流，需另行設計權限、監控與復原機制。

資料存取核准、交易授權與安全防護是三種不同決定。資料核准回答「代理可否讀取或處理這份資料」；交易授權回答「這筆付款是否通過既定規則」；安全防護則處理「是否要隔離主機、限制網路或阻擋可疑流量」。若三者都交給同一代理、共用同一組高權限憑證，出錯或遭提示注入時，影響可能從資料外洩一路擴大到交易操作與防護設定。

實作上可將代理的角色切開：一個代理只整理風險訊號，另一個受控服務執行支付規則，人員或既有授權系統負責最後核准；安全代理則只在允許的範圍內採取可回復的防護動作。若某些緊急隔離必須先於人工核准，應寫明觸發條件、允許的動作、監控對象、停用機制和回復步驟，並測試錯誤觸發是否會造成服務中斷。

“When there are differences between the guidance and official PCI standards, the PCI standard always takes precedence.” — PCI SSC

導入團隊如何檢查權限與責任交接？

從資料流、代理工具與人員責任三張清單開始，逐項連結到核准、紀錄、撤權及事件應變。 若使用外部模型或雲端工具，還要確認資料如何傳送、保存與再利用，以及供應商在 PCI 評估範圍中的角色。

第一，畫出資料流，標明資料從哪個系統進入代理、途中經過哪些模型或工具、最後送到何處。清單應包含訓練、提示脈絡、輸出、日誌與備份，不要只檢查使用者介面是否遮住卡號。第二，為每個代理列出獨立憑證、讀取範圍、可呼叫工具及可執行動作，並檢查憑證能否追蹤、撤回，代理是否能存取與任務無關的系統。

第三，替操作設計核准紀錄。至少留下提出者、核准者、時間、資料類型、動作、執行結果和例外原因；紀錄本身也須避免再次保存敏感支付資料。第四，訂出責任交接：誰核准代理輸出、誰維護模型與工具、誰接收異常告警、誰負責供應商聯繫和事件通報。PCI SSC 的 AI 原則指出，AI 無法承接需要正式責任的角色，相關操作應能追溯到具名的人員。

“Ultimate responsibility must come down to a single individual.” — PCI SSC《AI Principles: Securing the Use of AI in Payment Environments》

這項責任安排也要落在日常維運：人員異動時更新代理負責人與告警名單；模型、提示或工具權限改版時重新檢視核准範圍；演練撤銷憑證後，確認付款流程能切回人工或既有服務。若紀錄只留下代理名稱，卻無法找到當班承責者，事件發生後就難以判斷誰能停用代理、保存證據並通知相關單位。

若代理連到第三方模型、外部 API 或雲端服務，合約和技術檢查需涵蓋敏感資料處理責任、資料是否用於模型訓練、分包服務、保存期限與事件通知。整體 PCI 適用範圍仍須按實際資料流、服務功能及組織角色評估。可參考 PCI SSC 的《Security Considerations for AI Systems》指引公告及正式 PCI DSS 標準，並和收單機構或合格評估人員確認個別情境。

上線前可用測試環境演練幾種失敗情境：代理收到要求外傳卡號的指令、核准服務逾時、工具回傳超出任務所需的欄位，或撤權後仍持有有效連線。逐項確認代理會停止、降級或轉交人工，並檢視告警能否指出觸發原因及受影響資料。這些演練可暴露單看權限清單不容易發現的流程缺口，也能驗證復原責任是否有人承接。

• 先辨認明文、遮罩、截短、加密及代碼化資料，並檢查代理是否能透過工具還原資料。
• 將資料讀取、支付授權和安全防護分開設計；核准要對應具體資料和動作。
• 為代理配置最小權限、可撤回憑證、可稽核紀錄及明確的人員責任。
• PCI SSC 補充指引提供評估參考，正式 PCI 標準及個別適用範圍判斷仍優先。

常見問題

Q1: PCI SSC 是否規定所有 AI 代理每次都要人工核准？

不是所有代理動作都一律逐筆核准。指引建議，能接觸明文持卡人資料的代理，其涉及該資料的操作應取得明確人工核准；其他情境可依風險設計受監控的自主操作，並預先設定允許行為、停用條件和復原程序。

Q2: 使用 token 或加密卡號，就能讓 AI 系統排除 PCI 範圍嗎？

不能直接這樣判定。若代理同時能使用解密或代碼還原工具，仍可能具有讀取明文資料的能力；是否納入範圍需根據資料流、部署隔離、系統功能及其對持卡人資料環境的影響評估。

Q3: AI 代理可以自行核准交易或承擔資安責任嗎？

AI 可以提供授權判斷的輸入，也能在獲准後執行限定任務；正式核准和責任仍要指向人員或既有治理機制。少數緊急防護動作可按風險分析預先授權，但必須有監控、停用和回復安排。

支付工作流中的 AI 代理若涉及資料權限、治理或系統整合，歡迎交流討論。