MCP i OAuth2: Kto zatwierdził działanie agenta na twoim serwerze MCP?

Dlaczego dostęp do narzędzi utrudnia identyfikację

Model Context Protocol (MCP) jest obecnie standardowym elementem infrastruktury dla sztucznej inteligencji agentowej. Umożliwia modelowi jeden sposób na odkrywanie i wywoływanie zewnętrznych narzędzi, zasobów oraz usług. Nie trzeba konfigurować specjalnych integracji pomiędzy LLM a każdym API, z którym ma on kontakt – aplikacja łączy się z serwerem MCP i dowiaduje się, co ten serwer oferuje. Szukanie w bazie danych, zgłaszanie problemów na GitHubie, wysyłanie zapytań do Salesforce, wysyłanie e-maili czy pobieranie danych z systemu korporacyjnego – wszystko to sprowadza się do tej samej operacji, czyli wywołania narzędzia.

Gdy sztuczna inteligencja może działać, a nie tylko odpowiadać, kwestie tożsamości i upoważnienia szybko stają się skomplikowane. Kto jest sztuczną inteligencją, a kto człowiekiem stojącym za nią? Kto zatwierdził tę akcję i co dokładnie może robić sztuczna inteligencja? Do jakiego zasobu odnosiło się to upoważnienie? Czy sztuczna inteligencja może przekazać te uprawnienia innemu usłudze? A najważniejsze pytanie: czy OAuth2, protokół oparty głównie na dostępie oprogramowania do zasobów chronionych, może w wystarczający sposób przedstawić autonomicznego agenta działającego w imieniu osoby?

Odpowiedź jest skomplikowana. Wyrażenie „w imieniu” wskazuje na protokół OAuth2 Token Exchange. Obecna specyfikacja MCP o nim nie wspomina, chociaż łatwo jest zobaczyć, gdzie mógłby się on wpisać, a i tak nie rozwiązałby pozostałych wad opisanych poniżej.

Jak MCP funkcjonuje w praktyce

MCP definiuje standardowy protokół pomiędzy klientem sztucznej inteligencji a serwerem MCP. Uproszczony obraz wygląda następująco.

Aplikacja AI to klient MCP, a serwer MCP udostępnia mu swoje możliwości. Model może odkryć te możliwości i zdecydować, kiedy je wykorzystać. Istotną zmianą jest to, że LLM nie tylko wytwarza tekst – bierze udział w protokole.

Wyobraź sobie asystenta podłączonego do serwera MCP służącego do śledzenia spraw w firmie. Najpierw klient pyta serwer, jakie narzędzia posiada.

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

Serwer odpowiada listą swoich narzędzi.

{
  "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"
          }
        }
      }
    }
  ]
}

Teraz model wie, że dostępne są dwie możliwości. Załóżmy, że użytkownik poprosi go o znalezienie błędów w autoryzacji oraz stworzenie zgłoszenia podsumowującego najważniejszy z nich. Agent może rozpocząć od wykonywania zapytania wyszukiwawczego.

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

Serwer zwraca problemy z dopasowaniem.

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

Model odczytuje wyniki, wybiera ten najważniejszy i wysyła drugą prośbę.

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

Serwer potwierdza utworzenie.

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

Tutaj problem bezpieczeństwa staje się oczywisty. Agent przeszedł od czytania informacji do podejmowania działań widocznych poza systemem.

MCP nie rozwiązuje kwestii tożsamości

Powszechnym błędem jest przekonanie, że MCP rozstrzyga kwestię tożsamości. Tak nie jest. MCP określa, w jaki sposób klienci i serwery ze sobą współpracują, natomiast uwierzytelnianie i upoważnianie to odrębne zagadnienia.

Dla transporту opartego na HTTP, sekcja dotycząca upoważniania w obecnej specyfikacji (wersja z 2026-07-28) opiera się na standardzie OAuth 2.1. Sekcja ta nosi tytuł „upoważnianie”, prawdopodobnie dlatego, że to główny element standardu OAuth2, chociaż obejmuje również mechanizmy uwierzytelniania. Serwery MCP funkcjonują jako zasoby chronione przez OAuth2, a klienci MCP jako klienci OAuth2. Specyfikacja obejmuje również metadane zasobów chronionych, metadane serwerów upoważniania, wskaźniki zasobów oraz proces rejestracji i wykrywania klientów. Łączy ona następujące specyfikacje:

• projekt OAuth 2.1 IETF (draft-ietf-oauth-v2-1-13)
• Użycie tokenów nośnych w OAuth 2.0 (RFC 6750)
• Metadane serwera autoryzacji w OAuth 2.0 (RFC 8414)
• Rejestracja dynamiczna klientów w OAuth 2.0 (RFC 7591)
• Wskaźniki zasobów w OAuth 2.0 (RFC 8707)
• Metadane zasobów chronionych w OAuth 2.0 (RFC 9728)
• Identyfikacja wydawcy przez serwer autoryzacji (RFC 9207)
• Dokumenty metadanych identyfikatora klienta OAuth (projekt IETF)
• OpenID Connect Discovery 1.0 oraz OpenID Connect Dynamic Client Registration 1.0

Protokół jest coraz bardziej rygorystyczny. W rewizji z lipca 2026 roku klienci muszą sprawdzać parametr iss, aby zapobiec atakom polegającym na pomyleniu serwerów autoryzacji, dane uwierzytelniające klienta są powiązane z emitentem, który je stworzył, a Dynamic Client Registration ustępuje miejsca Dokumentom Metadanych ID Klienta. To, czy OAuth2 wystarcza dla agentów, pozostaje otwartym pytaniem.

OAuth istniał przed agentami

OAuth 2.0 został ustandaryzowany w 2012 roku, aby odpowiedzieć na dość proste pytanie: jak klient może uzyskać ograniczony dostęp do zasobu chronionego, nie znając hasła właściciela tego zasobu?

Model funkcjonował bardzo dobrze i stał się podstawą upoważnionego dostępu do API w całym Internecie. Autonomiczna sztuczna inteligencja jednak wprowadza inny rodzaj klienta. Klient OAuth2 tradycyjnie oznaczał aplikację. Agent może być autonomiczny, działać przez długi czas i wykonywać wiele kroków, być w stanie dynamicznie wybierać narzędzia, wywoływać kilka API, delegować zadania, działać w imieniu człowieka oraz podejmować decyzje, których ten nigdy nie sformułował. To zupełnie inny problem związany z autoryzacją.

To nie tak, że OAuth jest niesecure

Nikt nie powinien przesadzać z krytyką. RFC 6749 rzeczywiście uwzględniał kwestie bezpieczeństwa, a od tamtej pory OAuth2 rozwinął znacznie bardziej rozbudowaną architekturę bezpieczeństwa. Chodzi o to, że OAuth2 został celowo zaprojektowany jako framework, a nie pełny, obowiązujący protokół dla każdego nowoczesnego zastosowania. Implementatorzy mieli możliwość dokonywania wielu wyborów dotyczących bezpieczeństwa, a z czasem branża odkryła, że niektóre kombinacje tych wyborów są niebezpieczne. To właśnie jest powodem dodatkowych rozwiązań, takich jak autoryzacja i wykrywanie klientów, zabezpieczone metadane zasobów oraz wskaźniki zasobów, wzajemny TLS, DPoP oraz inne tokeny ograniczające nadawcę, wiązanie tokenów, PKCE oraz wytyczne dotyczące odnowy tokenów. Nagromadzenie tych rozwiązań było na tyle znaczne, że IETF wydało RFC 9700 – dokument z zaleceniami dotyczącymi najlepszych praktyk bezpieczeństwa w OAuth 2.0, który opiera się na RFC 6749, 6750 i 6819 oraz odrzuca słabsze tryby działania.

Zatem OAuth2 nie zawiodło – ewoluowało. Jednak ta ewolucja sama w sobie jest oznaką podstawowego problemu: początkowa abstrakcja wielokrotnie wymagała dodatkowych mechanizmów w miarę jak środowiska bezpieczeństwa stawały się coraz bardziej skomplikowane.

Co reprezentuje token?

Wróćmy do wcześniejszego przykładu. Użytkownik prosi o utworzenie dokumentu, sztuczna inteligencja decyduje się na wywołanie narzędzia MCP, a serwer otrzymuje token dostępu OAuth2. Co oznacza ten token? Może to być człowiek-uzyskujący dostęp, aplikacja AI, klient MCP, serwer MCP działający w imieniu człowieka lub jakaś kombinacja aplikacji i użytkownika. Nie są one równoważne, a w nieco innych, lecz w pełni uzasadnionych schematach OAuth2, może wystąpić którykolwiek z nich.

Jest to tym ważniejsze, gdy serwer MCP wywołuje inną API.

