Mjue Wakala Wako: Jinsi ya Kufunga Binadamu kwa Wakala wa AI

Mambo muhimu ya kuzingatia

• Mjue Wakala Wako (KYA) hautatuliwi kwa kumtaja wakala. Udhibiti thabiti ni mnyororo wa ugawaji mamlaka unaounganisha mtu aliyethibitishwa, mteja aliyesajiliwa, mamlaka zilizopewa, muktadha wa shirika, na kila hatua inayotokana.
• Sehemu ya Didit ya Itifaki ya Muktadha wa Modeli (MCP) inatoa zana 115 katika maeneo 19 na inatumia Open Authorization (OAuth) 2.1 na Proof Key for Code Exchange (PKCE) na Usajili wa Mteja Dynamic.
• MCP hufanya kazi kama mtumiaji wa Didit aliyeingia. Inarithi jukumu la shirika la mtumiaji huyo, kwa hivyo wakala aliyeunganishwa hawezi kupata ruhusa ambazo mtu huyo hakuwa nazo tayari.
• Ufunguo wa programu ulihifadhiwa katika faili ya usanidi unathibitisha umiliki wa kitambulisho, si ni binadamu gani alikabidhi hatua fulani. Funguo zinazoshirikiwa huunganisha waendeshaji na mawakala wengi kuwa kitambulisho kimoja cha programu.
• Uwajibikaji unahitaji utekelezaji na ushahidi: tokeni zenye mipaka na ukaguzi wa majukumu kabla ya hatua, kisha rekodi za ukaguzi zinazoonyesha nani alibadilisha nini.

Didit tayari imetoa utaratibu huu. Seva yake ya MCP inaunganisha mteja wa AI na utambulisho na shughuli za udanganyifu kupitia mtumiaji aliyeingia, badala ya kumchukulia wakala kama mshikiliaji asiyejulikana wa siri ya programu. Sehemu hii haina malipo, inatumia HTTP ya Mtiririko isiyo na hali, na inatoa zana 115. Utekelezaji pia unapatikana katika hazina ya umma ya GitHub iliyo na leseni ya MIT.

Kifaa hicho kinabadilisha swali muhimu. Badala ya kuomba ufafanuzi mwingine wa KYA, uliza: wakati wakala anapounda kikao cha uthibitishaji, kusoma uamuzi, au kubadilisha data ya nafasi ya kazi, ni nini kinachothibitisha ni mtu gani aliyeidhinisha, ni nini mtu huyo aliruhusu, na ni shirika gani lilikubali hatua hiyo?

Kufungwa kwa binadamu ni mnyororo wa ugawaji mamlaka

Jina la wakala, kitambulisho cha mfumo, ufunguo wa umma, au uthibitisho wa programu unaweza kusaidia kutambua mwigizaji wa mashine. Hakuna hata moja kati ya hizo, peke yake, inayothibitisha nani anawajibika kwa kile wakala anachofanya. Kufungwa kwa binadamu kunahitaji mnyororo wenye viungo tofauti:

• Mkuu: mtumiaji aliyethibitishwa au mmiliki wa huduma ambaye wakala anafanya kazi kwa niaba yake.
• Mteja: programu ya AI iliyoombwa ufikiaji.
• Ugawaji mamlaka: mamlaka na ridhaa iliyotolewa kwa mteja huyo.
• Muktadha wa uidhinishaji: jukumu la shirika na mipaka ya programu iliyotumika kwa ombi.
• Ushahidi: rekodi inayoweza kukaguliwa ya hatua na matokeo yake.

Kila kiungo hujibu swali tofauti. Uthibitishaji unasema nani aliingia. OAuth inasema ni mteja gani alipokea ufikiaji uliokabidhiwa. Mamlaka zinasema ni aina gani za operesheni ziliidhinishwa. Majukumu yanasema mtumiaji anaweza kufanya nini ndani ya shirika. Rekodi za ukaguzi zinasema nini hasa kilitokea. Kuunganisha vidhibiti hivi katika beji moja ya “wakala aliyethibitishwa” huficha sehemu muhimu zaidi: mamlaka ni ya kimuktadha na inaweza kubatilishwa.

