MCP OAuth — это схема авторизации для MCP-серверов по HTTP: сервер сообщает клиенту, где получить токен, пользователь подтверждает доступ в браузере, а дальше каждый запрос идёт с токеном, выданным именно для этого сервера. Так описывает спецификация MCP от 18 июня 2025 года. Для серверов, которые запускаются локально через stdio, действует другое правило: секреты берутся из окружения.
Устройство доступа
Авторизация в MCP опциональна. Если сервер её включает, он работает как OAuth-ресурс: без токена отвечает 401 и указывает, где искать сервер авторизации, клиент проходит согласие пользователя с защитой PKCE и получает токен для этого конкретного сервера.
Контур по спецификации выглядит так. Клиент обращается к серверу без токена и получает 401 с заголовком, где указан адрес метаданных защищаемого ресурса. Из них клиент узнаёт адрес сервера авторизации, при необходимости регистрируется на нём автоматически и открывает пользователю страницу согласия. В запросе токена клиент указывает, для какого MCP-сервера токен нужен, а сервер потом проверяет, что токен выдан именно ему. Токен идёт в заголовке Authorization в каждом запросе и никогда в строке адреса. Поскольку токен выдаётся после согласия конкретного пользователя, действия агента привязаны к этому человеку; для агентной схемы заведите отдельную служебную учётную запись, чтобы журнал различал человека и контур. Общий фундамент безопасности агентов раскрыт в статье про безопасность ИИ-агентов, здесь разбираем механику OAuth.
Сравнение с прежней практикой наглядно: вечный API-ключ в конфигурации знала вся команда, отозвать его без поломки интеграций было нельзя, а утечка обнаруживалась по косвенным следам. Токенная схема меняет экономику риска: спецификация рекомендует короткоживущие токены, а для публичных клиентов требует ротации токенов обновления. Секрет живёт недолго, привязан к серверу и к человеку, и отзыв закрывает доступ без смены общего ключа.
Выдача прав
- Перечислите операции сервера и разведите их по областям доступа: чтение, запись, администрирование.
- Создайте роли агента и человека отдельно: у агента область чтения шире, область записи — уже.
- Настройте экран согласия с понятными формулировками: пользователь видит, что именно разрешает.
- Определите срок жизни токена и правило продления: короткие токены с обновлением безопаснее вечных ключей.
Частая ошибка на этом шаге — копирование прав владельца аккаунта на агента. Агент ходит в системы много раз в день, и любая его ошибка умножается на число вызовов. Пакет «читать всё, писать почти ничего» с точечными исключениями на запись через подтверждение окупается спокойствием. Отказ при нехватке прав тоже проверьте тестом: сервер отвечает 403, когда у токена недостаточно областей, и агент должен показать понятную ошибку вместо повторных попыток.
Полезное дополнение к ролевой модели — матрица согласования: какие операции агент совершает сам, какие требуют кнопки человека, а какие запрещены в принципе. Матрица хранится рядом с описанием инструментов сервера и обновляется чаще конфигурации: изменения прав проходят через неё, и любой сотрудник видит текущую границу автономии контура.
Хранение секретов
Токены, клиентские идентификаторы и токены обновления живут в хранилище секретов, а код и конфигурация агента содержат ссылки на имена. Вариант «положили ключ в переменную окружения на ноутбуке разработчика» проходит на демо: при увольнении, потере ноутбука или случайной публикации репозитория вы получаете инцидент с неясными границами. Спецификация требует защищённого хранения токенов и у клиента, и у сервера: токен, попавший в лог или кэш, даёт злоумышленнику те же права, что и владельцу. Хранилище секретов с ротацией решает три задачи: доступ по ролям, автоматическая смена значений, быстрый отзыв при утечке. Если MCP-сервер сам ходит в сторонние API, для них он берёт отдельный токен, а полученный от клиента оставляет у себя: спецификация прямо запрещает передавать его дальше. Замерьте время отзыва доступа от сигнала «токен скомпрометирован» до отказа в обслуживании и записывайте результат каждого учения. Отдельно пропишите владение: у каждого секрета есть ответственный, который знает, зачем значение существует и кто его потребует при инциденте.
Сведите токены всех подключённых MCP-серверов в одно хранилище и назначьте владельца каждому секрету. Затем проведите учебную ротацию: смените значения, проверьте вызовы и найдите в журнале момент переключения.
Перед ротацией полезно собрать картину текущих выдач: кто, куда и с какими правами подключён сегодня.
Какие права сейчас выданы вашим агентам?
Журнал и отзыв
| Запись журнала | Зачем нужна | Кто смотрит |
|---|---|---|
| Кто запросил токен | Связь доступа с ролью и задачей | Владелец процесса |
| Какие области выданы | Проверка минимальности пакета | Информационная безопасность |
| Каждый вызов инструмента | Расследование инцидентов | Интегратор, служба безопасности |
| Факт отзыва | Подтверждение закрытия доступа | Аудитор, руководитель |
Отзыв прав проектируется как рядовая операция: кнопка отзыва доступна владельцу процесса без заявки разработчикам, а все токены служебной учётной записи гаснут одним действием. Проверяйте процедуру учениями: раз в квартал владелец процесса отзывает доступ тестовой учётной записи, и команда сверяет, что сервисы отвечают отказом, а журнал показывает полную картину обращений до момента отзыва. Запись об отзыве попадает в тот же журнал, что и выдача, и по паре записей видно, сколько жил доступ и кто его закрыл.
Держите журнал читаемым: запись обращения умещается в пару строк — кто, когда, какой инструмент, итог вызова. Избыточная детализация подрывает дисциплину просмотров, недостаточная превращает расследование в гадание. Оптимум проверяется учениями: по свежему инциденту цепочку действий агента, вплоть до аргументов вызова, можно восстановить из журнала без догадок.
Границы метода
OAuth закрывает вопрос «кто и с какими правами», но оставляет за рамками два соседних риска. Первый — вредоносный ввод: токен с честными правами отлично работает, когда агент получил в промпте инструкцию обращаться с данными иначе. Второй — слепая выдача: пользователь жмёт «разрешить», пролистав список областей. Оба риска лечатся практиками вокруг протокола: фильтрация ввода, лимиты на объёмы ответов инструментов, обучение команды читать экран согласия.
- Раз в месяц сверяйте выданные области с фактическими вызовами: всё, чем агент пользуется редко, урезайте.
- Настройте оповещения на аномальные пики вызовов: всплеск часто предшествует инциденту.
- Держите под рукой план отката: отзыв токена, остановка сценария, уведомление затронутых владельцев данных.
- Повторяйте учения по отзыву доступа для новых сотрудников: навык гасить токены должен жить в команде, а держать его в голове одного администратора опасно.
Настройка самих подключений между клиентом и сервером раскрыта в материале про MCP-подключения. Аудит контура с оценкой прав и журналов входит в ИИ-консалтинг: разбираем карту доступов, ищем избыточные области и составляем план сокращения.