Upravljanje konektorja MCP prek prehoda AI API: žetoni OAuth, obsegi orodij in dodeljevanje na uporabnika

Ko agent pokliče Gmail, Drive, Stripe, notranji sistem ali oddaljeni MCP strežnik, je zahteva modela le del varnostnega dogodka. Pravo operativno vprašanje je: kdo je odobril konektor, kateri OAuth obsegi so bili odobreni, katero orodje je bilo klicano, kateri podatki so zapustili mejo ponudnika modela in kako je mogoče preklicati dostop med incidentom?

Umetna inteligenca API prehod, ki posreduje samo modelne klice, ne more odgovoriti na ta vprašanja. Morda pozna najemnika, model, ključ API, velikost poziva in ceno. Morda ne ve, da je model delo prenesel na konektor, ki deluje pod žetonom OAuth človeškega uporabnika. Ta vrzel slabi dodeljevanje, politiko odobritve, preklic in revizijski odziv.

Praktični vzorec je obravnavati MCP avtorizacijo konektorja kot prvorazredni objekt nadzorne ravnine prehoda. Upravljanja konektorja ne zmanjšajte na seznam dovoljenih imen orodij. Upravljajte vpis konektorja, OAuth izvor žetona, klasifikacijo obsega orodja, pravilnik o odobritvi, stanje preklica in revizijsko beleženje kot del iste ravni upravljanja, ki že obravnava API upravljanje ključev, dostop do modela, pravilnik najemnika in analitiko uporabe.

Dejstva, priporočila in napovedi

Dejstva: OpenAI dokumentira oddaljeni MCP kot kategorijo orodja Odzivi API in omogoča aplikacijam, da zagotovijo OAuth dostopni žeton za oddaljeni MCP strežnik. OpenAI identificira tudi konektorje gostujočih storitev, kot so Gmail, Google Drive, Google Koledar, Dropbox in Microsoft Teams. Dokumentacija OpenAI o nadzoru podatkov pravi, da so MCP strežniki, ki se uporabljajo z oddaljenim MCP strežniškim orodjem, storitve tretjih oseb in za podatke, poslane njim, veljajo pravilniki o hrambi teh storitev. Dokumentacija povezovalnika Anthropic opisuje povezovalnike po meri z uporabo oddaljenih strežnikov MCP in ugotavlja, da uporabniki običajno pooblastijo povezovalnike prek OAuth z dovoljenji, ki jih je mogoče pozneje preklicati. Specifikacija avtorizacije MCP uporablja avtorizacijo v slogu OAuth za prevoze MCP na osnovi HTTP. OAuth Varnostna navodila v RFC 9700 so pomembna za ravnanje z žetoni, tokove avtorizacijske kode in varnost odjemalca.

Priporočila: Prehod mora registrirati konektorje pred produkcijsko uporabo, povezati vsak klic konektorja z najemnikom, ključem, uporabnikom, subjektom žetona in identiteto strežnika, razvrstiti orodja glede na tveganje branja/pisanja, uveljaviti politiko odobritve pred pošiljanjem in centralno vzdrževati stanje preklica.

Napovedi: Oddaljeno MCP sprejemanje bo potisnilo prehode umetne inteligence onkraj usmerjanja modela in merjenja žetonov. Prehode, ki ne vidijo identitete konektorja, OAuth obsega, odločitev o odobritvi in spodnjih meja zadrževanja, bo težje uporabljati v reguliranih okoljih, okoljih podjetij in okoljih, ki jih upravljajo partnerji.

Težava upravljanja je razcep identitete

Klici povezovalnika vključujejo vsaj tri identitete in jih ne bi smeli združiti v dnevnikih ali preverjanjih pravilnikov.

