Model Context Protocol (MCP) in Apigee – Übersicht

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Auf dieser Seite wird beschrieben, wie Sie mit Apigee Ihre APIs als MCP-Tools für agentische Anwendungen verfügbar machen. MCP in Apigee ist für Organisationen mit Abo-, Pay-as-you-go- und Evaluierungstarifen verfügbar, einschließlich Organisationen mit aktiviertem Datenstandort. Ab Apigee Hybrid-Version 1.17.0 ist MCP auch für Apigee Hybrid verfügbar. Die Laufzeitdatenebene wird in Ihrem eigenen Kubernetes-Cluster und nicht auf einer von Google verwalteten Infrastruktur ausgeführt. Informationen zum Hybrid-spezifischen Installations- und Konfigurationsablauf finden Sie unter MCP in Apigee Hybrid aktivieren.

Was ist das MCP?

Das Model Context Protocol (MCP) ist ein von Anthropic entwickeltes Open-Source-Protokoll, das die Verbindung von KI-Anwendungen mit Datenquellen, Workflows und Tools standardisiert.

KI-Anwendungen können MCP verwenden, um auf Google Cloud und Apigee-Dienste als Tools zuzugreifen. In diesem Zusammenhang sind die folgenden MCP-Begriffe nützlich:

  • MCP-Host: Die KI-Anwendung oder -Umgebung, die mit dem Nutzer interagiert. Der MCP-Host verwendet Large Language Models (LLMs), um Anfragen zu verarbeiten, die externe Daten oder Tools erfordern.
  • MCP-Client: Eine Komponente im MCP-Host, die die Kommunikation zwischen dem LLM und dem MCP-Server unterstützt. Es übersetzt die Anfragen des LLM an den MCP-Server und konvertiert die Antworten des MCP-Servers für das LLM. Außerdem werden verfügbare MCP-Server gefunden und verwendet.
  • MCP-Server: Der externe Dienst, der dem LLM Kontext, Daten oder Funktionen bereitstellt und als Proxy zwischen dem LLM und dem MCP-Client fungiert.

Funktionsweise von MCP in Apigee

MCP-Endpunkte für Google, Google Cloudund Apigee implementieren die MCP-Serverspezifikation. So können konforme MCP-Clients auf sie zugreifen, um:

  • Verfügbare Endpunkte ermitteln
  • Listet die verfügbaren Tools an einem Endpunkt auf.
  • Authentifizieren Sie sich bei einem Endpunkt.
  • Tools gemäß definierten Zugriffsrichtlinien aufrufen.

Jeder MCP-Client, der Remote-MCP-Endpunkte über HTTP/S unterstützt, kann auf diese Tools zugreifen. Da die Endpunkte verwaltet werden, müssen Sie keine lokalen MCP-Server, Remote-MCP-Server oder zusätzliche Infrastruktur installieren oder verwalten, damit agentische Anwendungen auf Ihre Dienste zugreifen können.

MCP in Apigee bietet JSON-RPC-Unterstützung für tools/list- und tools/call-Methoden. Sie können Ihren MCP-Endpunkt mit Parametern für Auffindbarkeit, Sicherheit, Netzwerkverfügbarkeit und Beobachtbarkeit anpassen.

Bereitstellungsmodelle

MCP ist in zwei Apigee-Bereitstellungsmodellen verfügbar:

  • Apigee (SaaS): Die MCP-Datenebene wird auf einer von Google verwalteten Infrastruktur gehostet. Sie stellen den MCP-Discovery-Proxy bereit und der Endpunkt ist sofort verfügbar.
  • Apigee Hybrid (selbst gehostet, ab Apigee Hybrid 1.17.0): Die MCP-Datenebene wird in Ihrem eigenen Kubernetes-Cluster ausgeführt. Die Apigee-Steuerungsebene generiert die MCP-Toolkonfiguration aus Ihrer OpenAPI-Spezifikation und Ihr Cluster ruft diese Konfiguration nach einem eigenen Zeitplan ab. MCP-Anfragetraffic verlässt Ihren Cluster nie. Siehe MCP in Apigee Hybrid aktivieren.

MCP-Datenebenenarchitektur in Apigee Hybrid

Das folgende Diagramm zeigt, wie die MCP-Komponenten zwischen der Apigee-Steuerungsebene und Ihrem Apigee Hybrid-Cluster verteilt sind.

