Команда поддержки подключает AI-агента: пусть отвечает клиентам по платежам, смотрит статусы транзакций, помогает с возвратами. Пилот идёт отлично — пока на аудите QSA не задаёт вопрос: «а этот агент хранит, обрабатывает или передаёт данные карт?» Пауза. Агент видит PAN в тикетах, логирует диалоги с номерами карт, ходит в биллинг по API. Ответ «да» означает, что в скоуп PCI DSS только что вошли: сам агент, его инструменты, хранилище логов, модель-провайдер и всё, что соединено с этим контуром. Это и есть blindspot, о котором предупреждает WitnessAI: команды смотрят в сторону будущих регулирований вроде EU AI Act и пропускают действующий риск — PCI DSS 4.0.1 уже применяется ко многим AI-инструментам сегодня.
Почему PCI DSS касается агентов уже сейчас
PCI DSS не знает слова «агент» — и ему оно не нужно. Стандарт оперирует потоками данных: всё, что хранит, обрабатывает или передаёт данные держателей карт (CHD) или чувствительные аутентификационные данные (SAD), — в скоупе. Агент поддержки, читающий PAN из тикета, обрабатывает CHD. Агент, передающий номер карты в биллинговый инструмент, передаёт CHD. Чат-лог с вставленным клиентом номером карты — это хранилище CHD, если лог пишется на диск. Каждое из трёх действий включает стандарт — независимо от того, человек это делает или робот.
Хронология версий важна для планирования: PCI DSS 3.2.1 retired 31 марта 2024 года — 4.0 осталась единственной действующей версией, а future-dated требования 4.0 стали обязательными 31 марта 2025 года. Любая оценка после этих дат идёт по полному тексту 4.x. Агент, внедрённый «между делом» в 2025–2026 годах, оценивается по тем же жёстким требованиям, что и остальная инфраструктура, — включая новые требования к скриптам, MFA и аутентификации.
Скоуп: CDE, connected, security-impacting
Руководство PCI SSC по скоупу и сегментации задаёт три концентрических круга — и агент легко оказывается в каждом:
Круг 1. CDE — cardholder data environment. Люди, процессы и технологии, которые хранят, обрабатывают или передают CHD/SAD. Агент, видящий PAN, — внутри. Его инструменты, его память, его логи — внутри.
Круг 2. Connected-to. Системы, соединённые с CDE. Агент, который сам PAN не видит, но ходит в систему внутри CDE (дергает биллинг-API, читает очередь тикетов с картами), — connected, а значит в скоупе со всеми применимыми требованиями к этому соединению.
Круг 3. Security-impacting. Системы, которые при компрометации могут повлиять на безопасность CDE: серверы аутентификации, IdP, системы управления доступом, журналы. Слой доступа, через который агенты ходят к платежам, — классический security-impacting компонент: его компрометация открывает CDE.
Без сегментации действует правило плоской сети: вся сеть — в скоупе оценки. Каждый новый агент без границ скоупа раздувает его дальше: больше систем в аудите, дороже оценка, сложнее поддерживать контроли.
Агент как significant change
Требование 12.5.2 PCI DSS 4.0 обязывает подтверждать скоуп минимум раз в 12 месяцев и при каждом significant change — с обновлением диаграмм потоков данных (1.2.4), идентификацией всех мест хранения/обработки/передачи, всех компонентов в CDE и connected, всех сегментационных контролей и всех подключений третьих сторон с доступом к CDE. А significant change — это, по определению стандарта: добавление железа, софта или сетевого оборудования; замена или major upgrade; изменения потоков данных или хранения; изменения границ скоупа; изменения механизмов логирования и аутентификации; изменения сервис-провайдеров.
Внедрение агента подпадает под несколько пунктов сразу: новый софт, новые потоки данных, новые границы, новые механизмы доступа. Практический вывод: подключение агента к платежам — это триггер внепланового пересмотра скоупа, а не «мелкое улучшение поддержки». Кто не пересмотрел — того пересмотрит QSA.
Сегментация и скоуп-редукция
Сегментация в PCI DSS не обязательна — но это рекомендованный способ уменьшить скоуп: изолированная CDE означает, что в оценку попадают только сегментированные системы. Для агентной инфраструктуры работают три приёма:
- Агент не видит PAN в принципе. Маскирование и токенизация до модели: номер карты превращается в токен на границе, агент оперирует последними четырьмя цифрами и токеном, detokenize — только отдельный сервис по отдельному разрешению. Агент вне CDE — самый дешёвый исход аудита.
- Микросегментация вместо VLAN-наивности. Традиционный подход «CDE за файрволом» доверяет всему внутри периметра. Zero Trust-подход (Coalfire, Elisity) изолирует на уровне сервисов: service mesh с mTLS, fine-grained authorization policies, workload-идентичности SPIFFE/SVID вместо IP-адресов. Граница едет вместе с нагрузкой, а не нарисована раз и навсегда.
- Документированные allowlist-соединения. Каждое разрешённое соединение через границу — с владельцем и бизнес-обоснованием (требование 1.2.6), сегментационные контроли — с пентестом минимум ежегодно (11.4.1/11.4.5). Недокументированная сегментация для assessor не существует.
Сигнал здоровой сегментации по практике: малое и стабильное множество разрешённых путей в CDE, регулярные результаты валидации границы, минимум временных исключений.
PAN: маскирование, токенизация, запреты
Данные карт требуют отдельной дисциплины — agent-specific правила поверх общих DLP:
- Render PAN unreadable (требование 3.4) — в точке входа в агента, а не где-то потом. Маскирование в памяти до передачи модели выводит AI-взаимодействия из скоупа аудита по данным.
- SAD не хранить никогда. CVV, PIN, данные магнитной полосы — агент не видит, не логирует, не кеширует. Ни в памяти, ни в трассировках, ни в eval-датасетах.
- Логи без PAN. Самая частая ловушка: агент пишет подробные траектории «для отладки», а в аргументах вызовов — номера карт. Redaction в логгере обязателен до диска.
- Eval и тренировочные данные. Датасеты с реальными PAN для тестов агента — это хранилище CHD со всеми вытекающими. Синтетика или токены.
- Вставка PAN пользователем. Клиент вставит номер карты в чат — это вопрос времени. Поток обязан это предвидеть: детект, маскирование, предупреждение, никакого «передай как есть».
Требования 7/8/10 в переводе на вызовы инструментов
Мэппинг на агентные системы (по разбору Veto) показывает, что классические требования ложатся на каждый управляемый вызов:
Требование 7 — контроль доступа. 7.2.1: модель доступа определена — policy-as-code перечисляет разрешённые инструменты, аргументы и approval-правила на идентичность агента. 7.2.2: доступ по должностной необходимости и least privilege — раздельные политики для support-, billing-, fraud- и reconciliation-агентов. 7.2.4: ревью доступов минимум раз в полгода — ресертификация политик агентов по расписанию. 7.2.5: системные учётки с минимальной привилегией — per-agent ключи с задокументированным назначением.
Требование 8 — идентификация и аутентификация. 8.2.1: уникальный ID на каждую сущность — уникальная идентичность и ключ на агента, изоляция между тенантами. 8.6.1: учётки приложений под контролем — история ротации ключей, скоупы по окружениям, алерты на аномальное использование. 8.6.2: никаких захардкоженных секретов — ключи только через secret manager, никогда в коде и конфигах агента.
Требование 10 — журналирование. 10.2.2: в каждой записи — кто, что, когда, успех/неуспех, откуда, какие данные затронуты — схема decision record на каждый вызов. 10.4.1: ежедневный разбор логов по событиям безопасности — вьюхи нарушений политик и подпись ревьюера.
Агент, чьи вызовы не дают этих артефактов, не «неудобен для аудита» — он не соответствует.
Доказательства для QSA
Соберите пакет до прихода assessor: диаграммы потоков CHD с агентом на них; реестр инструментов агента с привилегиями; политики доступа как код с историей изменений; журнал вызовов с полями требования 10; записи ресертификации доступов; результаты пентеста сегментации; доказательства маскирования (тесты redaction на входе и в логах); ротация ключей с историей; incident playbook под агентные сценарии. QSA проверяет не намерения, а артефакты с датами и подписями.
Чеклист перед аудитом
- Потоки CHD с участием агента нанесены на диаграммы; скоуп пересмотрен как significant change.
- Агент либо не видит PAN (маскирование/токенизация до модели), либо полностью в CDE с сегментами.
- SAD исключены из всех контуров агента: входы, память, логи, датасеты.
- Требования 7/8/10 закрыты артефактами на каждый вызов: политика, идентичность, журнал.
- Ревью доступов — минимум раз в полгода, с владельцами и подписями.
- Сегментация задокументирована, обоснована и пропентестена.
- Логи ежедневно разбираются; нарушения политик — с sign-off.
- Ключи ротируются, секреты — только через менеджер секретов.
Где Codenik
Codenik строится как граница, которую QSA понимает: агент не получает PAN — маскирование и токенизация стоят до модели, и AI-контур остаётся вне CDE. Где контакт с платежами необходим, каждый вызов идёт с уникальной идентичностью агента, скоупом least privilege и записью в журнале со всеми полями требования 10. Политики — как код с историей и ресертификацией под требование 7, ключи — короткоживущие и ротируемые под требование 8. Сегментация — не слайд, а enforce: нет скоупа — нет вызова, нет записи в журнале — нет операции. Аудит превращается из расследования в чтение артефактов.
Короткий вывод
PCI DSS не делает исключений для роботов: видит PAN — в скоупе, соединён с CDE — в скоупе, влияет на безопасность CDE — в скоупе. Хорошая новость: стандарт даёт и инструменты — сегментацию, маскирование, требования 7/8/10 как чеклист артефактов. Держите агента вне CDE маскированием до модели, а внутри — скоупами, идентичностями и журналами. Тогда вопрос QSA «а этот агент?» будет открывать папку с доказательствами, а не инцидент.