Upravljanje MCP konektorom putem AI API pristupnika: OAuth tokeni, opseg alata i dodjela po korisniku

Kada agent nazove Gmail, Drive, Stripe, interni sustav ili udaljeni MCP poslužitelj, zahtjev modela samo je dio sigurnosnog događaja. Pravo operativno pitanje je: tko je autorizirao konektor, koji su OAuth opsegi dodijeljeni, koji je alat pozvan, koji su podaci napustili granicu pružatelja modela i kako se pristup može opozvati tijekom incidenta?

AI API pristupnik koji samo modelira proxy pozive ne može odgovoriti na ta pitanja. Može znati stanara, model, ključ API, veličinu upita i cijenu. Možda ne zna da je model delegirao posao konektoru koji radi pod OAuth tokenom ljudskog korisnika. Taj jaz slabi atribuciju, politiku odobravanja, opoziv i revizijski odgovor.

Praktični obrazac je tretirati MCP autorizaciju konektora kao prvoklasni objekt kontrolne razine pristupnika. Nemojte smanjivati ​​upravljanje konektorom na popis dopuštenih naziva alata. Upravljajte upisom konektora, OAuth porijeklom tokena, klasifikacijom opsega alata, politikom odobrenja, stanjem opoziva i revizijskim zapisima kao dijelom istog sloja upravljanja koji već upravlja API upravljanjem ključem, pristupom modelu, pravilima zakupca i analitikom korištenja.

Činjenice, preporuke i predviđanja

Činjenice: OpenAI dokumentira udaljeni MCP kao kategoriju alata Odgovori API i omogućuje aplikacijama da daju OAuth pristupni token za udaljeni MCP poslužitelj. OpenAI također identificira konektore hostiranih usluga kao što su Gmail, Google Drive, Google Kalendar, Dropbox i Microsoft Teams. OpenAI dokumentacija za kontrolu podataka kaže da su MCP poslužitelji koji se koriste s udaljenim MCP poslužiteljskim alatom usluge trećih strana, a podaci koji im se šalju podliježu pravilima zadržavanja tih usluga. Dokumentacija konektora Anthropic opisuje prilagođene konektore koji koriste udaljene MCP poslužitelje i napominje da korisnici obično autoriziraju konektore putem OAuth, s dopuštenjima koja se kasnije mogu opozvati. Specifikacija autorizacije MCP koristi autorizaciju u stilu OAuth za HTTP-temeljene MCP prijenose. OAuth sigurnosne smjernice u RFC 9700 relevantne su za rukovanje tokenom, tokove autorizacijskog koda i sigurnost klijenta.

Preporuke: Gateway bi trebao registrirati konektore prije proizvodne upotrebe, vezati svaki poziv konektora za zakupca, ključ, korisnika, subjekt tokena i identitet poslužitelja, klasificirati alate prema riziku čitanja/pisanja, provoditi politiku odobrenja prije slanja i centralno održavati stanje opoziva.

Predviđanja: Daljinsko MCP usvajanje pomaknut će pristupnike umjetne inteligencije izvan usmjeravanja modela i mjerenja tokena. Pristupnike koji ne mogu vidjeti identitet konektora, OAuth opseg, odluke o odobrenju i nizvodne granice zadržavanja bit će teže koristiti u reguliranim, poslovnim okruženjima i okruženjima kojima upravljaju partneri.

Problem upravljanja je podjela identiteta

Pozivi konektora uključuju najmanje tri identiteta i ne bi se trebali spajati u zapisnicima ili provjerama pravila.

• Pozivatelj pristupnika: API ključ, račun usluge, radno opterećenje ili partnerska aplikacija koja je poslala zahtjev za model.
• Delegirani korisnik: čovjek ili krajnji korisnik koji je autorizirao pristup Gmailu, Disku, CRM-u, kalendaru, plaćanjima, internim podacima ili nekom drugom zaštićenom resursu.
• Cilj konektora: udaljeni MCP poslužitelj ili konektor hostirane usluge koji prima poziv alata i može ga proslijediti drugom sustavu.

Ako se ti identiteti skupe u jedno polje pod nazivom user, revizijski trag postaje dvosmislen. Račun proizvodne usluge može podnijeti zahtjev u ime 20.000 krajnjih korisnika. Jedan čovjek može autorizirati nekoliko konektora s različitim opsegom. Udaljeni MCP poslužitelj može otkriti alate podržane višestrukim nizvodnim uslugama. Gateway treba zasebna polja za sva tri.