MCP in der Apigee Hybrid-Architektur: MCP-Clients rufen Ihren vorhandenen Apigee-Ingress über HTTPS auf, der die Anfrage an Ihren Message Processor und dann an die neue MCP-Datenebene im Cluster weiterleitet. Die MCP-Toolkonfiguration wird von der Apigee-Steuerungsebene generiert und von Ihrem Cluster abgerufen. Die Apigee-Steuerungsebene ruft Ihren Cluster nie auf.

Zwei Eigenschaften dieser Architektur sind für die Planung und Sicherheitsüberprüfung wichtig:

  • MCP-Anfragetraffic bleibt innerhalb Ihres Clusters. MCP-Clients greifen über dieselbe URL auf Ihren vorhandenen Apigee-Ingress zu, die sie auch für jeden anderen Apigee-Proxy verwenden würden. Der Message Processor leitet die Anfrage dann an die MCP-Datenebene im selben Cluster weiter. Keine MCP-Anfrage oder -Antwort überschreitet zum Zeitpunkt der Anfrage die Grenze zu Google Cloud .
  • Die Konfiguration wird abgerufen, nicht übertragen. Die MCP-Toolkonfiguration wird von der Apigee-Steuerungsebene generiert und von einer Komponente in Ihrem Cluster nach einem Zeitplan abgerufen. Die Apigee-Steuerungsebene initiiert nie eine Verbindung zu Ihrem Cluster. Informationen zu den genauen Endpunkten, die der ausgehende Traffic Ihres Clusters zulassen muss, finden Sie unter Anforderungen an ausgehenden Netzwerktraffic.

Wichtige Funktionen von MCP in Apigee

MCP in Apigee bietet Funktionen für die Toolerkennung, Sicherheit und Governance. Mit diesen Funktionen können Sie verwalten, wie agentische Anwendungen mit Ihren Diensten interagieren.

Vereinfachte Tool-Erkennung mit dem API-Hub

Sie können verfügbare MCP-Endpunkte für Apigee-Dienste über einen Verzeichnisdienst ermitteln, der über eine REST-Schnittstelle zugänglich ist. Jeder MCP-Endpunkt unterstützt auch die MCP-Methode tools/list, mit der MCP-Clients die in diesem Endpunkt verfügbaren Tools ermitteln können.

Außerdem lässt sich MCP in den Apigee API-Hub einbinden. Wenn ein MCP-Discovery-Proxy bereitgestellt wird, übernimmt der API-Hub automatisch seine OpenAPI-Spezifikation, weist ihm den API-Stil MCP zu und ordnet API-Vorgänge einzelnen MCP-Tools zu. So können Entwickler im API-Hub ganz einfach nach MCP-fähigen APIs filtern und die semantische Suche mit Abfragen in natürlicher Sprache verwenden, um relevante Tools für ihre agentischen Anwendungen zu finden.

Platzierung des Tool-Arguments in der Backend-Anfrage

Wenn ein MCP-Client ein Tool aufruft, erstellt Apigee aus den vom Client bereitgestellten Argumenten eine Anfrage an Ihr Backend. Der Wert in, den jeder Parameter in Ihrer OpenAPI-Spezifikation deklariert, bestimmt, wo dieses Argument in der ausgehenden Anfrage platziert wird.

OpenAPI-Wert in Wo das Argument in der Backend-Anfrage gesendet wird
header Als Anfrageheader. Der Parametername wird genau so als Headername verwendet, wie er in der Spezifikation angegeben ist.
cookie Im Anfrageheader Cookie als name=value-Paar. Wenn ein Vorgang mehrere Cookie-Parameter deklariert, werden sie in einem Cookie-Header gesendet, getrennt durch ;  (ein Semikolon und ein Leerzeichen).
query Im Abfragestring.
path Wird in den Anfrage-URL-Pfad eingefügt.

Jeder Parameter wird im inputSchema des Tools angezeigt, unabhängig von seinem in-Wert. Ein MCP-Client stellt sie also alle auf dieselbe Weise bereit. Der Wert in ändert sich nur, wenn der Wert in der Anfrage an Ihr Backend platziert wird.

Im folgenden Vorgang wird beispielsweise ein Parameter an drei verschiedenen Orten deklariert:

paths:
  /orders:
    get:
      operationId: listOrders
      parameters:
        - name: X-Session-Id
          in: header
          schema:
            type: string
        - name: tenantId
          in: cookie
          schema:
            type: string
        - name: limit
          in: query
          schema:
            type: integer

Eine tools/call-Anfrage, die alle drei Argumente bereitstellt, erzeugt eine Backend-Anfrage der folgenden Form:

GET /orders?limit=25
X-Session-Id: sess-abc-123
Cookie: tenantId=tenant-xyz-789

Beachten Sie Folgendes:

  • Ein Argument, das an einen Header oder ein Cookie gebunden ist, wird nicht an den Abfragestring angehängt und ist nicht im Anfragetext enthalten.
  • Ein Argument, das der Client nicht bereitstellt, wird übersprungen. Es wird kein leerer Header, Cookie oder Suchparameter an seiner Stelle gesendet.
  • Ein gebundener Header ersetzt alle Header mit demselben Namen, die bereits in der Backend-Anfrage vorhanden sind. Andere Header in der Backend-Anfrage werden unverändert weitergeleitet.
  • Die Werte werden bei der Platzierung in der Backend-Anfrage prozentcodiert (RFC 3986). Ein Wert, der ein Leerzeichen oder ein reserviertes Zeichen enthält, erreicht Ihr Backend also in codierter Form. Decodieren Sie sie dort, wenn Sie das Original benötigen.
  • Wenn ein Vorgang und sein Pfad einen Parameter mit demselben Namen und demselben in-Wert deklarieren, gilt die Deklaration auf Vorgangsebene, wie es die OpenAPI-Spezifikation erfordert.
  • Geben Sie Parametern für denselben Vorgang unterschiedliche Namen, auch wenn sie unterschiedliche in-Werte deklarieren. OpenAPI identifiziert einen Parameter anhand des Paars aus Name und Speicherort, aber ein MCP-Tool akzeptiert nur einen einzelnen Wert pro Argumentnamen. Wenn in einer Spezifikation zwei gleichnamige Parameter mit unterschiedlichen in-Werten deklariert werden, stellt der Client einen Wert bereit, der an beide deklarierten Speicherorte in der Backend-Anfrage gesendet wird: Ein sessionId, der sowohl als in: cookie als auch als in: query deklariert ist, kommt im Cookie-Header und im Abfragestring an. Prüfen Sie dies, wenn Ihr Backend eine Logik hat, die davon abhängt, woher ein Wert stammt.
  • Bei Argumentnamen wird die Groß-/Kleinschreibung berücksichtigt. UserID und userid sind also zwei verschiedene Argumente. Bei header-Parametern sollten Sie außerdem darauf achten, dass sich die Namen nicht nur durch die Groß-/Kleinschreibung unterscheiden: Bei HTTP-Headernamen wird die Groß-/Kleinschreibung nicht berücksichtigt. Zwei Headerparameter, deren Namen sich nur durch die Groß-/Kleinschreibung unterscheiden, werden daher in der Backend-Anfrage in denselben Header aufgelöst und nur einer der beiden Werte bleibt erhalten.

Cookies sind der einzige Fall, in dem durch die Bindung etwas aus der Anfrage entfernt werden kann, anstatt nur etwas hinzuzufügen. Im Gegensatz zu anderen HTTP-Headern, die unabhängige Name/Wert-Paare enthalten, die jeweils einzeln festgelegt werden können, verwenden alle Cookies einen einzigen Cookie-Header. Apigee führt die von Ihnen gebundenen Cookies nicht mit den Cookies zusammen, die mit der Anfrage des MCP-Clients eingegangen sind: Wenn ein Aufruf ein Cookie-Argument enthält, wird der Cookie-Header vollständig durch die gebundenen Cookies ersetzt.

Ob ein Cookie, das mit der HTTP-Anfrage des MCP-Clients eingegangen ist, Ihr Backend erreicht, hängt also vom jeweiligen Toolaufruf ab:

  • Wenn für den Vorgang keine cookie-Parameter deklariert sind, wird der Cookie-Header unverändert an das Backend weitergeleitet.
  • Wenn der Vorgang cookie-Parameter deklariert, der Aufruf jedoch keine davon bereitstellt, wird der Cookie-Header wieder unverändert an das Backend weitergeleitet.
  • Sobald der Aufruf mindestens ein Cookie-Argument liefert, wird der Header Cookie nur durch die gebundenen Cookies ersetzt. Alle Cookies, die mit der Anfrage des Clients eingehen und nicht als cookie-Parameter deklariert sind, werden verworfen.