• Klicatelj prehoda: API ključ, storitveni račun, delovna obremenitev ali partnerska aplikacija, ki je poslala zahtevo za model.
• Pooblaščeni uporabnik: človek ali končni uporabnik, ki je odobril dostop do Gmaila, Drivea, CRM-ja, koledarja, plačil, internih podatkov ali drugega zaščitenega vira.
• Cilj konektorja: oddaljeni MCP strežnik ali konektor gostujoče storitve, ki sprejme klic orodja in ga lahko posreduje drugemu sistemu.

Če se te identitete strnejo v eno polje, imenovano user, postane revizijska sled dvoumna. Račun proizvodne storitve lahko odda zahtevo v imenu 20.000 končnih uporabnikov. En človek lahko odobri več konektorjev z različnimi obsegi. Oddaljeni strežnik MCP lahko izpostavi orodja, ki jih podpira več nadaljnjih storitev. Prehod potrebuje ločena polja za vsa tri.

Uporaben model dogodkov se začne s polji, kot so:

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

Ta struktura omogoča ekipam za varnost, finance in platforme, da odgovorijo na različna vprašanja iz istega zapisa. Kateri najemnik je priklical orodje? Kateri ključ aplikacije je to naredil? Kateri končni uporabnik je dodelil dostop? Kateri konektor je prejel podatke? Je bilo dejanje samo za branje ali destruktivno? Ali je bila potrebna odobritev?

Modelni konektorji kot viri prehoda

Poveznik je treba prijaviti, preden se uporabi v proizvodnji. Ni nujno, da je vpis počasen, vendar mora ustvariti trajen predmet, na katerega se pravilnik lahko sklicuje.

Minimalni vir povezovalnika lahko vključuje:

• tenant_id: najemnik ali organizacija ima dovoljenje za uporabo povezovalnika.
• connector_id: stabilen notranji identifikator, neodvisen od prikaznih imen strežnika.
• server_url: URL oddaljenega MCP strežnika ali identifikator gostujočega priključka.
• owner_user_id: skrbnik ali uporabnik, ki ga je vpisal.
• authorization_server: metapodatki izdajatelja ali avtorizacijskega strežnika, kjer so na voljo.
• allowed_tools: pregledana imena in različice orodij ali prstni odtisi.
• tool_classes: branje, pisanje, izvoz, skrbništvo, plačilo, sporočanje ali neznano.
• approved_scopes: OAuth obsegi, odobreni za konektor.
• retention_class: notranji standard, ponudnik modela, standard tretje osebe ali prepovedano za občutljive delovne obremenitve.
• revocation_status: aktivno, user_revoked, tenant_disabled, poteklo, v karanteni ali zavrnjeno.

To je po duhu podobno profilu modela ali zapisu poverilnic ponudnika, vendar avtorizacija konektorja ni isti predmet kot ključ modela navzgor. Poverilnice izvajalnega okolja ponudnika omogočajo, da prehod pokliče API-je modela. Žetoni konektorja predstavljajo delegirano pooblastilo v sisteme tretjih oseb ali notranje sisteme. Zaslužijo si ločeno poreklo, nadzor shranjevanja in revizijsko politiko.

Posredovanje ali preverjanje OAuth Žetoni namerno

Obstajata dva pogosta vzorca implementacije.

Posredovanje prehoda OAuth

V tem modelu prehod sproži ali koordinira tok OAuth, shrani žetone osveževanja ali gradivo žetonov za dostop v trezor, kuje kratkotrajne seje povezovalnika in pripne žetone za dostop pri pošiljanju oddaljenih MCP klicev. To daje prehodu močan nadzor nad soglasjem, življenjsko dobo žetona, preklicem in revizijskimi pridružitvami.

Kompromis je zapletenost. Prehod mora upravljati zaslone za soglasje, varnost pretoka avtorizacijske kode, osveževanje žetona, rotacijo žetona, šifrirano shranjevanje, upravljanje preusmeritve URI, preverjanje veljavnosti izdajatelja in konfiguracijo aplikacije OAuth, specifične za najemnika. RFC 9700 je tukaj pomemben, ker ta vzorec postavlja prehod blizu OAuth odgovornosti odjemalca.

