Безопасно ли давать AI доступ к Метрике и Search Console

Вопрос звучит примерно так: «Я готов попробовать AI для аналитики, но отдавать доступ к Метрике и Search Console как-то боязно». Опасение здравое — только направлено обычно не туда. Разберём, что при таком подключении происходит на самом деле.

Три реальных риска и один выдуманный

Начнём с того, чего бояться не стоит.

Выдуманный риск: «AI что-нибудь сломает». Модель не выполняет команды в вашем аккаунте. Она вызывает заранее описанные инструменты с фиксированным набором параметров — примерно как нажимает кнопки в готовом интерфейсе. Если среди инструментов нет «удалить счётчик», модель его не удалит, даже если очень захочет или если её об этом попросят в промпте.

Теперь то, о чём думать действительно стоит.

Риск 1: избыточные права. Сервис-посредник может запросить у Яндекса или Google больше прав, чем ему нужно для работы. Это не гипотетическая проблема: разница между «читать статистику» и «управлять аккаунтом» — один параметр в запросе авторизации.

Риск 2: утечка ключа. API-ключ — это доступ ко всем вашим данным. Если он лежит в адресе страницы, в скриншоте инструкции или в открытом репозитории, им может воспользоваться кто угодно.

Риск 3: данные в чужой переписке. Выгрузка попадает в контекст диалога с ChatGPT или Claude. Дальше вопрос уже не к посреднику, а к политике провайдера и настройкам вашего тарифа.

Дальше по каждому из трёх — что конкретно проверять.

Что видит модель, когда вы задаёте вопрос

Цепочка выглядит так: вы пишете вопрос → AI-клиент решает, какой инструмент вызвать → посредник идёт в API Метрики или Search Console → возвращает ответ → модель формулирует текст.

В контекст модели попадает то, что вернул API: агрегированные цифры по страницам, запросам, устройствам, регионам. Персональных данных посетителей там нет — ни Метрика, ни Search Console их в отчётах не отдают.

Что важно понимать: модель видит ровно тот срез, который был нужен для ответа. Вопрос про отказы за неделю не выгружает всю историю счётчика.

Read-only: почему AI не изменит настройки

Права доступа определяются на этапе авторизации, и это самое проверяемое место.

У Seely доступ к Google запрашивается с двумя правами: webmasters.readonly и analytics.readonly. Суффикс readonly — не обещание в тексте оферты, а технический запрет на стороне Google: запрос на изменение с таким токеном не пройдёт.

Проверить это можно самостоятельно. На экране согласия Google перечисляет, что именно разрешает приложение. Если там формулировка «просмотр данных» — это чтение. Если «управление» — стоит остановиться и разобраться зачем.

Единственное write-действие и его границы

Честно про исключение: одно действие с записью в связке всё-таки есть — отправка страниц на переобход в Яндекс Вебмастере (инструмент queue_webm_recrawl).

Что он делает: ставит указанный URL в очередь на повторный обход роботом. Ровно то же самое, что кнопка «Переобход страниц» в интерфейсе Вебмастера.

Что он не делает: не меняет контент страницы, не влияет на индексацию напрямую, не может ничего удалить. У операции есть суточная квота от самого Яндекса, поэтому даже при желании ассистент не сможет заспамить очередь.

Запускается инструмент только тогда, когда вы прямо просите: «отправь эти страницы на переобход». Сам по себе, в ответ на вопрос про трафик, он не сработает.

Мы специально проговариваем это в статье про безопасность. Сервис, который обещает «только чтение» и умалчивает про исключение, вызывает больше вопросов, чем тот, который исключение называет.

OAuth 2.1 против ключа в адресе

Раньше подключение к части клиентов выглядело так: ключ вставлялся прямо в адрес сервера, вида .../api/mcp?token=yamcp_.... Работало, но с двумя неприятными свойствами.

Первое: адрес с ключом остаётся везде. В истории браузера, в скриншоте инструкции, в логах прокси, в поле настроек коннектора, откуда его видно каждому, у кого есть доступ к экрану.

Второе: отозвать такой доступ можно только перевыпуском ключа. А ключ один на все клиенты — значит, отключив один, вы отключаете все.

При подключении через OAuth клиент вообще не получает ваш ключ. Он проводит вас через вход, получает собственные токены доступа, которые живут час и обновляются автоматически. Если приложение больше не нужно — вы отзываете доступ именно у него, остальные продолжают работать.

Практический вывод простой: если ваш клиент поддерживает OAuth (claude.ai и ChatGPT поддерживают), используйте его. Ключ оставьте для клиентов, где выбора нет.

Что остаётся на сервере и что не сохраняется

