Governance del connettore MCP tramite un gateway API AI: token OAuth, ambiti degli strumenti e attribuzione per utente

Quando un agente chiama Gmail, Drive, Stripe, un sistema interno o un server MCP remoto, la richiesta del modello è solo una parte dell'evento di sicurezza. La vera domanda operativa è: chi ha autorizzato il connettore, quali OAuth ambiti sono stati concessi, quale strumento è stato richiamato, quali dati hanno superato il confine del provider di modelli e come è possibile revocare l'accesso durante un incidente?

Un gateway AI API che esegue solo le chiamate ai modelli proxy non può rispondere a queste domande. Potrebbe conoscere il tenant, il modello, la chiave API, la dimensione del prompt e il costo. Potrebbe non sapere che il modello ha delegato il lavoro a un connettore che opera con il token OAuth di un utente umano. Questo divario indebolisce l'attribuzione, la politica di approvazione, la revoca e la risposta all'audit.

Il modello pratico è trattare MCP l'autorizzazione del connettore come un oggetto del piano di controllo del gateway di prima classe. Non ridurre la governance del connettore a una lista consentita di nomi di strumenti. Gestisci la registrazione del connettore, OAuth provenienza del token, classificazione dell'ambito dello strumento, policy di approvazione, stato di revoca e registrazione di controllo come parte dello stesso livello di governance che già gestisce API gestione delle chiavi, accesso al modello, policy del tenant e analisi di utilizzo.

Fatti, consigli e previsioni

Fatti: OpenAI documenta il MCP remoto come categoria di strumenti di risposta API e consente alle applicazioni di fornire un OAuth token di accesso per un server MCP remoto. OpenAI identifica anche i connettori dei servizi ospitati come Gmail, Google Drive, Google Calendar, Dropbox e Microsoft Teams. La documentazione sul controllo dei dati di OpenAI afferma che i server MCP utilizzati con lo strumento server remoto MCP sono servizi di terze parti e i dati ad essi inviati sono soggetti ai criteri di conservazione di tali servizi. La documentazione del connettore di Anthropic descrive i connettori personalizzati che utilizzano server remoti MCP e rileva che gli utenti comunemente autorizzano i connettori tramite OAuth, con autorizzazioni che possono essere successivamente revocate. La specifica di autorizzazione MCP utilizza l'autorizzazione in stile OAuth per i trasporti MCP basati su HTTP. OAuth Le linee guida sulla sicurezza nella RFC 9700 sono rilevanti per la gestione dei token, i flussi dei codici di autorizzazione e la sicurezza del client.

Consigli: un gateway deve registrare i connettori prima dell'utilizzo in produzione, associare ogni chiamata del connettore a tenant, chiave, utente, oggetto del token e identità del server, classificare gli strumenti in base al rischio di lettura/scrittura, applicare policy di approvazione prima dell'invio e gestire lo stato di revoca a livello centrale.

Previsioni: L'adozione remota MCP spingerà i gateway AI oltre il routing dei modelli e la misurazione dei token. I gateway che non sono in grado di visualizzare l'identità del connettore, OAuth l'ambito, le decisioni di approvazione e i limiti di conservazione a valle saranno più difficili da utilizzare in ambienti regolamentati, aziendali e gestiti da partner.

Il problema della governance è la suddivisione dell'identità

Le chiamate al connettore coinvolgono almeno tre identità e non devono essere unite nei log o nei controlli dei criteri.

• Chiamante del gateway: la API chiave, account di servizio, carico di lavoro o applicazione partner che ha inviato la richiesta del modello.
• Utente delegato: l'utente umano o finale che ha autorizzato l'accesso a Gmail, Drive, CRM, calendario, pagamenti, dati interni o un'altra risorsa protetta.
• Destinazione connettore: il server remoto MCP o il connettore del servizio ospitato che riceve la chiamata dello strumento e può inoltrarla a un altro sistema.

Se tali identità vengono compresse in un campo denominato user, l'audit trail diventa ambiguo. Un account di servizio di produzione può inviare una richiesta per conto di 20.000 utenti finali. Un singolo essere umano può autorizzare più connettori con ambiti diversi. Un server remoto MCP può esporre strumenti supportati da più servizi downstream. Il gateway necessita di campi separati per tutti e tre.

Un modello di eventi utile inizia con campi come:

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