Korisni model događaja počinje s poljima kao što su:

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

Ova struktura omogućuje timovima za sigurnost, financije i platformu da odgovore na različita pitanja iz istog zapisa. Koji je stanar pozvao alat? Koji ključ aplikacije je to učinio? Koji je krajnji korisnik delegirao pristup? Koji konektor je primio podatke? Je li radnja bila samo za čitanje ili destruktivna? Je li bilo potrebno odobrenje?

Priključci modela kao resursi pristupnika

Priključak treba biti upisan prije nego što se koristi u proizvodnji. Upis ne mora biti spor, ali trebao bi proizvesti trajan objekt na koji se pravila mogu pozivati.

Minimalni resurs konektora može uključivati:

• tenant_id: stanar ili organizacija kojoj je dopušteno korištenje konektora.
• connector_id: stabilni interni identifikator, neovisan o imenima za prikaz poslužitelja.
• server_url: udaljeni MCP URL poslužitelja ili identifikator hostiranog konektora.
• owner_user_id: administrator ili korisnik koji ga je upisao.
• authorization_server: metapodaci izdavača ili autorizacijskog poslužitelja ako su dostupni.
• allowed_tools: pregledani nazivi i verzije alata ili otisci prstiju.
• tool_classes: čitanje, pisanje, izvoz, administrator, plaćanje, slanje poruka ili nepoznato.
• approved_scopes: OAuth dometi odobreni za konektor.
• retention_class: interno, standard dobavljača modela, treće strane ili zabranjeno za osjetljiva radna opterećenja.
• revocation_status: aktivno, user_revoked, tenant_disabled, isteklo, u karanteni ili odbijeno.

Ovo je u duhu slično profilu modela ili zapisu vjerodajnica pružatelja usluga, ali autorizacija konektora nije isti objekt kao uzlazni ključ modela. Vjerodajnice za vrijeme izvođenja pružatelja dopuštaju pristupniku pozivanje API-ja modela. Tokeni konektora predstavljaju delegirane ovlasti u sustave treće strane ili unutarnje sustave. Zaslužuju zasebno porijeklo, kontrole pohrane i revizijska pravila.

Posredovanje ili provjera valjanosti OAuth Tokeni namjerno

Postoje dva uobičajena obrasca implementacije.

Posredovanje pristupnika OAuth

U ovom modelu pristupnik inicira ili koordinira OAuth protok, pohranjuje osvježavajuće tokene ili materijal pristupnih tokena u trezor, kuje kratkotrajne sesije konektora i prilaže pristupne tokene prilikom slanja udaljenih MCP poziva. To pristupniku daje snažnu kontrolu nad pristankom, životnim vijekom tokena, opozivom i pridruživanjima revizije.

Kompromis je složenost. Gateway mora rukovati zaslonima pristanka, sigurnošću toka autorizacijskog koda, osvježavanjem tokena, rotacijom tokena, šifriranom pohranom, upravljanjem URI-jem preusmjeravanja, provjerom valjanosti izdavatelja i OAuth konfiguracijom aplikacije specifične za stanara. RFC 9700 je ovdje bitan jer ovaj obrazac postavlja gateway blizu OAuth odgovornosti klijenta.

Upravljano aplikacijom OAuth

U ovom modelu, aplikacija dobiva OAuth token i prosljeđuje ga kroz model ili stazu pristupnika kada poziva udaljeni MCP konektor. To može biti brže za isporuku jer postojeći proizvodi možda već imaju tijekove autorizacije konektora.

Kompromis je fragmentirano upravljanje. Ako pristupnik vidi samo neprozirni token, možda neće znati predmet tokena, opsege, izdavatelja, svježinu, status opoziva ili porijeklo pristanka. Sigurnija verzija ovog obrasca zahtijeva da aplikacija pruži potpisane metapodatke konektora sa svakim pozivom, a pristupnik treba potvrditi izdavatelja, publiku, istek, upis konektora, povezivanje korisnika i odobreni opseg prije slanja.

Za konektore korisničkih podataka kao što su e-pošta, kalendar, pohrana, CRM i plaćanja, dajte prednost OAuth tokenima po korisniku. Dijeljeni dugotrajni tokeni nositelja trebali bi biti ograničeni na eksplicitne tijekove rada računa usluge dodijeljene zakupcu i pregledani kao resursi višeg rizika.

Normaliziraj opsege alata prije slanja

