MCP-ühenduse haldamine AI API lüüsi kaudu: OAuthi märgid, tööriistade ulatus ja kasutajapõhine omistamine

Kui agent helistab Gmailile, Drive'ile, Stripe'ile, sisesüsteemile või MCP kaugserverile, on mudelipäring vaid osa turvasündmusest. Tegelik tööküsimus on järgmine: kes volitas konnektorit, millised OAuth ulatust anti, milline tööriist käivitati, millised andmed väljusid mudelipakkuja piirist ja kuidas saab juurdepääsu intsidendi ajal tühistada?

AI API lüüs, mis edastab ainult mudelikõnesid, ei suuda neile küsimustele vastata. See võib teada rentnikku, mudelit, API võtit, viipa suurust ja maksumust. Ta ei pruugi teada, et mudel delegeeris töö konnektorile, mis töötab inimkasutaja märgi OAuth all. See lünk nõrgendab omistamist, kinnituseeskirju, tühistamist ja auditi vastust.

Praktiline muster on käsitleda MCP konnektori autoriseerimist esmaklassilise lüüsi juhtimistasandi objektina. Ärge vähendage konnektori juhtimist tööriistanimede lubatud loendisse. Hallake konnektori registreerimist, OAuth märgi päritolu, tööriista ulatuse klassifitseerimist, kinnitamispoliitikat, tühistamise olekut ja auditi logimist osana samast halduskihist, mis juba tegeleb API võtmehalduse, mudeli juurdepääsu, rentniku reeglite ja kasutusanalüütikaga.

Faktid, soovitused ja ennustused

Faktid: OpenAI dokumenteerib kaug-MCP vastuste API tööriistakategooriana ja võimaldab rakendustel pakkuda OAuth kaugserverile MCP juurdepääsuluba. OpenAI identifitseerib ka hostitud teenuse konnektorid, nagu Gmail, Google Drive, Google Calendar, Dropbox ja Microsoft Teams. Kasutaja OpenAI andmehalduse dokumentatsioon ütleb, et MCP serverid, mida kasutatakse serveri MCP kaugtööriistaga, on kolmanda osapoole teenused ja neile saadetud andmetele kehtivad nende teenuste säilitamiseeskirjad. Konnektori Anthropic dokumentatsioonis kirjeldatakse kohandatud konnektoreid, mis kasutavad MCP kaugservereid, ja märgitakse, et kasutajad volitavad konnektoreid tavaliselt OAuth kaudu, lubadega, mida saab hiljem tühistada. MCP volituse spetsifikatsioon kasutab OAuth-stiilis autoriseerimist HTTP-põhiste MCP vedude jaoks. OAuth RFC 9700 turbejuhised on asjakohased lubade käsitlemise, autoriseerimiskoodi voogude ja kliendi turvalisuse osas.

Soovitused: Lüüs peaks registreerima konnektorid enne tootmiskasutust, siduma iga konnektori kutse rentniku, võtme, kasutaja, loa subjekti ja serveri identiteediga, klassifitseerima tööriistu lugemis-/kirjutusriski järgi, jõustama heakskiidupoliitika enne saatmist ja säilitama tühistamise oleku tsentraalselt.

Prognoosid: Kaugjuhtimine MCP lükkab AI-lüüsid mudelimarsruutimisest ja märgimõõtmisest kaugemale. Lüüsi, mis ei näe konnektori identiteeti, OAuth ulatust, heakskiiduotsuseid ja allavoolu säilitamise piire, on reguleeritud, ettevõtete ja partnerite hallatavates keskkondades raskem kasutada.

Juhtimisprobleem on identiteedi lõhenemine

Konnektori kõned hõlmavad vähemalt kolme identiteeti ja neid ei tohiks logides ega eeskirjade kontrollides liita.

