MCP и OAuth2: кто разрешил действия агента на вашем сервере MCP?

Почему доступ к инструментам усложняет идентификацию

Протокол контекста модели (MCP) теперь является стандартным элементом архитектуры агентных ИИ-систем. Он предоставляет модели способ находить и вызывать внешние инструменты, ресурсы и сервисы. Не требуется настраивать индивидуальную интеграцию между большой языковой моделью и каждым API, с которым она взаимодействует; приложение подключается к серверу MCP и узнаёт, что предлагает этот сервер. Поиск в базе данных, создание задачи в GitHub, запрос к Salesforce, отправка электронного письма или извлечение данных из корпоративной системы — всё это сводится к одной операции, а именно к вызову инструмента.

Как только ИИ может действовать, а не просто отвечать, вопросы идентификации и авторизации быстро становятся сложными. Кто такой ИИ и кто человек, стоящий за ним? Кто разрешил это действие и что именно может делать ИИ? Для каких ресурсов предназначена авторизация? Может ли ИИ передать эти полномочия другому сервису? И самый важный вопрос: может ли OAuth2, протокол, в основном предназначенный для доступа программного обеспечения к защищенным ресурсам, адекватно отражать автономного агента, действующего от имени человека?

Ответ на этот вопрос сложен. Фраза «от имени» указывает на протокол обмена токенами OAuth2. Текущая спецификация MCP не упоминает его, хотя легко понять, где он мог бы вписаться, и это не устранило бы остальных недостатков.

Как на практике работает MCP

MCP определяет стандартный протокол взаимодействия между клиентом ИИ и сервером MCP. Упрощенная схема выглядит следующим образом.

Приложение на основе ИИ является клиентом MCP, а сервер MCP предоставляет ему доступ к своим возможностям. Модель может обнаруживать эти возможности и решать, когда их использовать. Заметным изменением является то, что большие языковые модели больше не просто генерируют текст — они участвуют в определённом протоколе.

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

{
  "method": "tools/list",
  "params": {}
}

Сервер отвечает списком своих инструментов.

{
  "tools": [
    {
      "name": "search_issues",
      "description": "Search project issues",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": {
            "type": "string"
          }
        }
      }
    },
    {
      "name": "create_issue",
      "description": "Create a new project issue",
      "inputSchema": {
        "type": "object",
        "properties": {
          "title": {
            "type": "string"
          },
          "description": {
            "type": "string"
          }
        }
      }
    }
  ]
}

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

{
  "method": "tools/call",
  "params": {
    "name": "search_issues",
    "arguments": {
      "query": "authentication bugs status:open"
    }
  }
}

Сервер возвращает информацию об обнаруженных проблемах.

{
  "content": [
    {
      "type": "text",
      "text": "Found 17 open authentication issues."
    }
  ]
}

Модель анализирует результаты, выбирает наиболее важный из них и отправляет второй запрос.

{
  "method": "tools/call",
  "params": {
    "name": "create_issue",
    "arguments": {
      "title": "Critical authentication issue",
      "description": "Summary of the highest-priority authentication defect..."
    }
  }
}

Сервер подтверждает создание.

{
  "content": [
    {
      "type": "text",
      "text": "Issue AUTH-4821 created successfully."
    }
  ]
}

Здесь проблема безопасности становится очевидной. Агент перешел от чтения информации к выполнению действий, видимых вне системы.

MCP не решает проблему идентификации

Распространенным заблуждением является мнение, что MCP решает вопросы идентификации. Это не так. MCP определяет способы взаимодействия клиентов и серверов, в то время как аутентификация и авторизация являются отдельными аспектами.

Для транспортных протоколов на основе HTTP раздел, посвященный авторизации, в текущей спецификации (версия от 2026-07-28), основан на OAuth 2.1. Этот раздел называется «Авторизация», вероятно, потому что именно это является основной задачей OAuth2, хотя в нем также рассматриваются механизмы аутентификации. Серверы MCP выступают в роли ресурсов, защищенных с помощью OAuth2, а клиенты MCP — в роли клиентов OAuth2. Спецификация также включает метаданные защищенных ресурсов, метаданные серверов авторизации, индикаторы ресурсов, а также процедуры регистрации и поиска клиентов. Она объединяет следующие спецификации:

• Черновик OAuth 2.1 от IETF (draft-ietf-oauth-v2-1-13)
• Использование токенов-носителей в OAuth 2.0 (RFC 6750)
• Метаданные сервера авторизации в OAuth 2.0 (RFC 8414)
• Динамическая регистрация клиентов в OAuth 2.0 (RFC 7591)
• Индикаторы ресурсов для OAuth 2.0 (RFC 8707)
• Метаданные защищенных ресурсов в OAuth 2.0 (RFC 9728)
• Идентификация эмитента сервера авторизации (RFC 9207)
• Документы с метаданными идентификаторов клиентов OAuth (черновик от IETF)
• OpenID Connect Discovery 1.0 и OpenID Connect Dynamic Client Registration 1.0