MCP poslužitelji mogu izložiti nazive alata i metapodatke, a neki ekosustavi daju savjete kao što su bilješke samo za čitanje. Koristite te signale, ali ne tretirajte metapodatke koje pruža poslužitelj kao potpuno pouzdane. Metapodaci alata mogu biti pogrešni, zastarjeli, dvosmisleni ili kontradiktorni. OWASP-ove MCP smjernice naglašavaju najmanje privilegije, popis dopuštenih, autentifikaciju, autorizaciju i nadzor; MCP Top 10 radova također skreće pozornost na rizike od trovanja alatom.

Gateway bi trebao održavati vlastite normalizirane klase radnji:

• Pročitajte: pretražite, popišite, dohvatite, dohvatite, dohvatite, sažmite postojeći sadržaj.
• Pišite: kreirajte, ažurirajte, uredite, označite, premjestite, komentirajte, rasporedite.
• Pošalji: e-pošta, chat poruka, webhook, odgovor na tiket, obavijest.
• Brisanje: uklanjanje, brisanje, arhiviranje, opoziv.
• Izvoz: skupno preuzimanje, prijenos datoteka, izdvajanje skupa podataka.
• Financijsko: naplata, povrat novca, faktura, isplata, promjena pretplate.
• Administrator: promjena dopuštenja, poziv korisnika, ažuriranje uloge, uređivanje pravila.
• Nepoznato: sve što nije pregledano ili nije pouzdano klasificirano.

Zatim nametnite pravila na normaliziranim klasama umjesto na neobrađenim nazivima alata. Na primjer:

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

Ovo održava politiku stabilnom kada konektor preimenuje gmail.search u mail.messages.query. Neobrađeni alat još treba pregledati, ali sustav odobravanja može razmišljati u operativnim kategorijama.

Pokreni provjeru konektora prije otpreme

Prije nego što pristupnik dopusti poziv konektora pokrenut modelom, trebao bi pokrenuti kompaktnu odluku prije otpreme. Ovdje se susreću analitika upotrebe umjetne inteligencije, sigurnosna pravila, tijek rada odobrenja i politika zadržavanja.

Praktični niz je:

1. Razriješi zakupca i ključ: identificirajte ključ pristupnika, zakupca, radno opterećenje, okruženje i zahtjev za model.
2. Rješavanje krajnjeg korisnika: zahtijevaju stabilan ID krajnjeg korisnika za delegirane konektore. Odbij anonimne delegirane pozive osim ako nisu izričito dopušteni.
3. Razriješi konektor: uskladi URL poslužitelja ili ID hostiranog konektora s prijavljenim resursom konektora.
4. Provjeri valjanost tokena: izdavatelj čeka, publika gdje je primjenjivo, istek, predmet, vezanje zakupca, stanje opoziva i potrebni opseg.
5. Klasificiraj radnju: naziv alata za mapiranje i metapodatke za čitanje, pisanje, slanje, brisanje, izvoz, financijski, administrativni ili nepoznati.
6. Provjeri granicu zadržavanja: utvrdi dopušta li radno opterećenje MCP obradu i zapisivanje poslužitelja treće strane.
7. Primjena pravila odobrenja: automatsko dopuštanje, zahtijevanje odobrenja korisnika, zahtijevanje odobrenja administratora, blokiranje ili karantena.
8. Rezervirajte proračun ako se može naplatiti: ako izvođenje konektora ima izravne ili neizravne troškove, rezervišite proračun prije otpreme.
9. Napišite odluku: ustrajte u odluci prije pozivanja konektora, a ne samo nakon uspjeha.

Prvo je napisati odluku. Ako konektor istekne, struji djelomični izlaz ili pokrene nizvodnu pogrešku, dnevnik revizije trebao bi i dalje prikazivati da je pristupnik dopustio ili odbio određenu pokušanu radnju.

Odobrenje bi trebalo biti svjesno tijeka rada

Odobrenje po pozivu jednostavno je razumjeti i često se ne može koristiti u praksi. Agent korisničke podrške koji treba pročitati kartu, pretražiti Drive, nacrtati e-poruku i ažurirati CRM zapis ne bi trebao prisiljavati korisnika na modal za svaku bezopasnu operaciju čitanja. U isto vrijeme, slanje e-pošte, brisanje datoteke, povrat plaćanja ili izvoz mape ne bi trebalo biti tiho delegirano jer je model odabrao alat.

Izvediva politika je slojevita:

• Automatsko dopuštanje pregledanih alata samo za čitanje za stanare niskog rizika i svježu autorizaciju korisnika.
• Zahtijevajte odobrenje za slanje, stvaranje, ažuriranje, brisanje, izvoz, financijske i administratorske radnje.
• Dopusti grupirana odobrenja za imenovani tijek rada, opseg i vremenski okvir.
• Zahtijevaj ponovno odobrenje kada se opseg proširi, definicije alata materijalno promijene ili se konektor premjesti u klasu višeg rizika.
• Blokiraj nepoznate alate dok se ne pregledaju.

Grupna odobrenja trebaju biti izričita. Korisnik može odobriti: "Sljedećih 30 minuta dopustite ovom tijeku rada podrške da pretražuje Disk i nacrte odgovora, ali zahtijeva potvrdu prije slanja." To je korisnije od prekidača za dopuštanje/zabranjivanje binarnog konektora.

Granice zadržavanja trebaju svoje vlastito polje

Udaljeni MCP pozivi mogu premjestiti podatke izvan granica zadržavanja i obrade pružatelja modela. To nije automatski pogrešno, ali mora biti vidljivo. Radnom opterećenju kojemu je dopuštena upotreba krajnje točke modela pod jednom postavkom zadržavanja podataka i dalje može biti zabranjeno slanje istog sadržaja poslužitelju MCP treće strane s različitim uvjetima zadržavanja.

Dodajte klasifikaciju zadržavanja radnim opterećenjima i konektorima. Primjeri klasa:

• internal_only: nisu dopušteni pozivi konektora trećih strana.
• approved_processors_only: konektor mora biti na popisu odobrenih dobavljača.
• third_party_standard_allowed: dopuštena je standardna obrada SaaS konektora.
• no_argument_logging: dopušteni pozivi konektora, ali argumenti moraju biti redigirani ili raspršeni.
• export_blocked: čitanje/pretraživanje dopušteno, skupni izvoz odbijen.

Ovdje pristupnik štiti timove od suptilne pogreške: pod pretpostavkom da se kontrole podataka davatelja modela automatski primjenjuju na svaki alat koji agent koristi. Oni se ne moraju nužno primijeniti nakon što se podaci pošalju na udaljeni MCP poslužitelj ili konektor vanjske usluge.

Izradite knjigu revizije konektora

Knjiga revizije konektora trebala bi pridružiti zahtjeve modela, autorizaciju pristupnika, slanje konektora i nizvodne rezultate. Nemojte se oslanjati samo na neobrađena praćenja pružatelja usluga jer svaki pružatelj može drugačije izložiti događaje alata, a zapisnici aplikacije mogu izostaviti token ili kontekst odobrenja.

Preporučena polja glavne knjige uključuju:

• model_request_id i ID traga.
• tenant_id, gateway_key_id, radno opterećenje, okruženje i ID krajnjeg korisnika.
• connector_id, hash URL-a poslužitelja, identifikator hostiranog konektora i klasa rizika.
• tool_name, verzija alata ili otisak metapodataka i normalizirana klasa radnje.
• OAuth izdavatelj, subjekt tokena, hash skupa opsega, segment isteka i porijeklo tokena.
• Argumenti hash, redigirani argumenti, klasa osjetljivosti i klasa zadržavanja.
• Odluka o odobrenju, odobravatelj, opseg odobrenja i istek odobrenja.
• Status slanja, status odgovora, klasa pogreške, latencija i ID-ovi nizvodnih zahtjeva gdje su dostupni.

Puno bilježenje argumenata može pomoći u odgovoru na incident, ali također povećava rizik privatnosti i zadržavanja. Preferirajte strukturirana polja, raspršivanje, selektivnu redakciju i oznake osjetljivosti prema zadanim postavkama. Puno snimanje dopustite samo pod izričitim incidentom ili pravilom otklanjanja pogrešaka s istekom.

Opoziv i karantena su zahtjevi proizvoda

Opoziv ne može biti ručno uređivanje baze podataka. Korisnici i administratori trebaju tijekove rada koji se trenutno pretvaraju u stanje pravila.

Implementirajte barem ove radnje:

• Prekid veze korisnika: opozovi ili označi neaktivnim sve tokene za autorizaciju konektora jednog korisnika.
• Onemogućivanje stanara: blokira jedan konektor za cijelog stanara bez onemogućavanja nepovezanog prometa modela.
• Upravljanje istekom tokena: neuspješno zatvaranje ili ponovno autoriziranje kada osvježavanje ne uspije ili svježina autorizacije premaši pravilo.
• Karantena konektora: blokira konektor uz očuvanje njegove konfiguracije i zapisa za istraživanje.
• Popis zabrane u hitnim slučajevima: blokiranje prema hash-u URL-a poslužitelja, ID-u konektora, izdavatelju ili otisku prsta alata.
• Smanjivanje opsega: ponovna autorizacija s manje opsega kada tijek rada više ne treba široki pristup.