Questa struttura consente ai team addetti alla sicurezza, alla finanza e alla piattaforma di rispondere a domande diverse dallo stesso record. Quale inquilino ha utilizzato lo strumento? Quale chiave dell'applicazione è stata eseguita? Quale utente finale ha delegato l'accesso? Quale connettore ha ricevuto i dati? L'azione è stata di sola lettura o distruttiva? Era necessaria l'approvazione?

Connettori modello come risorse gateway

Un connettore deve essere registrato prima di essere utilizzato in produzione. Non è necessario che la registrazione sia lenta, ma dovrebbe produrre un oggetto durevole a cui la policy può fare riferimento.

Una risorsa connettore minima può includere:

• tenant_id: il tenant o l'organizzazione sono autorizzati a utilizzare il connettore.
• connector_id: un identificatore interno stabile, indipendente dai nomi visualizzati del server.
• server_url: l'URL del server remoto MCP o l'identificatore del connettore ospitato.
• owner_user_id: l'amministratore o l'utente che lo ha registrato.
• authorization_server: metadati dell'emittente o del server di autorizzazione, ove disponibili.
• allowed_tools: nomi e versioni o impronte digitali degli strumenti esaminati.
• tool_classes: lettura, scrittura, esportazione, amministrazione, pagamento, messaggistica o sconosciuto.
• approved_scopes: OAuth ambiti approvati per il connettore.
• retention_class: interno, fornitore di modelli, standard di terze parti o vietato per carichi di lavoro sensibili.
• revocation_status: attivo, user_revoked, tenant_disabled, scaduto, messo in quarantena o negato.

Questo è simile nello spirito al profilo del modello o al record delle credenziali del fornitore, ma l'autorizzazione del connettore non è lo stesso oggetto di una chiave del modello upstream. Le credenziali di runtime del provider consentono al gateway di chiamare le API del modello. I token del connettore rappresentano l'autorità delegata nei sistemi interni o di terze parti. Meritano provenienza, controlli di archiviazione e policy di audit separati.

Broker o convalida deliberatamente OAuth token

Esistono due modelli di implementazione comuni.

Mediato dal gateway OAuth

In questo modello, il gateway avvia o coordina il flusso OAuth, archivia i token di aggiornamento o il materiale dei token di accesso in un vault, genera sessioni di connettore di breve durata e allega token di accesso durante l'invio di chiamate MCP remote. Ciò conferisce al gateway un controllo efficace sul consenso, sulla durata del token, sulla revoca e sui join di controllo.

Il compromesso è la complessità. Il gateway deve gestire le schermate di consenso, la sicurezza del flusso del codice di autorizzazione, l'aggiornamento dei token, la rotazione dei token, l'archiviazione crittografata, la gestione dell'URI di reindirizzamento, la convalida dell'emittente e la configurazione dell'applicazione OAuth specifica del tenant. La RFC 9700 è importante in questo caso perché questo modello colloca il gateway vicino a OAuth responsabilità del client.

Gestito dall'applicazione OAuth

In questo modello, l'applicazione ottiene il token OAuth e lo passa attraverso il modello o il percorso del gateway quando richiama un connettore MCP remoto. La spedizione può essere più rapida perché i prodotti esistenti potrebbero già disporre di flussi di autorizzazione del connettore.

Il compromesso è una governance frammentata. Se il gateway vede solo un token opaco, potrebbe non conoscere l'oggetto, gli ambiti, l'emittente, l'aggiornamento, lo stato di revoca o la provenienza del consenso del token. Una versione più sicura di questo modello richiede che l'applicazione fornisca metadati del connettore firmati con ogni chiamata e che il gateway convalidi l'emittente, il pubblico, la scadenza, la registrazione del connettore, l'associazione dell'utente e l'ambito approvato prima dell'invio.

Per i connettori dati utente quali email, calendario, spazio di archiviazione, CRM e pagamenti, preferisci i token OAuth per utente. I token al portatore condivisi di lunga durata dovrebbero essere limitati a flussi di lavoro espliciti di account di servizio limitati a un tenant e esaminati come risorse a rischio più elevato.

Normalizza gli ambiti dello strumento prima dell'invio

