MCP-Connector-Governance über ein AI-API-Gateway: OAuth-Tokens, Tool-Bereiche und Zuordnung pro Benutzer

Wenn ein Agent Gmail, Drive, Stripe, ein internes System oder einen MCP Remote-Server aufruft, ist die Modellanforderung nur ein Teil des Sicherheitsereignisses. Die eigentliche betriebliche Frage lautet: Wer hat den Connector autorisiert, welche OAuth Bereiche wurden gewährt, welches Tool wurde aufgerufen, welche Daten haben die Grenze des Modellanbieters verlassen und wie kann der Zugriff während eines Vorfalls widerrufen werden?

Ein AI API-Gateway, das nur Modellaufrufe weiterleitet, kann diese Fragen nicht beantworten. Es kennt möglicherweise den Mandanten, das Modell, den API-Schlüssel, die Eingabeaufforderungsgröße und die Kosten. Es weiß möglicherweise nicht, dass das Modell Arbeit an einen Connector delegiert hat, der unter dem OAuth-Token eines menschlichen Benutzers arbeitet. Diese Lücke schwächt die Zuordnung, die Genehmigungsrichtlinie, den Widerruf und die Prüfungsreaktion.

Das praktische Muster besteht darin, die MCP Connector-Autorisierung als erstklassiges Gateway-Steuerungsebenenobjekt zu behandeln. Reduzieren Sie die Connector-Governance nicht auf eine Zulassungsliste mit Toolnamen. Verwalten Sie die Connector-Registrierung, OAuth Token-Herkunft, Tool-Bereichsklassifizierung, Genehmigungsrichtlinie, Widerrufsstatus und Audit-Protokollierung als Teil derselben Governance-Ebene, die bereits API Schlüsselverwaltung, Modellzugriff, Mandantenrichtlinie und Nutzungsanalysen verwaltet.

Fakten, Empfehlungen und Vorhersagen

Fakten: OpenAI dokumentiert Remote-MCP als Antwort-API-Toolkategorie und ermöglicht es Anwendungen, ein OAuth Zugriffstoken für einen Remote-MCP-Server bereitzustellen. OpenAI identifiziert auch gehostete Dienst-Connectoren wie Gmail, Google Drive, Google Calendar, Dropbox und Microsoft Teams. In der Datenkontrolldokumentation von OpenAI heißt es, dass es sich bei MCP-Servern, die mit dem Remote-Server-Tool MCP verwendet werden, um Dienste von Drittanbietern handelt und an sie gesendete Daten den Aufbewahrungsrichtlinien dieser Dienste unterliegen. Die Connector-Dokumentation von Anthropic beschreibt benutzerdefinierte Connectors, die Remote-MCP-Server verwenden, und weist darauf hin, dass Benutzer Connectors häufig über OAuth autorisieren, wobei Berechtigungen später widerrufen werden können. Die MCP-Autorisierungsspezifikation verwendet eine Autorisierung im OAuth-Stil für HTTP-basierte MCP-Transporte. OAuth Die Sicherheitsrichtlinien in RFC 9700 sind für die Token-Verarbeitung, den Autorisierungscode-Ablauf und die Client-Sicherheit relevant.

Empfehlungen: Ein Gateway sollte Connectors vor der Produktionsverwendung registrieren, jeden Connector-Aufruf an Mandant, Schlüssel, Benutzer, Token-Betreff und Serveridentität binden, Tools nach Lese-/Schreibrisiko klassifizieren, Genehmigungsrichtlinien vor dem Versand durchsetzen und den Sperrstatus zentral verwalten.

Vorhersagen: Die Remote-Einführung MCP wird KI-Gateways über Modellrouting und Token-Messung hinaus vorantreiben. Gateways, die die Connector-Identität, den OAuth Umfang, die Genehmigungsentscheidungen und die nachgelagerten Aufbewahrungsgrenzen nicht sehen können, sind in regulierten Umgebungen, Unternehmensumgebungen und von Partnern betriebenen Umgebungen schwieriger zu verwenden.