• Lüüsi helistaja: võti API, teenusekonto, töökoormus või partnerirakendus, mis esitas mudelitaotluse.
• Delegeeritud kasutaja: inimene või lõppkasutaja, kes andis juurdepääsu Gmailile, Drive'ile, CRM-ile, kalendrile, maksetele, siseandmetele või muule kaitstud ressursile.
• Konnektori sihtmärk: kaugserver MCP või hostitud teenuse konnektor, mis võtab vastu tööriistakõne ja võib selle teise süsteemi edastada.

Kui need identiteedid kukuvad kokku ühele väljale nimega user, muutub kontrolljälg mitmetähenduslikuks. Tootmisteenuse konto võib esitada taotluse 20 000 lõppkasutaja nimel. Üks inimene võib volitada mitut erineva ulatusega pistikut. Kaugserver MCP võib paljastada tööriistad, mida toetavad mitmed allavooluteenused. Lüüs vajab kõigi kolme jaoks eraldi väljasid.

Kasulik sündmusemudel algab selliste väljadega nagu:

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

See struktuur võimaldab turva-, finants- ja platvormimeeskondadel vastata sama kirje erinevatele küsimustele. Milline rentnik kasutas tööriista? Milline rakenduse võti seda tegi? Millisele lõppkasutajale delegeeritud juurdepääs? Milline konnektor võttis vastu andmeid? Kas tegevus oli kirjutuskaitstud või hävitav? Kas kinnitus oli vajalik?

Mudelühendused lüüsiressurssidena

Konnektor tuleb registreerida enne, kui seda tootmises kasutatakse. Registreerimine ei pea olema aeglane, kuid see peaks tootma vastupidava objekti, millele reeglid võivad viidata.

Minimaalne konnektoriressurss võib hõlmata järgmist:

• tenant_id: rentnikul või organisatsioonil on lubatud konnektorit kasutada.
• connector_id: stabiilne sisemine identifikaator, mis ei sõltu serveri kuvatavatest nimedest.
• server_url: kaugserveri MCP URL või hostitud konnektori identifikaator.
• owner_user_id: administraator või kasutaja, kes selle registreeris.
• authorization_server: väljaandja või autoriseerimisserveri metaandmed, kui need on saadaval.
• allowed_tools: üle vaadatud tööriistade nimed ja versioonid või sõrmejäljed.
• tool_classes: lugemine, kirjutamine, eksportimine, administraator, makse, sõnumside või teadmata.
• approved_scopes: OAuth konnektori jaoks kinnitatud ulatust.
• retention_class: sisemine, mudelipakkuja, kolmanda osapoole standard või keelatud tundlike töökoormuste korral.
• revocation_status: aktiivne, user_revoked, tenant_disabled, aegunud, karantiini pandud või keelatud.

See on olemuselt sarnane mudeliprofiili või pakkuja mandaadikirjega, kuid konnektori autoriseerimine ei ole sama objekt, mis ülesvoolu mudelivõti. Pakkuja käitusaja mandaadid võimaldavad lüüsil kutsuda mudeli API-sid. Ühendusmärgid esindavad kolmanda osapoole või sisesüsteemidesse delegeeritud volitusi. Need väärivad eraldi päritolu, ladustamiskontrolli ja auditipoliitikat.

Maakler või kinnitage OAuth märgid tahtlikult

On kaks levinumat rakendusmustrit.

Lüüsi vahendatud OAuth

Selles mudelis algatab või koordineerib lüüs OAuth voogu, salvestab värskendusluba või juurdepääsulubade materjali varahoidlasse, loob lühiajalisi konnektoriseansse ja lisab kaugkõnede MCP saatmisel juurdepääsulubasid. See annab lüüsile tugeva kontrolli nõusoleku, loa kasutusaja, tühistamise ja auditi liitumiste üle.

Müügilahendus on keerukus. Lüüs peab käsitlema nõusolekuekraane, autoriseerimiskoodi voo turvalisust, loa värskendamist, loa pööramist, krüpteeritud salvestusruumi, ümbersuunamise URI haldust, väljaandja valideerimist ja rentnikupõhist OAuth rakenduse konfiguratsiooni. RFC 9700 on siin oluline, sest see muster asetab lüüsi OAuth kliendi kohustuste lähedale.

