MCP opublikowało stabilną specyfikację „Enterprise-Managed Authorization”; pozostałe szkice tożsamości machine-to-machine — w tym szkic OAuth client-credentials oraz dwie otwarte propozycje — pozostają nieukończone. Dla każdego, kto próbuje uruchamiać autonomiczne agenty za pomocą Model Context Protocol, oznacza to, że obecny protokół potrafi zweryfikować użytkownika-człowieka, ale nie oferuje gotowego sposobu na udowodnienie, że proces działający bez nadzoru jest tym, za kogo się podaje.
Dlaczego roadmapa ma znaczenie
Roadmapa Model Context Protocol (MCP) wymienia tożsamość i bezpieczeństwo agentów wśród swoich najważniejszych priorytetów. Zaplanowano wydanie czterech elementów: przepływu opartego na przeglądarce dla ludzi (human-centric browser flow), przepływu OAuth client-credentials dla usług, wiązania tokenów opartego na DPoP oraz mechanizmu federacji tożsamości obciążeń (workload-identity federation). Tylko pierwszy z nich — Enterprise-Managed Authorization — osiągnął status stabilny.
Co faktycznie robi stabilna specyfikacja
Enterprise-Managed Authorization pozwala administratorom IT przyznawać dostęp do serwera z poziomu jednej konsoli, zamiast wymagać od każdego pracownika zatwierdzania każdego połączenia. Przepływ ten wykorzystuje przekierowanie w przeglądarce i logowanie użytkownika, dzięki czemu osoba przy laptopie może przejść uwierzytelnianie, a następnie serwer ufa sesji tego użytkownika.
Ograniczenie jest oczywiste: proces wymaga człowieka przy klawiaturze. Agent, który działa w nocy, przetwarza dane lub odpowiada na alerty, nie ma nikogo, kto mógłby kliknąć przycisk logowania. W rezultacie każde wdrożenie zależne od agentów działających bez nadzoru nie może korzystać z jedynej specyfikacji, którą MCP obecnie gwarantuje.
Opcje w fazie szkicu i ich wady
Dwa szkice rozszerzeń mają na celu nadanie agentom własnej tożsamości:
- SEP-1932 (DPoP) – wiąże tokeny z parą kluczy publiczny-prywatny, co sprawia, że skradzione tokeny stają się bezużyteczne.
- SEP-1933 (Workload Identity Federation) – pozwala agentom dziedziczyć tożsamości już zapewnione w platformach chmurowych.
Oba rozwiązania istnieją jako otwarte pull requesty; żadne z nich nie zostało jeszcze włączone do oficjalnej specyfikacji. W międzyczasie jedyną inną udokumentowaną opcją jest przepływ OAuth client-credentials, który wymaga wstępnie zarejestrowanych sekretów. Przechowywanie tych sekretów w miejscu, w którym agent może je odczytać, tworzy klasyczną powierzchnię ataku: jeśli sekret wycieknie, każdy napastnik może podszyć się pod agenta.
Praktyczne kroki dla środowisk produkcyjnych już dziś
Ponieważ protokół nie zapewnia jeszcze natywnej tożsamości agenta, zespoły mogą nadal zabezpieczać agentów, przenosząc zarządzanie tożsamością poza MCP:
- Wydawaj weryfikowalne tożsamości na warstwie obciążenia (workload layer). Systemy takie jak SPIRE generują krótkotrwałe certyfikaty powiązane z korzeniem zaufania (trust root) hosta, co eliminuje statyczne sekrety.
- Kończ proces uwierzytelniania na bramie (gateway). Usługa front-endowa przechowuje klucz API lub token i przekazuje żądania w imieniu agenta, trzymając sekret poza środowiskiem uruchomieniowym.
- Autoryzuj na podstawie zweryfikowanej tożsamości, a nie zawartości tokena. Oddziel uwierzytelnianie (kto wywołuje) od autoryzacji (co może robić), aby polityka mogła być egzekwowana nawet w przypadku zmiany metody uwierzytelniania.
Na co zwrócić uwagę w przyszłości
Dwa otwarte pull requesty – wiązanie DPoP oraz federacja tożsamości obciążeń (workload-identity federation) – to jedyne drogi do prawdziwego standardu tożsamości machine-to-machine w ramach MCP. Jeśli społeczność je zaakceptuje, agenci będą mogli udowodnić posiadanie klucza prywatnego lub dziedziczyć tożsamości wydawane przez chmurę bez narażania sekretów. Do tego czasu każde wdrożenie produkcyjne musi polegać na zewnętrznych ramach tożsamości lub zaakceptować ryzyko związane ze statycznymi poświadczeniami.
Wniosek jest jasny: MCP może obecnie uwierzytelnić osobę stojącą za żądaniem, ale nie uwierzytelnia jeszcze oprogramowania, które to żądanie wysyła. Zespoły potrzebujące bezpiecznych autonomicznych agentów nie powinny czekać na finalizację specyfikacji; muszą budować tożsamość na warstwie obciążenia już dziś i śledzić oczekujące propozycje dotyczące DPoP oraz federacji.