AWS Bedrock AgentCore: Serverloser MCP-Proxy mit IAM, OAuth 2.0 JWT und CloudWatch-Observability für Enterprise-Governance

AWS veröffentlichte am 29. April 2026 eine Referenzarchitektur für die Bereitstellung eines benutzerdefinierten MCP-Proxys als serverlosen Workload auf Amazon Bedrock AgentCore Runtime. Die Implementierung richtet sich direkt an Organisationen, die bereits Governance- und Compliance-Logik für KI-Tools haben, aber ihre bestehende Infrastruktur nicht in Lambda-Funktionen oder Sidecar-Container umstrukturieren möchten. Autor des Beitrags ist Nizar Kheir, Senior Solutions Architect bei AWS.

Wie ist die Architektur der MCP-Proxy-Schicht aufgebaut?

Das System besteht aus drei Schichten, die sich gegenseitig unabhängig authentifizieren. Die MCP-Client-Schicht enthält die Agenten-Workloads auf dem AgentCore Runtime. Die MCP-Proxy-Schicht ist der benutzerdefinierte Vermittler, der die Governance-Logik verarbeitet – diese Schicht ist die Neuerung der Ankündigung. Die Upstream-Server-Schicht enthält bestehende MCP-Endpunkte (AgentCore Gateway, selbst gehostete Server, Drittanbieterdienste). Der Proxy leitet Anfragen transparent weiter und wendet dabei eigene Transformationen an, sodass bestehende Tools nicht wissen müssen, dass ein Proxy im Pfad liegt.

Wie erkennt der Proxy vorgelagerte Tools und authentifiziert Aufrufe?

Der Proxy verwendet das FastMCP-Framework für die dynamische Erkennung vorgelagerter Tools beim Start über eine tools/list-Anfrage – die Tools werden anschließend lokal ohne manuelle Registrierung erneut bereitgestellt. Für die Authentifizierung werden zwei Methoden unterstützt: IAM/SigV4, bei dem der Proxy die Ausführungsrolle übernimmt und ausgehende Anfragen automatisch signiert, sowie OAuth 2.0 Client Credentials Grant mit JWT-Bearer-Token, die im Speicher gecacht und automatisch aktualisiert werden. Integrierte Observability wird durch CloudWatch Logs und OpenTelemetry-Integration bereitgestellt.

Welche konkreten Governance-Beispiele nennt die AWS-Referenz?

Zwei Beispiele veranschaulichen die Stärke des Ansatzes. PII-Tokenisierung: Der Proxy fängt Tool-Argumente ab, ersetzt sensible Daten (persönliche IDs, Kartennummern) durch reversible Token, bevor er sie an das Backend-System sendet, und kehrt die Token in der Antwort um – das Backend sieht niemals rohe PII-Daten. Identity-based Tool Restriction: Richtlinienprüfungen in Tool-Handlern schränken ein, welche Tools ein bestimmter Aufrufer aufrufen darf; optional wird die tools/list-Antwort gefiltert, sodass der Aufrufer keine Tools sieht, für die er keine Berechtigung hat. Kheir betont: „Jede Schicht in dieser Architektur authentifiziert sich unabhängig. Sie injizieren Ihre eigene Logik auf der MCP-Protokollschicht durch den Proxy, während der vorgelagerte Server weiterhin Tools ausführt und seine eigene Autorisierung verwaltet.“ Das GitHub-Repository enthält automatisierte setup_and_deploy.py-Skripte für IAM-Rolle, Container-Build und AgentCore-Deployment.