Obecnie kilka domen autoryzacji się pokrywa. Zanim serwer podejmie działanie, może musieć ustalić tożsamość użytkownika, agenta wykonywającego zadanie, klienta MCP, który wysłał żądanie, to, co zostało zatwierdzone przez użytkownika, narzędzia, których może używać agent, dostępne API oraz to, czy dane działanie mieści się w ramach pierwotnych uprawnień. To znacznie więcej niż pokazana poniżej prosta struktura.

Zdezorientowany zastępca

Jednym z najpoważniejszych zagrożeń bezpieczeństwa w MCP jest błąd ze strony zastępcy. Załóżmy, że serwer MCP otrzymuje token przeznaczony dla niego samego, a następnie wywołuje API poniżej w łańcuchu. Niedbała implementacja może po prostu przekazać ten token, a właśnie takie zachowanie ma zapobiec obecna instrukcja bezpieczeństwa MCP. Zgodnie ze specyfikacją serwer musi sprawdzić, czy token został wydany właśnie jemu, i nigdy nie może przekazać tokenu klienta innemu usłudze. Gdy potrzebuje API powyżej w łańcuchu, powinien uzyskać inny token wydany dla danego zasobu poniżej w łańcuchu. Zasada jest następująca:

a nie taka:

Pierwszy model tworzy oddzielne granice zaufania. Dodanie bramy MCP dodatkowo komplikuje sprawę, ale zasada pozostaje ta sama: nigdy nie przekazywać tokenów w dół łańcucha.

Role OAuth2 w MCP

Na uproszczonym poziomie proces wygląda w ten sposób.

Serwer MCP stanowi chroniony zasób. Klient otrzymuje token dostępu, przedstawia go przy każdej operacji MCP, a serwer go weryfikuje. To jest standardowe OAuth2. Specyfikacja wzmacnia to za pomocą wskaźników zasobów (parametru resource), dzięki czemu żądanie autoryzacji określa konkretny serwer MCP, do którego odnosi się token. To jest dobre rozwiązanie, ale nie rozwiązuje magicznie wszystkich problemów z autoryzacją agentów.

Co dodaje OIDC

OAuth2 odpowiada na pytanie, do czego klient ma uprawnienia dostępu. OIDC dodaje warstwę tożsamości, która wskazuje, kim jest zautoryzowana osoba, co jest przydatne dla agentów. Dostawca tożsamości może zautoryzować użytkownika na przykład w następujący sposób:

Alice

OIDC może dostarczyć informacje o tożsamości użytkownika, OAuth2 może zapewnić upoważnienie delegowane, a klient MCP może następnie otrzymać token dostępu reprezentujący upoważnienie przyznane klientowi do konkretnej zasoby. Koncepcyjnie wygląda to w ten sposób.

Jednak nadal istnieje luka koncepcyjna. Autoryzacja użytkownika nie oznacza autoryzacji każdej z decyzji agenta. Użytkownik może pozwolić aplikacji na odczytanie swojej poczty e-mail, co nie jest tym samym, co pozwolenie agentowi AI na wysłanie dowolnej poczty, którą sam zdecyduje się wysłać. To jest problem polityki.

Problemy z zakresami

Zakresy są często przedstawiane jako rozwiązanie. Przykład upoważnienia typu calendar-read wygląda w ten sposób.

scope=calendar.read

i taka dotacja na wysyłkę.

scope=email.send

Ale systemy agentowe ujawniają, jak ogólne są te zakresy. Weźmy na przykład zwykłe uprawnienie do wysyłania e-maili.

email.send

Czy umożliwia sztucznej inteligencji wysyłanie wiadomości do kogokolwiek? Wysyłanie nieograniczonej liczby wiadomości? Wysyłanie dokumentów finansowych lub poufnych danych korporacyjnych? Przebieranie się za użytkownika? Wysyłanie wiadomości bez proszenia o potwierdzenie? W opisie nie jest to określone. Prawdziwa decyzja może wymagać dodatkowego kontekstu w tym kierunku.

Subject
Agent
Tool
Action
Resource
Target
Context
Risk
Time
Policy

To bardziej przypomina autoryzację opartą na zasadach niż tradycyjne zakresy OAuth2. Mówiąc językiem starszym, jest to różnica pomiędzy decyzjami autoryzacyjnymi o grubych a drobnych granulacjach.

Agent jako nowy podmiot bezpieczeństwa

To może być najważniejsza zmiana koncepcyjna. Tradycyjne aplikacje zazwyczaj mają dość stabilną tożsamość. Agent AI może być tworzony dynamicznie, z kilku części jednocześnie.

