Miałeś swoje narzędzia MCP działające jak w zegarku. Slack, GitHub, Jira, baza danych — wszystko podłączone przez MCP, uniwersalny standard wtyczek dla narzędzi AI. Wkleiłeś klucze API do JSONa, odpaliłeś lokalnie i poczułeś się jak wiedźmin. Wszystko gadało ze wszystkim.

A potem weszło ci security. Gdzie trzymasz te dane uwierzytelniające? Jak się rotują? Kto jeszcze ma do nich dostęp? Odpowiedź na wszystkie trzy: nikt nie wie. A ten cichy niepokój, który poczułeś? Pomnóż go przez każdą firmę próbującą przenieść agentów AI z dema na produkcję.

W kwietniu 2026 wszystkie trzy główne platformy AI wypuściły swoje rozwiązania uwierzytelniające dla MCP — i żadne z nich nie zgadza się z pozostałymi, jak to powinno działać.

Jeden protokół, trzy sejfy

9 kwietnia Anthropic uruchomił Managed Agents z Credential Vault — szyfrowanym proxy, które pobiera twoje sekrety, żeby kod agenta nigdy nie dotknął prawdziwych danych uwierzytelniających. OAuth z automatycznym odświeżaniem, statyczne bearer tokeny, cały zestaw. Limit 20 poświadczeń na vault, bo najwyraźniej bezpieczeństwo enterprise'owe ma kartę z pieczątkami.

15 kwietnia OpenAI zaktualizował swoje Agents SDK. Ich propozycja: wrzuć bearer token w nagłówku, sam ogarniaj odświeżanie. Potrzebujesz OAuth? Zbuduj sobie. Ale tu jest komedia: ChatGPT Apps wymagają OAuth 2.1 — bearer tokeny odrzucone na wejściu. Jedna firma, która wysyła SDK mówiące 'tokeny są OK" i produkt mówiący 'absolutnie nie". OpenAI prowadzi publiczną kłótnię sam ze sobą o uwierzytelnianie, a deweloperzy mogą sobie wybrać stronę.

17 kwietnia Google wypuścił ADK 1.0 — później zaprezentowany na Cloud Next 22 kwietnia. Pięć typów poświadczeń, w tym konta usługowe, Application Default Credentials i flow OAuth z pauzą i wznowieniem. Działa pięknie — jeśli już złożyłeś przysięgę wierności GCP. Dla reszty to pełna przeróbka auth z googlowym akcentem.

Trzy sprytne podejścia. Trzy niekompatybilne systemy. MCP miał być USB dla AI. Okazuje się, że do każdego portu potrzebujesz innej ładowarki.

Specyfikacja, której nikt nie przestrzega

Specyfikacja MCP (wersja 2026-03-15) wymaga OAuth 2.1 z resource indicators — poprawnie ograniczone tokeny, porządne bezpieczeństwo, cały pakiet. Na papierze temat zamknięty.

W praktyce ekosystem nie dostał memo. Jak pisaliśmy w ubiegłotygodniowej analizie łańcucha dostaw, serwery MCP mają fundamentalny problem z higieną — większość serwerów społecznościowych wciąż opiera się na statycznych kluczach API siedzących w plikach konfiguracyjnych. Audyt AgentSeal z 10 kwietnia obejmujący 1808 serwerów wykazał, że dwie trzecie jest nafaszerowane podatnościami — od obejścia autoryzacji po command injection. Nic z tego się nie poprawiło przez dwa tygodnie.

Ale aspekt stricte autoryzacyjny jest tu ważniejszy: spośród partnerów startowych trzech platform, prawie żaden nie implementuje OAuth 2.1 zgodnie ze specyfikacją. Credential Vault Anthropica zadebiutował z Notion, Asaną i Sentry — trzy zarządzane integracje z setek serwerów, których deweloperzy faktycznie używają. Dokumentacja Google ADK prezentuje pięć wzorców auth, ale w przykładach domyślnie używa kluczy API. SDK OpenAI całkowicie odpuszcza — 'przynieś własne auth" oznacza, że większość deweloperów przynosi ścieżkę najmniejszego oporu: statyczny token skopiowany z dashboardu.

Dlaczego ta luka? OAuth 2.1 wymaga infrastruktury po stronie serwera. Samotny deweloper utrzymujący open-source'owy konektor MCP w weekendy nie ma token endpoint, serwera przekierowań ani flow odświeżania. Jak ujął to jeden sfrustrowany maintainer w wątkach społecznościowych: "Po prostu nienawidzę tego, że klienci nie wspierają jednocześnie OAuth i kluczy API, więc muszę wspierać oba!" Specyfikacja wymaga tego, czego ekosystem nie jest w stanie dostarczyć.

Prawdziwy koszt: napisz raz, zamknij się wszędzie

Model auth każdej platformy ma sens wewnętrznie. Anthropic gra korporacyjnego rodzica — zamyka szafkę z lekarstwami, żeby dzieci się nie otruły. Google wykorzystuje swój cloudowy stos tożsamości — wydajne, jeśli już się wprowadziłeś do domu GCP. OpenAI maksymalizuje wolność dewelopera — co jest dyplomatycznym sposobem na powiedzenie, że nie chcieli budować infrastruktury auth i nazwali to ficzerem.

Zbiorowy koszt to vendor lock-in na warstwie poświadczeń. Narzędzie podłączone do Credential Vault Anthropica nie działa w Google ADK bez przepisania auth. Narzędzie polegające na kontach usługowych GCP jest bezużyteczne w SDK OpenAI. MCP obiecał 'napisz raz, podłącz gdziekolwiek". Auth zamienił to w 'napisz raz, potem napisz uwierzytelnianie jeszcze raz dla każdej platformy". To samo narzędzie, trzy rachunki za podatek integracyjny.

Raport bezpieczeństwa MCP od Futurum Group ujął to klarownie: "Pytanie, które faktycznie zadają przedsiębiorstwa, nie brzmi, czy MCP działa. Brzmi, czy mogą zarządzać tym, co robi."

Twój zespół security wciąż czeka

Pamiętasz ich? Wciąż stoją w twoich drzwiach. Tyle że teraz zamiast jednej niewygodnej odpowiedzi musisz im dać trzy — każda zamykająca cię w innej platformowej teologii tego, jak powinny działać poświadczenia.

Jeśli oceniasz narzędzia MCP pod produkcję, sprawdzenie funkcjonalności to za mało. Ten konektor Slacka mruczący sobie w Claude Managed Agents? Dolicz pełną przeróbkę auth na Google ADK. Twój zespół wybrał SDK OpenAI dla "elastyczności"? Baw się dobrze budując OAuth od zera, podczas gdy ChatGPT Apps odmawiają użycia tego, co zbudowałeś.

MCP ma jeden protokół i trzy religie poświadczeń. Protokół działa. Ta "uniwersalna" część rozleciała się na warstwie uwierzytelniania — dokładnie tam, gdzie dema stają się wdrożeniami. Kto sprawi, że auth zgodne ze standardami będzie bezbolesne dla ludzi, którzy faktycznie budują serwery MCP, a nie tylko ich używają, ten przejmie rynek produkcyjny. Na razie — nikt. Dostawcie więcej krzeseł dla security — to spotkanie potrwa długo.