Wakala anayeaminika si tu anayeweza kutambulika. Lazima aweze kuonyesha njia isiyokatika kutoka kwa mkuu anayewajibika hadi hatua maalum, iliyoruhusiwa.

Kwa nini ufunguo katika faili ya usanidi unashindwa mtihani wa uwajibikaji

Ufunguo wa API wa programu unaweza kufaa kwa ushirikiano uliodhibitiwa wa seva-kwa-seva. Si, wenyewe, utaratibu wa kufunga binadamu-kwa-wakala. Ufunguo uliyonakiliwa kwa kawaida hujibu swali moja: “Je, mpigaji simu huyu ana kitambulisho kinachokubalika kwa programu hii?” Haujibu nani alianzisha wakala, nani aliidhinisha kazi ya sasa, au ikiwa simu mbili zinazotumia ufunguo huo zilitoka kwa watu tofauti.

Njia za kushindwa zinatabirika. Timu hushiriki ufunguo katika mazingira ya ndani. Mchakato wa wakala unarithi kutoka faili ya usanidi. Wakala wa pili anapokea nakala. Kumbukumbu kisha huhusisha kila simu na kitambulisho kimoja cha programu. Kubatilisha kitambulisho hicho hukatiza kila kazi inayokitumia, huku kukiacha tukio la ugawaji mamlaka lisiloeleweka.

Didit kwa makusudi haitoi njia ya ufunguo wa programu kwa sehemu yake ya MCP iliyopangishwa. Ushirikiano wa nyuma bado unaweza kutumia API za REST za Didit zenye vitambulisho vya programu, lakini ufikiaji wa MCP wa mbali unahitaji mtiririko wa OAuth wa mtumiaji. Utengano huo ni muhimu: kitambulisho cha REST kinawakilisha ushirikiano wa programu; tokeni ya MCP inawakilisha ufikiaji uliokabidhiwa kutoka kwa mtumiaji aliyeingia.

OAuth 2.1, PKCE, na Usajili wa Mteja Dynamic

OAuth ni msingi wa ugawaji mamlaka katika muundo huu. Mtiririko hautoi nenosiri la mtumiaji kwa wakala, na hauweki siri ya jukwaa inayoweza kutumika tena katika usanidi wa MCP. Badala yake, mteja wa AI anapata tokeni ya ufikiaji yenye mipaka baada ya mtumiaji kuthibitisha na Didit na kuidhinisha ufikiaji.

1. Sajili mteja

Usajili wa Mteja Dynamic huruhusu mteja wa MCP anayepatana kujisajili na seva ya uidhinishaji ya Didit bila kitambulisho cha mteja kilichotayarishwa awali kwa mikono. Hii inatoa seva ya uidhinishaji usajili tofauti wa mteja ambao inaweza kutoa ufikiaji. Usajili unatambua mteja wa OAuth; haithibitishi, wenyewe, kwamba programu ya mteja inaaminika.

2. Funga jibu la uidhinishaji kwa mteja

PKCE huunda kithibitishaji cha mara moja na changamoto kwa jaribio la uidhinishaji. Mteja anayeanza mtiririko lazima awasilishe kithibitishaji wakati akibadilishana msimbo wa uidhinishaji. Hii inapunguza thamani ya msimbo uliyonaswa kwa sababu mchakato mwingine hauwezi kuukomboa bila kithibitishaji.

3. Thibitisha na toa ridhaa

Mtumiaji anaingia kwenye Didit Business Console, ambayo hufanya kazi kama seva ya uidhinishaji, na kuidhinisha mamlaka zilizoombwa. Didit inatangaza didit:verification kwa shughuli za uthibitishaji na didit:management kwa usimamizi wa nafasi ya kazi. Mteja anapaswa kuomba mamlaka inayohitajika tu kwa kazi.

4. Thibitisha kila simu

Seva ya rasilimali ya MCP iliyopangishwa inathibitisha tokeni ya mbebaji kabla ya kutuma simu ya zana. Tokeni ya mtumiaji iliyothibitishwa na muktadha wa shirika husafiri na ombi kwa Didit. Huduma ya chini kisha inatathmini jukumu lililopo na ruhusa za mtumiaji huyo. Matokeo ni semantiki za kufanya kazi kama mtumiaji, sio kitambulisho kipya cha mtumiaji mkuu kilichoundwa kwa ajili ya wakala.

