MCP-connectorbeheer via een AI API-gateway: OAuth-tokens, toolscopes en attributie per gebruiker

Wanneer een agent Gmail, Drive, Stripe, een intern systeem of een externe MCP server aanroept, is het modelverzoek slechts een deel van de beveiligingsgebeurtenis. De echte operationele vraag is: wie heeft de connector geautoriseerd, welke OAuth scopes zijn toegekend, welke tool is aangeroepen, welke gegevens hebben de grens van de modelprovider verlaten en hoe kan de toegang worden ingetrokken tijdens een incident?

Een AI API-gateway die alleen proxy-modeloproepen uitvoert, kan deze vragen niet beantwoorden. Het kan de tenant, het model, de API-sleutel, de promptgrootte en de kosten kennen. Mogelijk weet het niet dat het model werk heeft gedelegeerd aan een connector die werkt onder het OAuth-token van een menselijke gebruiker. Deze kloof verzwakt de attributie, het goedkeuringsbeleid, de intrekking en de auditrespons.

Het praktische patroon is om MCP connectorautorisatie te behandelen als een eersteklas gateway-besturingsvlakobject. Beperk het connectorbeheer niet tot een toelatingslijst met toolnamen. Beheer de inschrijving van de connector, OAuth token-herkomst, classificatie van het toolbereik, goedkeuringsbeleid, intrekkingsstatus en auditlogboekregistratie als onderdeel van dezelfde beheerlaag die al API sleutelbeheer, modeltoegang, tenantbeleid en gebruiksanalyses afhandelt.

Feiten, aanbevelingen en voorspellingen

Feiten: OpenAI documenteert externe MCP als een toolcategorie Reacties API en staat toepassingen toe een OAuth toegangstoken te leveren voor een externe MCP server. OpenAI identificeert ook gehoste serviceconnectors zoals Gmail, Google Drive, Google Agenda, Dropbox en Microsoft Teams. Volgens de gegevensbeheerdocumentatie van OpenAI zijn de MCP-servers die worden gebruikt met de externe MCP-servertool services van derden, en de gegevens die naar hen worden verzonden vallen onder het bewaarbeleid van die services. De connectordocumentatie van Anthropic beschrijft aangepaste connectoren die gebruikmaken van externe MCP-servers en merkt op dat gebruikers doorgaans connectoren autoriseren via OAuth, waarbij machtigingen later kunnen worden ingetrokken. De autorisatiespecificatie MCP gebruikt autorisatie in OAuth-stijl voor HTTP-gebaseerde MCP transporten. OAuth Beveiligingsrichtlijnen in RFC 9700 zijn relevant voor tokenverwerking, autorisatiecodestromen en clientbeveiliging.

Aanbevelingen: Een gateway moet connectoren registreren vóór productiegebruik, elke connectoraanroep binden aan tenant, sleutel, gebruiker, tokenonderwerp en serveridentiteit, tools classificeren op basis van lees-/schrijfrisico, goedkeuringsbeleid afdwingen vóór verzending en de intrekkingsstatus centraal bijhouden.

Voorspellingen: De adoptie op afstand MCP zal AI-gateways verder brengen dan alleen modelrouting en tokenmeting. Gateways die de connectoridentiteit, OAuth reikwijdte, goedkeuringsbeslissingen en downstream-retentiegrenzen niet kunnen zien, zullen moeilijker te gebruiken zijn in gereguleerde, zakelijke en door partners beheerde omgevingen.

Het bestuursprobleem is identiteitssplitsing

Connectoraanroepen omvatten ten minste drie identiteiten en mogen niet worden samengevoegd in logboeken of beleidscontroles.

• Gateway-aanroeper: de API sleutel, het serviceaccount, de werklast of de partnertoepassing die het modelverzoek heeft ingediend.
• Gedelegeerde gebruiker: de menselijke of eindgebruiker die toegang heeft verleend tot Gmail, Drive, CRM, agenda, betalingen, interne gegevens of een andere beschermde bron.
• Connectordoel: de externe MCP server of gehoste serviceconnector die de toolaanroep ontvangt en deze kan doorsturen naar een ander systeem.

Als deze identiteiten samenvallen in één veld met de naam user, wordt het audittraject dubbelzinnig. Met een productiedienstaccount kan namens 20.000 eindgebruikers een aanvraag worden ingediend. Eén persoon kan meerdere connectoren met verschillende scopes autoriseren. Een externe MCP-server kan tools beschikbaar stellen die worden ondersteund door meerdere downstream-services. De gateway heeft voor alle drie aparte velden nodig.

Een handig gebeurtenismodel begint met velden als:

{
  "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"
}

Dankzij deze structuur kunnen beveiligings-, financiële en platformteams verschillende vragen vanuit hetzelfde dossier beantwoorden. Welke tenant heeft de tool aangeroepen? Welke applicatiesleutel heeft dit gedaan? Welke eindgebruiker heeft gedelegeerde toegang? Welke connector heeft gegevens ontvangen? Was de actie alleen-lezen of destructief? Was goedkeuring vereist?

Modelconnectoren als gatewaybronnen

Een connector moet worden ingeschreven voordat deze in productie wordt gebruikt. Inschrijving hoeft niet langzaam te zijn, maar moet wel een duurzaam object opleveren waarnaar het beleid kan verwijzen.

Een minimale connectorbron kan het volgende omvatten:

• tenant_id: de huurder of organisatie die de connector mag gebruiken.
• connector_id: een stabiele interne identificatie, onafhankelijk van de weergavenamen van de server.
• server_url: de externe MCP server-URL of gehoste connector-ID.
• owner_user_id: de beheerder of gebruiker die de aanmelding heeft gedaan.
• authorization_server: metadata van de uitgever of autorisatieserver, indien beschikbaar.
• allowed_tools: gereedschapsnamen en -versies of vingerafdrukken beoordeeld.
• tool_classes: lezen, schrijven, exporteren, beheren, betalen, berichten versturen of onbekend.
• approved_scopes: OAuth scopes goedgekeurd voor de connector.
• retention_class: intern, modelprovider, standaard van derden of verboden voor gevoelige productietaken.
• revocation_status: actief, user_revoked, tenant_disabled, verlopen, in quarantaine geplaatst of geweigerd.

Dit is in essentie vergelijkbaar met een modelprofiel of providerreferentierecord, maar connectorautorisatie is niet hetzelfde object als een upstream-modelsleutel. Runtime-referenties van de provider zorgen ervoor dat de gateway model-API's kan aanroepen. Connectortokens vertegenwoordigen gedelegeerde bevoegdheden naar externe of interne systemen. Ze verdienen een aparte herkomst, opslagcontrole en auditbeleid.

Broker of valideer OAuth Tokens opzettelijk

Er zijn twee algemene implementatiepatronen.

Gateway-bemiddeld OAuth

In dit model initieert of coördineert de gateway de OAuth stroom, slaat vernieuwingstokens of toegangstokenmateriaal op in een kluis, beheert kortstondige connectorsessies en koppelt toegangstokens bij het verzenden van externe MCP oproepen. Dit geeft de gateway sterke controle over toestemming, tokenlevensduur, intrekking en auditjoins.

De wisselwerking is complexiteit. De gateway moet toestemmingsschermen, beveiliging van de autorisatiecodestroom, tokenvernieuwing, tokenrotatie, gecodeerde opslag, beheer van omleidings-URI's, validatie van de uitgever en tenantspecifieke OAuth-applicatieconfiguratie afhandelen. RFC 9700 is hier van belang omdat dit patroon de gateway dicht bij OAuth klantverantwoordelijkheden plaatst.

Applicatiebeheerd OAuth

In dit model verkrijgt de applicatie het OAuth-token en geeft dit door via het model- of gatewaypad bij het aanroepen van een externe MCP-connector. Dit kan sneller worden verzonden omdat bestaande producten mogelijk al connectorautorisatiestromen hebben.

De wisselwerking is een gefragmenteerd bestuur. Als de gateway alleen een ondoorzichtig token ziet, kent deze mogelijk niet het tokenonderwerp, het bereik, de uitgever, de versheid, de intrekkingsstatus of de herkomst van de toestemming. Een veiligere versie van dit patroon vereist dat de applicatie bij elke aanroep ondertekende metadata van de connector levert, en dat de gateway de uitgever, het publiek, de vervaldatum, de inschrijving van de connector, de gebruikersbinding en het goedgekeurde bereik vóór verzending moet valideren.

Voor connectoren voor gebruikersgegevens, zoals e-mail, agenda, opslag, CRM en betalingen, geeft u de voorkeur aan tokens per gebruiker OAuth. Gedeelde dragertokens met een lange levensduur moeten worden beperkt tot expliciete serviceaccountworkflows die zijn gericht op een tenant en worden beoordeeld als bronnen met een hoger risico.

Toolscopes normaliseren vóór verzending

