PCI Security Standards Council(PCI SSC)は、決済環境におけるAIシステムへ入力するデータの保護と、AIを悪用した攻撃への防御を扱うガイダンス「Security Considerations for AI Systems」を公開しました。
この文書は業界の関係者とともに作成されたもので、ガバナンス、導入、アクセス制御、テスト、PCI標準の適用について取り上げています。推奨事項はあくまで助言であり、既存のPCI要件が優先されます。
PCI SSCのエグゼクティブディレクターであるGina Gobeyn氏は、次のように述べています。「決済環境でAIの利用が拡大するなか、すべての関係者にはこの技術を責任を持って使う義務があります。今回の追加ガイダンスは、AIを安全に導入するための実践的な出発点となります」
AIシステムに対するPCI DSSのスコープ設定(出典:PCI SSC)
アクセス権限と説明責任を定める
PCI SSCは、AIシステムを選定・導入する前に、その目的、権限、データアクセスの範囲を定めるよう推奨しています。「最小エージェンシー(least agency)」の考え方に基づき、各システムには割り当てられたタスクに必要なアクセス権と機能だけを与えます。
AIの出力については、適切な立場にある人間が正式に責任を負うべきです。あわせて、どの操作に人間の承認が必要かを組織として明確にしておく必要があります。アクセス制限は、ID管理ポリシーやネットワーク分離といった独立した統制によって実施すべきだとしています。
機密データへのアクセス、外部との通信、信頼できないソースからの無制限な入力という3つの要素を、1つのAIシステムに集約することは避けるべきです。ワークフロー上3つすべてが必要な場合は、異なる権限を持つエージェント間で役割を分離するよう、ガイダンスは勧めています。
AIのインベントリと部品表(BOM)には、モデル、バージョン、ホスティング環境、連携先、データの利用・保持ポリシー、想定ユーザーを記載します。また、利用規定と技術的な統制を整備し、従業員が承認なく導入・利用するツール、いわゆるシャドーAIを把握し、制限できるようにすべきです。
統制をテストし、障害に備える
安全対策は、大規模な機能テストやユーザー受け入れテストの前に検証する必要があります。この検証には、制限を回避できないかを確かめる敵対的テストも含まれます。
導入後も、監視と再検証を継続し、挙動の変化を検知します。レビューの工程では、AIの出力を過信するあまり、レビュー担当者が誤りを見逃すおそれがある点も考慮しなければなりません。
このガイダンスは、タスクごとに人間が承認する方式に加え、個々の操作ごとの承認は行わず、監視下でAIシステムが許可された操作を実行する方式も示しています。後者の「監視付き自律」では、許可する操作、承認が必要な条件、停止のトリガー、変更を元に戻す手順を組織が定めておく必要があります。最終的な責任は、適切な立場にある人間が引き続き負います。
平文のカード会員データにアクセスできるエージェントについては、そのデータに関わる操作に対して、人間による明示的な承認を求めることを推奨しています。
機密データと認証情報を守る
AIシステムには、パスワードや暗号鍵など、保護されていない重要度の高いシークレットを扱わせたり、生成させたり、管理させたりすべきではありません。認証情報はシークレット管理ツールで管理し、ソースコード、プロンプト、AIのコンテキスト、出力、ログには含めないようにします。
乱数が必要な場合は、信頼できる乱数生成器を使うようPCI SSCは推奨しています。パスワードや暗号鍵に使う値は、AIシステムの外部に置く必要がある場合もあります。
組織は、可能な限り暗号化またはトークン化された決済データを使うべきです。データ損失防止(DLP)の統制はAIから独立して動作させ、ログは機密性の高い決済情報を保持せずに調査を支援できる内容にする必要があります。
PCIのスコープ設定では、AIシステムの導入形態、分離状況、学習用データを含むアカウントデータへのアクセス、カード会員データシステムのセキュリティに影響を及ぼしうるかどうかを考慮します。暗号化またはトークン化されたデータへのアクセスと、それを復号・脱トークン化するツールへのアクセスを併せ持つ場合は、読み取り可能なデータへのアクセスと同等に扱うべきです。
AIを悪用した攻撃に対処する
PCI SSCは、AIが脆弱性の発見、エクスプロイトの開発、ソーシャルエンジニアリングを加速させるおそれがあると警告しています。そのため、脆弱性の継続的な監視と、検出結果やパッチの優先順位を決める手順を整えるよう推奨しています。
防御策としては、サービスと権限の制限、レガシーシステムの分離、フィッシング耐性のある認証の採用、機密データの暗号化、侵害による影響の封じ込めなどを挙げています。
AIが生成したコードやパッチには、セキュリティテストと機能テストを実施する必要があります。レビューでは、埋め込まれた認証情報、不適切な依存関係、新たに生じた脆弱性がないかを確認し、修正が根本的な問題に対処できているかも見極めます。
導入例の一つでは、脆弱性管理を複数のエージェントに分担させています。問題の特定、パッチ適用計画の作成、変更のテスト、承認済み更新の展開をそれぞれ別のエージェントが担う形です。権限は役割ごとに割り当て、ロールバック手順は展開前にテストします。
外部プロバイダーを評価する
機密データにアクセスできる外部のAIプロバイダーは、該当するサードパーティサービスプロバイダーの要件に基づいて評価すべきです。契約では、機密情報に対する責任の所在を明記し、組織のデータをAIの学習に使うことを明確に禁止し、再委託先の状況を把握できるようにして、侵害時の通知条件を定める必要があります。
インシデント対応計画と定期的なテストでは、プロンプトインジェクション、モデルポイズニング、承認された範囲外の操作、機密データにアクセスする未承認のAIツールを想定しておくことが求められます。
翻訳元: https://www.helpnetsecurity.com/2026/10/09/pci-ssc-payment-environments-ai-security-guidance/
