Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # MCP-Verwaltungsstrategie Die andere wichtige Funktion, die MCP Unternehmen bietet, ist die Unterstützung zentralisierter Governance. Ihre MCP-Governance-Strategie sollte sich mit der Authentifizierung und Autorisierung sowohl der MCP-Server als auch der Ressourcen befassen, auf die sie zugreifen. Sie sollte sich auch mit der Ratenbegrenzung befassen, um nachgelagerte Ressourcen zu schützen, betriebliche Kennzahlen zur Überwachung der Nutzung und Leistung der Tools sowie die Verwaltung der Bereitstellung und Verteilung von MCP-Servern. ## Authentifizierung und Autorisierung Einer der wichtigsten Bestandteile Ihrer Authentifizierungs- und Autorisierungsstrategie ist die Verwaltung des Downstream-Ressourcenzugriffs von MCP-Servern aus. Wenn ein Benutzer einen Agenten aufruft, werden Authentifizierung und Autorisierung durchgeführt, um sicherzustellen, dass der Benutzer berechtigt ist, den Agenten anzurufen. Anschließend orchestriert der Agent den Aufruf bestimmter Tools auf MCP-Servern. Sie müssen für jedes Tool entscheiden, wie der Zugriff autorisiert werden soll. Eine Option ist die *machine-to-machine Autorisierung*, bei der keine Zustimmung oder Interaktion des Benutzers erforderlich ist. Beispielsweise verwendet ein zeitbasierter Agentenaufruf einen MCP-Server, um Protokolle von einer Anwendung zu sammeln und zu analysieren. In diesem Szenario ist der Agent vorab autorisiert, auf die angegebenen Daten zuzugreifen. Die zweite Option ist der *vom Benutzer delegierte Zugriff*, bei dem ein Benutzer seine Zustimmung zum Zugriff auf benutzerspezifische Daten und Ressourcen erteilt. Die folgende Tabelle zeigt Authentifizierungs- und Autorisierungsmuster. | | | **Faktor** | **Vom Benutzer delegierter Zugriff** | **Machine-to-machine** | | --- |--- |--- | | Eigentum an Daten | Benutzerspezifische Autorisierung von Daten | System- oder organisationsweite Daten | | Interaktion mit dem Benutzer | Der Benutzer ist anwesend und kann zustimmen | Keine Benutzerinteraktion | | Zeitpunkt des Vorgangs | Interaktiv oder in Echtzeit | Hintergrund, geplant oder stapelweise | | Umfang der Genehmigung | Die Berechtigungen variieren je nach Benutzer | Konsistente Berechtigungen auf Agentenebene | Der vom Benutzer delegierte Zugriff erfordert eine sorgfältige Implementierung und sollte zusammen mit Ihrem Sicherheitsteam entwickelt werden. Agenten müssen in der Lage sein, zu beurteilen, welche Tools ein LLM ausgewählt hat und ob für sie eine zusätzliche Autorisierung erforderlich ist. MCP-Tools müssen Beschreibungen enthalten, aus denen hervorgeht, welche Authentifizierungs- und Autorisierungsanforderungen sie haben und wo Zugriffstoken abgerufen werden können. Client-Anwendungen müssen Zwischenauthentifizierungsanforderungen unterstützen, und der MCP-Client muss die abgerufenen Anmeldeinformationen bei jedem Tool-Aufruf an den Agenten zurücksenden. Sie sollten sicherstellen, dass MCP-Tools immer über eigene Token für den Zugriff auf externe Funktionen verfügen und dass der Zugriff protokolliert und geprüft wird. Benutzeranmeldedaten sollten nicht über Ihr Agentensystem weitergegeben werden. Beispielsweise sollten Ihre MCP-Server nicht dasselbe Token für den Zugriff auf Daten verwenden, mit dem der Agent aufgerufen wurde. Downstream-Aufrufe sollten speziell generierte Token mit explizitem Gültigkeitsbereich verwenden. Dies trägt dazu bei, zusätzliche Schutzmaßnahmen bereitzustellen, um einen unbeabsichtigten Datenzugriff im Rahmen von Aktionen zu verhindern. Auf diese Weise kann auch verhindert werden, dass Halluzinationen unbeabsichtigte Folgen haben. Stellen Sie sich vor, ein Benutzer mit vollen Administratorrechten bittet einen Agenten, eine Produktionsdatenbank zur Verwendung in der Vorproduktion zu klonen. Dazu benötigt der Benutzer lediglich `CREATE` Berechtigungen`READ`. Nehmen wir an, das LLM halluziniert und glaubt, dass es im Rahmen dieser Anfrage die alte Datenbank bereinigen muss. Wenn die Anmeldeinformationen des Benutzers wiederverwendet werden, wäre dies wahrscheinlich erfolgreich, da die ursprünglichen Anmeldeinformationen des Benutzers über Berechtigungen verfügen. `DELETE` Wenn der MCP-Server stattdessen ein Token verwendet, das bewusst auf den Umfang der Daten für die Anfrage beschränkt ist `READ` und nur die `CREATE` Rechte und Rechte hat, würde der Versuch, die Produktionsdatenbank zu löschen, fehlschlagen. Sie können [Amazon Bedrock AgentCore Identity](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/common-use-cases.html) verwenden, um diese Muster zu implementieren. Stellen Sie sicher, dass Sie bewusst entscheiden, ob die Berechtigungen zum Auflisten und Aufrufen von Tools, die von einem MCP-Server gehostet werden, auch Berechtigungen für die externen Funktionen beinhalten, die der MCP-Server bereitstellt. Dieser Identitätsfluss vom MCP-Server zur Ressource und zurück zum Benutzer hängt von der Art des verwendeten Authentifizierungs- und Autorisierungsdienstes ab. Sie müssen entscheiden, wie dies in großem Umfang für Ihre MCP-Server gehandhabt wird. Implementieren Sie bei der Gestaltung Ihrer Authentifizierungs- und Autorisierungsmuster Mechanismen zur Token-Isolierung, die für jedes Tool, auf das zugegriffen wird, unterschiedliche Zugriffstoken abrufen. Verwenden Sie Token nicht erneut zwischen Tools und Servern. AgentCore Identity bietet diese Fähigkeit zur Token-Isolierung. Es verwaltet automatisch sowohl Workload-Token (zur machine-to-machine Authentifizierung) als auch Benutzertoken (für vom Benutzer delegierten Zugriff), um eine korrekte Trennung sicherzustellen und eine Eskalation von Berechtigungen zu verhindern. Dies ist besonders wichtig, wenn Remote-MCP-Server oder MCP-Gateways integriert werden. ### Bewährte Methoden für die MCP-Authentifizierung und -Autorisierung + **Token-Trennung** — Geben Sie keine Inhaber-Token von Anrufern an nachgelagerte Dienste weiter. Stellen Sie sicher, dass das Feld aud (Audience) mit dem Server übereinstimmt, der das Token empfängt. Der Zielgruppenanspruch gibt an, für welchen Dienst das Token bestimmt ist, und verhindert so die unbefugte Wiederverwendung von Token auf verschiedenen MCP-Servern. + **Wählen Sie einen Zugriffsansatz** — Wählen Sie für jedes Tool, das Ihre MCP-Server bereitstellen, zwischen machine-to-machine und vom Benutzer delegiertem Zugriff. Erwägen Sie, Tools auf demselben MCP-Server zu gruppieren, die dasselbe Authentifizierungsmuster verwenden. ## Steuerung der Last Wie bei jedem verteilten System müssen Sie überlegen, wie Sie die Last in Ihrer MCP-Serverflotte kontrollieren können. Zunächst überlegen Sie, ob Sie eine Ratenbegrenzung auf Ihren MCP-Servern implementieren sollten und wo die Grenzwerte implementiert werden sollen. Wenn Sie sich dafür entscheiden, keine Ratenbegrenzung zu implementieren, geben Sie jegliche Ratenbegrenzung weiter, die von nachgelagerten Ressourcen vorgenommen wird. Viele Systeme entscheiden sich für eine Ratenbegrenzung auf der Grundlage von Anforderungsattributen, wie z. B. einer Benutzer- oder Konto-ID. Stellen Sie sicher, dass die Anfragen, die an nachgelagerte Dienste gesendet werden, dieselben Attribute aufweisen, sodass mehrere Benutzer nicht durch die Belastung durch einen anderen Benutzer beeinträchtigt werden. Wenn Sie sich für die Implementierung einer Ratenbegrenzung entscheiden, empfiehlt es sich, die primäre Ratenbegrenzung auf MCP-Serverebene zu implementieren, wobei Back-End-Dienste sekundären Schutz bieten und Agenten ihr Verhalten auf der Grundlage von Ratenbegrenzungen anpassen. Überlegen Sie, ob die Ratenbegrenzungen pro MCP-Server oder pro Tool gelten. Serverratenbeschränkungen pro MCP tragen zum Schutz Ihrer MCP-Serverflotte und -Services in einer Umgebung mit mehreren Mandanten bei. Das kann jedoch sehr grobkörnig sein. Die Ratenbegrenzungen pro Werkzeug sollen verhindern, dass nachgelagerte Ressourcen überlastet werden, die sich selbst möglicherweise nicht ausreichend einschränken. Wenn ein Tool mehrere Funktionen aufruft APIs, sollten Sie das Ratenlimit so einstellen, dass es sich an der niedrigsten Rate orientiert, die für diese APIs Tools zulässig ist. Die Weitergabe von Informationen zur Ratenbegrenzung in HTTP-Headern kann auch eine nützliche Metrik für Benutzer und automatisierte Systeme sein, um ihre eigene Anforderungsrate und Wiederholungsstrategie zu verwalten. Sie können diese Header beispielsweise von Ihrem MCP-Server an den Agenten zurücksenden, wie im folgenden Beispiel gezeigt: ``` X-RateLimit-Limit: 100 X-RateLimit-Remaining: 45 X-RateLimit-Reset: 1640995200 ``` Darüber hinaus sollten Sie einen Lastabbau in Betracht ziehen, um den gesamten Service zu schützen, wenn kein einziger Kunde ein Ratenlimit überschreitet, die Last jedoch die Systemleistung beeinträchtigt. ### Bewährte Methoden zur Steuerung der Auslastung + **Wählen Sie einen Ansatz zur Ratenbegrenzung** — Planen Sie eine Ratenbegrenzung für einzelne Benutzer ein, entweder auf der Grundlage ihrer Nutzung nachgelagerter Ressourcen oder aufgrund ihrer Nutzung Ihres MCP-Servers und Ihrer Tools. + **Ziehen Sie Lastabbau in Betracht** — Schützen Sie Ihre MCP-Serverflotte vor allgemeiner Überlastung, die nicht von einem einzelnen oder einer Handvoll Kunden verursacht wird. ## Operationelle Metriken Die wichtigsten Kennzahlen, die für MCP-Implementierungen erfasst werden müssen, sollten sich auf das Kundenerlebnis konzentrieren, das sie bieten. Zu diesen Kennzahlen gehören in der Regel die Token-Nutzung, die Genauigkeit der Toolauswahl, die Anzahl der beim Agenten registrierten Tools und die Latenz der Tools. Durch die Überwachung der von den einzelnen Tools zurückgegebenen Ausgabetokens können Sie beispielsweise Alarme einrichten, wenn Tools einen Schwellenwert für die Nutzung von Kontextfenstern überschreiten. Wenn ein Tool diesen Schwellenwert überschreitet, sollten Sie das Verhalten des Tools überprüfen. Dies steht auch im Zusammenhang mit der Designstrategie des MCP-Tools. Kennzahlen zur Genauigkeit der Toolauswahl geben Aufschluss darüber, wie gut die Agenten die geeigneten Tools für bestimmte Aufgaben auswählen, während Ausführungsgeschwindigkeit und Erfolgsquoten Leistungsengpässe und Zuverlässigkeitsprobleme aufzeigen. Um beispielsweise die Genauigkeitsmetriken für die Toolauswahl und den Tool-Einsatz zu bewerten, erstellten AWS Teams Gold-Datasets für Regressionstests. Die Datensätze wurden synthetisch generiert, indem historische API-Aufrufprotokolle bei Benutzeranfragen verwendet LLMs wurden. Anhand der vordefinierten Metriken zur Werkzeugauswahl und zum Werkzeugeinsatz (wie Genauigkeit der Werkzeugauswahl, Genauigkeit der Werkzeugparameter und Genauigkeit von Funktionsaufrufen mit mehreren Turns) konnten die AWS Teams objektiv beurteilen, ob der KI-Agent in der Lage ist, die geeigneten Tools korrekt zu identifizieren, ihre Parameter mit genauen Werten zu füllen und über Gesprächsrunden hinweg kohärente Werkzeugaufrufsequenzen aufrechtzuerhalten. Durch die Messung von Kennzahlen zur Anzahl der bei einem Agenten registrierten Tools können Sie potenzielle Herausforderungen bei der Verwaltung von Kontextfenstern sowie Änderungen an den verfügbaren Tools von MCP-Servern identifizieren. Sie sollten regelmäßig Betriebskennzahlen überprüfen, die Aufschluss über die Benutzererfahrung mit Ihrem MCP-Server und den Tools geben.