Rakenduse hallatav OAuth

Selles mudelis hangib rakendus OAuth märgi ja edastab selle kaugühenduse MCP käivitamisel mudeli või lüüsi tee kaudu. Selle tarnimine võib olla kiirem, kuna olemasolevatel toodetel võib juba olla konnektori autoriseerimisvood.

Müügilahendus on killustatud juhtimine. Kui lüüs näeb ainult läbipaistmatut luba, ei pruugi see teada loa teemat, ulatust, väljaandjat, värskust, tühistamise olekut ega nõusoleku päritolu. Selle mustri turvalisem versioon nõuab, et rakendus esitaks iga kõnega allkirjastatud konnektori metaandmed ning lüüs peaks enne saatmist kinnitama väljaandja, sihtrühma, aegumise, konnektori registreerimise, kasutaja sidumise ja kinnitatud ulatuse.

Kasutajaandmete konnektorite (nt e-post, kalender, salvestusruum, kliendisuhete haldus ja maksed) puhul eelistage kasutajapõhiseid märke OAuth. Jagatud pikaealised kandjamärgid peaksid piirduma selgesõnaliste teenusekonto töövoogudega, mis on hõlmatud rentnikule ja mida vaadatakse üle kui kõrgema riskiga ressursse.

Tööriista ulatuse normaliseerimine enne saatmist

MCP serverid võivad avaldada tööriistade nimesid ja metaandmeid ning mõned ökosüsteemid pakuvad vihjeid, näiteks kirjutuskaitstud märkusi. Kasutage neid signaale, kuid ärge käsitlege serveri pakutavaid metaandmeid täielikult usaldusväärsena. Tööriista metaandmed võivad olla valed, aegunud, mitmetähenduslikud või võistlevad. OWASP-i MCP juhised tõstavad esile vähimad privileegid, lubade nimekirja lisamine, autentimine, autoriseerimine ja jälgimine; MCP 10 parimat tööd juhivad tähelepanu ka tööriistamürgituse riskidele.

Lüüs peaks säilitama oma normaliseeritud tegevusklassid:

• Loe: otsige, loendage, hankige, tooge, tooge, tehke kokkuvõte olemasolevast sisust.
• Kirjutage: looge, värskendage, redigeerige, sildistage, teisaldage, kommenteerige, ajakavage.
• Saada: meil, vestlussõnum, veebihaak, pileti vastus, teatis.
• Kustuta: eemalda, tühjenda, arhiivi, tühista.
• Eksport: hulgiallalaadimine, failiedastus, andmestiku ekstraktimine.
• Finants: tasu, tagasimakse, arve, väljamakse, tellimuse muutmine.
• Administraator: loa muutmine, kasutaja kutse, rollivärskendus, eeskirjade muutmine.
• Tundmatu: kõik, mida pole üle vaadatud või mis pole kindlalt klassifitseeritud.

Seejärel jõustage reeglid normaliseeritud klassidele, mitte tööriistade töötlemata nimedele. Näiteks:

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

See hoiab poliitika stabiilsena, kui konnektor nimetab gmail.search ümber numbriks mail.messages.query. Töötlemata tööriist vajab veel ülevaatamist, kuid kinnitussüsteem võib põhjendada töökategooriaid.

Käitage väljasaatmiseelne konnektori kontroll

Enne kui lüüs lubab mudeli algatatud konnektorikõne, peaks see käivitama kompaktse saatmiseelse otsuse. Siin kohtuvad AI kasutusanalüütika, turbeeeskirjad, kinnitamise töövoog ja säilitamiseeskirjad.

Praktiline jada on järgmine:

1. Üürniku ja võtme lahendamine: tuvastage lüüsi võti, rentnik, töökoormus, keskkond ja mudelipäring.
2. Lõppkasutaja lahendamine: nõuavad delegeeritud konnektorite jaoks stabiilset lõppkasutaja ID-d. Keelduge anonüümsed delegeeritud kõned, kui see pole selgesõnaliselt lubatud.
3. Konnektor lahendamine: vastendage serveri URL või hostitud konnektori ID registreeritud konnektoriressursiga.
4. Kinnitage luba: kontrollige väljaandjat, vaatajaskonda, kui see on kohaldatav, aegumist, teemat, rentniku sidumist, tühistamise olekut ja nõutavaid ulatusi.
5. Toimingu liigitamine: kaarditööriista nimi ja metaandmed lugemiseks, kirjutamiseks, saatmiseks, kustutamiseks, eksportimiseks, finants-, administraatori- või tundmatuteks.
6. Kontrollige säilituspiiri: määrake, kas töökoormus võimaldab kolmanda osapoole MCP serveri töötlemist ja logimist.
7. Rakenda kinnituseeskirju: luba automaatselt, nõua kasutaja kinnitust, nõua administraatori kinnitust, blokeeri või karantiini.
8. Reserveelarve, kui arveldatav: kui konnektori täitmisel on otsesed või kaudsed tasud, reserveerige eelarve enne saatmist.
9. Kirjutage otsus: jätkake otsust enne konnektori kutsumist, mitte ainult pärast õnnestumist.

Kõigepealt on oluline otsuse kirjutamine. Kui konnektor aegub, voogesitab osalise väljundi või käivitab allavoolu tõrke, peaks auditilogi siiski näitama, et lüüs lubas või keelas konkreetse toimingukatse.

Kinnitamine peaks olema töövoo suhtes teadlik

Kõnepõhine kinnitus on lihtsalt põhjendatav ja sageli praktikas kasutuskõlbmatu. Klienditoe agent, kes peab piletit lugema, Drive'i otsima, meili koostama ja CRM-i kirjet värskendama, ei tohiks sundida kasutajat iga kahjutu lugemistoimingu jaoks modaali valima. Samal ajal ei tohiks meili saatmist, faili kustutamist, makse tagasimaksmist või kausta eksportimist vaikselt delegeerida, kuna mudel valis tööriista.

Töötav poliitika on mitmekihiline:

• Luba automaatselt ülevaadatud kirjutuskaitstud tööriistad madala riskitasemega üürnikele ja värske kasutaja autoriseerimine.
• Nõua kinnitust saatmiseks, loomiseks, värskendamiseks, kustutamiseks, eksportimiseks, finants- ja administraatoritoiminguteks.
• Rühmitatud kinnituste lubamine nimega töövoo, ulatuse ja ajaakna jaoks.
• Nõuge uuesti heakskiitu, kui ulatused laienevad, tööriista definitsioonid oluliselt muutuvad või konnektor liigub kõrgemasse riskiklassi.
• Blokeerige tundmatud tööriistad kuni ülevaatamiseni.

Grupeeritud kinnitused peavad olema selgesõnalised. Kasutaja võib nõustuda järgmise 30 minuti jooksul: "Lubage sellel toe töövool Drive'ist ja vastuste mustanditest otsida, kuid enne saatmist on vaja kinnitust." See on kasulikum kui kahendliidese lubamise/keelamise lüliti.

Säilitamise piirid vajavad oma välja

Kaugkõned MCP võivad andmeid teisaldada väljapoole mudelipakkuja säilitamis- ja töötlemispiire. See ei ole automaatselt vale, kuid see peab olema nähtav. Töökoormus, millel on lubatud kasutada mudeli lõpp-punkti ühe andmete säilitamise sätte alusel, võib siiski olla keelatud sama sisu saatmine kolmanda osapoole MCP serverisse erinevate säilitamistingimustega.

Lisage nii töökoormustele kui ka konnektoritele säilitusklassifikatsiooni. Näidisklassid:

• internal_only: kolmanda osapoole konnektorikõned pole lubatud.
• approved_processors_only: konnektor peab olema kinnitatud hankijate loendis.
• third_party_standard_allowed: standardne SaaS-konnektori töötlemine on lubatud.
• no_argument_logging: konnektorikutsed on lubatud, kuid argumendid tuleb redigeerida või räsistada.
• export_blocked: lugemine/otsing lubatud, hulgieksport keelatud.

