ИИ-агент для маркетплейсов: как выдать права безопасно

AI 10 мин чтения

---

Подключить ИИ-агента к Wildberries, Ozon или Яндекс Маркету можно за несколько часов. Настроить это так, чтобы агент не стал точкой уязвимости - задача другого порядка. Большинство проблем возникают не из-за плохой модели, а из-за того, как выстроена связка «токен - инструменты - права доступа». Ниже - практический разбор того, где именно ломается безопасность и что с этим делать.

Почему «просто дать токен» - это не решение

Когда агенту передают тот же API-ключ, которым пользуется менеджер вручную, он получает всё сразу: чтение заказов, изменение цен, управление акциями, добавление товаров. Задача агента при этом может быть куда скромнее - например, формировать утреннюю сводку по продажам. Но если в обрабатываемых данных окажется скрытая инструкция - в описании товара, в тексте отзыва, в теле письма - модель может её выполнить. Это называется промпт-инъекцией, и она работает именно потому, что языковая модель не умеет надёжно разграничивать «данные, которые нужно обработать» и «команды, которым нужно следовать».

Если при этом агент имеет права на запись, последствия выходят за рамки испорченного отчёта: изменённые цены, товары, добавленные в акции без ведома продавца, отправленные сообщения. Чем шире права - тем выше цена ошибки или атаки. Именно поэтому вопрос «какие права нужны агенту» должен предшествовать вопросу «как подключить агента».

Отдельная проблема - общие сервисные аккаунты. Когда несколько агентов или сотрудников используют один токен, журнал действий теряет смысл: непонятно, кто именно и зачем выполнил конкретную операцию. При инциденте это делает расследование практически невозможным.

Практический вывод здесь простой: у каждого агента должна быть собственная идентичность, привязанная к конкретной задаче и ограниченная по сроку действия. Не токен пользователя, переданный агенту, а производная от пользовательской сессии с явно заданными границами.

Как устроены права на трёх основных маркетплейсах

Прежде чем выдавать токен, стоит разобраться, что именно он открывает на каждой площадке - потому что логика везде своя.

Ozon

На Ozon права задаются ролями API-ключа. Для задач чтения - аналитики, мониторинга заказов, формирования отчётов - достаточно роли с доступом только на чтение. Изменение цен входит в роль Product. Фактический набор ролей конкретного ключа можно проверить через метод /v1/roles - это стоит делать перед подключением любого агента, а не полагаться на то, что написано в интерфейсе.

Wildberries

На WB важно понимать разницу между типами токенов. Базовый токен позволяет вручную выбрать нужные группы прав. Сервисный токен настраивается автоматически под конкретный сценарий. Персональный токен - отдельная история: его нельзя передавать третьим лицам и использовать в облачных сервисах. Если агент работает в облаке, персональный токен для этого не подходит.

Права записи в разделе «Цены и скидки» на WB - это не только изменение цен. Они также включают управление скидками и добавление товаров в акции. Это значит, что агент с такими правами может влиять на участие в промо - даже если задача была только скорректировать цену.

Яндекс Маркет

На Яндекс Маркете группа разрешений pricing охватывает сразу несколько связанных функций: цены, акции, буст продаж и ставки. Выдавая эту группу агенту, который должен только читать данные о ценах, вы фактически открываете ему доступ к рекламным инструментам. Это типичный пример, когда структура прав площадки не совпадает с логикой задачи агента.

Во всех трёх случаях метод HTTP-запроса сам по себе не определяет уровень риска. POST-запрос может быть безопасным чтением с фильтрами, а GET - триггером для цепочки действий. Важны назначение метода и группа разрешений, к которой он относится.

Три уровня защиты, которые нужны одновременно

Большинство интеграций останавливаются на первом уровне - аутентификации. Токен есть, запросы проходят, агент работает. Но реальные инциденты чаще происходят там, где аутентификация настроена правильно, а следующие два уровня отсутствуют.

Первый уровень - аутентификация: кто именно обращается к сервису. Токен или ключ подтверждает, что запрос пришёл от конкретного агента, а не от постороннего.

Второй уровень - области действия токена: какую категорию операций он вообще допускает. Это то, что настраивается при создании ключа - роли на Ozon, группы прав на WB, группы разрешений на Яндекс Маркете.

Третий уровень - проверка конкретной операции: разрешён ли именно этот вызов с именно этими аргументами в текущем контексте. Например, агент имеет право менять цены, но только в заданном диапазоне, только для определённых SKU и только после подтверждения продавца. Этот уровень реализуется не на стороне маркетплейса, а в логике самого приложения или оркестратора.

Если третий уровень отсутствует, агент с правами на запись цен технически может установить цену в 1 рубль - и маркетплейс это примет, потому что токен валидный и права есть. Ограничение должно быть в вашей системе, не в API площадки.

Для автоматической записи минимальный набор защит выглядит так:

• ограничение списка товаров, которыми агент вправе управлять;
• минимальная допустимая цена как жёсткий порог;
• подтверждение продавца для изменений выше заданного порога;
• журнал всех изменений с возможностью отката.

Что спросить перед подключением агента

