MCP та OAuth2: Хто авторизував дію агента на вашому сервері MCP?

Чому доступ до інструментів ускладнює ідентифікацію

Протокол контексту моделі (MCP) тепер є стандартним елементом для агентних ШІ. Він надає моделі спосіб виявлення та виклику зовнішніх інструментів, ресурсів та сервісів. Не потрібно створювати індивідуальну інтеграцію між LLM та кожним 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)
• Документи з метаданями ID клієнта OAuth (проєкт IETF)
• OpenID Connect Discovery 1.0 та OpenID Connect Dynamic Client Registration 1.0

Протокол постійно удосконалюється. У версії від липня 2026 року клієнти зобов’язані перевіряти параметр iss для запобігання атакам на плутанину з сервером авторизації; облікові дані клієнта прив’язані до емітента, який їх створив, а механізм динамічної реєстрації клієнтів поступається місцем документам метаданих ID клієнта. Чи достатній 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, проте це не є заміною специфічно для 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 забезпечуватиме протокол інструментів, система можливостей чи політик обмежуватиме те, що агент може фактично робити, а точка виконання політик здійснюватиме остаточний виклик.

Відсутня складова: намір

Намір — це те, з чим традиційна авторизація не була створена для роботи. Припустимо, користувач просить агента знайти рейс до Маніли за ціною до 1 000 доларів та забронювати його. У процесі агент може шукати авіакомпанії, порівнювати тарифи, переглядати календар, бачити дані паспорта, бронювати місце та оплачувати. Користувач ніколи не схвалював кожен з цих запитів API окремо. Він схвалив лише намір, що суттєво відрізняється від звичайної веб-авторизації, оскільки агент перетворює загальне завдання на послідовність дій машини. Системі безпеки може знадобитися проаналізувати наступне.

Ось чому твердження про те, що OAuth2 не підходить для агентів, має певну правду, за умови правильного розуміння цієї критики. OAuth2 може авторизувати кожен окремий запит. Він не забезпечує вбудований спосіб оцінки того, чи відповідають ці запити наміру користувача та делегованим повноваженням агента.

MCP як приклад тестування

MCP змушує спільноту, яка працює над ідентичністю та безпекою, стикнутися з проблемою, яка накопичувалася роками. OAuth2 був розроблений саме для вирішення цієї проблеми.

Агентський ШІ пропонує щось інше.

Ланцюжок дій стає динамічним: учасники можуть змінюватися, агент приймає рішення, інструменти знаходяться в реальному часі, а сервіс на наступному етапі може навіть не знати про первісного користувача. Проте система все одно мусить відповісти, хто авторизував дію, що є набагато складнішим запитанням.

OAuth2 не зникне

Хочеться сказати, що OAuth2 існує раніше за ШІ, тому не може працювати з ним. Але це занадто спрощено. OAuth2 вижив попри величезні зміни в Інтернеті, тому що є справді корисною системою делегування, а специфікація MCP чітко ґрунтується на OAuth 2.1 та не відмовляється від нього. Ймовірніше, майбутнє буде еволюційним:

• OAuth2 як основа
• OIDC для ідентифікації
• MCP для стандартної взаємодії з інструментами
• DPoP та пов’язані з ним механізми для міцнішого прив’язування токенів
• Індикатори ресурсів для пов’язування токенів із призначеними для них ресурсами
• Системи можливостей для обмеження дій агентів
• Механізми політик для оцінки контексту
• Новіші протоколи, такі як GNAP, для більш розширених семантик делегування

Зміна підходу

Агентні ШІ не створюють переважно нової проблеми автентифікації. Новою проблемою є авторизація та делегування. Автентифікація запитує, хто ви, тоді як OAuth2 запитує, до чого ви маєте доступ. Агентна авторизація мусить визначити, які повноваження були делеговані цьому агенту, від імені кого, щодо яких ресурсів та за якими обмеженнями, а також чи входить ця конкретна дія до цих повноважень. Це більш складне запитання, і, ймовірно, вимагає більш розширеної моделі безпеки.

Майбутнє, ймовірно, не буде протистоянням OAuth2 та якоїсь нової технології. Швидше за все, це буде поєднання OAuth2, OIDC, MCP, механізмів обмежень, політик, посиленої криптографічної безпеки та делегування з урахуванням особливостей агентів. MCP просто робить межі існуючої архітектури ідентифікації неможливими до ігнорування, що може стати одним із найважливіших внесків цієї технології в екосистему ШІ.