MCP servers kunnen toolnamen en metadata openbaar maken, en sommige ecosystemen bieden hints zoals alleen-lezen annotaties. Gebruik deze signalen, maar behandel metagegevens die door de server worden verstrekt niet als volledig vertrouwd. Metagegevens van tools kunnen verkeerd, verouderd, dubbelzinnig of vijandig zijn. De MCP-richtlijnen van OWASP benadrukken minimale rechten, toelatingslijsten, authenticatie, autorisatie en monitoring; MCP Top 10-werk vestigt ook de aandacht op de risico's van gereedschapsvergiftiging.

Een gateway moet zijn eigen genormaliseerde actieklassen behouden:

• Lezen: bestaande inhoud zoeken, weergeven, ophalen, ophalen, ophalen en samenvatten.
• Schrijven: maken, bijwerken, bewerken, labelen, verplaatsen, reageren, plannen.
• Verzenden: e-mail, chatbericht, webhook, ticketreactie, melding.
• Verwijderen: verwijderen, opschonen, archiveren, intrekken.
• Exporteren: bulkdownload, bestandsoverdracht, datasetextractie.
• Financieel: kosten, terugbetaling, factuur, uitbetaling, abonnementswijziging.
• Beheerder: wijziging van rechten, gebruikersuitnodiging, rolupdate, beleidsbewerking.
• Onbekend: alles wat niet is beoordeeld of niet met vertrouwen is geclassificeerd.

Dwing vervolgens beleid af voor genormaliseerde klassen in plaats van onbewerkte toolnamen. Bijvoorbeeld:

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;
}

Hierdoor blijft het beleid stabiel wanneer een connector de naam gmail.search wijzigt in mail.messages.query. De onbewerkte tool moet nog worden beoordeeld, maar het goedkeuringssysteem kan in operationele categorieën redeneren.

Voer een connectorcontrole vóór verzending uit

Voordat de gateway een door een model geïnitieerde connectoraanroep toestaat, moet deze een compacte beslissing vóór verzending uitvoeren. Dit is waar AI-gebruiksanalyse, beveiligingsbeleid, goedkeuringsworkflow en bewaarbeleid samenkomen.

Een praktische reeks is:

1. Tenant en sleutel oplossen: identificeer de gatewaysleutel, tenant, werklast, omgeving en modelverzoek.
2. Eindgebruiker oplossen: vereist een stabiele eindgebruikers-ID voor gedelegeerde connectoren. Anonieme gedelegeerde oproepen weigeren, tenzij expliciet toegestaan.
3. Connector oplossen: koppel de server-URL of de gehoste connector-ID aan een geregistreerde connectorbron.
4. Token valideren: controleer uitgever, doelgroep, indien van toepassing, vervaldatum, onderwerp, huurderbinding, intrekkingsstatus en vereiste bereiken.
5. Classificatieactie: kaarttoolnaam en metagegevens om te lezen, schrijven, verzenden, verwijderen, exporteren, financieel, beheerder of onbekend.
6. Controleer de bewaargrens: bepaal of de werklast serververwerking en logboekregistratie door derden MCP toestaat.
7. Goedkeuringsbeleid toepassen: automatisch toestaan, gebruikersgoedkeuring vereisen, beheerdersgoedkeuring vereisen, blokkeren of in quarantaine plaatsen.
8. Reserveer budget indien factureerbaar: als de uitvoering van de connector directe of indirecte kosten met zich meebrengt, reserveer dan budget vóór verzending.
9. Schrijf de beslissing: handhaaf de beslissing voordat u de connector aanroept, en niet pas na succes.

Het is belangrijk dat u eerst de beslissing opschrijft. Als de connector een time-out krijgt, gedeeltelijke uitvoer streamt of een downstream-fout activeert, moet het auditlogboek nog steeds laten zien dat de gateway een specifieke actiepoging heeft toegestaan of geweigerd.

Goedkeuring moet workflowbewust zijn

Goedkeuring per gesprek is eenvoudig te redeneren en in de praktijk vaak onbruikbaar. Een medewerker van de klantenondersteuning die een ticket moet lezen, Drive moet doorzoeken, een e-mail moet opstellen en een CRM-record moet bijwerken, mag de gebruiker niet voor elke onschuldige leeshandeling door een modaal dwingen. Tegelijkertijd mag het verzenden van een e-mail, het verwijderen van een bestand, het terugbetalen van een betaling of het exporteren van een map niet stilzwijgend worden gedelegeerd omdat een model een tool heeft geselecteerd.

Een werkbaar beleid is gelaagd:

• Gecontroleerde alleen-lezen tools automatisch toestaan voor huurders met een laag risico en nieuwe gebruikersautorisatie.
• Goedkeuring vereisen voor verzend-, maak-, update-, verwijder-, export-, financiële en administratieve acties.
• Sta gegroepeerde goedkeuringen toe voor een benoemde workflow, bereik en tijdvenster.
• Hernieuwde goedkeuring vereisen wanneer het bereik groter wordt, tooldefinities wezenlijk veranderen of de connector naar een hogere risicoklasse wordt verplaatst.
• Blokkeer onbekende tools totdat ze worden beoordeeld.

Gegroepeerde goedkeuringen moeten expliciet zijn. Een gebruiker kan het volgende goedkeuren: "Geef deze ondersteuningsworkflow de komende 30 minuten toestemming om Drive te doorzoeken en antwoorden op te stellen, maar er is een bevestiging vereist voordat deze wordt verzonden." Dat is nuttiger dan een schakelaar voor toestaan/weigeren van een binaire connector.

Bewaargrenzen hebben hun eigen veld nodig

Op afstand MCP-oproepen kunnen gegevens verplaatsen buiten de bewaar- en verwerkingsgrenzen van de modelaanbieder. Dat is niet automatisch verkeerd, maar het moet wel zichtbaar zijn. Het is mogelijk dat een werkbelasting die een modeleindpunt mag gebruiken onder één instelling voor het bewaren van gegevens, nog steeds niet dezelfde inhoud naar een MCP server van derden kan sturen met andere bewaartermijnen.

Voeg bewaarclassificatie toe aan zowel productietaken als connectoren. Voorbeeldklassen:

• internal_only: geen connectoraanroepen van derden toegestaan.
• approved_processors_only: connector moet op een goedgekeurde leverancierslijst staan.
• third_party_standard_allowed: standaard SaaS-connectorverwerking is toegestaan.
• no_argument_logging: connectoraanroepen toegestaan, maar argumenten moeten worden geredigeerd of gehasht.
• export_blocked: lezen/zoeken toegestaan, bulkexport geweigerd.

Dit is waar de gateway teams beschermt tegen een subtiele fout: ervan uitgaan dat de gegevenscontroles van de modelprovider automatisch van toepassing zijn op elke tool die de agent gebruikt. Ze zijn niet noodzakelijkerwijs van toepassing zodra gegevens naar een externe MCP server of externe serviceconnector worden verzonden.

Een connector-auditgrootboek maken

Een connectorcontrolegrootboek moet modelaanvragen, gateway-autorisatie, connectorverzending en downstream-resultaten samenvoegen. Vertrouw niet alleen op onbewerkte traceringen van de provider, omdat elke provider toolgebeurtenissen op een andere manier kan weergeven, en applicatielogboeken de token- of goedkeuringscontext kunnen weglaten.

Aanbevolen grootboekvelden zijn onder meer:

• model_request_id en trace-ID.
• tenant_id, gateway_key_id, werklast, omgeving en eindgebruikers-ID.
• connector_id, server-URL-hash, gehoste connector-ID en risicoklasse.
• tool_name, toolversie of metadata-vingerafdruk en genormaliseerde actieklasse.
• OAuth uitgever, tokenonderwerp, bereikset-hash, vervalbucket en token-herkomst.
• Hash van argumenten, geredigeerde argumenten, gevoeligheidsklasse en retentieklasse.
• Goedkeuringsbesluit, goedkeurder, goedkeuringsbereik en vervaldatum van de goedkeuring.
• Verzendingsstatus, reactiestatus, foutklasse, latentie en downstream-verzoek-ID's, indien beschikbaar.

Het volledig registreren van argumenten kan de respons op incidenten helpen, maar verhoogt ook het risico op privacy en retentie. Geef standaard de voorkeur aan gestructureerde velden, hashing, selectieve redactie en gevoeligheidstags. Volledige registratie alleen toestaan onder een expliciet incident- of foutopsporingsbeleid met vervaldatum.

Intrekking en quarantaine zijn productvereisten

Intrekking kan geen handmatige databasebewerking zijn. Gebruikers en beheerders hebben workflows nodig die in een onmiddellijke beleidsstatus veranderen.

Implementeer ten minste deze acties:

• Verbinding verbroken door gebruiker: alle tokens voor de connectorautorisatie van één gebruiker intrekken of inactief markeren.
• Tenant uitschakelen: blokkeer één connector voor een hele tenant zonder niet-gerelateerd modelverkeer uit te schakelen.
• Afhandeling van tokenvervaldatum: mislukt gesloten of autoriseert opnieuw wanneer vernieuwen mislukt of de versheid van de autorisatie het beleid overschrijdt.
• Connectorquarantaine: blokkeer een connector terwijl de configuratie en logboeken ervan behouden blijven voor onderzoek.
• Weigerlijst voor noodgevallen: blokkeren op basis van server-URL-hash, connector-ID, uitgever of tool-vingerafdruk.
• Bereik downgraden: autoriseer opnieuw met minder bereik wanneer een werkstroom niet langer brede toegang nodig heeft.