Das Governance-Problem ist die Aufspaltung der Identität

Connector-Aufrufe umfassen mindestens drei Identitäten und sollten nicht in Protokollen oder Richtlinienprüfungen zusammengeführt werden.

• Gateway-Aufrufer: der API Schlüssel, das Dienstkonto, die Arbeitslast oder die Partneranwendung, die die Modellanfrage übermittelt hat.
• Delegierter Benutzer: der Mensch oder Endbenutzer, der den Zugriff auf Gmail, Drive, CRM, Kalender, Zahlungen, interne Daten oder eine andere geschützte Ressource autorisiert hat.
• Connector-Ziel: der Remote-MCP Server oder gehostete Service-Connector, der den Tool-Aufruf empfängt und ihn möglicherweise an ein anderes System weiterleitet.

Wenn diese Identitäten in einem Feld namens user zusammengefasst werden, wird der Prüfpfad mehrdeutig. Ein Produktionsdienstkonto kann eine Anfrage im Namen von 20.000 Endbenutzern einreichen. Ein einzelner Mensch kann mehrere Konnektoren mit unterschiedlichen Bereichen autorisieren. Ein Remote-MCP-Server kann Tools verfügbar machen, die von mehreren Downstream-Diensten unterstützt werden. Das Gateway benötigt für alle drei separate Felder.

Ein nützliches Ereignismodell beginnt mit Feldern wie:

{
  "request_id": "req_01J...",
  "tenant_id": "tenant_acme",
  "gateway_key_id": "key_support_bot_prod",
  "workload_id": "support_agent",
  "end_user_id": "user_7421",
  "connector_id": "conn_google_drive_support",
  "mcp_server_url_hash": "sha256:...",
  "oauth_subject": "google-oauth-sub:...",
  "tool_name": "drive.files.search",
  "tool_action_class": "read",
  "approval_decision": "auto_allowed",
  "retention_class": "third_party_standard",
  "downstream_request_id": "optional_provider_or_connector_id"
}

Mit dieser Struktur können Sicherheits-, Finanz- und Plattformteams verschiedene Fragen aus demselben Datensatz beantworten. Welcher Mieter hat das Tool aufgerufen? Welcher Anwendungsschlüssel hat es verursacht? Welcher Endbenutzer hat den Zugriff delegiert? Welcher Connector hat Daten empfangen? War die Aktion schreibgeschützt oder destruktiv? War eine Genehmigung erforderlich?

Konnektoren als Gateway-Ressourcen modellieren

Ein Connector sollte registriert werden, bevor er in der Produktion verwendet wird. Die Registrierung muss nicht langsam sein, aber sie sollte ein dauerhaftes Objekt erzeugen, auf das die Richtlinie verweisen kann.

Eine minimale Connector-Ressource kann Folgendes umfassen:

• tenant_id: Der Mandant oder die Organisation, die den Connector verwenden darf.
• connector_id: eine stabile interne Kennung, unabhängig von Server-Anzeigenamen.
• server_url: die URL des Remote-MCP-Servers oder die gehostete Connector-ID.
• owner_user_id: der Administrator oder Benutzer, der es registriert hat.
• authorization_server: Metadaten des Ausstellers oder Autorisierungsservers, sofern verfügbar.
• allowed_tools: überprüfte Toolnamen und -versionen oder Fingerabdrücke.
• tool_classes: Lesen, Schreiben, Exportieren, Admin, Zahlung, Messaging oder unbekannt.
• approved_scopes: OAuth Bereiche für den Connector genehmigt.
• retention_class: intern, Modellanbieter, Drittanbieterstandard oder für sensible Arbeitslasten verboten.
• revocation_status: aktiv, user_revoked, tenant_disabled, abgelaufen, unter Quarantäne gestellt oder abgelehnt.