Kto więc jest podmiotem bezpieczeństwa? Prawdopodobnie wszystkie one. System autoryzacji może potrzebować wyrażenia czegoś więcej niż tylko „Alice może uzyskać dostęp do Salesforce”. Może być konieczne stwierdzenie, że Alice upoważniła tego konkretnego agenta, działającego w ramach tej konkretnej aplikacji, do wykonywania określonych działań wobec tego tenanta Salesforce, zgodnie z określonymi zasadami. To znacznie bogatsze stwierdzenie.

To podobne do każdego systemu przechowującego w pamięci tymczasowej wiele tokenów dostępu pochodzących z dużego grona użytkowników, zarówno ludzi, jak i aplikacji, aby uzyskać dostęp do licznych zasobów. Pytanie brzmi, czy można ufać agencie, że będzie chronił te tokeny i wybierze właściwy, gdy nadejdzie czas na działanie w imieniu danego użytkownika.

Czy OAuth2 nie nadaje się dla agentów?

To wnioski nie są uzasadnione. Lepiej powiedzieć, że OAuth2 rozwiązuje część problemu autoryzacji agentów, a cały problem jest większy niż OAuth2. Doskonale radzi sobie z dostępem delegowanym, który ustanawia w ten sposób.

Ekosystem agentów wymaga więcej odpowiedzi: który agent działa w imieniu której osoby, za pomocą jakiego narzędzia, w jakim celu, do jakiego zasobu, pod jakimi uprawnieniami i zasadami, na jak długo, w ramach jakich ograniczeń transakcyjnych i z jaką zatwierdzeniem ze strony człowieka. Posiadanie tokena dostępu nie eliminuje żadnego z tych pytań.

Nowe propozycje

Widoczne są kilka kierunków rozwoju.

GNAP

Najbardziej oczywistym kandydatem opartym na standardach jest GNAP, czyli Grant Negotiation and Authorization Protocol. Został stworzony, aby przezwyciężyć ograniczenia związane z autoryzacją i delegowaniem w stylu OAuth2, oferując możliwość delegowania uprawnień oprogramowaniu oraz przekazywania mu wynikających z tego elementów, obejmujących zarówno dostęp do API, jak i informacje o podmiocie. Jego projekt zakładał bardziej zaawansowane mechanizmy delegowania niż te dostępne w OAuth2. GNAP jest obecnie proponowanym standardem IETF pod numerem RFC 9635, a RFC 9767 dotyczy połączeń z serwerami zasobów. Odpowiada on na pytanie, czy ktoś zaproponował coś ponad OAuth2, jednak nie stanowi zamiennika specyficznego dla MCP, a OAuth2 pozostaje dominujący.

Protokoły bezpieczeństwa specyficzne dla MCP

Naukowcy proponują również protokoły oparte na MCP i sztucznej inteligencji agentowej. Secure Model Context Protocol (SMCP) rozszerzyłby MCP o zintegrowane zarządzanie tożsamościami, wzajemną autoryzację, propagację kontekstu bezpieczeństwa, ścisłe egzekwowanie zasad oraz rejestrację działań. Inna propozycja, MCPSec, zakłada weryfikację umiejętności agenta oraz autoryzację wiadomości w celu przeciwdziałania zagrożeniom specyficznym dla MCP. Te działania pokazują, że autoryzacja to nie jedyne wyzwanie – ekosystem agentów może musieć określić nie tylko to, kim jesteś, ale także jakie umiejętności sobie przypisujesz oraz czy te twierdzenia można sprawdzić kryptograficznie. To prowadzi w kierunku bezpieczeństwa opartego na umiejętnościach.

Uprawnienia oparte na umiejętnościach

To może okazać się ważniejsze niż zastąpienie OAuth. Zamiast przyznać agentowi zakres email.send, system mógłby mu przekazać ściśle zdefiniowaną umiejętność.

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

Agent posiada kryptograficznie weryfikowalny dokument upoważnienia i nie może wykorzystać tej uprawnień do niczego innego. To jest znacznie bliższe temu, czego potrzebują systemy oparte na agentach, ponieważ agent nie jest jedynie autoryzowany – otrzymał konkretne uprawnienia.

OAuth2 w połączeniu z czymś jeszcze

Ostateczna architektura prawdopodobnie nie ogłosi OAuth2 martwym standardem. Będzie wyglądać mniej więcej w ten sposób.