Посредник по определению видит запросы и ответы — иначе он не смог бы их передать. Значимо другое: что из этого записывается на диск.

У Seely данные аналитики не сохраняются: запрос проксируется в API и ответ уходит клиенту. В базу пишется только служебная запись о вызове — идентификатор пользователя, название инструмента, успешно или с ошибкой, код ответа и длительность в миллисекундах. Ни цифр, ни адресов страниц, ни текста вопроса там нет.

Сам API-ключ в базе тоже не лежит в открытом виде: хранится его HMAC-SHA256-хеш, а сравнение идёт способом, устойчивым к подбору по времени ответа. Даже при доступе к базе восстановить ключ из хеша нельзя.

Это тот тип утверждений, который стоит проверять у любого сервиса, а не принимать на слово.

Разграничение: только выбранные счётчики и сайты

Даже корректно выданный read-only доступ покрывает все счётчики вашего аккаунта. Если вы ведёте десять проектов, а показать AI хотите один, нужен второй уровень разграничения.

В Seely он реализован на стороне сервера: в кабинете вы отмечаете конкретные счётчики Метрики, сайты Вебмастера, ресурсы Search Console и GA4. Запрос к неотмеченному счётчику не выполнится — проверка стоит до обращения к API, а не в описании инструмента.

Разница принципиальная. Ограничение, записанное в описании инструмента, модель может проигнорировать. Ограничение на стороне сервера — нет.

Как отозвать доступ

Тут два независимых уровня, их часто путают.

Доступ AI-клиента к Seely. В кабинете блок «Подключённые приложения» показывает всех, кто подключился через OAuth. Кнопка «Отозвать» срабатывает мгновенно: следующий запрос клиента получит 401. Для подключений по ключу отдельного списка нет — там отзыв означает перевыпуск ключа.

Доступ Seely к вашим данным. Отзывается на стороне провайдера: в настройках безопасности Яндекс ID и в разделе «Сторонние приложения» аккаунта Google. После этого сервис перестаёт получать данные независимо от того, что происходит на его стороне.

Второй уровень — тот самый рубильник, который стоит знать заранее. Он работает, даже если сервис недоступен или вы забыли пароль от кабинета.

Обучаются ли ChatGPT и Claude на ваших данных

По умолчанию — нет. И OpenAI, и Anthropic заявляют, что не используют для обучения моделей данные, приходящие через API и через бизнес-тарифы.

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

Отдельно стоит помнить, что политики провайдеров меняются. Формулировка, актуальная сегодня, может отличаться через год — это причина сверяться с первоисточником, а не с чужой статьёй.

Чек-лист перед подключением любого MCP-сервера

Список применим не только к Seely — по нему стоит проверять любой сервис, который просит доступ к вашей аналитике.

• Какие права запрашиваются. Прочитайте экран согласия целиком. «Просмотр» и «управление» — разные вещи.
• Есть ли write-действия. Если сервис заявляет «только чтение», спросите, есть ли исключения. Молчание в ответ — плохой знак.
• Можно ли ограничить источники. Возможность выбрать конкретные счётчики важнее, чем красивое описание безопасности.
• Где живёт ключ. Если единственный способ подключения — ключ в адресе, это минус.
• Как отзывается доступ. Проверьте, что кнопка существует, до того как она понадобится.
• Что сохраняется на сервере. Метаданные вызовов — нормально. Сохранение самих выгрузок требует объяснения.
• Что говорит провайдер AI. Настройки обучения на переписке — на вашей стороне, не на стороне посредника.

Если данные клиентские

Для агентств и фрилансеров вопрос стоит острее: вы отдаёте доступ не к своим данным.

Практический минимум: предупредите клиента письменно, что подключаете сторонний сервис к его аналитике на чтение, назовите сервис и объясните, зачем. Зафиксируйте, что доступ отзывается в любой момент и как именно. Если у клиента есть требования по обработке данных, сверьтесь с ними до подключения, а не после.

Хорошая новость в том, что в отчётах Метрики, Вебмастера, Search Console и GA4 нет персональных данных посетителей — только агрегированная статистика. Это заметно упрощает разговор.

Короткий вывод

Подключение AI к аналитике безопасно ровно настолько, насколько аккуратно выданы права. Read-only scope, разграничение по конкретным счётчикам, OAuth вместо ключа в адресе и работающая кнопка отзыва закрывают все три реальных риска.

Что делать дальше: пройдите чек-лист выше по тому сервису, который рассматриваете. Если ответы вас устроили — подключайте, пошаговая инструкция здесь. Если на каком-то пункте ответа нет — это и есть повод не торопиться.