AWS pokazuje, ile naprawdę waży "produkcyjny" serwer MCP

AWS opublikował 30 czerwca obszerny przewodnik, który krok po kroku buduje serwer MCP dla sklepu internetowego i podłącza go do Mistrala. Model Context Protocol pozwala modelowi rozmawiać z zewnętrznymi narzędziami przez jeden wspólny serwer: piszesz serwer wystawiający zestaw funkcji, a różni klienci AI podłączają się do niego bez osobnej integracji dla każdego. Sklep z tytułu jest tu tylko przykładem. Prawdziwą treścią jest architektura bezpieczeństwa i to, ile naprawdę waży słowo "produkcyjny".

Użytkownik pisze "pokaż moje ostatnie zamówienia". Po drugiej stronie działa Vibe, konwersacyjny klient Mistrala na przeglądarkę, iOS i Androida. Sam decyduje, że musi wywołać narzędzie get_order_history, i wysyła żądanie do serwera przez HTTPS. Do żądania dołączony jest token JWT, podpisany kryptograficznie bilet, który użytkownik dostał wcześniej, logując się przez Cognito, usługę tożsamości AWS. Zanim to żądanie w ogóle dotrze do kodu aplikacji, AgentCore Runtime, zarządzana warstwa, w której serwer po prostu działa bez twojej troski o kontenery, sprawdza token: podpis, datę ważności i to, czy klient jest na liście dozwolonych. Nieważny token leci do kosza, a kod serwera nawet się nie uruchamia.

Cała rzecz stoi na rozdzieleniu uwierzytelniania na dwie warstwy, każda z osobną odpowiedzialnością. Infrastruktura, czyli AgentCore, robi kryptografię i potwierdza, że token jest prawdziwy i niewygasły. Aplikacja dostaje token już zweryfikowany i zajmuje się tylko jednym: zamienia go na tożsamość konkretnego klienta. Token OAuth 2.1 nie nosi bowiem w sobie identyfikatora klienta, więc serwer musi jeszcze raz odpytać Cognito o pole custom:customer_id, które łączy zalogowanego użytkownika z jego zamówieniami w bazie. Dopiero z tym identyfikatorem sięga do bazy DynamoDB, i to wyłącznie po dane tego jednego klienta.