Upravljano z aplikacijo OAuth

V tem modelu aplikacija pridobi žeton OAuth in ga posreduje skozi model ali pot prehoda, ko prikliče oddaljeni konektor MCP. To je lahko hitrejše za pošiljanje, ker obstoječi izdelki morda že imajo tokove avtorizacije povezovalnika.

Kompromis je razdrobljeno upravljanje. Če prehod vidi samo neprozoren žeton, morda ne pozna predmeta žetona, obsegov, izdajatelja, svežosti, statusa preklica ali porekla soglasja. Varnejša različica tega vzorca zahteva, da aplikacija zagotovi podpisane metapodatke povezovalnika z vsakim klicem, prehod pa mora potrditi izdajatelja, ciljno skupino, potek veljavnosti, včlanitev povezovalnika, vezavo uporabnika in odobren obseg pred pošiljanjem.

Za konektorje uporabniških podatkov, kot so e-pošta, koledar, shramba, CRM in plačila, raje uporabite OAuth žetone za vsakega uporabnika. Dolgotrajni nosilni žetoni v skupni rabi bi morali biti omejeni na eksplicitne poteke dela storitvenega računa, ki se nanašajo na najemnika, in jih pregledati kot vire z večjim tveganjem.

Normaliziraj obsege orodja pred pošiljanjem

MCP strežniki lahko razkrijejo imena orodij in metapodatke, nekateri ekosistemi pa nudijo namige, kot so opombe samo za branje. Uporabite te signale, vendar metapodatkov, ki jih posreduje strežnik, ne obravnavajte kot popolnoma zaupanja vrednih. Metapodatki orodja so lahko napačni, zastareli, dvoumni ali kontradiktorni. Smernice OWASP MCP poudarjajo najmanjše privilegije, seznam dovoljenih, avtentikacijo, avtorizacijo in nadzor; MCP Top 10 del opozarja tudi na tveganje zastrupitve z orodjem.

Prehod mora vzdrževati svoje normalizirane razrede dejanj:

• Preberite: iskanje, seznam, pridobivanje, pridobivanje, pridobivanje, povzemanje obstoječe vsebine.
• Pišite: ustvarite, posodobite, uredite, označite, premaknite, komentirajte, razporedite.
• Pošlji: e-pošta, sporočilo v klepetu, webhook, odgovor na zahtevo, obvestilo.
• Izbriši: odstrani, počisti, arhiviraj, prekliči.
• Izvoz: množični prenos, prenos datotek, ekstrakcija nabora podatkov.
• Finančno: bremenitev, vračilo, račun, izplačilo, sprememba naročnine.
• Skrbnik: sprememba dovoljenja, povabilo uporabnika, posodobitev vloge, urejanje pravilnika.
• Neznano: vse, kar ni pregledano ali ni zanesljivo razvrščeno.

Nato uveljavite pravilnik za normalizirane razrede namesto neobdelanih imen orodij. Na primer:

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

To ohranja pravilnik stabilen, ko konektor preimenuje gmail.search v mail.messages.query. Neobdelano orodje je še vedno treba pregledati, vendar lahko sistem odobritve razmišlja v operativnih kategorijah.

Zaženite preverjanje konektorja pred pošiljanjem

Preden prehod dovoli klic konektorja, ki ga sproži model, mora zagnati kompaktno odločitev pred pošiljanjem. Tukaj se srečujejo analiza uporabe umetne inteligence, varnostna politika, potek dela za odobritev in politika hrambe.

Praktično zaporedje je:

1. Razreši najemnika in ključ: določite ključ prehoda, najemnika, delovno obremenitev, okolje in zahtevo modela.
2. Razreši končnega uporabnika: zahteva stabilen ID končnega uporabnika za pooblaščene povezovalnike. Zavrni anonimne delegirane klice, razen če so izrecno dovoljeni.
3. Razreši konektor: ujemanje URL-ja strežnika ali ID-ja gostujočega konektorja z vpisanim virom konektorja.
4. Preverjanje žetona: preverite izdajatelja, ciljno skupino, kjer je primerno, potek veljavnosti, zadevo, vezavo najemnika, stanje preklica in zahtevana področja.
5. Dejanje razvrščanja: ime orodja za zemljevid in metapodatki za branje, pisanje, pošiljanje, brisanje, izvoz, finančno, skrbniško ali neznano.
6. Preverite mejo hrambe: določite, ali delovna obremenitev dovoljuje MCP obdelavo in beleženje strežnikov tretjih oseb.
7. Uporaba pravilnika o odobritvi: samodejno dovoli, zahteva odobritev uporabnika, zahteva odobritev skrbnika, blokira ali postavi v karanteno.
8. Rezerviraj proračun, če je plačljiv: če ima izvedba konektorja neposredne ali posredne stroške, rezerviraj proračun pred pošiljanjem.
9. Napišite odločitev: vztrajajte pri odločitvi, preden pokličete konektor, ne šele po uspehu.

Najprej je pomembno napisati odločitev. Če konektor poteče, pretaka delni izhod ali sproži napako v spodnjem toku, mora dnevnik nadzora še vedno pokazati, da je prehod dovolil ali zavrnil določen poskus dejanja.

Odobritev mora upoštevati potek dela

Odobritev na klic je preprosta in v praksi pogosto neuporabna. Agent za podporo strankam, ki mora prebrati prijavo, iskati v storitvi Drive, osnutek e-pošte in posodobiti zapis CRM, uporabnika ne bi smel prisiliti skozi modal za vsako neškodljivo operacijo branja. Istočasno pošiljanje e-pošte, brisanje datoteke, vračilo plačila ali izvoz mape ne bi smeli biti tiho delegirani, ker je model izbral orodje.

Uporabna politika je večplastna:

• Samodejno dovoli pregledana orodja samo za branje za najemnike z nizkim tveganjem in novo avtorizacijo uporabnikov.
• Zahtevaj odobritev za pošiljanje, ustvarjanje, posodabljanje, brisanje, izvoz, finančna in skrbniška dejanja.
• Omogočanje skupinskih odobritev za imenovan potek dela, obseg in časovno okno.
• Zahtevaj ponovno odobritev, ko se obsegi razširijo, definicije orodij bistveno spremenijo ali se konektor premakne v višji razred tveganja.
• Blokiraj neznana orodja, dokler niso pregledana.

Odobritve v skupinah morajo biti izrecne. Uporabnik lahko odobri: "Naslednjih 30 minut dovolite temu delovnemu toku podpore, da išče Drive in osnutke odgovorov, vendar zahteva potrditev pred pošiljanjem." To je bolj uporabno kot stikalo za dovoljenje/zavrnitev binarnega konektorja.

Meje zadrževanja potrebujejo svoje lastno polje

Oddaljeni MCP klici lahko premaknejo podatke izven meja hrambe in obdelave ponudnika modela. To ni samodejno napačno, vendar mora biti vidno. Delovni obremenitvi, ki ji je dovoljena uporaba končne točke modela pod eno nastavitvijo hrambe podatkov, je morda še vedno prepovedano pošiljanje iste vsebine strežniku tretje osebe MCP z drugačnimi pogoji hrambe.

Dodajte klasifikacijo hrambe delovnim obremenitvam in povezovalnikom. Primeri razredov:

• internal_only: klici povezovalnika tretjih oseb niso dovoljeni.
• approved_processors_only: konektor mora biti na seznamu odobrenih prodajalcev.
• third_party_standard_allowed: standardna obdelava priključka SaaS je dovoljena.
• no_argument_logging: klici konektorja so dovoljeni, vendar morajo biti argumenti redigirani ali zgoščeni.
• export_blocked: branje/iskanje dovoljeno, masovni izvoz zavrnjen.