Da der dritte Fall von den Argumenten eines bestimmten Aufrufs gesteuert wird, kann ein Vorgang mit optionalen Cookie-Parametern Cookies bei einem Aufruf weitergeben und beim nächsten verwerfen. Es gibt keine Einstellung, mit der ein nicht deklariertes Cookie beibehalten wird. Wenn Ihr Backend von einem Cookie abhängt, deklarieren Sie es als cookie-Parameter für jeden Vorgang, der es benötigt. So wird der Wert immer vom Toolaufruf bereitgestellt und nicht von der Anfrage des Clients übernommen.

Sicherheit

MCP in Apigee umfasst mehrere Sicherheitsebenen zum Schutz Ihrer Dienste. Sie können den Zugriff mithilfe von Authentifizierung, Autorisierung, Netzwerkgrenzen und Inhaltsscans steuern.

Authentifizierung

Von Apigee gehostete MCP-Endpunkte unterstützen OAuth 2.1 und OpenID Connect (OIDC) für die Authentifizierung. So wird sichergestellt, dass nur KI-Agenten, MCP-Clients und Endnutzer mit bestätigten Identitäten auf Ihre MCP-Endpunkte zugreifen und MCP-Tools aufrufen können. Mit Metadaten für geschützte Ressourcen können Clients die OAuth-Autorisierungsserver finden.

Detaillierte Autorisierungsrichtlinien

Sie können den Zugriff auf Ihre MCP-Tools basierend auf OAuth-Client-Identitäten einschränken. Sie können beispielsweise eine Richtlinie in Ihrem MCP Discovery-Proxy konfigurieren, die festlegt, dass nur bestimmte KI-Agenten mit bekannten Clientidentitäten auf ein MCP-Tool für einen Zahlungsdienst zugreifen können.

Verantwortung des Clients für Toolaufrufe

MCP-Clientanwendungen sind dafür verantwortlich, dass Toolaufrufe von Menschen überwacht werden, z. B. indem der Nutzer vor dem Ausführen von zustandsändernden Vorgängen aufgefordert wird, dies zu bestätigen. Weitere Informationen finden Sie in der Dokumentation zum Model Context Protocol.

Beobachtbarkeit und Analysen

Für von Apigee gehostete Endpunkte können Sie Apigee Analytics verwenden, um detaillierte Nutzungsinformationen für Ihre MCP-Tools aufzurufen. Mit Analytics können Sie MCP-spezifischen Traffic von Standard-API-Traffic segmentieren und Messwerte auf der Ebene einzelner Tools aufrufen, z. B. das Volumen von tools/list-Anfragen (Erkennung) im Vergleich zu tools/call-Anfragen (Ausführung). Leistungsmesswerte helfen Ihnen auch, zwischen Proxy-Overhead und Zielantwortzeit zu unterscheiden, sodass Sie Engpässe effektiver lokalisieren können.

Zuverlässigkeit und Fehlerbehebung

Um die Fehlerbehebung zu verbessern und mehr Einblick in den Bereitstellungsprozess zu bieten, zeigt Apigee bestimmte Infrastruktur- und Konfigurationsfehler in der Benutzeroberfläche an. Wenn eine Bereitstellung aufgrund einer ungültigen OpenAPI-Spezifikation oder eines regionalen Infrastrukturproblems fehlschlägt, erhalten Sie in der Benutzeroberfläche umsetzbares Feedback, mit dem Sie das Problem ohne Unterstützung des Supports beheben können.

MCP mit Apigee verwenden

Sie können Ihre vorhandenen Apigee-APIs als MCP-Tools bereitstellen und über MCP-Endpunkte zugänglich machen. Diese Endpunkte können entweder auf Host- oder Umgebungsgruppenebene konfiguriert werden. Wenn Ihre cymbal-Organisation beispielsweise acht Hostnamen hat (z.B. api.cymbal.com, partners.cymbal.com), die jeweils mit einer anderen Umgebungsgruppe verknüpft sind, können Sie für jeden Hostnamen einen dedizierten MCP-Server hosten.