Протокол постоянно ужесточается. В обновлении от июля 2026 года клиенты обязаны проверять параметр iss, чтобы предотвратить атаки, связанные с путаницей между серверами авторизации; учетные данные клиента привязываются к организации-эмитенту, которая их создала, а механизм динамической регистрации клиентов постепенно заменяется документами метаданных идентификаторов клиента. Остается открытым вопрос о том, достаточно ли OAuth2 для работы агентов.

OAuth существовал до агентов

OAuth 2.0 был стандартизирован в 2012 году для ответа на довольно простой вопрос: как клиент может получить ограниченный доступ к защищенному ресурсу, не зная пароля владельца ресурса?

Модель сработала очень хорошо и стала основой для децентрализованного доступа к API в Интернете. Однако автономный ИИ приносит с собой совершенно иной тип клиента. Раньше под клиентом OAuth2 понималось приложение. Агент может быть автономным, работать длительное время и выполнять несколько шагов, способен динамически выбирать инструменты, вызывать несколько API, делегировать задачи, действовать от имени человека и принимать решения, которые тот никогда не формулировал. Это совершенно другая проблема авторизации.

Дело не в том, что OAuth небезопасен

Никто не должен преувеличивать критику. В RFC 6749 действительно учитывались вопросы безопасности, и с тех пор OAuth2 развил значительную архитектуру безопасности. Суть в том, что OAuth2 был специально создан как фреймворк, а не как полный протокол с жесткими требованиями для всех современных реализаций. Разработчики имели возможность делать множество выборов в области безопасности, и со временем индустрия поняла, что некоторые комбинации этих выборов могут быть опасными. Именно поэтому были добавлены такие элементы, как аутентификация и поиск клиентов, защищенные метаданные ресурсов и их индикаторы, взаимный TLS, DPoP и другие токены с ограничениями для отправителя, привязка токенов, PKCE и рекомендации по их обновлению. Накопленный объем материала стал настолько значительным, что IETF выпустил RFC 9700 — документ с рекомендациями по лучшим практикам обеспечения безопасности OAuth 2.0, основанный на RFC 6749, 6750 и 6819, в котором устаревшие способы работы отменены.

Означает ли это, что OAuth2 потерпел неудачу? Нет — он эволюционировал. Однако сама эта эволюция является признаком основной проблемы: первоначальная абстракция неоднократно требовала дополнительных механизмов по мере усложнения среды безопасности.

Что представляет собой токен?

Вернемся к примеру из начала. Пользователь просит создать новый элемент, ИИ решает вызвать инструмент MCP, а сервер получает токен доступа OAuth2. Что означает этот токен? Он может относиться к человеку-пользователю, к приложению ИИ, к клиенту MCP, к серверу MCP, действующему от имени человека, или к какой-то комбинации приложения и пользователя. Эти варианты не являются эквивалентными, и в слегка отличающихся, но полностью законных сценариях работы OAuth2 может произойти любой из них.

Это становится ещё более важным, когда сервер MCP вызывает другой API.

В настоящее время несколько доменов авторизации перекрываются. Прежде чем принять решение, серверу может потребоваться установить личность пользователя, агента, выполняющего действие, клиента MCP, инициировавшего запрос, то, что было одобрено пользователем, инструменты, которые может использовать агент, доступные внутренние API, а также определить, остается ли данное действие в рамках первоначальных полномочий. Это гораздо сложнее, чем показано на простой схеме ниже.

Растерянный заместитель

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

а не в этом:

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

Роль OAuth2 в MCP

На упрощенном уровне процесс выглядит следующим образом.

Сервер MCP является защищаемым ресурсом. Клиент получает токен доступа, предоставляет его при каждой операции с MCP, и сервер проверяет его. Это стандартный механизм OAuth2. Спецификация усиливает его с помощью индикаторов ресурсов (параметр resource), так что запрос на авторизацию указывает конкретный сервер MCP, для которого предназначен токен. Это хорошо, но это не решает магическим образом всех проблем с авторизацией агентов.

Что добавляет OIDC

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

Alice

OIDC может предоставлять сведения об идентичности пользователя, OAuth2 — полномочия, делегированные другому агенту, а клиент MCP затем может получить токен доступа, представляющий собой разрешение на использование ресурса для данного клиента. Концептуально это выглядит следующим образом.

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

Проблемы с диапазонами полномочий

Диапазоны полномочий часто рассматриваются как решение. Пример разрешения на чтение календаря выглядит следующим образом.

scope=calendar.read

и такая грант на отправку.

scope=email.send

Но агентные системы показывают, насколько грубыми бывают диапазоны полномочий. Возьмём, к примеру, простое разрешение на отправку электронных писем.

email.send

Разрешает ли он ИИ отправлять сообщения кому угодно? Отправлять неограниченное количество сообщений? Отправлять финансовые документы или конфиденциальные корпоративные данные? Подделывать личность пользователя? Отправлять сообщения без запроса подтверждения? В описании этого не сказано. Для принятия решения, возможно, потребуется дополнительная информация по этим вопросам.