Važan detalj implementacije je da se status opoziva mora provjeriti u trenutku slanja. Noćna sinkronizacija korisna je za usklađivanje, ali nije dovoljna za odgovor na incident.

Probe usklađenosti za udaljene MCP konektore

Prije nego što konektor bude dostupan proizvodnim zakupcima, testirajte ga kao upravljanu ovisnost. Paket kratkih sondi otkriva mnoge pogreške integracije i pravila.

• Otkrivanje metapodataka vraća stabilan identitet poslužitelja i očekivane definicije alata.
• Metapodaci zaštićenih resursa i ponašanje autorizacije odgovaraju dokumentiranim pretpostavkama gdje je primjenjivo.
• Zahtjevi za registraciju dinamičkog klijenta su razumljivi, podržani ili izričito onemogućeni.
• Zahtjevi bez tokena sigurno ne uspijevaju.
• Tokeni koji su istekli padaju predvidljivo i ne pokreću nekontrolirane ponovne pokušaje.
• Klasifikacija čitanja/pisanja odgovara promatranom ponašanju, ne samo opisima.
• Pogrešno oblikovani metapodaci alata su odbijeni ili označeni kao nepoznati.
• Promjene popisa alata pokreću pregled kada se promijene nazivi, opseg, opisi ili klase rizika.
• Pogreške konektora bilježe se bez curenja osjetljivih argumenata u generička polja pogreške.

Ove sonde nisu zamjena za sigurnosni pregled, ali gatewayu daju ponovljiv način otkrivanja pomaka. Udaljeni MCP poslužitelji mogu se mijenjati neovisno o dobavljaču modela i neovisno o ciklusu izdavanja vaše aplikacije.

Kontrolni popis za implementaciju

• Stvorite registar konektora s poljima zakupca, poslužitelja, autorizacije, opsega, alata, rizika, zadržavanja i opoziva.
• Odvojite identitet ključa pristupnika, delegirani identitet krajnjeg korisnika i identitet konektora u svakoj odluci o politici.
• Pohranite tokene konektora u trezor vjerodajnica, ali ih držite različitim od vjerodajnica za vrijeme izvođenja pružatelja modela.
• Preferiraj po korisniku OAuth za konektore korisničkih podataka; ograničite tokene dijeljenih usluga na eksplicitne tijekove rada računa usluge.
• Normalizirajte radnje alata u čitanje, pisanje, slanje, brisanje, izvoz, financije, administraciju i nepoznato.
• Pokrenite provjere prije otpreme za upis konektora, valjanost tokena, podudaranje opsega, kompatibilnost zadržavanja, stanje odobrenja i rezervaciju proračuna.
• Zabilježite odluke konektora prije slanja i odredite konačni status nakon odgovora ili pogreške.
• Izrada tijekova rada prekida veze korisnika, onemogućavanja stanara, karantene konektora i popisa zabrane u hitnim slučajevima.
• Provjerite metapodatke konektora, ponašanje tokena, odstupanje alata i pogrešno oblikovane metapodatke prije proizvodne upotrebe.

Zaključak koji se može poduzeti

MCP i servisni konektori čine agente korisnima jer omogućuju modelima da djeluju na stvarnim sustavima. Ta ista korisnost pretvara autorizaciju konektora u brigu kontrolne ravnine, a ne detalj brzog inženjeringa.

Gateway bi trebao znati više od modela, broja tokena i API ključa. Trebao bi znati koji je konektor pozvan, koji ga je korisnik autorizirao, koji su opsegi dodijeljeni, koja je klasa radnje alata zatražena, je li potrebno odobrenje, je li granica zadržavanja kompatibilna i kako se pristup može opozvati. Započnite s registrom konektora, provjerom pravila prije slanja i združenom knjigom revizije. Zatim dodajte OAuth posredovanje, grupirana odobrenja, ispitivanja sukladnosti i karantenu u hitnim slučajevima kako upotreba konektora raste.

Cilj nije blokirati daljinsko MCP usvajanje. Cilj je učiniti pristup konektoru pripisivim, opozivim, preglednim i kompatibilnim s istim očekivanjima upravljanja koja timovi već primjenjuju na pristup modelu i OpenAI-kompatibilan API pristupnik.

Povezano čitanje

• šire upravljanje agentskim alatom uzorci