Dies ähnelt im Geiste einem Modellprofil oder einem Anbieteranmeldedatensatz, aber die Connector-Autorisierung ist nicht dasselbe Objekt wie ein Upstream-Modellschlüssel. Mit den Laufzeitanmeldeinformationen des Anbieters kann das Gateway Modell-APIs aufrufen. Connector-Token stellen delegierte Berechtigungen für Drittsysteme oder interne Systeme dar. Sie verdienen separate Herkunft, Speicherkontrollen und Prüfrichtlinien.

OAuth Tokens absichtlich vermitteln oder validieren

Es gibt zwei gängige Implementierungsmuster.

Gateway-vermittelt OAuth

In diesem Modell initiiert oder koordiniert das Gateway den OAuth-Fluss, speichert Aktualisierungstoken oder Zugriffstokenmaterial in einem Tresor, erstellt kurzlebige Connector-Sitzungen und hängt Zugriffstoken an, wenn MCP Remoteaufrufe versendet werden. Dies gibt dem Gateway eine starke Kontrolle über Einwilligung, Token-Lebensdauer, Widerruf und Audit-Joins.

Der Kompromiss ist die Komplexität. Das Gateway muss Zustimmungsbildschirme, Autorisierungscode-Flusssicherheit, Token-Aktualisierung, Token-Rotation, verschlüsselte Speicherung, Umleitungs-URI-Verwaltung, Ausstellervalidierung und mandantenspezifische OAuth-Anwendungskonfiguration verarbeiten. RFC 9700 ist hier wichtig, da dieses Muster das Gateway in die Nähe der OAuth Kundenverantwortung bringt.

Anwendungsverwaltet OAuth

In diesem Modell erhält die Anwendung das OAuth-Token und leitet es über den Modell- oder Gateway-Pfad weiter, wenn sie einen Remote-MCP-Connector aufruft. Dies kann schneller erfolgen, da bestehende Produkte möglicherweise bereits über Connector-Autorisierungsabläufe verfügen.

Der Kompromiss ist eine fragmentierte Governance. Wenn das Gateway nur ein undurchsichtiges Token sieht, kennt es möglicherweise nicht den Betreff, den Bereich, den Aussteller, die Aktualität, den Widerrufsstatus oder die Herkunft der Einwilligung des Tokens. Eine sicherere Version dieses Musters erfordert, dass die Anwendung bei jedem Aufruf signierte Connector-Metadaten bereitstellt, und das Gateway sollte vor dem Versand Aussteller, Zielgruppe, Ablauf, Connector-Registrierung, Benutzerbindung und genehmigten Bereich validieren.

Für Benutzerdaten-Konnektoren wie E-Mail, Kalender, Speicher, CRM und Zahlungen bevorzugen Sie OAuth-Tokens pro Benutzer. Gemeinsam genutzte langlebige Inhabertokens sollten auf explizite Dienstkonto-Workflows beschränkt werden, die auf einen Mandanten beschränkt sind und als Ressourcen mit höherem Risiko überprüft werden.

Werkzeugumfänge vor dem Versand normalisieren

MCP Server können Werkzeugnamen und Metadaten offenlegen, und einige Ökosysteme stellen Hinweise wie schreibgeschützte Anmerkungen bereit. Verwenden Sie diese Signale, behandeln Sie vom Server bereitgestellte Metadaten jedoch nicht als vollständig vertrauenswürdig. Tool-Metadaten können falsch, veraltet, mehrdeutig oder widersprüchlich sein. Die MCP-Anleitung von OWASP hebt die geringsten Rechte, die Zulassungsliste, die Authentifizierung, die Autorisierung und die Überwachung hervor. MCP Top-10-Arbeiten machen auch auf das Risiko einer Werkzeugvergiftung aufmerksam.

Ein Gateway sollte seine eigenen normalisierten Aktionsklassen verwalten:

• Lesen: Vorhandenen Inhalt suchen, auflisten, abrufen, abrufen, abrufen, zusammenfassen.
• Schreiben: erstellen, aktualisieren, bearbeiten, beschriften, verschieben, kommentieren, planen.
• Senden: E-Mail, Chat-Nachricht, Webhook, Ticket-Antwort, Benachrichtigung.
• Löschen: entfernen, bereinigen, archivieren, widerrufen.
• Export: Massen-Download, Dateiübertragung, Datensatzextraktion.
• Finanzen: Belastung, Rückerstattung, Rechnung, Auszahlung, Abonnementänderung.
• Admin: Berechtigungsänderung, Benutzereinladung, Rollenaktualisierung, Richtlinienbearbeitung.
• Unbekannt: alles, was nicht überprüft oder nicht sicher klassifiziert wurde.

Erzwingen Sie dann die Richtlinie für normalisierte Klassen anstelle von Rohwerkzeugnamen. Zum Beispiel:

policy connector_default {
  allow read when tenant.connector_risk in ["low", "medium"]
    and user.authorization_age_days <= 90
    and connector.retention_class != "prohibited";

  require_approval send, write when connector.risk != "low";
  require_approval export, delete, financial, admin;
  deny unknown;
}

Dadurch bleibt die Richtlinie stabil, wenn ein Connector gmail.search in mail.messages.query umbenennt. Das Rohtool muss noch überprüft werden, aber das Genehmigungssystem kann in Betriebskategorien argumentieren.

Führen Sie eine Pre-Dispatch-Connector-Prüfung durch

Bevor das Gateway einen modellinitiierten Connector-Aufruf zulässt, sollte es eine kompakte Pre-Dispatch-Entscheidung ausführen. Hier treffen KI-Nutzungsanalysen, Sicherheitsrichtlinien, Genehmigungsworkflows und Aufbewahrungsrichtlinien aufeinander.

Eine praktische Reihenfolge ist:

1. Mandanten und Schlüssel auflösen: Identifizieren Sie den Gateway-Schlüssel, den Mandanten, die Arbeitslast, die Umgebung und die Modellanforderung.
2. Endbenutzer auflösen: erfordert eine stabile Endbenutzer-ID für delegierte Connectors. Anonyme delegierte Anrufe ablehnen, sofern nicht ausdrücklich erlaubt.
3. Connector auflösen: Server-URL oder gehostete Connector-ID einer registrierten Connector-Ressource zuordnen.
4. Token validieren: Überprüfen Sie den Aussteller, ggf. die Zielgruppe, den Ablauf, den Betreff, die Mandantenbindung, den Widerrufsstatus und die erforderlichen Bereiche.
5. Aktion klassifizieren: Ordnen Sie den Namen und die Metadaten des Tools zum Lesen, Schreiben, Senden, Löschen, Exportieren, Finanzen, Admin oder Unbekannten zu.
6. Aufbewahrungsgrenze prüfen: Bestimmen Sie, ob die Arbeitslast die Verarbeitung und Protokollierung von Servern MCP von Drittanbietern zulässt.
7. Genehmigungsrichtlinie anwenden: Automatisch zulassen, Benutzergenehmigung erforderlich, Administratorgenehmigung erforderlich, blockieren oder unter Quarantäne stellen.
8. Budget reservieren, falls abrechnungsfähig: Wenn für die Connector-Ausführung direkte oder indirekte Gebühren anfallen, reservieren Sie das Budget vor dem Versand.
9. Schreiben Sie die Entscheidung: Behalten Sie die Entscheidung bei, bevor Sie den Connector aufrufen, nicht erst nach Erfolg.

Es kommt zuerst darauf an, die Entscheidung zu schreiben. Wenn der Connector das Zeitlimit überschreitet, eine Teilausgabe streamt oder einen Downstream-Fehler auslöst, sollte das Audit-Protokoll dennoch anzeigen, dass das Gateway einen bestimmten Aktionsversuch zugelassen oder abgelehnt hat.

