dokumenty metadanych klienta

Dokumenty metadanych klienta — mechanizm identyfikacji klienta MCP przez opis dostępny pod stałym adresem, zamiast dynamicznej rejestracji u każdego serwera osobno. Formalnie zastępuje Dynamic Client Registration w specyfikacji 2026-07-28. Tożsamość klienta da się dzięki temu sprawdzić i wycofać w jednym miejscu.

W Polsce nazywane też:

metadane klientatożsamość klienta MCP

Zanim klient MCP połączy się z serwerem, musi zostać przez niego rozpoznany. Sposób, w jaki to się dzieje, właśnie się zmienia.

Czym są dokumenty metadanych klienta

CIMD to mechanizm, w którym klient jest identyfikowany przez dokument opisujący go, dostępny pod stałym adresem, zamiast rejestrować się dynamicznie u każdego serwera z osobna. Serwer pobiera opis klienta z podanego adresu i na tej podstawie prowadzi autoryzację.

Co zastępuje

Dotychczasowe podejście opierało się na dynamicznej rejestracji klientów: klient zgłaszał się do serwera i otrzymywał świeży identyfikator. Przy układzie, w którym jeden klient łączy się z dziesiątkami serwerów, oznaczało to dziesiątki niezależnych rejestracji, każdą do osobnego utrzymania i unieważnienia.

Specyfikacja 2026-07-28 formalnie odchodzi od tego modelu na rzecz dokumentów metadanych.

Dlaczego to porządkuje bezpieczeństwo

Tożsamość klienta przestaje być czymś, co powstaje przy każdym połączeniu, a staje się czymś, co można sprawdzić i wycofać w jednym miejscu. Przy agentach, gdzie długowieczne poświadczenia rozsiane po wielu usługach są znaną słabością, to zmiana idąca we właściwą stronę.

Kontekst

Zmianie towarzyszy walidacja wystawcy zgodnie z RFC 9207 — element utwardzania autoryzacji, które w tej wersji specyfikacji objęło kilka obszarów naraz.

zarządzana autoryzacja korporacyjnaRozszerzenie MCP odpowiadające na potrzeby autoryzacji w organizacjach: centralne zarządzanie dostępem agentów do serwerów i zgodność z rzeczywistymi wdrożeniami OAuth i OpenID Connect. Powstało, bo rdzeń nie rozstrzygał układu „jeden klient, wiele serwerów o różnych właścicielach".bezstanowy rdzeń MCPArchitektura wprowadzona w specyfikacji 2026-07-28, w której stan podróżuje w treści komunikatów zamiast być trzymany przez konkretną instancję serwera. Umożliwia skalowanie poziome i odporność na zerwane połączenia. Towarzyszą jej nagłówki HTTP z nazwą metody i narzędzia oraz deterministyczna kolejność list, stabilizująca cache promptu.OAuth dla agentówAdaptacja standardu OAuth 2.0 do przypadku gdzie autoryzację przeprowadza autonomiczny agent AI — wymagająca rozwiązania problemów specyficznych dla agentów: bezpiecznego przechowywania tokenów bez narażenia modelu językowego, odnowienia tokenów bez interakcji użytkownika i ograniczenia zakresu uprawnień do minimum.Wyciek poświadczeńNieautoryzowane ujawnienie poświadczeń uwierzytelniających — kluczy API, tokenów, haseł — przez agenta AI: przez złośliwy atak nakłaniający agenta do ich ujawnienia, błąd konfiguracji który przechowuje credentials niezabezpieczenie, lub włączenie ich do odpowiedzi przez nieuwagę. Moltbook case study: 1,5 miliona API keys w plaintext w bazie danych.Tożsamość agentaMechanizmy weryfikacji tego, kim jest agent odwiedzający stronę — czy jest tym za kogo się podaje, kto go wysłał i jakie ma uprawnienia do działania w imieniu użytkownika.