Agentic Commerce Protocol (ACP) предлагает новый подход к интеграции AI-агентов в процесс покупок, и его архитектура безопасности заслуживает детального изучения. Сегодня ИИ-агенты могут выбирать, сравнивать и даже оплачивать товары. Но как не дать им выйти за рамки полномочий? ACP отвечает на этот вопрос — не запретами, а архитектурой.
Философия безопасности ACP
ACP следует принципу secure by design: безопасность встроена на всех уровнях, а не добавлена как слой.
Протокол основан на том, что продавец остаётся «системой записи» для всех заказов, платежей и налогов, а ACP обеспечивает безопасный мост между AI-агентами и существующей коммерческой инфраструктурой. Платежи по-прежнему проходят через PSP (провайдеров платёжных услуг) продавца — но с участием ИИ-агентов.
Архитектура защиты
Транспортный уровень
ACP защищает все коммуникации с помощью TLS 1.2+. Особое внимание уделяется валидации сертификатов и поддержке Perfect Forward Secrecy, что предотвращает расшифровку перехваченного трафика даже при компрометации долгосрочных ключей.
Защита на транспортном уровне особенно важна для AI-агентов, обрабатывающих чувствительные данные, и служит основой всей архитектуры безопасности.
Аутентификация
ACP использует многофакторный подход к аутентификации, сочетающий традиционные Bearer токены с криптографическими подписями. Каждый запрос должен включать действительный API-ключ в заголовке Authorization, но этого недостаточно для полной аутентификации.
Дополнительный слой безопасности обеспечивается через HMAC-SHA256 подписи, которые создаются на основе канонического JSON и временной метки. Даже если злоумышленник перехватит API-ключ, он не сможет создать валидные запросы без знания секретного ключа для подписи.
Временные метки (RFC 3339) добавляют защиту от replay-атак, ограничивая время жизни каждого запроса. Серверы ACP проверяют свежесть запросов в рамках допустимого окна расхождения часов, что предотвращает повторное использование перехваченных запросов.
Идемпотентность и защита от replay-атак
ACP поддерживает идемпотентность (свойство объекта или операции при повторном применении операции к объекту давать тот же результат, что и при первом) критических запросов. Каждый критический запрос (создание сессии, завершение покупки) может содержать Idempotency-Key, который гарантирует, что повторные запросы с тем же ключом и параметрами вернут тот же результат.
Это ключевой механизм безопасности. Он предотвращает случайное дублирование транзакций при сетевых сбоях и защищает от атак, направленных на создание множественных заказов.
Каноническая сериализация JSON обеспечивает детерминированное представление данных, что критично для корректной работы криптографических подписей. Даже минимальные изменения в форматировании JSON приведут к невалидной подписи.
Токенизация платёжных данных
ACP защищает платежные данные с помощью токенов. Вместо передачи реальных номеров карт, протокол использует «delegated vault tokens» — ограниченные по времени и сумме токены, которые могут быть использованы только в рамках конкретной транзакции.
Эти токены создаются с помощью специального API endpoint /agentic_commerce/delegate_payment и содержат строгие ограничения:
— Максимальная сумма транзакции
— Валюта
— Время истечения
— Причина использования
Такой подход минимизирует риски, связанные с хранением и передачей чувствительных платежных данных, при этом сохраняя функциональность для AI-агентов.
Особенности для AI-агентнов
Shared Payment Token
ACP использует Shared Payment Token — одноразовый токен, который выдается только после явной авторизации пользователя через платежную систему (например, Stripe). Этот механизм решает основную проблему агентских платежей: как убедиться, что агент действует по поручению пользователя, а не по собственному усмотрению.
Агент получает одноразовый токен, привязанный к конкретной транзакции и содержащий строгие ограничения, которые он не может обойти.
Ограничение контекста API
ACP реализует принцип минимальных привилегий для AI-агентов. Агент взаимодействует с магазином только через строго определенные API-методы («посмотреть корзину», «оформить заказ»), получая доступ только к структурированному состоянию (например, ID товара и сумме), но не к персональным данным.
Это создаёт изолированную среду: агент может выполнять только действия, разрешённые продавцом через API. Нет возможности для агента изменить цену товара или получить доступ к данным других пользователей, что снижает риски prompt-инъекций и других атак, специфичных для AI-систем.
Внешняя аутентификация через PSP
ACP не хранит данные карт — вся проверка проходит через сторонние системы с собственными защитными механизмами (3D Secure, биометрия). Роль Stripe или PayPal в этом процессе критически важна: они выступают в качестве внешнего аудитора, проверяющего подлинность пользователя до передачи токена агенту.
Эта архитектура перекладывает основную нагрузку по аутентификации пользователя на специализированные платежные системы, которые уже имеют проверенные механизмы безопасности и соответствуют всем регуляторным требованиям.
Устойчивость к атакам
ACP спроектирован с учетом некоторых киберугроз. Система защищает от:
Prompt injection: Ограничение контекста API и одноразовые токены предотвращают модификацию финансовых параметров через подмену запросов.
Подмена агента (Agent Impersonation): защищена криптографическими подписями и строгой идентификацией.
Confused Deputy: Ограничение прав доступа агента через API и четкое разделение ролей предотвращают злоупотребление доверием к MCP серверам.
Утечка данных: Автоматическое удаление чувствительных данных из логов и токенизация минимизируют ущерб от утечек.
Безопасность в ACP — это не набор отдельных мер, а сквозной принцип, который пронизывает каждый аспект протокола. От базового транспортного шифрования до сложных механизмов токенизации, каждый уровень архитектуры вносит свой вклад в общую защиту системы.
ACP показывает: чтобы ИИ-агенты стали надёжными покупателями, им не нужны “кандалы” — им нужны чёткие правила и безопасные границы.
где подробнее почитать:
https://t.me/pwnai — мой канал
https://github.com/agentic-commerce-protocol/agentic-commerce-protocol — github протокола
Источник: habr.com