Genehmigung sollte Workflow-bewusst sein

Die Genehmigung pro Anruf ist einfach zu begründen und in der Praxis oft unbrauchbar. Ein Kundendienstmitarbeiter, der ein Ticket lesen, Drive durchsuchen, eine E-Mail verfassen und einen CRM-Datensatz aktualisieren muss, sollte den Benutzer nicht bei jedem harmlosen Lesevorgang durch ein Modal zwingen. Gleichzeitig sollte das Senden einer E-Mail, das Löschen einer Datei, die Rückerstattung einer Zahlung oder das Exportieren eines Ordners nicht stillschweigend delegiert werden, weil ein Model ein Tool ausgewählt hat.

Eine praktikable Richtlinie ist geschichtet:

• Überprüfte schreibgeschützte Tools für Mandanten mit geringem Risiko und neue Benutzerautorisierung automatisch zulassen.
• Genehmigung für Sende-, Erstellungs-, Aktualisierungs-, Lösch-, Export-, Finanz- und Verwaltungsaktionen erforderlich.
• Gruppierte Genehmigungen für einen benannten Workflow, Umfang und Zeitfenster zulassen.
• Eine erneute Genehmigung ist erforderlich, wenn der Umfang erweitert wird, sich Werkzeugdefinitionen wesentlich ändern oder der Connector in eine höhere Risikoklasse wechselt.
• Unbekannte Tools bis zur Überprüfung blockieren.

Gruppierte Genehmigungen sollten explizit sein. Ein Benutzer kann Folgendes genehmigen: „Erlauben Sie diesem Support-Workflow für die nächsten 30 Minuten, Drive zu durchsuchen und Antworten zu entwerfen, erfordern Sie jedoch eine Bestätigung vor dem Senden.“ Das ist nützlicher als ein Binär-Connector-Schalter zum Zulassen/Verweigern.

Aufbewahrungsgrenzen benötigen ihr eigenes Feld

Remote MCP-Aufrufe können Daten außerhalb der Aufbewahrungs- und Verarbeitungsgrenzen des Modellanbieters verschieben. Das ist nicht automatisch falsch, muss aber sichtbar sein. Einer Arbeitslast, die einen Modellendpunkt unter einer Datenaufbewahrungseinstellung verwenden darf, kann es dennoch untersagt sein, denselben Inhalt an einen MCP-Server eines Drittanbieters mit unterschiedlichen Aufbewahrungsbedingungen zu senden.

Fügen Sie eine Aufbewahrungsklassifizierung sowohl zu Arbeitslasten als auch zu Connectors hinzu. Beispielklassen:

• internal_only: keine Connector-Aufrufe von Drittanbietern zulässig.
• approved_processors_only: Connector muss auf einer Liste zugelassener Anbieter stehen.
• third_party_standard_allowed: Standard-SaaS-Connector-Verarbeitung ist zulässig.
• no_argument_logging: Connector-Aufrufe zulässig, aber Argumente müssen geschwärzt oder gehasht werden.
• export_blocked: Lesen/Suchen erlaubt, Massenexport verweigert.

Hier schützt das Gateway Teams vor einem subtilen Fehler: Es wird davon ausgegangen, dass die Datenkontrollen des Modellanbieters automatisch auf jedes vom Agent verwendete Tool angewendet werden. Sie gelten nicht unbedingt, sobald Daten an einen MCP Remote-Server oder einen externen Dienst-Connector gesendet werden.

Erstellen Sie ein Connector-Audit-Ledger

Ein Connector-Audit-Ledger sollte Modellanfragen, Gateway-Autorisierung, Connector-Versand und Downstream-Ergebnisse zusammenführen. Verlassen Sie sich nicht nur auf rohe Anbieterverfolgungen, da jeder Anbieter Tool-Ereignisse möglicherweise unterschiedlich offenlegt und in Anwendungsprotokollen möglicherweise Token- oder Genehmigungskontext weggelassen wird.