OAuth2 nadal wydaje tokeny dostępu, OIDC ustala tożsamość osoby, MCP dostarcza protokołu narzędzi, system możliwości lub zasad ogranicza to, co agent może faktycznie robić, a punkt egzekwowania zasad dokonuje ostatecznego wywołania.

Brakujący element: intencja

Intencja to coś, z czym tradycyjna autoryzacja nie została zaprojektowana, aby sobie z tym poradzić. Załóżmy, że użytkownik prosi agenta o znalezienie lotu do Manili za mniej niż 1000 dolarów i jego rezerwację. W trakcie tego procesu agent może wyszukiwać linie lotnicze, porównywać ceny, sprawdzać kalendarz, otwierać dane paszportu, rezerwować miejsce i dokonywać płatności. Użytkownik nigdy nie zatwierdził indywidualnie każdej z tych żądań API. Zatwierdził jedynie intencję, co znacznie odróżnia się od konwencjonalnej autoryzacji w sieci, ponieważ agent przekształca ogólną instrukcję w serię działań wykonywanych przez maszynę. System bezpieczeństwa może potrzebować rozważenia następujących kwestii.

Dlatego twierdzenie, że OAuth2 nie nadaje się dla agentów, ma w sobie ziarno prawdy, o ile krytykę interpretuje się poprawnie. OAuth2 może autoryzować każde wezwanie. Nie zapewnia on jednak w sposób wrodzony pełnego sposobu na ocenę, czy te wezwania odpowiadają intencji osoby oraz uprawnieniom delegowanym agentowi.

MCP jako przypadek testowy

MCP zmusza społeczność zajmującą się tożsamością i bezpieczeństwem do zmierzenia się z problemem, który narasta od lat. OAuth2 został zaprojektowany wokół tej łańcuchowej struktury.

Sztuczna inteligencja typu agencyjny wprowadza coś zupełnie innego.

Łańcuch ten staje się dynamiczny – uczestnicy mogą się zmieniać, agent podejmuje decyzje, narzędzia są odkrywane w trakcie działania, a usługa końcowa może w ogóle nie znać oryginalnego użytkownika. Mimo to system nadal musi odpowiedzieć, kto zatwierdził daną akcję, co jest znacznie trudniejszym pytaniem.

OAuth2 nie zniknie

Kuszące jest twierdzenie, że OAuth2 istniał przed sztuczną inteligencją, więc nie może być z nią używany. To zbyt uproszczone. OAuth2 przetrwał ogromne zmiany w internecie, ponieważ stanowi naprawdę przydatną ramę delegacji, a specyfikacja MCP jest wyraźnie oparta na OAuth 2.1 i go nie porzuca. Bardziej prawdopodobną przyszłością jest ewolucja:

• OAuth2 jako podstawa
• OIDC do zarządzania tożsamością
• MCP do standardowej interakcji z narzędziami
• DPoP oraz powiązane z nim mechanizmy dla silniejszego wiązania tokenów
• Wskaźniki zasobów służące do powiązania tokenów z przeznaczonymi im zasobami
• Systemy umiejętności służące do ograniczenia tego, co mogą robić agenci
• Silniki polityk do oceny kontekstu
• Nowsze protokoły, takie jak GNAP, zapewniające bogatszą semantykę delegacji

Zmiana w jednej koncepcji

Sztuczna inteligencja oparta na agentach nie stwarza głównie nowego problemu autoryzacji. Nowymi problemami są upoważnianie i delegacja. Autoryzacja pyta, kim jesteś, natomiast OAuth2 pyta, do czego masz dostęp. Upoważnianie w modelu agentowym musi określić, jaka władza została delegowana temu agentowi, w imieniu kogo, wobec jakich zasobów i pod jakimi ograniczeniami, oraz czy dana akcja mieści się w tych ramach. To bardziej złożone pytanie, które prawdopodobnie wymaga bardziej zaawansowanego modelu bezpieczeństwa.

Przyszłość prawdopodobnie nie będzie polegać na konfrontacji OAuth2 z czymś nowym. Bardziej prawdopodobne jest, że to OAuth2, OIDC, MCP, mechanizmy określania możliwości, zasady, silniejsze zabezpieczenia kryptograficzne oraz delegacja uwzględniająca agenty będą współpracować ze sobą. MCP po prostu sprawia, że ograniczenia istniejącej architektury tożsamości stają się nie do zignorowania, co może okazać się jednym z jego najważniejszych wkładów w ekosystem sztucznej inteligencji.