Ein verwalteter Zielendpunkt (ORG_NAME.mcp.apigee.internal) wird mit einem speziellen MCP-Discovery-Proxy in Ihrer Apigee-Organisation bereitgestellt, in der Ihre MCP-Server verfügbar gemacht werden.

In der folgenden Tabelle sehen Sie ein Beispiel dafür, wie Kunden, einschließlich der fiktiven Organisation Cymbal, mehrere MCP-Endpunkte mit Apigee konfigurieren können.

Kunde Hostname und MCP-Basispfad MCP-Server-Zielendpunkt API-Proxy Umgebung / Umgebungsgruppe
cymbal api.cymbal.com/mcp cymbal.mcp.apigee.internal
(Mandantenprojekt der Cymbal-Organisation)		 mcp-api-proxy1 prod/prod-env-group
api-internal.cymbal.com/mcp cymbal.mcp.apigee.internal
(Mandantenprojekt der Cymbal-Organisation)		 mcp-api-proxy2 internal/internal-env-group
api-service.cymbal.com/mcp cymbal.mcp.apigee.internal
(Mandantenprojekt der Cymbal-Organisation)		 mcp-api-proxy3 dev/dev-env-group

Beschränkungen

Für MCP in Apigee gelten die folgenden Einschränkungen:

  • Die Anzahl der MCP-Tools in einer Apigee-Organisation ist auf 1.000 begrenzt.
  • Die Bereitstellung der MCP-Infrastruktur kann in den folgenden Regionen Kapazitätsbeschränkungen unterliegen:
    • europe-central2
    • europe-southwest1
    • europe-west9
    • me-central2

    Wenn ein Bereitstellungsfehler angezeigt wird oder sich der Bereitstellungsstatus nie in Bereitgestellt ändert, kann dies an vorübergehenden Kapazitätsbeschränkungen der Infrastruktur in der ausgewählten Region liegen. Versuchen Sie, den Proxy in einer Umgebung in einer anderen Region bereitzustellen.

  • MCP in Apigee unterstützt die folgenden OpenAPI-Versionen: 3.0.0, 3.0.1, 3.0.2, 3.0.3.
  • API-Statistiken im Apigee API-Hub sind nicht für MCP-APIs und ‑Tools verfügbar, die in Apigee-Organisationen mit aktiviertem VPC-SC bereitgestellt werden.
  • GET-Aufrufe für MCP-Fehlerantworten geben den Fehler 405 zurück, da der MCP-Server derzeit keine SSE-Streams (Server-Sent Events) unterstützt.
  • In den API-Statistiken des Apigee API-Hubs werden MCP-APIs oder Traffic für MCP-Ressourcen erst angezeigt, wenn Apigee Version 1-17-0-apigee-6 vollständig in allen verfügbaren Regionen eingeführt wurde.
  • Sie können das API-Stilattribut für eine API-Ressource mit vorhandenen API-Vorgängen nicht in MCP ändern.

Apigee Hybrid-spezifische Einschränkungen