Zu den empfohlenen Ledger-Feldern gehören:

• model_request_id und Trace-ID.
• tenant_id, gateway_key_id, Arbeitslast, Umgebung und Endbenutzer-ID.
• connector_id, Server-URL-Hash, gehostete Connector-ID und Risikoklasse.
• tool_name, Toolversion oder Metadaten-Fingerabdruck und normalisierte Aktionsklasse.
• OAuth Aussteller, Token-Betreff, Bereichssatz-Hash, Ablauf-Bucket und Token-Herkunft.
• Argument-Hash, redigierte Argumente, Vertraulichkeitsklasse und Aufbewahrungsklasse.
• Genehmigungsentscheidung, Genehmiger, Genehmigungsumfang und Genehmigungsablauf.
• Versandstatus, Antwortstatus, Fehlerklasse, Latenz und Downstream-Anfrage-IDs, sofern verfügbar.

Eine vollständige Argumentprotokollierung kann die Reaktion auf Vorfälle unterstützen, erhöht aber auch das Datenschutz- und Aufbewahrungsrisiko. Bevorzugen Sie standardmäßig strukturierte Felder, Hashing, selektive Schwärzung und Vertraulichkeits-Tags. Erlauben Sie die vollständige Erfassung nur im Rahmen einer expliziten Vorfall- oder Debugging-Richtlinie mit Ablaufdatum.

Widerruf und Quarantäne sind Produktanforderungen

Der Widerruf kann keine manuelle Datenbankbearbeitung sein. Benutzer und Administratoren benötigen Workflows, die sofort in den Richtlinienstatus übergehen.

Implementieren Sie mindestens diese Aktionen:

• Benutzertrennung: alle Token für die Connector-Autorisierung eines Benutzers widerrufen oder als inaktiv markieren.
• Mandanten deaktivieren: Blockieren Sie einen Connector für einen gesamten Mandanten, ohne nicht verwandten Modellverkehr zu deaktivieren.
• Token-Ablaufbehandlung: Schließen fehlschlagen oder erneut autorisieren, wenn die Aktualisierung fehlschlägt oder die Aktualität der Autorisierung die Richtlinie überschreitet.
• Connector-Quarantäne: Blockieren Sie einen Connector, während seine Konfiguration und Protokolle zur Untersuchung erhalten bleiben.
• Notfall-Sperrliste: Blockierung durch Server-URL-Hash, Connector-ID, Aussteller oder Tool-Fingerabdruck.
• Bereichsherabstufung: Erneute Autorisierung mit weniger Bereichen, wenn ein Workflow keinen umfassenden Zugriff mehr benötigt.

Das wichtige Implementierungsdetail besteht darin, dass der Sperrstatus zum Versandzeitpunkt überprüft werden muss. Eine nächtliche Synchronisierung ist für den Abgleich nützlich, für die Reaktion auf Vorfälle reicht sie jedoch nicht aus.

Konformitätsprüfungen für Remote-MCP-Anschlüsse

Bevor ein Connector für Produktionsmandanten verfügbar ist, testen Sie ihn als geregelte Abhängigkeit. Eine kurze Prüfsuite erkennt viele Integrations- und Richtlinienfehler.

• Metadatenerkennung gibt eine stabile Serveridentität und erwartete Tooldefinitionen zurück.
• Geschützte Ressourcenmetadaten und Autorisierungsverhalten stimmen gegebenenfalls mit dokumentierten Annahmen überein.
• Dynamische Client-Registrierungsanforderungen werden verstanden, unterstützt oder ausdrücklich deaktiviert.
• Anfragen ohne Token schlagen sicher fehl.
• Abgelaufene Token schlagen vorhersehbar fehl und lösen keine unkontrollierten Wiederholungsversuche aus.
• Die Lese-/Schreibklassifizierung stimmt mit beobachtetem Verhalten überein, nicht nur mit Beschreibungen.
• Fehlerhafte Tool-Metadaten werden abgelehnt oder als unbekannt markiert.
• Änderungen der Werkzeugliste lösen eine Überprüfung aus, wenn sich Namen, Bereiche, Beschreibungen oder Risikoklassen ändern.
• Connector-Fehler werden protokolliert, ohne dass vertrauliche Argumente in allgemeine Fehlerfelder gelangen.

