На конференції AI Engineer Europe в Лондоні інженер GitHub Сем Морроу, який очолює розробку MCP-сервера компанії, розповів про те, як GitHub за рік перетворив експериментальний сервер Model Context Protocol на один із наймасштабніших і водночас найбільш захищених у екосистемі. Центральна тема цієї еволюції — безпека, автентифікація та перехід від локальних, небезпечних токенів до віддаленої архітектури з OAuth 2.1.
Model Context Protocol (MCP) — це спосіб підключати LLM-агентів до зовнішніх сервісів як до «інструментів», не вшиваючи API-логіку безпосередньо в модель. GitHub, як одна з найбільших платформ для розробників, став одним із перших великих гравців, хто спробував зробити MCP-сервер не просто демо-рішенням, а продакшн-сервісом із реальними вимогами до безпеки, масштабування та відповідності корпоративним політикам.
Проблема «диких» токенів: як MCP-агенти відкрили новий клас ризиків
Одне з найнеприємніших відкриттів, яке зробила команда GitHub, спостерігаючи за тим, як MCP використовують «у полі», стосується того, як саме користувачі дають агентам доступ до своїх облікових записів і даних.
У багатьох реальних інсталяціях MCP сьогодні використовуються прості текстові токени доступу, які:
по-перше, зберігаються там, де агент може їх безпосередньо прочитати;
по-друге, часто є довгоживучими;
по-третє, мають надмірні привілеї.
Фактично це означає, що агент — або будь-який код, який має доступ до його середовища виконання, — отримує ключ від усього облікового запису користувача. Якщо до цього додати ризики prompt injection та витоку даних через інструменти, стає очевидно: така модель автентифікації створює ідеальні умови для зловживань.
Це не стільки свідомий вибір користувачів, скільки наслідок того, що «правильно» налаштований безпечний доступ часто виявляється складнішим, ніж просто вставити токен у конфіг. Щоб зробити все коректно, клієнти мають працювати з системними сховищами ключів, шифруванням, інтеграцією з ОС. Деякі середовища, як-от VS Code, уже це роблять, але загалом екосистема ще далека від зрілості.
На цьому тлі стає зрозуміло, чому GitHub вирішив зробити ставку на віддалений MCP-сервер із повноцінною OAuth-моделлю замість того, щоб покладатися на локальні токени.
Від локального до віддаленого: як MCP-специфікація відкрила шлях до безпечнішої архітектури
Публічна історія MCP у GitHub почалася в квітні 2024 року, коли компанія відкрила вихідний код локального MCP-сервера. Приблизно в той самий час у специфікації MCP з’явилася підтримка віддаленого HTTP, що стало ключовим моментом для всієї архітектури.
Підтримка remote HTTP у MCP-спеціфікації дала змогу будувати сервери, до яких клієнти підключаються по мережі, а не запускають їх локально як окремий процес. Для GitHub це означало можливість:
перенести логіку доступу до GitHub API на сторону сервера;
контролювати автентифікацію централізовано;
зробити безпечний шлях підключення «шляхом найменшого опору» для користувача.
Команда свідомо вирішила: користувач не повинен завантажувати локальний рантайм, щоб скористатися MCP-сервером GitHub. Натомість сервер має працювати як повноцінний віддалений сервіс, який сам відповідає за авторизацію, обмеження доступу та захист токенів.
Це рішення стало фундаментом для наступного кроку — інтеграції з OAuth 2.1.
OAuth 2.1 і PKCE: як GitHub посилив автентифікацію MCP-клієнтів
Віддалений MCP-сервер GitHub працює на базі OAuth 2.1 — сучасної еволюції класичного OAuth 2.0, яка закріплює низку найкращих практик безпеки. Для MCP це критично: клієнти часто є десктопними застосунками або розширеннями, які не можуть безпечно зберігати секрети, як це роблять бекенд-сервіси.
Щоб зробити авторизаційні потоки ще стійкішими, команда MCP GitHub долучилася до вдосконалення власної інфраструктури OAuth. Зокрема, вони допомогли додати підтримку PKCE (Proof Key for Code Exchange) до авторизаційного сервера GitHub.
PKCE — це механізм, який захищає авторизаційний код від перехоплення. Клієнт генерує випадковий секрет (code verifier), обчислює з нього похідне значення (code challenge) і надсилає його разом із запитом на авторизацію. Коли клієнт обмінює авторизаційний код на токен, він має довести, що володіє оригінальним секретом. Навіть якщо хтось перехопить сам код, без verifier він не зможе отримати токен.
Для MCP-клієнтів, які працюють на машинах користувачів і не можуть покладатися на приховані серверні секрети, PKCE стає ключовим елементом безпеки. У поєднанні з OAuth 2.1 це дозволяє:
уникати вбудованих у клієнт секретів;
мінімізувати ризики перехоплення коду;
краще захищати інтерактивні сценарії входу.
GitHub намагався зробити саме OAuth-авторизацію «шляхом за замовчуванням» для підключення до MCP-сервера, щоб користувачам не доводилося вручну створювати й вставляти токени.
Однак на цьому шляху команда зіткнулася з очікуваннями спільноти щодо ще однієї функції — динамічної реєстрації клієнтів.
Чому GitHub відмовився від dynamic client registration і що натомість пропонує MCP
Багато розробників, які працюють із OAuth, очікували, що GitHub підтримає dynamic client registration для MCP-клієнтів. Ідея виглядає привабливо: клієнт може автоматично зареєструвати себе на авторизаційному сервері, отримати client_id (і, за потреби, client_secret), не вимагаючи ручної реєстрації застосунку в налаштуваннях GitHub.
Однак GitHub свідомо вирішив не підтримувати цей механізм для свого OAuth-базованого MCP-сервера. Причини виявилися радше інфраструктурними й операційними, ніж суто теоретичними.
По-перше, динамічна реєстрація створює ризик неконтрольованого зростання бази застосунків. Якщо будь-який клієнт може автоматично зареєструватися, кількість записів у базі OAuth-аплікацій може рости без обмежень, що ускладнює адміністрування, моніторинг і аудит.
По-друге, виникають проблеми з rate limiting. Щоб коректно обмежувати запити, авторизаційний сервер має якось «групувати» застосунки, але за умов динамічної реєстрації це стає нетривіальним завданням: ідентичність клієнта важко вважати стабільною й надійною.
По-третє, сама ідентичність застосунку в такій моделі стає розмитою. Якщо будь-хто може створити новий клієнт із довільними параметрами, важко будувати надійні політики безпеки, довіряти ідентифікаторам клієнтів і відстежувати їхню поведінку.
У підсумку GitHub розглянув dynamic client registration, але відкинув його як «добре задуману, але помилкову» ідею в контексті своєї інфраструктури. Компанія не єдина, хто дійшов такого висновку: чимало авторизаційних серверів також свідомо не підтримують цей механізм.
Натомість екосистема MCP рухається в іншому напрямку — до використання метаданих client ID.
Client ID metadata як новий стандарт для MCP
У специфікації MCP формується консенсус: замість динамічної реєстрації краще використовувати client ID metadata. Ідея полягає в тому, що клієнт MCP може описувати себе через стандартизовані метадані, які сервер може використовувати для налаштування авторизаційних потоків, логування та політик безпеки, не створюючи окремий запис застосунку в базі OAuth.
GitHub розглядає можливість підтримати client ID metadata у своєму MCP-сервері. Остаточних обіцянок немає, але всередині команди є явне прагнення це зробити. Очікуваний ефект — значне спрощення процесу входу для користувачів: клієнти зможуть передавати більше інформації про себе без необхідності повноцінної динамічної реєстрації.
Для екосистеми MCP це може стати компромісом між керованістю інфраструктури та гнучкістю клієнтів, зберігаючи при цьому чітку модель безпеки.
Авторизація як фільтр інструментів: як GitHub прив’язує MCP-можливості до scope
Окрема важлива частина безпекової моделі GitHub MCP — те, як сервер співвідносить інструменти, доступні агенту, з реальними правами користувача в GitHub. Ідеться не лише про те, щоб захистити токени, а й про те, щоб не показувати агенту інструменти, які він не має права використовувати.
GitHub використовує OAuth і персональні токени доступу (PAT) як джерело інформації про scope — тобто про те, які дії користувачеві дозволені в API. Ці scope прямо впливають на те, які MCP-інструменти взагалі з’являються в інтерфейсі агента.
Якщо користувач входить до MCP-сервера GitHub за допомогою PAT, сервер одразу фільтрує набір доступних інструментів відповідно до scope цього токена. Користувачеві не потрібно нічого додатково налаштовувати: достатньо надати токен, і сервер сам вирішує, які інструменти можна показати, а які — приховати.
Це дає одразу кілька переваг:
агент не бачить інструментів, які гарантовано не спрацюють через брак прав;
зменшується поверхня атаки — немає сенсу намагатися викликати інструменти, до яких немає доступу;
користувачі з обмеженими правами отримують «урізаний», але безпечніший набір можливостей.
У випадку OAuth GitHub пішов ще далі, реалізувавши так званий step-up OAuth.
Step-up OAuth: інтерактивне «додання прав» без зриву сесії
Step-up OAuth — це підхід, за якого клієнт починає з мінімально необхідного набору scope, а потім, коли виникає потреба виконати більш привілейовану дію, сервер може «попросити» користувача розширити права.
У MCP-сервері GitHub це працює так: якщо агент намагається викликати інструмент, для якого поточні scope недостатні, сервер не просто повертає помилку. Натомість він повертає так званий scope challenge — запит на розширення прав.
Клієнт може показати користувачеві інтерактивний запит: чи згоден він надати додаткові дозволи. Якщо користувач погоджується й проходить оновлений OAuth-флоу, поточний виклик інструменту не вважається проваленим — він може продовжитися вже з новими правами.
Це важливий UX- і безпековий компроміс:
користувач не змушений одразу видавати максимально широкі права «про всяк випадок»;
агент може працювати в режимі «мінімально необхідних привілеїв», підвищуючи їх лише за потреби;
інтерактивний характер step-up робить момент розширення прав явним і контрольованим.
У поєднанні з фільтрацією інструментів за scope це формує більш керовану модель доступу: набір інструментів, які агент бачить і може викликати, завжди є функцією поточних прав користувача.
Від prompt injection до enterprise-профілів ризику: чому безпека MCP — це не лише про токени
Навіть із правильно налаштованим OAuth та обмеженими scope проблема безпеки MCP не зводиться лише до автентифікації. Prompt injection і витік даних через інструменти залишаються реальними ризиками.
Один із прикладів — публікація Invariant Labs, де було продемонстровано коректно реалізовану атаку prompt injection із витоком приватних даних із GitHub через MCP-інструменти. У цьому сценарії інструменти GitHub MCP дійсно можуть бути використані для витоку, якщо користувач увімкнув широкий набір можливостей і надав агенту доступ до приватних репозиторіїв.
Однак важливо, що подібні атаки не є унікальними для MCP чи GitHub. Будь-яка агентна система, яка має доступ до зовнішніх API й приватних даних, стикається з тією ж «летальною тріадою» prompt injection, надмірних привілеїв і відсутності чітких меж між даними та інструкціями.
GitHub має справу з дуже різними профілями ризику користувачів:
від організацій із air-gapped інсталяціями GitHub Enterprise Server у жорстко контрольованих середовищах;
до індивідуальних розробників, які підключають агентів безпосередньо до github.com із повним доступом до свого акаунта.
Завдання MCP-сервера — не нав’язувати єдину модель безпеки, а надати механізми, які дозволяють адаптуватися до різних сценаріїв. Саме тому так багато уваги приділяється:
централізованій авторизації через OAuth;
фільтрації інструментів за scope;
можливості поетапного розширення прав;
відмові від небезпечних практик на кшталт довгоживучих plaintext-токенів.
У підсумку GitHub намагається зробити так, щоб «правильний» шлях — використання віддаленого MCP-сервера з OAuth — був не лише безпечнішим, а й простішим для користувача, ніж ручне керування токенами.
Висновок: MCP дорослішає — і безпека стає ключовою частиною дизайну
За трохи більше ніж рік MCP-сервер GitHub пройшов шлях від локального open source-проєкту до віддаленого продакшн-сервісу з продуманою моделлю безпеки. Ключові елементи цієї еволюції:
перехід до remote HTTP, закладений у специфікації MCP ще в квітні 2024 року;
інтеграція з OAuth 2.1 і впровадження PKCE в авторизаційному сервері GitHub;
свідоме рішення відмовитися від dynamic client registration через проблеми масштабованості, rate limiting і ідентичності застосунків;
рух екосистеми MCP у бік client ID metadata як більш керованої альтернативи;
фільтрація інструментів за scope токена та підтримка step-up OAuth, що дозволяє безболісно розширювати права без зриву поточних викликів;
спроба витіснити практику plaintext, довгоживучих, надмірно привілейованих токенів, які сьогодні масово використовуються в MCP «у полі».
Усе це показує, що MCP як технологія входить у фазу дорослішання. Якщо перша хвиля була зосереджена на тому, щоб «змусити агентів працювати» з інструментами, то наступна — про те, як зробити це безпечно, керовано й масштабовано.
Для розробників агентів і платформ, які планують інтегруватися з GitHub чи будувати власні віддалені MCP-сервери, досвід GitHub стає практичним орієнтиром: безпека не може бути надбудовою поверх MCP — вона має бути вбудована в саму архітектуру сервера, модель авторизації та дизайн інструментів.