See on koht, kus lüüs kaitseb meeskondi peente vigade eest: eeldades, et mudelipakkuja andmete juhtelemendid rakenduvad automaatselt igale agendi kasutatavale tööriistale. Need ei pruugi kehtida, kui andmed saadetakse MCP kaugserverisse või välisteenuse konnektorisse.

Koostage konnektori auditi pearaamat

Konnektori auditi pearaamat peaks ühendama mudelitaotlused, lüüsi autoriseerimise, konnektori väljasaatmise ja allavoolu tulemused. Ärge toetuge ainult pakkuja töötlemata jälgedele, sest iga pakkuja võib tööriista sündmused erinevalt paljastada ja rakenduste logid võivad märki või kinnituse konteksti välja jätta.

Soovitatavad pearaamatu väljad hõlmavad järgmist:

• model_request_id ja jälje ID.
• tenant_id, gateway_key_id, töökoormus, keskkond ja lõppkasutaja ID.
• connector_id, serveri URL-i räsi, hostitud konnektori identifikaator ja riskiklass.
• tool_name, tööriista versioon või metaandmete sõrmejälg ja normaliseeritud toiminguklass.
• OAuth väljaandja, märgi teema, ulatuse komplekti räsi, aegumissalv ja märgi päritolu.
• Argumentide räsi, redigeeritud argumendid, tundlikkusklass ja säilitusklass.
• Kinnitusotsus, kinnitaja, kinnituse ulatus ja kinnituse aegumine.
• Saadavale saatmise olek, vastuse olek, veaklass, latentsusaeg ja päringu ID-d allavoolu.

Täielik argumentide logimine võib aidata intsidentidele reageerida, kuid suurendab ka privaatsust ja säilitamise ohtu. Eelistage vaikimisi struktureeritud välju, räsimist, valikulist redigeerimist ja tundlikkuse silte. Lubage täielik jäädvustamine ainult otsese vahejuhtumi või aegumisega silumisreeglite korral.

Tühistamine ja karantiin on tootenõuded

Tühistamine ei saa olla andmebaasi käsitsi muutmine. Kasutajad ja administraatorid vajavad töövooge, mis muutuvad koheseks poliitikaolekuks.

Rakendage vähemalt järgmised toimingud:

• Kasutaja ühenduse katkestamine: tühistage või märkige passiivseks kõik ühe kasutaja konnektori autoriseerimise märgid.
• Renniku keelamine: blokeerige kogu rentniku jaoks üks konnektor, ilma et see keelaks sõltumatu mudeliliikluse.
• Tokeni aegumise käsitlemine: nurjumine sulgemine või uuesti volitamine, kui värskendamine ebaõnnestub või volituse värskus ületab eeskirju.
• Konnektori karantiini: blokeerige konnektor, säilitades samal ajal selle konfiguratsiooni ja logid uurimiseks.
• Hädaolukorra keelamise loend: blokeerimine serveri URL-i räsi, konnektori ID, väljaandja või tööriista sõrmejälje järgi.
• Ulatusala alandamine: autoriseerige uuesti vähemate ulatustega, kui töövoog ei vaja enam laia juurdepääsu.

Oluline rakendamise üksikasi on see, et tühistamise olekut tuleb kontrollida lähetamise ajal. Öine sünkroonimine on sobitamiseks kasulik, kuid sellest ei piisa intsidentidele reageerimiseks.

Kaugjuhtimispuldi vastavussondid MCP pistikud

Enne kui konnektor on tootmisrentnikele saadaval, testige seda kui reguleeritud sõltuvust. Lühike uurimiskomplekt tabab palju integratsiooni- ja poliitikatõrkeid.