Tukaj prehod ščiti ekipe pred subtilno napako: ob predpostavki, da se nadzor podatkov ponudnika modela samodejno uporablja za vsako orodje, ki ga uporablja agent. Ni nujno, da veljajo, ko so podatki poslani oddaljenemu MCP strežniku ali zunanjemu priključku za storitve.

Izdelajte knjigo revizije povezovalnika

Knjiga nadzora povezovalnika bi morala združevati zahteve po modelu, avtorizacijo prehoda, pošiljanje povezovalnika in rezultate na nižji stopnji. Ne zanašajte se samo na neobdelane sledi ponudnika, ker lahko vsak ponudnik dogodke orodij razkrije drugače, dnevniki aplikacij pa lahko izpustijo žeton ali kontekst odobritve.

Priporočena polja glavne knjige vključujejo:

• model_request_id in ID sledi.
• tenant_id, gateway_key_id, delovna obremenitev, okolje in ID končnega uporabnika.
• connector_id, zgoščena vrednost URL-ja strežnika, identifikator gostujočega priključka in razred tveganja.
• tool_name, različica orodja ali prstni odtis metapodatkov in normaliziran razred dejanj.
• OAuth izdajatelj, predmet žetona, razpršitev nabora obsega, vedro poteka in izvor žetona.
• Zgoščena vrednost argumentov, redigirani argumenti, razred občutljivosti in razred hrambe.
• Odločitev o odobritvi, odobritelj, obseg odobritve in potek odobritve.
• Stanje odpreme, stanje odgovora, razred napake, zakasnitev in ID-ji zahtev nižjega toka, kjer so na voljo.

Popolno beleženje argumentov lahko pomaga pri odzivanju na incidente, vendar tudi poveča zasebnost in tveganje zadrževanja. Privzeto daj prednost strukturiranim poljem, zgoščevanju, selektivnemu urejanju in oznakam občutljivosti. Dovoli popoln zajem samo v okviru izrecnega incidenta ali pravilnika o odpravljanju napak s potekom.

Preklic in karantena sta zahtevi za izdelek

Preklic ne more biti ročno urejanje baze podatkov. Uporabniki in skrbniki potrebujejo poteke dela, ki se takoj spremenijo v stanje pravilnika.

Izvedite vsaj ta dejanja:

• Uporabniška prekinitev povezave: prekliči ali označi neaktivne vse žetone za avtorizacijo konektorja enega uporabnika.
• Onemogoči najemnika: blokira en konektor za celotnega najemnika, ne da bi onemogočil promet nepovezanega modela.
• Obravnava poteka žetona: neuspešno zaprtje ali ponovna avtorizacija, ko osvežitev ne uspe ali svežost avtorizacije presega pravilnik.
• Karantena konektorja: blokirajte konektor, hkrati pa ohranite njegovo konfiguracijo in dnevnike za preiskavo.
• Seznam zavrnitev v sili: blokiranje glede na zgoščeno vrednost URL-ja strežnika, ID konektorja, izdajatelja ali prstni odtis orodja.
• Znižanje obsega: ponovno avtorizirajte z manj obsegi, ko potek dela ne potrebuje več širokega dostopa.

Pomembna podrobnost izvedbe je, da je treba status preklica preveriti ob odpremi. Nočna sinhronizacija je uporabna za usklajevanje, vendar ne zadostuje za odziv na incident.

Sonde skladnosti za oddaljene MCP priključke

Preden je konektor na voljo najemnikom proizvodnje, ga preizkusite kot regulirano odvisnost. Komplet kratkih sond odkrije številne napake integracije in pravilnika.

