MCP і OAuth2: хто дазволіў дзеянне агента на вашым MCP-серверы?

Чаму доступ да інструментам ускладнюе аўтэнтыкацыю

Model Context Protocol (MCP) ўжо ўважаецца стандартным элементам для агентных AI-сістэм. Ён дае модэлю можлівасць аднарадзіцца з зовнішнімі інструментамі, рэсурсамі і службамі, а таксама вызываць іх. Не трэба ствараць індывідуальную інтэграцыю між LLM і кожным API, з якім ён взаімаецца; прыкладнэць канектуецца да сервера MCP і даведаецца, што той сервер можа запростаць. Пошук у базе дадзеных, падача запіта на GitHub, запыт да Salesforce, адправка электранаўскага пісьма чы выкарыстоўванне даных з корпаратыўнай сістэмы — усе гэта стае частынай адной і той жа операцыі, тое ўзыву інструмента.

Калі ШТЫ можа дзеяць, а не толькі адказваць, пытанні ідэнтыфікацыі і автарызацыі быстра становяцца складнымі. Хто такі ШТЫ, і хто ўсё-такі чалавек за яго спінам? Хто автарызаваў дзеянне, і што самэўсё можа рабіць ШТЫ? Для каго была надана автарызацыя? Можа ШТЫ перадаць гэтую аўтарытэт другой службе? А найбольшае пытанне: чы можа OAuth2, пратакол, створаны пераважна для доступу да захаваных рэсурсаў праз програмнае забезпечэнне, адпаведна выражаць аўтаномнага агента, які дзеяе за чалавека?

Адказ складны. Фраза "ад імені" натыкаецца на пратакол адміністрацыі токенама OAuth2. Чынныя спефікацыі MCP яго не згадваюць, хоць лёгка ўбачыць, дзе ён мог бы паслужыць, і ён не вылечыць іншых недастаткаў, указаных выкладзе.

Як MCP працуе на практыцы

MCP візначае стандартны пратакол між кліентам ШТЫ і серверам MCP. Спрошчанае зображэнне выглядае так.

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

Уявіце сабе асістэнта, прыўязанага да сервера 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. Спецыфікатор таксама уключае метаданы захішчаных рэсурсаў, метаданы сервераў автарызацыі, паказчыкі рэсурсаў, а таксама працэсы рэгістрацыі і аднаходжэння вярнікаў. У ёму аднароджаныя гэтыя спецыфікаторы:

• Праект IETF для OAuth 2.1 (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 ў інтэрнэтэ. Аднак аўтонамныя AI прыносяць іншы тып кліента. Кліент OAuth2 раней абыў сямым прыкладам прыемплі. Агент можа быць аўтонамным, працаваць дзялейна і выпалняць калькі крокаў, магчымае дынамічна выбіраць інструменты, вызываць калькі API, дэлегаваць задачы, дзеяць ад імені чалавека і прымыкаць рашэнні, якія чалавек ніколі не задаў. Гэта зусім іншая проблема автарызаціі.

Не тое што OAuth ўразлівы

Ніхто не павінен прыткаваць крытыку. У RFC 6749 асалі былі врачунаны пытанні безпекі, а OAuth2 з тэх пачатку развіў значную безпековую архітэктуру. Суць у тым, што OAuth2 быў спецыяльна створаны як фрэймворк, а не як повны прыкладны протакол для кожнага сучаснага развёртвання. Адпрацоўвальнікі мелі можлівасць робіць многа выборы ў аспектах безпекі, і з часам промысел з’ясаваў, што дзеяныя комбінацыі гэтых выбораў ўскладнююць сітуацыю з безпекай. Самэ гэта стало прычыной дадатковых змян: аўтэнтыфікацыя і выявлення кліента, захішчаныя метаданы рэсурсаў і паказчыкі рэсурсаў, взаімны TLS, DPoP і іншы токены, абмежаныя па надавальніку, прыўязка токенаў, PKCE і інструкцыі з аднавлення. Колькасць гэтых змян была настолькі веліка, што IETF выдала RFC 9700 — документ з найкрашчымі сучаснымі практыкамі безпекі для OAuth 2.0, які базуецца на RFC 6749, 6750 і 6819 і відмовляецца ад менш эфектыўных способаў функцыонавання.

Такім чынам OAuth2 не зазнаў неудачы. Ён эвалююў. Аднак сама гэта эвалюцыя ўсё ж ўскладнюе адкрыць асновную проблему: спачатковая абстракцыя паўтараючыся патрабавала дадатковых механізмаў, калі сэрвісы безпекі ставалі ўсё бол складнымі.

Што прэдставляе токен?

Вернімся да пачатковага прыклада. Пользоватэль просі стварыць новы элемент, AI прымае рашэнне вызваць інструмент MCP, а сервер прымеў токен доступу OAuth2. Што означае гэты токен? Ён можа прэдставляць людзкага карыстальніка, AI-праграму, кліента 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, а радыя автарызацыі, базаванай на правілах. Больш проста кажучы, гэта разліка межаў автарызацыйных рашэнняў з вялікай і з малай дзеярознасцю.

Агент як новы суб’ект безпекі

Гэта можа быць найважнейшая канцэптуальная змяна. Традыцыяныя прыкладнікі зазвычай маюць досыта стабільную ідэнтычнасць. Агент AI можа быць створаны дынамічна, з калькі лічбы частак адразу.

Тады хто ёсць суб’ект безпекі? Верагодна, ўсе яны. Сістэма автарызацыі можа патрабаваць не толькі заявы „Эліс можа адкрыць 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 быў створаны самэль гэтай ланцоўке.

Агентныя AI прыносяць нешто іншае.

Ланцоўка стае дынамічной. Учаснікі можуць змяніцца, агент прымае рашэнні, інструменты знаходзяцца ў рэальным часе, а служба, якая працуе пасля, можа нават не знаты пра первіснага корыстніка. Аднак сістэма все рава должна адпаведзець, хто автарызаваў дзеянне, што ўзяточна сложнейшы вопыт.

OAuth2 не знікне

Імпульсіва ўзнікла думка, што OAuth2 існуе ранейш за AI і таму не можа працаваць з яйго. Гэта занадта проста. OAuth2 перажыў вялікія змяны ў інтэрнэце, таму што ён ўсампрада корыстны канструкт для дэлегавання, а спефікацыя MCP чыста будуе на OAuth 2.1 і не абмовляецца ад яго. Больш правядзімыя перспектывы — эвалюцыя:

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

Змена ў адной ідэі

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

Будучыня, верагацею, не будзе выборам между OAuth2 і чымсь новым. Больш верагацею, гэта будзе саўместная праця OAuth2, OIDC, MCP, механізмаў капасітэтав, правіл, адносна моцнейшых крыптаграфічных методаў захавання даных і дэлегавання з урахоўваннем агента. MCP проста робіць межы існуючай архітэктуры ідэнтыфікацыі немагчымымі да ігнаравання, і гэта можа стаць аднам з яе найважлівейшых вяліканстваў для экасыстэмы ШЫ.