Diese Tests sind kein Ersatz für die Sicherheitsüberprüfung, aber sie geben dem Gateway eine wiederholbare Möglichkeit, Abweichungen zu erkennen. MCP Remote-Server können sich unabhängig vom Modellanbieter und unabhängig von Ihrem Anwendungs-Release-Zyklus ändern.

Implementierungs-Checkliste

• Erstellen Sie eine Connector-Registrierung mit den Feldern „Mandant“, „Server“, „Autorisierung“, „Bereich“, „Tool“, „Risiko“, „Aufbewahrung“ und „Widerruf“.
• Separate Gateway-Schlüsselidentität, delegierte Endbenutzeridentität und Connector-Identität bei jeder Richtlinienentscheidung.
• Speichern Sie Connector-Tokens in einem Anmeldeinformations-Tresor, aber trennen Sie sie von den Laufzeitanmeldeinformationen des Modellanbieters.
• Pro Benutzer bevorzugen OAuth für Benutzerdaten-Konnektoren; Beschränken Sie gemeinsam genutzte Diensttokens auf explizite Dienstkonto-Workflows.
• Tool-Aktionen in Lesen, Schreiben, Senden, Löschen, Exportieren, Finanzen, Admin und Unbekannt normalisieren.
• Führen Sie vor dem Versand Prüfungen für Connector-Registrierung, Token-Gültigkeit, Bereichsübereinstimmung, Aufbewahrungskompatibilität, Genehmigungsstatus und Budgetreservierung durch.
• Konnektorentscheidungen vor dem Versand protokollieren und den endgültigen Status nach Antwort oder Fehler festlegen.
• Erstellen Sie Arbeitsabläufe für Benutzertrennung, Mandantendeaktivierung, Connector-Quarantäne und Notfall-Denylist.
• Konnektor-Metadaten, Token-Verhalten, Tool-Drift und fehlerhafte Metadaten vor der Verwendung in der Produktion prüfen.

Umsetzbare Schlussfolgerung

MCP und Dienstkonnektoren machen Agenten nützlich, weil sie Modelle auf realen Systemen agieren lassen. Derselbe Nutzen macht die Connector-Autorisierung zu einem Problem der Steuerungsebene und nicht zu einem Detail der Eingabeaufforderung.

Das Gateway sollte mehr als das Modell, die Token-Anzahl und den API-Schlüssel wissen. Es sollte wissen, welcher Connector aufgerufen wurde, welcher Benutzer ihn autorisiert hat, welche Bereiche gewährt wurden, welche Tool-Aktionsklasse angefordert wurde, ob eine Genehmigung erforderlich war, ob die Aufbewahrungsgrenze kompatibel war und wie der Zugriff widerrufen werden kann. Beginnen Sie mit einer Connector-Registrierung, einer Richtlinienprüfung vor dem Versand und einem verbundenen Audit-Ledger. Fügen Sie dann OAuth Brokerage, gruppierte Genehmigungen, Konformitätsprüfungen und Notfallquarantäne hinzu, wenn die Connector-Nutzung zunimmt.

Das Ziel besteht nicht darin, die MCP Ferneinführung zu blockieren. Das Ziel besteht darin, den Connector-Zugriff zuschreibbar, widerrufbar, überprüfbar und mit den gleichen Governance-Erwartungen kompatibel zu machen, die Teams bereits an den Modellzugriff und ein OpenAI-kompatibles API Gateway stellen.

Verwandte Lektüre

• umfassendere Agent-Tool-Governance-Muster