MCP-серверы Cursor перед выдачей ключей агенту

После того как в Cursor подключён MCP-сервер, агент перестаёт быть источником текста и становится исполняющим процессом. Официальный гайд по безопасности MCP формулирует это жёстко: локальный сервер работает с теми же привилегиями, что и клиент, поэтому переприлегированный сервер или вредоносная команда запуска способны вытащить файл вроде ~/.ssh/id_rsa (по MCP security best-practices, 2026-07-18).

Отсюда рабочий тезис, который можно проверить и опровергнуть: если MCP-сервер использует неотделимый или более широкий, чем задача, секрет, конфигурация не соответствует минимальным правам. Проверяют это не «в целом по IDE», а по каждому серверу отдельно: какой ключ он держит, какое право этот ключ несёт, кто владелец и куда уходят данные.

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

Подключите AI-агентов с оплатой в рублях на provod.ai

Где Cursor хранит конфигурацию и как передать секрет

Cursor читает определения MCP из двух областей: проектной .cursor/mcp.json и глобальной ~/.cursor/mcp.json. Когда сервер описан в обеих, побеждает проектное определение (по docs Cursor, 2026-07-18). Именно про эту механику спрашивают, когда ищут «mcp сервера cursor»: где физически лежит настройка и что перекрывает что. Практический вывод: узкий сервер, привязанный к репозиторию, может переопределить более широкий глобальный, и это работает в пользу безопасности, если проектная версия строже.

Секреты Cursor советует не хардкодить в mcp.json никогда. Поддерживаемые способы передать секрет: интерполяция переменной окружения ("${env:VAR}"), отдельный .envFile для stdio-серверов, заголовок вида Authorization: Bearer ${env:TOKEN} для удалённых серверов и статические OAuth-креды. Там же прямая рекомендация — использовать «restricted API keys with minimal required permissions», ограниченные ключи с минимально необходимыми правами. Тот же вопрос, «как подключить mcp к cursor», на уровне файлов сводится именно к этому: не к тому, что вставить в конфиг, а к тому, каким способом передать секрет так, чтобы он не уехал в git текстом.

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

Allowlist — это фильтр по умолчанию, а не граница принуждения

По умолчанию Cursor спрашивает подтверждение перед запуском любого MCP-инструмента. Более тонкий контроль даёт permissions.json: пользовательский ~/.cursor/permissions.json и репозиторный <workspace>/.cursor/permissions.json. Allowlist задаётся записями вида server:tool и поддерживает шаблоны, например my-server:* или *:tool. Приоритет такой: настройки в дашборде админа команды перекрывают permissions.json, а тот перекрывает настройки IDE (по docs Cursor, 2026-07-18).

Здесь легко обмануться. Документация Cursor по разрешениям прямо называет allowlist и правила autoRun «best-effort convenience» и «not a security guarantee». Решительный агент или атака через prompt-injection способны их обойти. Allowlist сужает поверхность, но не является границей принуждения, и относиться к нему как к последней линии обороны нельзя.

Минимальный проектный конфиг, каким он документирован на момент написания, выглядит так:

{ "mcpServers": { "github": { "command": "github-mcp-server", "args": ["--read-only", "--toolsets", "repos,issues"], "env": { "GITHUB\_TOKEN": "${env:GITHUB\_MCP\_TOKEN}" } } } }

{ "mcp": { "allowlist": ["github:\*"] } }

Здесь github:* — документированный Cursor шаблон вида server:*, а не имя группы инструментов: набор, который агент реально увидит, уже сужен флагом --toolsets на уровне самого сервера, и allowlist лишь разрешает вызывать инструменты внутри этого суженного набора.

Матрица «MCP-сервер — ключ — право — владелец»

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

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

Верхняя строка опирается на подтверждённые возможности конкретного сервера. Две нижние — шаблоны, вердикт по ним выносит сам разработчик, источник его не подтверждает.

GitHub MCP-сервер: пример узкого ключа, а не общий стандарт

Официальный MCP-сервер GitHub — рабочий пример того самого разделения, которое требует матрица. Он поддерживает OAuth-логин (токен держится только в памяти), fine-grained PAT или классический PAT; флаг --read-only пропускает write-инструменты, даже если их явно запросили; флаги --toolsets/--tools открывают только выбранные группы инструментов — repos, issues, actions, code_security — вместо всей поверхности API. Документация GitHub советует выдавать только нужные права (repo, read:packages, read:org) и использовать отдельные токены на проект и окружение (по github/github-mcp-server, 2026-07-18).

Это пример одного сервера, а не общий закон: как Slack, Postgres или файловый сервер обходятся с кредами, проверяется отдельно, и токен-модель GitHub на них не переносится.

Спецификация MCP подтверждает это с другой стороны. Авторизация в протоколе опциональна; когда сервер её реализует, он выступает OAuth 2.1 resource server и обязан валидировать токены, но стандартных имён областей спецификация намеренно не задаёт — насколько узко можно ограничить ключ, решает автор конкретного сервера (по MCP authorization spec, 2026-07-18). Поэтому «универсального scope-стандарта MCP» не существует: repo или read:org — примеры GitHub, а не требование протокола.