MCP server possono esporre nomi di strumenti e metadati e alcuni ecosistemi forniscono suggerimenti come annotazioni di sola lettura. Utilizza questi segnali, ma non considerare i metadati forniti dal server come completamente attendibili. I metadati dello strumento possono essere errati, obsoleti, ambigui o contraddittori. La guida MCP di OWASP evidenzia i privilegi minimi, l'inserimento nella lista consentita, l'autenticazione, l'autorizzazione e il monitoraggio; MCP I 10 lavori principali richiamano l'attenzione anche sui rischi di avvelenamento da utensili.

Un gateway dovrebbe mantenere le proprie classi di azioni normalizzate:

• Leggi: cerca, elenca, ottieni, recupera, recupera, riepiloga i contenuti esistenti.
• Scrivi: crea, aggiorna, modifica, etichetta, sposta, commenta, pianifica.
• Invia: email, messaggio di chat, webhook, risposta al ticket, notifica.
• Elimina: rimuovi, elimina, archivia, revoca.
• Esportazione: download collettivo, trasferimento file, estrazione set di dati.
• Finanziario: addebito, rimborso, fattura, pagamento, modifica dell'abbonamento.
• Amministratore: modifica autorizzazione, invito utente, aggiornamento ruolo, modifica policy.
• Sconosciuto: tutto ciò che non è stato recensito o non classificato con sicurezza.

Quindi applica la policy alle classi normalizzate invece che ai nomi degli strumenti non elaborati. Ad esempio:

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

Ciò mantiene la policy stabile quando un connettore rinomina gmail.search in mail.messages.query. Lo strumento grezzo necessita ancora di revisione, ma il sistema di approvazione può ragionare in categorie operative.

Esegui un controllo del connettore prima dell'invio

Prima che il gateway consenta una chiamata al connettore avviata dal modello, dovrebbe eseguire una decisione pre-dispatch compatta. È qui che si incontrano analisi sull'utilizzo dell'AI, criteri di sicurezza, flusso di lavoro di approvazione e criteri di conservazione.

Una sequenza pratica è:

1. Risolvi tenant e chiave: identifica la chiave del gateway, il tenant, il carico di lavoro, l'ambiente e la richiesta del modello.
2. Risolvi utente finale: richiede un ID utente finale stabile per i connettori delegati. Rifiuta le chiamate delegate anonime a meno che non siano esplicitamente consentite.
3. Risolvi connettore: abbina l'URL del server o l'ID del connettore ospitato a una risorsa connettore registrata.
4. Convalida token: controlla emittente, pubblico ove applicabile, scadenza, oggetto, associazione del tenant, stato di revoca e ambiti richiesti.
5. Azione di classificazione: nome dello strumento mappa e metadati da leggere, scrivere, inviare, eliminare, esportare, finanziario, amministratore o sconosciuto.
6. Verifica limite di conservazione: determina se il carico di lavoro consente l'elaborazione e la registrazione di server MCP di terze parti.
7. Applica criterio di approvazione: autorizzazione automatica, richiesta dell'approvazione dell'utente, richiesta dell'approvazione dell'amministratore, blocco o quarantena.
8. Riserva budget se fatturabile: se l'esecuzione del connettore prevede addebiti diretti o indiretti, riserva budget prima dell'invio.
9. Scrivi la decisione: mantieni la decisione prima di chiamare il connettore, non solo dopo il successo.

Scrivere prima la decisione è importante. Se il connettore va in timeout, trasmette un output parziale o attiva un errore downstream, il log di controllo dovrebbe comunque mostrare che il gateway ha consentito o negato un tentativo di azione specifica.

L'approvazione dovrebbe tenere conto del flusso di lavoro

L'approvazione per chiamata è semplice da ragionare e spesso inutilizzabile nella pratica. Un agente dell'assistenza clienti che deve leggere un ticket, eseguire ricerche su Drive, redigere un'e-mail e aggiornare un record CRM non deve forzare l'utente a utilizzare una modalità modale per ogni operazione di lettura innocua. Allo stesso tempo, l'invio di un'e-mail, l'eliminazione di un file, il rimborso di un pagamento o l'esportazione di una cartella non dovrebbero essere delegati silenziosamente perché un modello ha selezionato uno strumento.

Una norma praticabile è stratificata:

• Consenti automaticamente strumenti di sola lettura revisionati per tenant a basso rischio e autorizzazione per nuovi utenti.
• Richiedi l'approvazione per le azioni di invio, creazione, aggiornamento, eliminazione, esportazione, finanziarie e amministrative.
• Consenti approvazioni raggruppate per un flusso di lavoro, un ambito e un intervallo di tempo denominati.
• Richiedi una nuova approvazione quando gli ambiti si espandono, le definizioni dello strumento cambiano sostanzialmente o il connettore passa a una classe di rischio più elevata.
• Blocca gli strumenti sconosciuti fino alla revisione.