Mwongozo wa uthibitishaji wa MCP unaandika mtiririko, wakati muhtasari wa MCP unaeleza sehemu iliyopangishwa na mfumo wa mteja.

Kufanya kazi kama mtumiaji hufanya mamlaka iweze kusomeka

Tuseme opereta wa kufuata anaunganisha mteja wa AI kwa Didit. Mteja kwanza anaita didit_context_get, ambayo inarudisha mashirika na programu ambazo mtumiaji aliyeingia anaweza kufikia. Ikiwa mtumiaji ana shirika na programu moja isiyo na utata, muktadha unaweza kutatuliwa kiotomatiki. Ikiwa kadhaa zinapatikana, operesheni inaweza kupunguzwa kwa shirika na programu maalum.

Wakala anaweza kisha kupiga didit_session_create ili kuunda kikao cha uthibitishaji na didit_session_get_decision ili kupata matokeo yake. Hayo ni majina halisi ya zana za kwanza za kikoa katika orodha ya sasa ya MCP. Mtumiaji asiye na ruhusa inayohitajika hapati ruhusa hiyo kwa kuunganisha wakala; mipaka sawa ya uidhinishaji wa shirika bado inatumika.

Huu ndio tofauti kuu kutoka kwa kitambulisho cha programu kinachoshirikiwa. Katika mfumo wa OAuth, ombi linafika kama mtumiaji anayejulikana anayefanya kazi kupitia mteja aliyesajiliwa na mamlaka zilizotangazwa. Katika mfumo wa ufunguo ulioshirikiwa, mfumo wa chini unaona kitambulisho cha programu, wakati binadamu na wakala nyuma ya simu fulani hubaki bila kutofautishwa isipokuwa ndege tofauti ya udhibiti inasambaza muktadha huo.

Ukaguzi: kutoka “nani anaweza kutenda?” hadi “nani alifanya nini?”

Uidhinishaji huzuia hatua isiyo na mipaka. Ukaguzi unaelezea hatua baada ya kutokea. Didit inafichua didit_audit_log_list ili mtumiaji aliyeidhinishwa aweze kukagua viingilio vya ukaguzi wa programu vinavyoelezea nani alibadilisha nini. Kwa sababu kila ombi la MCP lililopangishwa hubeba tokeni ya mbebaji ya mtumiaji aliyeingia na muktadha wa shirika uliotatuliwa, hatua hiyo inahusishwa na mpigaji simu huyo badala ya mchakato wa wakala usiojulikana.

Rekodi kamili ya uchunguzi pia inapaswa kuhifadhi ushahidi upande wa wakala. Kwa mtiririko wa kazi wenye athari kubwa, rekodi kitambulisho cha wakala, usajili wa mteja, mamlaka iliyoombwa, shirika na programu lengwa, jina la zana, muhuri wa muda, hali ya idhini, na uwakilishi salama wa pembejeo na matokeo. Usihifadhi tokeni za ufikiaji au malipo nyeti ya utambulisho. Njia ya ukaguzi wa jukwaa na kumbukumbu ya utekelezaji wa wakala inapaswa kuwa na uhusiano bila kurudia siri au data binafsi iliyodhibitiwa.

Uhusiano si sawa na kutokana na kukana, na kumbukumbu ya ukaguzi si mbadala wa ruhusa ndogo zaidi. Vidhibiti vinaimarisha kila mmoja:

• Tumia ufikiaji wa muda mfupi na uonyeshaji upya uliodhibitiwa badala ya vitambulisho vya kudumu vilivyoshirikiwa.
• Toa mamlaka ndogo zaidi ya OAuth na jukumu la shirika lenye ruhusa ndogo zaidi.
• Hitaji uthibitisho wa binadamu kwa shughuli za uharibifu au zenye athari kubwa isiyo ya kawaida.
• Weka muktadha wa shirika na programu wazi wakati lengo zaidi ya moja linapatikana.
• Batilisha kikao cha mtumiaji au ruzuku ya mteja wakati ugawaji mamlaka unapaswa kuisha.
• Fuatilia rekodi za ukaguzi kwa waigizaji wasiotarajiwa, zana, malengo, au muda.

Kile ambacho kufungwa kunathibitisha—na kile ambacho hakithibitishi