Гайд по безопасности добавляет два правила. Сервер не должен принимать токены, выпущенные не для него: token passthrough запрещён. И отдельно — «scope minimization»: omnibus-области вроде files:*, db:*, admin:* раздувают радиус поражения и мешают отзыву, а рекомендуемый паттерн — прогрессивный least-privilege, минимальный read-only на старте и логируемое повышение только под конкретную привилегированную операцию (по MCP security best-practices, 2026-07-18).

Модельный ключ Cursor и ключ MCP-сервера — разные секреты

Когда разработчик ищет «cursor api ключ», он почти всегда имеет в виду ключ провайдера модели: тот, что вставляется в настройках AI-подключения, а не в mcp.json. И «cursor ai api» — это про то, какая модель отвечает в чате и автодополнении, а не про то, какой инструмент агент может дёрнуть через MCP.

Разделение важно, потому что это разные ключи с разным радиусом ущерба. Модельный ключ, если его скомпрометировать, стоит денег на токенах. MCP-ключ, если его скомпрометировать, даёт агенту write-доступ к инфраструктуре. Смешать их в одном секрете, положить оба рядом в один файл без разбора прав — ровно тот антипаттерн, который матрица выше должна ловить.

Что provod.ai упрощает, а что нет

Практический случай «как подключить claude к cursor» или «как подключить deepseek к cursor» решается сменой пары base_url и ключа в настройках модели, а не правкой mcp.json. Здесь эту половину задачи можно упростить: provod.ai даёт один API, совместимый с протоколом OpenAI, для каталога моделей, доступных на платформе. Клиент, который поддерживает этот протокол, подключается заменой base_url и ключа, а фактическая поддержка конкретных моделей и эндпоинтов остаётся в рамках текущего каталога provod.ai.

base\_url: https://api.provod.ai/v1

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

Когда ключ можно выдавать

Интеграция допускается, когда для каждого MCP-сервера выполнены все четыре условия; иначе конфигурацию нужно доработать до выдачи ключа.

Цена такого решения простая: выдать отдельные ограниченные секреты и проверить маршрут неудобнее, чем один широкий ключ на всё. Взамен получаешь ограниченный радиус ошибки агента. Альтернативы — общий ключ на все серверы или доступы агенту уровня пользователя — отклоняются, потому что каждая нарушает хотя бы один критерий из таблицы.

Где аудит заканчивается

Матрица и минимальные права сужают ущерб, но не заменяют защиту репозитория и не дают абсолютной безопасности. Allowlist Cursor остаётся best-effort и обходится prompt-injection: это ограничение самого механизма, а не аккуратности настройки. Enterprise-документация Cursor описывает Run Mode (Auto-review с LLM-классификатором, Allowlist, Run Everything) для терминала и инструментов, но отдельного механизма аудита того, какие секреты видит конкретный MCP-сервер, не даёт; тонкий контроль она предлагает через хуки и права файловой системы (по docs Cursor, 2026-07-18).

Полное поведение каждого сервера без конкретной проверки остаётся неизвестным, и это честная зона незнания, а не повод для допущений. Отдельные сценарии придётся разбирать вручную: связка «cursor mcp сервер и 1с», например, упирается в вопросы, которые источники здесь не покрывают, — как именно такой сервер держит креды и куда отправляет данные, проверяется на его собственной документации, а не по аналогии с GitHub. Речь также не про совместимость с OpenCode MCP: здесь разбор ограничен правами и ключами именно Cursor.

FAQ

Достаточно ли прописать allowlist, чтобы ограничить агента?

Нет. По документации Cursor allowlist — «not a security guarantee». Он сужает поверхность, но не является границей принуждения; минимальные права на самом ключе важнее.

Можно ли одним ключом обслужить несколько серверов?

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

Существует ли стандартный набор scope у MCP?

Нет. Спецификация оставляет имена областей автору сервера; repo или read:org — примеры GitHub, а не протокольное требование.

Что проверять при обновлении сервера?

Конфигурацию перепроверяют при каждом изменении сервера: новые инструменты могут расширить право ключа незаметно.

provod.ai — проверяйте сценарий в чате и переносите его в API

Сначала сравните ответы в едином интерфейсе, затем подключите выбранную модель к продукту: прототип и production используют общий кабинет, баланс и доступы команды.

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Переход из чата в API не меняет ценовую модель: запросы оплачиваются по официальным тарифам 1:1, без дополнительной маржи provod.ai.

Пройдите путь от первого запроса до интеграции: форма регистрации · цены на модели · защита данных по 152-ФЗ · главная provod.ai

Источники

• Cursor (Anysphere), MCP, 2026-07-18 — cursor.com/docs/mcp
• Cursor (Anysphere), Permissions, 2026-07-18 — cursor.com/docs/reference/permissions
• Cursor (Anysphere), LLM safety and controls, 2026-07-18 — cursor.com/docs/enterprise/llm-safety-and-controls
• Model Context Protocol, Authorization, 2026-07-18 — modelcontextprotocol.io/specification/2025-11-25/basic/authorization
• Model Context Protocol, Security best practices, 2026-07-18 — modelcontextprotocol.io/docs/tutorials/security/security_best_practices
• GitHub, github-mcp-server, 2026-07-18 — github.com/github/github-mcp-server