Если вы подключаете готового агента или сервис автоматизации, до передачи токена стоит получить ответы на конкретный список вопросов. Это не паранойя - это стандартная практика, которую рекомендует OWASP в своём перечне угроз для агентных приложений.

Что запросить у поставщика или зафиксировать самостоятельно:

• Полный список данных, к которым агент запрашивает доступ, и методов, которые он вызывает.
• Список магазинов и товаров, которые агент вправе затрагивать.
• Правила подтверждения: какие действия требуют явного согласия продавца, а какие выполняются автоматически.
• Механизм аудита: где хранится журнал действий, кто имеет к нему доступ, как долго он хранится.
• Процедура восстановления: что происходит при ошибке агента, как откатить изменения.
• Правила хранения токена: где он хранится, кто имеет к нему доступ, как он отзывается при необходимости.

Если на эти вопросы нет чётких ответов - это сигнал, что архитектура безопасности не проработана. Агент с широкими правами и без журнала действий - это риск, который сложно оценить заранее и дорого устранять после инцидента.

Среда выполнения: изоляция и контроль

Помимо прав доступа к API маркетплейсов, важна среда, в которой работает агент. Если агент имеет доступ к почте, файловой системе, CRM или внешним API одновременно с доступом к маркетплейсам, успешная атака через один канал может распространиться на остальные.

Принцип изоляции инструментов означает, что каждый инструмент агента должен быть доступен только тогда, когда он нужен для текущей задачи, и только с теми параметрами, которые эта задача предполагает. Агент, формирующий отчёт по ценам, не должен иметь активного доступа к инструменту отправки сообщений покупателям - даже если технически этот инструмент есть в системе.

Отдельного внимания заслуживает память агента. Если агент использует долгосрочную память или RAG (поиск по базе знаний), важно контролировать, что туда попадает. Скомпрометированные данные в памяти могут влиять на поведение агента в будущих сессиях - это называется отравлением памяти. Для защиты нужны проверка источников данных, ограничение срока хранения и контроль целостности.

Телеметрия и журналы вызовов инструментов - не опциональная функция, а базовое требование. Без них невозможно ни расследовать инцидент, ни убедиться, что агент действует в рамках заданных ограничений. Хороший журнал фиксирует не только факт вызова, но и аргументы, контекст задачи и идентификатор агента.

Человеческий контроль: где он нужен, а где мешает

Одна из типичных ошибок при проектировании агентных систем - либо полное отсутствие человеческого подтверждения, либо его избыток. Если агент запрашивает подтверждение на каждое действие, оператор начинает кликать «ОК» автоматически, не читая. Это называется перегрузкой запросами на подтверждение, и она делает контроль номинальным.

Практический подход: подтверждение нужно для действий, которые необратимы или имеют высокую цену ошибки. Изменение цены на 5% в рамках заданного диапазона - можно автоматически. Массовое изменение цен на весь каталог, добавление товаров в акцию, отправка сообщений покупателям - требуют явного согласия.

Для агентов, работающих с репутацией бренда на маркетплейсах - например, генерирующих ответы на отзывы - граница между автоматическим и подтверждаемым действием особенно важна. Ответ на нейтральный отзыв можно публиковать автоматически, если он прошёл проверку на соответствие tone of voice. Ответ на негативный отзыв с конкретной претензией лучше показать модератору перед публикацией. Сервисы вроде SaleSynergy строят именно такую логику: автоответы на отзывы работают в рамках заданных правил, а спорные случаи уходят на ручную проверку.

Как применить это на практике прямо сейчас

Если вы уже используете агента или планируете подключить - вот конкретные шаги, которые снижают риски без остановки работы.

1. Проверьте текущие права токенов. На Ozon - через /v1/roles. На WB - в настройках токена в личном кабинете. Убедитесь, что агент имеет только те права, которые нужны для его фактических задач. Если агент только читает данные - права на запись должны быть отключены.
2. Разделите токены по задачам. Агент для аналитики и агент для управления ценами должны использовать разные ключи с разными правами. Это позволяет отозвать доступ одного агента, не затрагивая другого.
3. Составьте реестр действий агента. Зафиксируйте: какие данные читает, какие методы вызывает, какие товары затрагивает, какие действия выполняет автоматически, а какие требуют подтверждения. Этот документ нужен и для аудита, и для онбординга новых сотрудников.
4. Настройте журналирование. Каждое действие агента должно быть записано с аргументами и контекстом. Если ваш инструмент автоматизации не предоставляет такого журнала - это повод пересмотреть выбор инструмента.
5. Определите пороги для подтверждения. Для изменения цен: минимальная цена как жёсткий порог, максимальное изменение за одну операцию, список товаров, которые агент вправе трогать. Для других действий - аналогичная логика.
6. Проверьте правила хранения токена. Персональный токен WB нельзя использовать в облачных сервисах. Если агент работает в облаке - убедитесь, что используется подходящий тип токена и он хранится в защищённом хранилище, а не в переменных окружения или конфигурационных файлах репозитория.
7. Запланируйте регулярный аудит. Права и задачи агентов меняются со временем. Раз в квартал стоит проверять, соответствуют ли выданные права актуальным задачам, и отзывать лишнее. Это занимает меньше времени, чем разбор инцидента.