Безопасный протокол ACP для ИИ-агентов: защита покупок и платежей

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