Für MCP in Apigee Hybrid gelten die folgenden Einschränkungen:

  • Als in: header oder in: cookie deklarierte Toolargumente werden im Abfragestring gesendet. Das standortspezifische Routing, das unter Platzierung von Tool-Argumenten in der Backend-Anfrage beschrieben wird, ist in Apigee Hybrid noch nicht verfügbar. Bis dahin erreicht ein Parameter, der einen dieser Speicherorte deklariert, Ihr Backend als Suchparameter. Dies ist das Verhalten, das vor dieser Funktion galt. Die Zeilen in: query und in: path dieser Tabelle gelten für Apigee Hybrid wie beschrieben.
  • Die Anzahl der MCP-Tools ist durch die Größe begrenzt, nicht durch eine feste Anzahl. Im Gegensatz zu Apigee (wo eine feste maximale Anzahl von MCP-Tools pro Organisation erzwungen wird) begrenzt Apigee Hybrid die Toolkapazität durch vier Größenlimits: OpenAPI-Spezifikationsdateigröße, MCP-Proxy-Bundle-Größe, tools/list-Antwortgröße pro Hostname und die Anzahl der Hostnamen pro Umgebungsgruppe. Bei den meisten OpenAPI-Spezifikationen können Sie in der Regel davon ausgehen, dass 10.000 MCP-Tools pro Organisation mit dem Standardlimit für die Antwortgröße verwendet werden können. Die tatsächliche Kapazität hängt von der genauen Form Ihrer Spezifikation ab (hauptsächlich von der Anzahl der Parameter und der Eigenschaften des Anfrage-Bodys sowie der Länge der Beschreibung). Antwortschemas werden nicht auf das Budget angerechnet. Informationen zum Schätzen der Kapazität für Ihre spezifischen OpenAPI-Spezifikationen sowie zu den vier harten Limits und ihren Fehlermodi finden Sie unter MCP-Tool-Kapazität schätzen.
  • Durch das Aktivieren oder Deaktivieren von MCP wird ein gestaffeltes Canary-Release von Message Processor-Pods ausgelöst. Der Apigee-Operator aktualisiert die Pod-Spezifikation des Message Processors, wenn Sie MCP aktivieren oder deaktivieren. Der Message Processor-ApigeeDeployment-Controller führt die Änderung über ein gestaffeltes Canary-Release aus, anstatt einen standardmäßigen rollierenden Neustart von Kubernetes durchzuführen. Der Release wird nur bei den Übergängen zum Aktivieren und Deaktivieren ausgelöst, nicht bei laufenden MCP-Bereitstellungsaktivitäten oder MCP-Traffic im stabilen Zustand. Planen Sie die erste Aktivierung und alle nachfolgenden Deaktivierungen während eines genehmigten Wartungsfensters.
  • Die Größe der MCP-Pod-Ressourcen wird vom Kunden verwaltet. Die MCP-Pods werden mit den Ressourcenanfragen und -limits ausgeführt, die durch die integrierten Standardwerte in den Apigee Hybrid-Helm-Diagrammen festgelegt sind. Wenn Ihre Arbeitslast mehr Kapazität erfordert, passen Sie CPU und Arbeitsspeicher in overrides.yaml an. Die verfügbaren Felder finden Sie in der overrides.yaml-Feldreferenz.
  • Eine MCP-Datenebene pro Apigee-Organisation und Cluster. In Version 1.17.0 stellt der Apigee-Operator eine MCP-Datenebene für jede im Cluster installierte Apigee-Organisation bereit. In einem Cluster, der mehrere Apigee-Organisationen hostet, wird eine MCP-Datenebene pro Organisation ausgeführt. Die Datenebenen sind unabhängig und haben keine gemeinsame Konfiguration.
  • Eine einheitliche Aktivierung in einer Umgebungsgruppe ist erforderlich. Aktivieren Sie MCP einheitlich für alle Cluster, die dieselbe Apigee-Umgebungsgruppe bedienen. Wenn MCP in einigen Clustern aktiviert ist und in anderen nicht, erhalten MCP-Anfragen, die an einen Cluster ohne MCP weitergeleitet werden, die Antwort 503 Service Unavailable.
  • One-Way-TLS zwischen Message Processor und MCP-Datenebene. In Version 1.17.0 wird One-Way-TLS zwischen dem Message Processor und der MCP-Datenebene verwendet.
  • Die MCP-Datenebene verwendet den Message Processor für die Aufruferidentität. Die MCP-Datenebene im Cluster authentifiziert ihre Aufrufer in 1.17.0 nicht unabhängig. Sie geht davon aus, dass Anfragen, die sie erreichen, bereits von einem Apigee-Proxy authentifiziert wurden, der im Message Processor ausgeführt wird. Jede MCP-Anfrage, die authentifiziert werden soll, muss über einen Apigee-MCP-Proxy eingehen, der eine Authentifizierungsrichtlinie erzwingt (siehe Zugriff auf MCP-Tools verwalten). Produktionskunden sollten Cluster-Steuerungen für eingehenden Traffic anwenden, damit nur Message Processor-Pods (Kubernetes-Label app=apigee-runtime im selben Kubernetes-Namespace, in dem Apigee Hybrid installiert ist) den MCP-Dienst über TCP 443 erreichen können. Verwenden Sie die von Ihrer Plattform unterstützte Policy Engine (Kubernetes NetworkPolicy, Cilium, Calico, Istio AuthorizationPolicy), um diese Einschränkung zu erzwingen.

Nächste Schritte