Le approvazioni raggruppate devono essere esplicite. Un utente può approvare: "Per i prossimi 30 minuti, consenti a questo flusso di lavoro di supporto di effettuare ricerche in Drive e bozze di risposte, ma richiedi conferma prima dell'invio". Questo è più utile dell'interruttore Consenti/Nega del connettore binario.

I confini della conservazione necessitano di un proprio campo

Le chiamate remoteMCP possono spostare i dati al di fuori dei limiti di conservazione ed elaborazione del fornitore del modello. Ciò non è automaticamente sbagliato, ma deve essere visibile. A un carico di lavoro a cui è consentito utilizzare un endpoint del modello in base a un'impostazione di conservazione dei dati potrebbe comunque essere vietato l'invio dello stesso contenuto a un server MCP di terze parti con termini di conservazione diversi.

Aggiungi la classificazione di conservazione sia ai carichi di lavoro che ai connettori. Classi di esempio:

• internal_only: non sono consentite chiamate a connettori di terze parti.
• approved_processors_only: il connettore deve essere presente in un elenco di fornitori approvati.
• third_party_standard_allowed: l'elaborazione del connettore SaaS standard è consentita.
• no_argument_logging: chiamate al connettore consentite, ma gli argomenti devono essere oscurati o sottoposti ad hashing.
• export_blocked: lettura/ricerca consentita, esportazione collettiva negata.

È qui che il gateway protegge i team da un sottile errore: presupporre che i controlli dei dati del fornitore di modelli si applichino automaticamente a ogni strumento utilizzato dall'agente. Non si applicano necessariamente una volta inviati i dati a un server MCP remoto o a un connettore di servizio esterno.

Crea un registro di controllo del connettore

Un registro di controllo del connettore dovrebbe unire le richieste del modello, l'autorizzazione del gateway, l'invio del connettore e i risultati downstream. Non fare affidamento solo sulle tracce non elaborate del provider, poiché ciascun provider può esporre gli eventi dello strumento in modo diverso e i log dell'applicazione potrebbero omettere il token o il contesto di approvazione.

I campi contabili consigliati includono:

• model_request_id e ID traccia.
• tenant_id, gateway_key_id, carico di lavoro, ambiente e ID utente finale.
• connector_id, hash dell'URL del server, identificatore del connettore ospitato e classe di rischio.
• tool_name, versione dello strumento o impronta digitale dei metadati e classe di azione normalizzata.
• OAuth emittente, oggetto del token, hash del set di ambito, bucket di scadenza e provenienza del token.
• Hash degli argomenti, argomenti oscurati, classe di sensibilità e classe di conservazione.
• Decisione di approvazione, approvatore, ambito dell'approvazione e scadenza dell'approvazione.
• Stato dell'invio, stato della risposta, classe di errore, latenza e ID delle richieste downstream, ove disponibili.

La registrazione completa degli argomenti può aiutare la risposta agli incidenti, ma aumenta anche il rischio di privacy e conservazione. Preferisci campi strutturati, hashing, redazione selettiva e tag di riservatezza per impostazione predefinita. Consenti l'acquisizione completa solo in base a un incidente esplicito o a una policy di debug con scadenza.

Revoca e quarantena sono requisiti del prodotto

La revoca non può essere una modifica manuale del database. Gli utenti e gli amministratori necessitano di flussi di lavoro che si trasformino in uno stato immediato delle policy.

Implementa almeno queste azioni:

• Disconnessione utente: revoca o contrassegna come inattivi tutti i token per l'autorizzazione del connettore di un utente.
• Disabilita tenant: blocca un connettore per un intero tenant senza disabilitare il traffico del modello non correlato.
• Gestione scadenza token: chiusura con errore o riautorizzazione quando l'aggiornamento non riesce o l'aggiornamento dell'autorizzazione supera i criteri.
• Quarantena del connettore: blocca un connettore preservandone la configurazione e i log per eventuali indagini.
• Lista negata di emergenza: blocco in base all'hash dell'URL del server, all'ID del connettore, all'emittente o all'impronta digitale dello strumento.
• Declassamento dell'ambito: autorizza nuovamente con meno ambiti quando un flusso di lavoro non necessita più di un accesso ampio.

