MCP-сервер для бизнеса — это точка входа, через которую ИИ-агенты клиентов (ChatGPT, Claude и другие) обращаются к сервисам компании: ищут товары, проверяют наличие, смотрят историю заказов. Публичный сервер без входа отдаёт всем одинаковый обезличенный ответ. Чтобы агент работал с данными конкретного клиента, нужна авторизация: по спецификации MCP это OAuth 2.1 — агент получает собственный токен, человек сам выбирает разрешения и может отозвать доступ, а сервер проверяет права при каждом вызове. Так в октябре 2026 года сделал «ВкусВилл».
Материал подготовлен AIrassvet 16 октября 2026 года по статье «ВкусВилла» в блоге компании на Хабре, новости CNews от 15 октября 2026 года, а также по разделам авторизации и безопасности актуальной спецификации Model Context Protocol (версия 2026-07-28). Он адресован владельцам цифровых продуктов, руководителям e-commerce и ИТ-директорам, которые решают, открывать ли свои сервисы ИИ-агентам клиентов и как сделать это безопасно. Мы не тестировали MCP-сервер «ВкусВилла» и не измеряли его эффект: схема внедрения, таблицы и чек-лист — методика редакции. AIrassvet не аффилирован с «ВкусВиллом», CNews и разработчиками MCP; раздел в конце статьи описывает услуги издателя.
Содержание
- Кратко
- Что изменилось у «ВкусВилла»
- Зачем бизнесу MCP-сервер и когда хватит публичного
- Как устроен доступ по OAuth
- Что требует спецификация MCP
- Как спроектировать разрешения
- Риски и как их закрыть
- План запуска по этапам
- Частые вопросы
- Первоисточники и метод проверки
Кратко
- Клиенты уже приходят с агентами. «ВкусВилл» запустил публичный MCP-сервер в декабре 2025 года, а 15 октября 2026 года добавил авторизацию: теперь агент с разрешения покупателя видит каталог для его адреса, историю онлайн-заказов, любимый продукт и персональные скидки.
- Публичного сервера мало, когда ответ зависит от клиента. Агент «ВкусВилла» искал по всему каталогу, и часть найденных товаров оказывалась недоступна к заказу из магазина или даркстора, из которого будет доставка.
- Стандарт авторизации уже определён. Спецификация MCP строит доступ на OAuth 2.1: сервер — это сервер ресурсов, агент — клиент, а токен выдаётся под конкретный сервер и конкретные разрешения.
- Главное решение — набор разрешений. Узкие права на чтение, отдельные права на персональные данные и отдельные — на действия вроде заказа снижают ущерб при утечке токена.
- Запускать стоит поэтапно: публичный каталог → чтение персональных данных → действия с подтверждением человека.
Что изменилось у «ВкусВилла»
Первую версию публичного MCP-сервера «ВкусВилл» выпустил в декабре 2025 года как эксперимент для разработчиков и пользователей ИИ-агентов. Сервер умел искать товары по каталогу, показывать состав и КБЖУ и собирать ссылку на готовую корзину; позже появились поиск рецептов, поиск по штрихкоду и подбор аналогов (CNews, 15.10.2026).
Главную проблему компания описывает прямо: поиск в публичном сервере шёл по всему каталогу, а на сайте покупатель видит ассортимент магазина, из которого ему привезут заказ. Передавать магазин параметром не получилось — для некоторых адресов доставка возможна из нескольких дарксторов, и итоговый определяет алгоритм. К тому же без входа агенту недоступны персонализация и программа лояльности (блог «ВкусВилла» на Хабре).
Решение — доступ в личный кабинет по OAuth 2.0 с PKCE. Компания сформулировала четыре требования информационной безопасности:
- агент входит под своими учётными данными, а не под логином и паролем покупателя;
- агент не получает доступ к персональным данным клиента сверх разрешённого;
- человек сам выбирает, что готов делегировать агенту;
- человек может отозвать доступ.
После авторизации агенту доступны четыре возможности: поиск по каталогу для адреса пользователя с учётом наличия в реальном времени, история онлайн-заказов, любимый продукт и персональные скидки; разрешения сервер проверяет при каждом обращении. По словам компании, с января по сентябрь 2026 года среднее ежедневное количество заказов, связанных с MCP-сервером, выросло более чем в пять раз (CNews) — это данные самого «ВкусВилла», абсолютные значения не раскрыты.
Зачем бизнесу MCP-сервер и когда хватит публичного
MCP (Model Context Protocol) — открытый протокол, по которому ИИ-агент получает доступ к внешним инструментам и данным. Для компании MCP-сервер — это «витрина для агентов»: тот же каталог, запись или личный кабинет, но в виде функций, которые агент может вызвать.
Агентный канал не заменяет сайт и приложение: это дополнительный вход для клиентов, которые уже поручают задачи ассистенту. Что выбрать на старте, зависит от того, меняется ли ответ от клиента к клиенту.
| Сценарий | Публичный сервер без входа | Сервер с авторизацией |
|---|---|---|
| Каталог, описания, цены для всех | Достаточно | Не нужен |
| Наличие и ассортимент по адресу клиента | Неточно: агент не знает точку доставки | Нужен |
| История заказов, лояльность, скидки | Недоступно | Нужен, с отдельными разрешениями |
| Оформление заказа, запись, оплата | Только ссылка на корзину для человека | Нужен, плюс подтверждение человеком |
| Внутренние данные компании | Нельзя | Только для сотрудников, через корпоративный вход |
Публичного сервера хватает, если агенту нужно найти и сравнить: справочники, каталог, расписание. Авторизация становится нужна, когда ответ зависит от конкретного человека или агент должен что-то сделать от его имени. Начинать с публичного варианта разумно: «ВкусВилл» почти год собирал обратную связь, прежде чем добавить вход.
Подробнее о том, как подключать сторонние MCP-серверы к своим агентам, мы писали в разборе MCP-сервера 2ГИС, а о подготовке интернет-магазина к агентам — в статье про умный поиск для интернет-магазина.
Как устроен доступ по OAuth
OAuth — стандарт делегированного доступа: человек разрешает приложению действовать от своего имени в пределах выбранных прав, не передавая ему пароль. В MCP роль приложения играет агент.
На примере «ВкусВилла» процесс выглядит так (блог компании):
- Регистрация клиента. Пользователь регистрирует OAuth-клиента и указывает адрес возврата (redirect URI) своей агентной платформы — у Claude.ai это
https://claude.ai/api/mcp/auth_callback, у ChatGPT адрес берётся из окна создания плагина. Сейчас можно создать только персонального агента, привязанного к карте лояльности владельца; клиентов для нескольких людей и партнёрскую программу компания обещает позже. - Передача учётных данных агенту. Идентификатор и секрет приходят на почту. Компания отдельно предупреждает: не вставлять их в чат с агентом и не передавать в недоверенные сервисы. В том же письме — ссылка для отзыва доступа; сейчас удаление занимает до 24 часов.
- Согласие человека. При первом обращении агент формирует ссылку, человек проходит по ней и отмечает, какие действия и данные доступны агенту (scopes).
- Токен. Временный код агент обменивает на JWT-токен доступа со сроком жизни 24 часа; после этого авторизацию нужно пройти снова. Автоматическое обновление токена, мгновенный отзыв и панель управления доступами в планах компании.
PKCE — дополнение к OAuth, которое не даёт перехватчику обменять украденный код авторизации на токен: клиент доказывает, что именно он начинал вход.
Короткий срок жизни токена и обязательный повторный вход неудобны, но ограничивают ущерб: украденный токен перестаёт работать через сутки.
Что требует спецификация MCP
Спецификация MCP (версия 2026-07-28) описывает авторизацию для серверов, доступных по HTTP. Ключевые требования (раздел Authorization):
| Требование | Что это значит для компании |
|---|---|
| Сервер MCP — сервер ресурсов OAuth 2.1 | Выдачей токенов занимается сервер авторизации — ваш или существующий корпоративный, а MCP-сервер их проверяет |
Клиент обязан указывать параметр resource (RFC 8707) |
Токен выпускается под конкретный MCP-сервер, а не «на всё» |
| Сервер обязан проверять, что токен выпущен именно для него | Чужой токен, даже валидный, нужно отклонять |
| Неверный или просроченный токен — ответ 401 | Агент понимает, что нужен повторный вход |
| Недостаточно прав — ответ 403 с нужными scopes | Агент может запросить дополнительное разрешение у человека |
| Регистрация клиентов: метаданные клиента (Client ID Metadata Documents) рекомендованы, динамическая регистрация допускается, но помечена устаревшей | Заранее решите, как агентные платформы будут регистрироваться у вас |
| Минимальные права при выборе scopes | Агент запрашивает только то, что нужно для задачи |
Отдельный документ о безопасности (Security Best Practices) называет антипаттерн «проброс токена» (token passthrough): MCP-сервер принимает токен, не проверив, кому он выдан, и пересылает его во внутренние API. Спецификация прямо запрещает серверу принимать токены, выпущенные не для него. Для серверов-посредников, которые обращаются к сторонним API, требуется согласие для каждого клиента, а экран согласия должен показывать имя клиента, запрашиваемые права и адрес возврата.
Как спроектировать разрешения
Набор разрешений — это то, что человек увидит на экране согласия и что определит ущерб при утечке токена. В документе о безопасности MCP широкие права вроде files:* или db:* приводятся как пример плохого дизайна: они увеличивают последствия компрометации токена и запутывают журнал аудита.
Практическая схема для клиентского сервиса (методика редакции):
| Группа | Пример разрешения | Риск при утечке | Подтверждение человеком |
|---|---|---|---|
| Каталог по адресу | catalog:read |
Низкий | Не нужно |
| История заказов | orders:read |
Средний: персональные данные | Один раз при согласии |
| Лояльность и скидки | loyalty:read |
Средний | Один раз при согласии |
| Корзина | cart:write |
Средний | Желательно перед оплатой |
| Заказ и оплата | orders:create |
Высокий | Для каждого заказа |
| Изменение профиля, адреса, телефона | profile:write |
Высокий | Не выдавать агентам на старте |
Чек-лист перед запуском:
- Каждый инструмент MCP-сервера связан с одним разрешением; инструменты на чтение и запись разделены.
- Агент получает только данные, нужные для задачи: например, историю заказов без телефона и адреса, если они не требуются.
- Срок жизни токена определён и соответствует риску; есть отзыв доступа, и сроки отзыва честно указаны пользователю.
- Сервер проверяет аудиторию токена и права при каждом вызове.
- Учётные данные клиента выдаются по защищённому каналу, а пользователь предупреждён не передавать их в чат.
- Каждый вызов журналируется с идентификатором клиента и пользователя.
- Действия с деньгами и необратимые операции требуют подтверждения человеком вне агента.
Риски и как их закрыть
Авторизация решает вопрос «кто и на что имеет право», но не делает агента безопасным сама по себе.
| Риск | Как проявляется | Что делать |
|---|---|---|
| Избыточные полномочия (OWASP LLM06) | Агенту выдали больше функций и прав, чем нужно задаче | Узкие scopes, отдельные инструменты на чтение и запись, подтверждение рискованных действий |
| Проброс токена | Сервер передаёт токен клиента во внутренние API | Проверять аудиторию; во внутренние системы ходить своим служебным доступом |
| «Запутанный заместитель» (confused deputy) | Сервер-посредник с одним статическим клиентом позволяет получить код авторизации без согласия пользователя | Согласие для каждого клиента, защищённый экран согласия |
| Утечка учётных данных | Пользователь вставил секрет клиента в чат с агентом | Предупреждения, короткий срок жизни токена, быстрый отзыв |
| Промпт-инъекция через данные | Текст из отзывов, описаний товаров или заметок попадает агенту как инструкция | Возвращать агенту данные, а не команды; не давать инструментам опасных действий без подтверждения |
Категорию избыточных полномочий OWASP описывает в Top 10 для LLM-приложений 2025 года (LLM06 Excessive Agency). Подробнее о границах автономности — в статье «Управление автономностью ИИ-агентов», о защите на уровне шлюза — в разборе LLM-файрвола.
План запуска по этапам
Методика редакции; сроки зависят от готовности API и сервера авторизации компании.
- Инвентаризация. Выпишите 3–5 задач, которые клиенты уже пытаются поручать ассистентам: найти товар, проверить статус заказа, записаться. Для каждой определите данные и системы-источники.
- Публичный сервер. Откройте только общедоступные данные: каталог, справочники, расписание. Соберите журнал вызовов и обратную связь — какие инструменты нужны и где агенту не хватает контекста.
- Авторизация на чтение. Подключите сервер авторизации, выделите разрешения на чтение персональных данных, ограничьте срок жизни токена, сделайте отзыв доступа.
- Действия с подтверждением. Добавляйте корзину, заказ или запись только с подтверждением человеком и журналом действий.
- Метрики. Отслеживайте долю успешных вызовов, ошибки 401/403, отзывы доступа, жалобы и заказы, пришедшие через агентный канал. Чтобы увидеть эффект, сравнивайте с базовым уровнем до запуска.
Частые вопросы
Что такое MCP-сервер для бизнеса?
Это сервис, через который ИИ-агенты клиентов вызывают функции компании по открытому протоколу Model Context Protocol: ищут товары, проверяют наличие, смотрят заказы. Он работает как витрина для агентов рядом с сайтом и приложением.
Зачем MCP-серверу авторизация?
Без входа сервер отвечает всем одинаково и не знает адрес, историю и скидки клиента. Авторизация по OAuth позволяет агенту работать с данными конкретного человека в пределах прав, которые тот выбрал, и даёт возможность отозвать доступ.
Какой стандарт авторизации требует спецификация MCP?
OAuth 2.1. MCP-сервер выступает сервером ресурсов, агент — клиентом. Токен выдаётся под конкретный сервер (параметр resource по RFC 8707), а сервер обязан проверять, что токен выпущен именно для него.
Получает ли агент пароль клиента?
Нет. Агент входит под своими учётными данными клиента OAuth, а человек на отдельной странице подтверждает, какие данные и действия доступны. Пароль от личного кабинета агенту не передаётся.
Можно ли разрешить агенту оформлять заказы?
Технически да, но это действие высокого риска. Разумно начинать с разрешений на чтение, а заказ и оплату выдавать отдельным разрешением и подтверждать каждую операцию человеком.
С чего начать компании?
С публичного сервера на общедоступных данных и журнала вызовов. Когда станет понятно, каких данных агентам не хватает, добавляйте авторизацию на чтение, а затем действия с подтверждением.
Первоисточники и метод проверки
Метод: 16 октября 2026 года мы прочитали статью «ВкусВилла» на Хабре и новость CNews, выписали требования, шаги авторизации и список новых возможностей, сверили требования к OAuth с актуальной спецификацией MCP 2026-07-28 и документом о безопасности, а категории рисков — с OWASP. Собственных испытаний MCP-сервера «ВкусВилла» AIrassvet не проводил; таблицы разрешений, рисков, чек-лист и план запуска — методика редакции.
- Хабр, блог «ВкусВилла», 15.10.2026: «ВкусВилл приготовил MCP-сервер с авторизацией» — требования, шаги OAuth 2.0 + PKCE, срок жизни токена, планы.
- CNews, 15.10.2026: «ВкусВилл» обновил MCP-сервер — история сервера, четыре новые возможности, рост заказов по данным компании, комментарий продакта.
- Model Context Protocol: Authorization, версия 2026-07-28 и Security Best Practices.
- OWASP: LLM06:2025 Excessive Agency.
Ограничения: рост заказов в пять раз — заявление «ВкусВилла» без абсолютных значений и методики; функции сервера могут меняться, актуальное описание публикуется на странице сервера. Спецификация MCP регулярно обновляется — сверяйте требования с действующей версией.
Как AIrassvet помогает открыть сервисы компании ИИ-агентам клиентов
MCP-сервер — это интеграция с вашими системами: каталогом, CRM, учётом заказов, программой лояльности. На сайте AIrassvet описаны направления, которые относятся к этой задаче напрямую:
- аудит процессов и подготовка данных: какие задачи клиенты поручают агентам, какие данные для них нужны и какие из них персональные;
- разработка ИИ-агентов и интеграций с каналами связи и бизнес-системами — включая инструменты, через которые внешние агенты получают доступ к сервисам;
- автоматизация действий в интерфейсах ERP, 1С и браузера там, где у системы нет готового API;
- интеграция, тестирование и поддержка после запуска: сценарии вызовов, проверка прав и журналирование.
Первый шаг — выбрать одну клиентскую задачу, описать текущий путь клиента, системы-источники данных, ограничения по безопасности и критерий, по которому запуск агентного канала будет считаться успешным.
Итог: агентный канал начинается с прав доступа
Пример «ВкусВилла» показывает, как развивается агентный канал: сначала публичный каталог, затем вход по OAuth, при котором человек выбирает разрешения, токен живёт сутки, а сервер проверяет права при каждом вызове. Спецификация MCP уже задаёт эту рамку: OAuth 2.1, токен под конкретный сервер, запрет на проброс чужих токенов.
Компании, которая хочет принимать клиентов с ИИ-агентами, не нужно сразу открывать заказы и оплату. Достаточно начать с публичных данных, затем добавить узкие разрешения на чтение, а действия выдавать только с подтверждением человека.
