AWS beschreibt in einem am 20. Oktober 2026 veröffentlichten Tutorial eine Referenzarchitektur, die KI-Agenten mit X.509-Zertifikaten identifiziert und ihre Anfragen kryptografisch absichert. MCP bietet daneben eine optionale OAuth-Autorisierung für HTTP-Transporte. Sie autorisiert den Zugriff auf den Transport, während die Zertifikate einzelne Agenten identifizieren und signierte Anfragen sowie die Delegation durch einen Nutzer ermöglichen.
MCP-Autorisierung und Agentenidentität erfüllen verschiedene Aufgaben
Die MCP-Spezifikation sieht eine optionale OAuth-basierte Autorisierung für HTTP-Transporte vor. Für STDIO-Implementierungen empfiehlt sie stattdessen, Zugangsdaten aus der Umgebung zu beziehen. Die MCP-Autorisierung regelt damit den Zugriff über einen Transportweg. Die X.509-Architektur von AWS ergänzt dazu eine kryptografische Identität für Agenten und prüfbare Nachweise für ihre Anfragen. Die MCP-Spezifikation zur Autorisierung beschreibt den Geltungsbereich des OAuth-Verfahrens.
| Mechanismus | Geltungsbereich | Was geprüft oder ermöglicht wird | Transport oder Vertrauensgrenze |
| Optionale MCP-Autorisierung mit OAuth | HTTP-Transport | Autorisierung von HTTP-Anfragen und Prüfung der vorgesehenen Zielressource | HTTP; für STDIO gilt ein anderer Ansatz |
| X.509-Architektur von AWS | Identität von Agenten und deren Anfragen | Zertifikatsidentität, signierte Anfragen, Nutzerdeligation und ein auf den MCP-Server begrenztes Token | Nutzer zu System, Agent zu Agent und Agent zu MCP-Server |
Drei Vertrauensgrenzen vom Login bis zum Tool-Aufruf
AWS ordnet den Ablauf drei Grenzen zu: vom Nutzer zum System, zwischen Agenten sowie vom Agenten zum MCP-Server. X.509 ist ein Standard für digitale Zertifikate. Eine PKI, eine Infrastruktur für öffentliche Schlüssel, stellt diese Zertifikate aus und ermöglicht es, Signaturen und Zertifikatsketten zu prüfen.
Nach dem OAuth-Login tauscht Keycloak das Sitzungstoken gegen ein Token ein, dessen vorgesehener Empfänger auf den MCP-Server beschränkt ist. Das vollständige Sitzungstoken wird laut AWS nicht an die Agenten weitergegeben. Jeder Agent erzeugt sein RSA-Schlüsselpaar lokal und schickt eine Zertifikatsanforderung an EJBCA Enterprise, die Zertifizierungsstelle im Beispiel. Der private Schlüssel bleibt dabei in der Anwendung und wird weder an EJBCA gesendet noch zwischen Agenten geteilt. Das Zertifikat und der private Schlüssel werden anschließend als PKCS#12-Paket in AWS Secrets Manager gespeichert.
Der Nutzer signiert eine Delegationserklärung. Sie enthält unter anderem die SHA-256-Fingerabdrücke der Agentenzertifikate sowie den Nutzerbezeichner und Angaben zu Ausstellung und Ablauf. Damit lässt sich prüfen, welche Agentenzertifikate der Nutzer autorisiert hat.
Bei einer Anfrage signiert der Agent die Nutzlast, den Tool-Namen, die Argumente, einen Zeitstempel und eine Nonce. Eine Nonce ist hier ein zufälliger Wert, der eine erneute Verwendung derselben Anfrage erkennbar machen soll. AWS beschreibt dafür RSA-PSS-SHA256. Der empfangende Agent beziehungsweise der MCP-Server prüft unter anderem Signatur, Zeitfenster, Einmaligkeit der Nonce, Zertifikatskette, Berechtigungen und Widerrufsstatus. Der MCP-Server gleicht außerdem Token, Delegation und Zertifikatsidentität miteinander ab.
Zeitfenster und Zertifikatswiderruf
Im Beispiel gilt für signierte Anfragen ein Standard-Zeitfenster von 60 Sekunden. Jede Anfrage enthält eine 128-Bit-Nonce; der Zwischenspeicher für bereits verwendete Nonces hält Einträge doppelt so lange wie das konfigurierte maximale Anfragealter. Das Beispiel-Zertifikat ist sieben Tage gültig.
AWS beschreibt eine OCSP-Abfrage, mit der der Server den Widerrufsstatus eines Zertifikats prüft. Ist der OCSP-Dienst nicht erreichbar, soll die Validierung fehlschlagen. Für einen Widerruf sieht das Beispiel vor, Nutzer- und Agentenzertifikate zu widerrufen, die zugehörigen Secrets ohne Wiederherstellungsfrist zu löschen und die Keycloak-Sitzung zu beenden.
Voraussetzungen und Einsatzbereich des Beispiels
Für die beschriebene Konfiguration nennt AWS Keycloak ab Version 26.2, Python ab Version 3.9 sowie EJBCA Enterprise mit REST API V1 und einem OCSP-Responder. Benötigt werden außerdem AWS-Zugriff auf Amazon Bedrock, Amazon RDS for MySQL, Amazon SES und AWS Secrets Manager. Die Schlüssel im Beispiel sind lokal erzeugte RSA-Schlüssel mit mindestens 2048 Bit.
Der Beispielaufbau verbindet Amazon Bedrock und das AWS Strands Agents SDK mit Keycloak, EJBCA Enterprise, FastMCP und einer MySQL-Datenbank in Amazon RDS. Das begleitende AWS-Samples-Projekt auf GitHub bezeichnet sich als Demonstration für Lernen und Entwicklung. Vor einem Produktionseinsatz seien zusätzliche Sicherheitsmaßnahmen und eine Prüfung erforderlich.