Il dettaglio importante dell'implementazione è che lo stato di revoca deve essere controllato al momento della spedizione. Una sincronizzazione notturna è utile per la riconciliazione, ma non è sufficiente per la risposta agli incidenti.

Sonde di conformità per MCP connettori remoti

Prima che un connettore sia disponibile per i tenant di produzione, testalo come dipendenza governata. Una breve suite di sondaggi rileva molti errori di integrazione e policy.

• Il rilevamento dei metadati restituisce un'identità del server stabile e le definizioni degli strumenti previste.
• I metadati delle risorse protette e il comportamento dell'autorizzazione corrispondono ai presupposti documentati, ove applicabile.
• I requisiti di registrazione del client dinamico sono compresi, supportati o esplicitamente disabilitati.
• Le richieste senza token falliscono in modo sicuro.
• I token scaduti falliscono in modo prevedibile e non attivano tentativi incontrollati.
• La classificazione in lettura/scrittura corrisponde al comportamento osservato, non solo alle descrizioni.
• I metadati dello strumento non validi vengono rifiutati o contrassegnati come sconosciuti.
• Le modifiche all'elenco degli strumenti attivano la revisione quando cambiano nomi, ambiti, descrizioni o classi di rischio.
• Gli errori del connettore vengono registrati senza che gli argomenti sensibili vengano divulgati in campi di errore generici.

Queste sonde non sostituiscono la revisione della sicurezza, ma forniscono al gateway un modo ripetibile per rilevare la deriva. I server remoti MCP possono cambiare indipendentemente dal fornitore del modello e indipendentemente dal ciclo di rilascio dell'applicazione.

Elenco di controllo per l'implementazione

• Crea un registro dei connettori con i campi tenant, server, autorizzazione, ambito, strumento, rischio, conservazione e revoca.
• Identità della chiave del gateway, identità dell'utente finale delegato e identità del connettore separate in ogni decisione relativa alle policy.
• Memorizza i token del connettore in un archivio credenziali, ma mantienili distinti dalle credenziali runtime del provider di modelli.
• Preferisci per utente OAuth per i connettori dati utente; limita i token di servizio condiviso a flussi di lavoro di account di servizio espliciti.
• Normalizza le azioni dello strumento in lettura, scrittura, invio, eliminazione, esportazione, finanziaria, amministrazione e sconosciuto.
• Esegui controlli pre-invio per la registrazione del connettore, la validità del token, la corrispondenza dell'ambito, la compatibilità di conservazione, lo stato di approvazione e la prenotazione del budget.
• Registra le decisioni del connettore prima dell'invio e stabilisci lo stato finale dopo la risposta o l'errore.
• Crea flussi di lavoro per la disconnessione degli utenti, la disattivazione del tenant, la quarantena dei connettori e la lista bloccata di emergenza.
• Esamina i metadati del connettore, il comportamento dei token, la deriva dello strumento e i metadati non corretti prima dell'utilizzo in produzione.

Conclusione attuabile

MCP e i connettori di servizio rendono gli agenti utili perché consentono ai modelli di agire su sistemi reali. Quella stessa utilità trasforma l'autorizzazione del connettore in una preoccupazione del piano di controllo, non in un dettaglio di tempestività ingegneristica.

Il gateway dovrebbe conoscere più del modello, del conteggio dei token e della chiave API. Dovrebbe sapere quale connettore è stato chiamato, quale utente lo ha autorizzato, quali ambiti sono stati concessi, quale classe di azione dello strumento è stata richiesta, se era necessaria l'approvazione, se il limite di conservazione era compatibile e come è possibile revocare l'accesso. Inizia con un registro dei connettori, un controllo delle policy pre-invio e un registro di controllo unito. Quindi aggiungi OAuth intermediazione, approvazioni raggruppate, verifiche di conformità e quarantena di emergenza man mano che l'utilizzo del connettore aumenta.

L'obiettivo non è bloccare l'adozione MCP remota. L'obiettivo è rendere l'accesso al connettore attribuibile, revocabile, rivedibile e compatibile con le stesse aspettative di governance che i team già applicano all'accesso al modello e a un gateway OpenAIcompatibile API.

Lettura correlata

• modelli di governance dello strumento agente più ampi