Mfumo huu unathibitisha kuwa akaunti ya Didit iliyothibitishwa ilikabidhi ufikiaji wenye mipaka kwa mteja wa OAuth na kwamba kila ombi linatathminiwa na ruhusa za shirika la mtumiaji huyo. Huunda uwajibikaji wa vitendo kwa akaunti na mnyororo unaoweza kukaguliwa kwa hatua za jukwaa.

Hauthibitishi kiotomatiki kwamba mwenye akaunti ana utambulisho wa kiraia uliothibitishwa, kwamba programu ya mteja iliyoidhinishwa haijabadilishwa, au kwamba binadamu anaangalia kikamilifu kila hatua. Hayo yanahitaji uhakikisho wa ziada. Ikiwa uhakikisho wa utambulisho wa kisheria ni muhimu, thibitisha mkuu wakati wa kuingia na vidhibiti vya Mjue Mteja Wako (KYC) na funga matokeo hayo kwa akaunti. Ikiwa asili ya programu ni muhimu, ongeza uthibitisho wa mteja na matoleo yaliyosainiwa. Ikiwa uwepo ni muhimu, hitaji idhini ya hatua-juu wakati wa hatua nyeti.

Mtazamo huu wa tabaka huweka KYA kuwa waaminifu. Utambulisho wa wakala, utambulisho wa binadamu, uidhinishaji uliokabidhiwa, sera ya wakati wa utekelezaji, na ushahidi wa ukaguzi ni vidhibiti vinavyohusiana, sio lebo zinazoweza kubadilishana.

Utekelezaji uliotekelezwa unaoweza kukagua

Utekelezaji wa Didit unatoa rejea halisi kwa timu zinazounda mipaka sawa ya uwajibikaji. Seva iliyopangishwa inathibitisha kama mtumiaji wa Didit aliyeingia, inarithi jukumu la shirika la mtumiaji huyo, na inatumia utambulisho huo kwa kila simu ya zana. Zana zake 115 zilizopangishwa zinajumuisha maeneo 19, kutoka muktadha na vikao vya uthibitishaji hadi mtiririko wa kazi, mashirika, uchambuzi, na kumbukumbu za ukaguzi. Orodha ya sasa ya zana inaorodhesha uso halisi.

Kwa muktadha wa bidhaa, kifurushi kamili cha KYC kinagharimu $0.33 na huunganisha Uthibitishaji wa Vitambulisho, Liveness Passiv, Mechi ya Uso, na Uchambuzi wa IP. Didit inajumuisha ukaguzi 500 bila malipo kwa mwezi na inatumiwa na kampuni 2,000+ katika uzalishaji. Seva ya MCP yenyewe haina malipo, kwa hivyo timu zinaweza kutathmini mfumo wa ugawaji mamlaka na ruhusa bila kuongeza ada tofauti ya kiunganishi.

Ili kuona jinsi utaratibu huu unavyofaa katika mtiririko mpana wa kazi wa wakala, soma jinsi MCP ya utambulisho na udanganyifu inavyofanya kazi kwa mawakala wa AI na rejea ya zana ya Didit MCP.

Funga wakala kabla ya kuamini hatua

Tatizo gumu katika utambulisho wa wakala si kubuni jina thabiti la programu. Ni kuhifadhi uwajibikaji wa binadamu wakati programu inavuka violesura na kutenda kwa kasi ya mashine. OAuth 2.1 inatoa ufikiaji uliokabidhiwa. PKCE inalinda ubadilishanaji wa uidhinishaji. Usajili wa Mteja Dynamic unatambua mteja anayeunganisha. Mamlaka na majukumu ya shirika yanazuia mamlaka. Rekodi za ukaguzi hufanya matokeo yaweze kukaguliwa.

Unaweza kukagua usanifu katika hazina ya Didit MCP, kukagua nyaraka za uthibitishaji, au kuunganisha Didit kwa Claude. Mtihani muhimu ni rahisi: kwa hatua yoyote ya wakala iliyopendekezwa, unaweza kumtambua mtumiaji anayewajibika, mteja, mamlaka iliyotolewa, mipaka ya shirika, na ushahidi wa ukaguzi unaotokana? Ikiwa kiungo chochote kinakosekana, wakala hajafungwa kikamilifu.