Subject
Agent
Tool
Action
Resource
Target
Context
Risk
Time
Policy

Это больше похоже не на традиционные диапазоны OAuth2, а на авторизацию, основанную на правилах. Иными словами, это разница между решениями об авторизации с крупной и с мелкой степенью детализации.

Агент как новый субъект безопасности

Возможно, это самое важное концептуальное изменение. Традиционные приложения обычно имеют довольно стабильную идентичность. Агент ИИ может формироваться динамически, из нескольких компонентов одновременно.

Так кто же является субъектом безопасности? Возможно, все они. Системе авторизации может потребоваться выразить нечто большее, чем просто «Элис может получить доступ к Salesforce». Ей может потребоваться указать, что Элис авторизовала этот конкретный агент, работающий в рамках этого конкретного приложения, на выполнение определенных действий в отношении данного тенанта Salesforce при соблюдении определенных правил. Это гораздо более полное описание.

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

Несет ли OAuth2 проблемы для агентов?

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

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

Новые предложения

Возникает несколько направлений развития.

GNAP

Самым очевидным кандидатом, основанным на стандартах, является GNAP — протокол для ведения переговоров и предоставления разрешений. Он был создан для преодоления ограничений, связанных с механизмами авторизации и делегирования в стиле OAuth2, позволяя делегировать полномочия программному обеспечению и передавать ему полученные результаты, включая доступ к API и информацию о субъекте. В его конструкции рассматривается более сложный механизм делегирования, чем тот, который предлагает OAuth2. В настоящее время GNAP является предлагаемым стандартом IETF по документу RFC 9635, а RFC 9767 касается подключений к серверам ресурсов. Эти документы действительно отвечают на вопрос о том, были ли предложены какие-либо решения, выходящие за рамки OAuth2, однако GNAP не является заменой специфичной для MCP системе безопасности, и OAuth2 по-прежнему остается доминирующим стандартом.

Специфичные для MCP протоколы безопасности

Исследователи также предлагают протоколы, основанные на MCP и агентном ИИ. Протокол безопасного контекста модели (SMCP) расширяет функции MCP за счёт единой системы управления идентичностями, взаимной аутентификации, передачи информации о безопасном контексте, строгого применения правил и ведения журнала аудита. Другое предложение — MCPSec — предусматривает сертификацию способностей агентов и аутентификацию сообщений для противодействия угрозам, характерным именно для MCP. Эти усилия подчёркивают, что аутентификация — это не единственная проблема. Экосистема агентов может потребовать не только определения того, кто вы такой, но и проверки того, какие способности вы заявляете и могут ли эти заявления быть проверены с помощью криптографии. Это способствует развитию безопасности, основанной на способностях.

Авторизация на основе способностей

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

Capability:
    Principal: Agent-472
    Subject: Alice
    Action: send-email
    Resource: alice@example.com
    Destination: bob@example.com
    Maximum: 1 message
    Expiration: 10 minutes

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

OAuth2 плюс что-то ещё

В конечной архитектуре, вероятно, не будет объявлено о смерти OAuth2. Она будет выглядеть примерно так.

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

Отсутствующий элемент: намерение

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

Именно поэтому утверждение о том, что OAuth2 не подходит для агентов, содержит долю правды, при условии правильного понимания критики. OAuth2 может авторизовать каждый отдельный запрос, но он не обеспечивает сам по себе полного способа для определения того, соответствуют ли эти запросы намерению пользователя и полномочиям, делегированным агенту.

MCP как пример тестового случая

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

Агентные ИИ-системы вносят что-то новое.

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

OAuth2 не исчезнет

Хочется сказать, что OAuth2 существовал до появления ИИ, поэтому он не может быть использован с ним. Но это слишком упрощённо. OAuth2 выдержал огромные изменения в Интернете, потому что представляет собой действительно полезную систему делегирования полномочий, а спецификация MCP явно основана на OAuth 2.1 и не отказывается от него. Более вероятным будущим является эволюция:

• OAuth2 в качестве основы
• OIDC для управления идентификацией
• MCP для стандартного взаимодействия с инструментами
• DPoP и связанные с ним механизмы для более прочной привязки токенов
• Индикаторы ресурсов для связывания токенов с предназначенными для них ресурсами
• Системы способностей для ограничения действий агентов
• Механизмы политик для оценки контекста
• Более современные протоколы, такие как GNAP, для более сложной семантики делегирования

Изменение в одной концепции

Искусственный интеллект в форме агентов не создаёт новую проблему аутентификации. Новые проблемы — это авторизация и делегирование. Аутентификация определяет, кто вы, тогда как OAuth2 определяет, к каким ресурсам у вас есть доступ. Авторизация агентов должна учитывать, какие полномочия были делегированы этому агенту, от имени кого, в отношении каких ресурсов и при каких ограничениях, а также соответствует ли конкретное действие этим полномочиям. Это более сложный вопрос, и, вероятно, требует более совершенной модели безопасности.

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