Het belangrijke implementatiedetail is dat de intrekkingsstatus moet worden gecontroleerd op het moment van verzending. Een nachtelijke synchronisatie is nuttig voor afstemming, maar is niet voldoende voor incidentrespons.

Conformiteitssondes voor externe MCP connectoren

Voordat een connector beschikbaar is voor productietenants, test u deze als een beheerde afhankelijkheid. Een korte testsuite spoort veel integratie- en beleidsfouten op.

• De ontdekking van metagegevens retourneert een stabiele serveridentiteit en verwachte tooldefinities.
• Metagegevens van beveiligde bronnen en autorisatiegedrag komen waar van toepassing overeen met gedocumenteerde aannames.
• Vereisten voor dynamische clientregistratie worden begrepen, ondersteund of expliciet uitgeschakeld.
• Verzoeken zonder tokens mislukken veilig.
• Verlopen tokens mislukken voorspelbaar en veroorzaken geen ongecontroleerde nieuwe pogingen.
• Lees-/schrijfclassificatie komt overeen met waargenomen gedrag, niet alleen met beschrijvingen.
• Onjuist opgemaakte tool-metagegevens worden afgewezen of gemarkeerd als onbekend.
• Wijzigingen in de toollijst leiden tot beoordeling wanneer namen, bereiken, beschrijvingen of risicoklassen veranderen.
• Connectorfouten worden geregistreerd zonder dat gevoelige argumenten in algemene foutvelden terechtkomen.

Deze tests zijn geen vervanging voor de beveiligingscontrole, maar geven de gateway een herhaalbare manier om drift te detecteren. Externe MCP servers kunnen onafhankelijk van de modelaanbieder en onafhankelijk van de releasecyclus van uw applicatie veranderen.

Implementatiechecklist

• Maak een connectorregister met velden voor tenant, server, autorisatie, bereik, tool, risico, retentie en intrekking.
• Afzonderlijke gatewaysleutelidentiteit, gedelegeerde eindgebruikersidentiteit en connectoridentiteit bij elke beleidsbeslissing.
• Sla connectortokens op in een kluis voor inloggegevens, maar houd ze gescheiden van de runtime-inloggegevens van de modelprovider.
• Geef de voorkeur per gebruiker OAuth voor connectoren voor gebruikersgegevens; beperk gedeelde servicetokens tot expliciete serviceaccountworkflows.
• Normaliseer toolacties in lezen, schrijven, verzenden, verwijderen, exporteren, financieel, administratief en onbekend.
• Voer controles vóór verzending uit op connectorinschrijving, tokengeldigheid, bereikmatch, retentiecompatibiliteit, goedkeuringsstatus en budgetreservering.
• Log connectorbeslissingen vóór verzending en regel de definitieve status na reactie of fout.
• Ontkoppeling van gebruikers, uitschakelen van tenants, quarantaine van connectoren en workflows voor weigeringslijsten voor noodgevallen.
• Metagegevens van de probe-connector, tokengedrag, tool-drift en verkeerd opgemaakte metadata vóór gebruik in productie.

Conclusie waar actie op ondernomen kan worden

MCP en serviceconnectors maken agenten nuttig omdat ze modellen op echte systemen laten werken. Door datzelfde nut wordt de autorisatie van de connector een kwestie van het besturingsvlak, en niet een technisch detail van de prompt.

De gateway zou meer moeten weten dan het model, het aantal tokens en de API sleutel. Het moet weten welke connector is aangeroepen, welke gebruiker deze heeft geautoriseerd, welke scopes zijn verleend, welke toolactieklasse is aangevraagd, of goedkeuring vereist is, of de retentiegrens compatibel is en hoe toegang kan worden ingetrokken. Begin met een connectorregister, een beleidscontrole vóór verzending en een samengevoegd auditgrootboek. Voeg vervolgens OAuth makelaardij, gegroepeerde goedkeuringen, conformiteitsondes en noodquarantaine toe naarmate het connectorgebruik groeit.

Het doel is niet om adoptie op afstand MCP te blokkeren. Het doel is om connectortoegang toewijsbaar, herroepbaar, controleerbaar en compatibel te maken met dezelfde governanceverwachtingen die teams al hanteren voor modeltoegang en een OpenAI-compatibele API gateway.

Gerelateerd lezen

• bredere beheerpatronen voor agenttools