• Metaandmete avastamine tagastab stabiilse serveri identiteedi ja eeldatava tööriista definitsiooni.
• Kaitstud ressursi metaandmed ja autoriseerimiskäitumine vastavad vajadusel dokumenteeritud eeldustele.
• Dünaamilise kliendi registreerimisnõuded on arusaadavad, toetatud või selgesõnaliselt keelatud.
• Tokeniteta taotlused ebaõnnestuvad turvaliselt.
• Aegunud märgid ebaõnnestuvad etteaimatavalt ega käivita kontrollimatuid korduskatseid.
• Lugemise/kirjutamise klassifikatsioon vastab täheldatud käitumisele, mitte ainult kirjeldustele.
• Tööriista valesti vormindatud metaandmed lükatakse tagasi või märgitakse tundmatuks.
• Tööriistaloendi muudatused käivitavad nimede, ulatuste, kirjelduste või riskiklasside muutumisel ülevaatuse.
• Konnektori vead logitakse ilma tundlikke argumente üldistele veaväljadele lekkimata.

Need sondid ei asenda turvaülevaatust, kuid annavad lüüsile korratava viisi triivi tuvastamiseks. Kaugserverid MCP võivad muutuda sõltumata mudeli pakkujast ja teie rakenduse väljalasketsüklist.

Rakendamise kontroll-loend

• Looge rentniku, serveri, volituse, ulatuse, tööriista, riski, säilitamise ja tühistamise väljadega konnektoriregister.
• Igas poliitikaotsuses eraldi lüüsivõtme identiteet, delegeeritud lõppkasutaja identiteet ja konnektori identiteet.
• Salvestage konnektori žetoonid mandaadihoidlas, kuid hoidke neid mudelipakkuja käitusaja mandaatidest eristatuna.
• Eelistage kasutaja-andmete konnektorite jaoks kasutaja kohta OAuth; piirata jagatud teenuse tunnuseid selgesõnaliste teenusekonto töövoogudega.
• Tööriistatoimingute normaliseerimine lugemiseks, kirjutamiseks, saatmiseks, kustutamiseks, eksportimiseks, finantseerimiseks, administreerimiseks ja tundmatuks.
• Käitage saatmiseelseid kontrolle konnektori registreerimise, loa kehtivuse, ulatuse vastavuse, säilitamise ühilduvuse, kinnitusoleku ja eelarvereserveerimise kohta.
• Logi konnektori otsused enne saatmist ja määrake lõplik olek pärast vastust või viga.
• Kasutajate ühenduse katkestamise, rentniku keelamise, konnektori karantiini ja hädaolukorra keelamise töövoogude loomine.
• Enne tootmiskasutust uurige konnektori metaandmeid, märgi käitumist, tööriista triivi ja valesti vormindatud metaandmeid.

Aktiivjäreldus

MCP ja teeninduskonnektorid muudavad agendid kasulikuks, kuna võimaldavad mudelitel reaalsetes süsteemides toimida. Sama kasulikkus muudab konnektori autoriseerimise juhtimistasandi probleemiks, mitte kiireks inseneridetailideks.

Lüüs peaks teadma rohkem kui mudel, lubade arv ja võti API. See peaks teadma, millist konnektorit kutsuti, milline kasutaja selle autoriseeris, millised ulatused anti, millist tööriista tegevusklassi taotleti, kas kinnitus oli vajalik, kas säilituspiir oli ühilduv ja kuidas juurdepääsu saab tühistada. Alustage konnektoriregistrist, saatmiseelsest poliitikakontrollist ja ühendatud auditi pearaamatust. Seejärel lisage konnektori kasutuse kasvades OAuth vahendustegevus, rühmitatud kinnitused, vastavusproovid ja hädaolukorra karantiini.

Eesmärk ei ole blokeerida MCP kaugkasutamist. Eesmärk on muuta konnektorijuurdepääs omistatavaks, tühistatavaks, ülevaatavaks ja ühilduvaks samade juhtimisootustega, mida meeskonnad juba rakendavad mudelijuurdepääsule ja OpenAI-ühilduvale API lüüsile.

Seotud lugemine

• haldustööriist mustrid