AWS opisał przykład tożsamości agentów AI opartej na certyfikatach X.509, podpisanych żądaniach i delegowaniu uprawnień przez użytkownika. Tożsamość agenta i autoryzacja transportu MCP rozwiązują różne problemy: specyfikacja MCP przewiduje opcjonalną autoryzację OAuth dla transportu HTTP, a przykład AWS dodaje między innymi dowód, który agent podpisał konkretne żądanie.
Przykład łączy usługi AWS z platformą EJBCA firmy Keyfactor. AWS opublikował tutorial 20 października 2026 r.; opisuje on architekturę referencyjną, a nie wdrożenie produkcyjne.
Autoryzacja MCP a tożsamość agenta
Autoryzacja MCP określa, jak klient uzyskuje dostęp do chronionego serwera. Certyfikat X.509 może natomiast pomóc potwierdzić tożsamość agenta i sprawdzić podpisane przez niego żądanie. W przykładzie AWS oba mechanizmy należą do odrębnych warstw kontroli.
| Mechanizm | Zakres | Co sprawdza lub umożliwia | Transport lub granica zaufania |
| Opcjonalna autoryzacja OAuth w MCP | Dostęp klienta do chronionego serwera na rzecz właściciela zasobu | Serwer sprawdza token dostępu, w tym jego odbiorcę | Transport HTTP; specyfikacja zaleca, by implementacje STDIO pobierały dane dostępowe ze środowiska |
| Tożsamość X.509 w przykładzie AWS | Tożsamość agenta, jego żądania i delegowanie przez użytkownika | Podpis żądania, certyfikat agenta, delegowanie i powiązanie tożsamości | Użytkownik–system, agent–agent oraz agent–serwer narzędzi |
Specyfikacja MCP określa autoryzację jako opcjonalną. Dla transportu HTTP opisuje mechanizm oparty na OAuth; implementacjom używającym STDIO zaleca korzystanie z danych dostępowych ze środowiska. Autoryzacja transportu nie zastępuje mechanizmów potwierdzających tożsamość konkretnego agenta ani podpisu jego żądania.
Trzy granice zaufania w przykładzie AWS
AWS dzieli przepływ na trzy granice: użytkownik–system, agent–agent oraz agent–serwer MCP. Pierwsza wiąże zgodę użytkownika z agentami, druga pozwala odbiorcy sprawdzić podpisane żądanie od innego agenta, a trzecia sprawdza uprawnienia przed wywołaniem narzędzia.
Od logowania do decyzji serwera MCP
Użytkownik loguje się przez Keycloak. Aplikacja wymienia token sesyjny na token z ograniczonym odbiorcą, przeznaczony dla serwera MCP. Agent otrzymuje ten węższy token, a nie pełny token sesyjny.
Aplikacja generuje lokalnie parę kluczy RSA o długości co najmniej 2048 bitów i wysyła do EJBCA żądanie certyfikacyjne zawierające klucz publiczny. Klucz prywatny nie trafia do EJBCA. Aplikacja przechowuje go wraz z certyfikatem w AWS Secrets Manager.
Następnie użytkownik podpisuje asercję delegowania. Zawiera ona odciski SHA-256 certyfikatów agentów, tożsamość użytkownika oraz czas wystawienia i wygaśnięcia. W ten sposób przykład wiąże uprawnienie agenta z konkretnym certyfikatem, zamiast przekazywać agentowi klucz prywatny użytkownika.
Gdy agent wysyła żądanie do innego agenta, podpisuje jego treść, nazwę narzędzia, argumenty, znacznik czasu i nonce. Podpis wykorzystuje RSA-PSS-SHA256. Agent odbierający sprawdza między innymi podpis, aktualność żądania, unikalność nonce, zaufanie do łańcucha certyfikatów, rolę nadawcy i status certyfikatu w OCSP.
Serwer MCP sprawdza token i jego odbiorcę, podpisaną kopertę żądania oraz asercję delegowania. Porównuje też nazwę użytkownika z tokenu z podmiotem delegowania i nazwą w certyfikacie agenta. Dopiero po tych kontrolach przykład dopuszcza wywołanie narzędzia.
Nonce, czas ważności i unieważnianie
Każda koperta zawiera losowy nonce o długości 128 bitów. Domyślne okno aktualności żądania wynosi 60 sekund. Pamięć podręczna przechowuje nonce przez dwukrotność skonfigurowanego maksymalnego wieku koperty, by odrzucić ponowne użycie tej samej wartości. Ponowiona operacja wymaga nowej koperty i nowego nonce.
Przykładowy profil certyfikatu ustawia jego ważność na siedem dni. AWS opisuje sprawdzanie statusu certyfikatu przez OCSP przy każdym żądaniu, a niedostępność OCSP traktuje jako powód do odmowy. W architekturze unieważnienie certyfikatów użytkownika i agentów, usunięcie sekretów oraz zakończenie sesji Keycloak składają się na procedurę wylogowania.
Wymagania i przeznaczenie demonstracji
Przykład wymaga Keycloak w wersji 26.2 lub nowszej do standardowej wymiany tokenów RFC 8693 oraz Pythona 3.9 lub nowszego. Potrzebuje też EJBCA Enterprise z REST API V1 i responderem OCSP, a po stronie AWS dostępu do Amazon Bedrock, Amazon RDS for MySQL, Amazon SES i AWS Secrets Manager. Architekturę zbudowano z użyciem AWS Strands Agents SDK i FastMCP.
README repozytorium AWS Samples określa projekt jako demonstrację do nauki i rozwoju. Do zastosowania produkcyjnego wymagane są dodatkowe wzmocnienie zabezpieczeń i przegląd.