• Odkrivanje metapodatkov vrne stabilno identiteto strežnika in pričakovane definicije orodij.
• Metapodatki zaščitenega vira in vedenje avtorizacije se ujemajo z dokumentiranimi predpostavkami, kjer je to primerno.
• Zahteve za registracijo dinamičnega odjemalca so razumljive, podprte ali izrecno onemogočene.
• Zahteve brez žetonov varno ne uspejo.
• Potečeni žetoni ne uspejo predvidljivo in ne sprožijo nenadzorovanih ponovnih poskusov.
• Klasifikacija branja/pisanja se ujema z opazovanim vedenjem, ne le z opisi.
• Napačno oblikovani metapodatki orodja so zavrnjeni ali označeni kot neznani.
• Spremembe seznama orodij sprožijo pregled, ko se spremenijo imena, obsegi, opisi ali razredi tveganja.
• Napake povezovalnika se beležijo brez uhajanja občutljivih argumentov v generična polja napak.

Te sonde niso nadomestilo za varnostni pregled, ampak dajejo prehodu ponovljiv način za zaznavanje premikanja. Oddaljeni MCP strežniki se lahko spremenijo neodvisno od ponudnika modela in neodvisno od cikla izdaje vaše aplikacije.

Kontrolni seznam za implementacijo

• Ustvarite register konektorja s polji najemnika, strežnika, avtorizacije, obsega, orodja, tveganja, hrambe in preklica.
• Ločena identiteta ključa prehoda, delegirana identiteta končnega uporabnika in identiteta konektorja v vsaki odločitvi pravilnika.
• Shranite žetone povezovalnika v shrambo poverilnic, vendar naj bodo ločeni od poverilnic izvajalnega okolja ponudnika modela.
• Prednost glede na uporabnika OAuth za konektorje uporabniških podatkov; omeji žetone storitev v skupni rabi na eksplicitne delovne tokove storitvenega računa.
• Normalizirajte dejanja orodja v branje, pisanje, pošiljanje, brisanje, izvoz, finančno, skrbniško in neznano.
• Zaženite preverjanja pred pošiljanjem za včlanitev konektorja, veljavnost žetona, ujemanje obsega, združljivost zadrževanja, stanje odobritve in rezervacijo proračuna.
• Zabeležite odločitve konektorja pred pošiljanjem in poravnajte končno stanje po odgovoru ali napaki.
• Izdelajte poteke dela za prekinitev povezave med uporabniki, onemogočanje najemnika, karanteno konektorja in seznam za zavrnitev v sili.
• Preskusi metapodatke konektorja, vedenje žetona, odmik orodja in nepravilno oblikovane metapodatke pred produkcijsko uporabo.

Uporabni sklep

MCP in povezovalniki storitev naredijo agente uporabne, saj omogočajo modelom delovanje v realnih sistemih. Ta ista uporabnost spremeni pooblastilo konektorja v skrb nadzorne ravnine in ne podrobnosti hitrega inženiringa.

Prehod mora vedeti več kot model, število žetonov in ključ API. Vedeti mora, kateri konektor je bil poklican, kateri uporabnik ga je pooblastil, kateri obsegi so bili odobreni, kateri razred dejanj orodja je bil zahtevan, ali je bila potrebna odobritev, ali je bila meja hrambe združljiva in kako je mogoče dostop preklicati. Začnite z registrom povezovalnikov, preverjanjem pravilnika pred pošiljanjem in združeno revizijsko knjigo. Nato dodajte OAuth posredništvo, skupinske odobritve, sonde skladnosti in karanteno v sili, ko se uporaba konektorjev povečuje.

Cilj ni preprečiti sprejemanja na daljavo MCP. Cilj je omogočiti dostop konektorja, ki ga je mogoče pripisati, preklicati, pregledati in združljiv z enakimi pričakovanji glede upravljanja, ki jih ekipe že uporabljajo za dostop do modela in OpenAI-združljiv API prehod.

Sorodno branje

• upravljanje širšega agentskega orodja vzorci