Uthibitishaji (Authentication) huangalia wewe ni nani; uidhinishaji (authorization) huamua kile unachoweza kufanya. Idadi inayoongezeka ya programu zinazoendeshwa na AI huthibitisha utambulisho wa mtumiaji mara moja wakati wa kuingia (login) na kisha kuruhusu wakala (agent) huyo kufanya kazi kwenye rasilimali yoyote kwa kipindi chote cha kikao, jambo ambalo kwa uhalisia ni kama kumpa "hundi isiyo na kikomo." Muundo huo unafungua mlango wa kuvuja kwa data kwa bahati mbaya, barua pepe zisizohitajika, au hata mabadiliko ya uharibifu kwenye kanzidata (database), na hatari hiyo huongezeka kila wakati msaidizi wa AI anapoweza kuitumia zana nyingi kwa kasi ya milisekunde.

Kwa nini kosa hili linaendelea kutokea

Watengenezaji wengi wa AI huchukulia skrini ya kuingia kama lango pekee la usalama. Kodo huomba nywila (password) au tokeni, huainisha kikao kama "iliyothibitishwa," na kisha hudhani kuwa ombi lolote linalofuata ni salama. Katika programu ya wavuti ya kawaida, mbofyo wa polepole wa mtumiaji binadamu hutoa pointi ya asili ya kudhibiti kasi; binadamu atasita kabla ya kubofya "futa" (delete). Hata hivyo, wakala wa AI anaweza kutuma mfululizo wa wito wa zana (tool calls) makumi ndani ya sekunde chache. Ikiwa jukwaa litauliza tu "Je, mtumiaji ameingia?" kila wito utapokea ruhusa ile ile isiyo na vikwazo.

Chanzo kikuu ni urahisi. Timu mara nyingi hutengeneza akaunti moja ya huduma (service account) yenye muda mrefu kwa ajili ya programu nzima ili kodi isihitaji kusimamia tokeni au scope nyingi. Akaunti hiyo kwa kawaida huwa na ruhusa pana—kusoma, kuandika, kufuta—kwenye miradi yote. Wakati msaidizi wa AI anapofanya kazi ndani ya kikao hicho, anapokea ruhusa hizo moja kwa moja, bila kujali ikiwa kazi ya sasa inazihitaji kweli.

Hatari iliyopo

  • Kuvuja kwa data – Wakala anayeweza kusoma faili yoyote baada ya mtumiaji kuingia anaweza kwa bahati mbaya kuvuta nyaraka za siri kwenye jibu ambalo baadaye linaweza kushirikiwa nje ya shirika.
  • Vitendo visivyokusudiwa – Msaidizi wa AI wa mhandisi wa usaidizi anaweza kutekeleza dodoso la SQL dhidi ya kanzidata za uzalishaji (production databases) kwa sababu tu kikao cha mhandisi bado kiko hai, hata kama dodoso hilo halihusiani na tiketi inayoshughulikiwa.
  • Uzingatiaji wa kanuni – Sheria nyingi za ulinzi wa data zinahitaji ufikiaji uwe mdogo kadiri inavyohitajika. Mfumo wa ruhusa wa jumla unaweza kukiuka kanuni hizo na kusababisha ukaguzi au faini.
  • Gharama za uendeshaji – Makosa yanayofuta au kubadilisha rekodi huwalazimu timu kurudisha nyuma mabadiliko, kuchunguza vyanzo, na kujenga upya imani na watumiaji—vitu vyote ambavyo vinapoteza muda na pesa.

Hatua inayokosekana: uidhinishaji wa kila tendo

Uidhinishaji unapaswa kutathminiwa kwenye kila "mlango" ndani ya mfumo, si tu kwenye lango kuu. Swali linabadilika kutoka "Huyu ni nani?" kwenda "Je, tendo hili mahususi kwenye rasilimali hii mahususi linaweza kufanyika sasa hivi?" Kuanzisha ukaguzi huo hakuhitaji usanidi mpya kabisa; unahitaji tu mabadiliko kutoka kwenye alama moja ya kikao kwenda kwenye tokeni fupi zenye mipaka maalum (scoped tokens).

Jinsi inavyofanya kazi kwa vitendo

  1. Omba tokeni yenye scope iliyofafanuliwa – Wakala wa AI anapohitaji kuitumia zana, kwanza hupata tokeni inayoorodhesha ruhusa kamili zinazohitajika (k.m., read:ticket, execute:sql_query).
  2. Thibitisha tokeni kwa kila wito – Kabla ya zana inapoanza kufanya kazi, huduma hukagua ikiwa tokeni inajumuisha scope inayohitajika na ikiwa tokeni haijaisha muda wake.
  3. Linganisha rasilimali na scope – Ikiwa ombi linakusudia mradi au kanzidata fulani, tokeni lazima iruhusu waziwazi ufikiaji wa utambulisho huo.
  4. Kataa au ruhusu – Ikiwa ukaguzi wowote utafeli, wito unakataliwa na wakala anapokea kosa ambalo anaweza kumjulisha mtumiaji.

Tofauti ya kodi ni rahisi. Njia "mbaya" inaweza kuonekana kama:

if session.is_authenticated():
    tool.run(params)

Njia "nzuri" inaongeza ukaguzi:

token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
    tool.run(params)
else:
    raise PermissionError

Mtindo wa pili unaongeza mistari michache lakini unalazimisha mfumo kuuliza swali sahihi kwa kila operesheni.

Viwango vinavyorahisisha kazi

Scope za OAuth 2.0 tayari zinatoa njia inayotumika sana kuzuia kile tokeni inachoweza kufanya. Kwa kutoa tokeni za ufikiaji za muda mfupi ambazo zinajumuisha scope kama project:1234:write au email:send, watengenezaji wanaweza kutegemea maktaba zilizopo kufanya hatua ya uhakiki.

Rich Authorization Requests (RFC 9396) mpya zaidi zinaongeza wazo hili, zikiiruhusu mteja kuomba ruhusa za kina wakati wa utendaji (runtime) badala ya kufafanua orodha tuli mapema. Urahisi huo ni muhimu wakati mtiririko wa kazi wa AI unaweza kuhitaji kuongeza au kuondoa uwezo papo hapo kulingana na nia ya mtumiaji.

Hoja ya upande wa pili: urahisi dhidi ya usalama

Baadhi ya timu hudai kuwa ukaguzi wa kila tendo huongeza ucheleweshaji (latency) na utata wa kodi, hasa wakati msaidizi wa AI anapaswa kuitia kazi zana nyingi kwa mfuatano wa haraka. Wanabainisha kuwa tokeni moja ya kikao (session token) huepusha mzigo wa kupata na kuthibitisha tokeni mpya kwa kila wito. Hata hivyo, upande wa pili wa mabadiliko hayo ni kuongezeka kwa hatari kubwa ya matumizi mabaya. Huduma za kisasa za uthibitishaji wa tokeni zimeundwa kufanya kazi ndani ya mikrosekunde, na safari ya ziada ya mtandao (network round-trip) inaweza kuunganishwa (batched) au kuhifadhiwa (cached) bila kusaliti kanuni ya upendeleo mdogo zaidi (principle of least privilege). Katika mazingira ambapo uadilifu wa data na uzingatiaji wa sheria (compliance) ni jambo lisiloweza kujadiliwa, gharama ndogo ya utendaji inazidiwa na upungufu wa hatari.

Nini cha kufuatilia baadaye

  • Utekelezaji wa tokeni zenye upeo maalum (scoped tokens) katika AI SDKs – Fuatilia maboresho ya vifaa vya majukwaa makubwa ya AI; mengi yanaanza kutoa kazi saidizi (helper functions) kwa ajili ya upeo unaozingatia OAuth.
  • Mifumo ya sera-kama-kodi (Policy-as-code frameworks) – Suluhisho zinazoibuka huruhusu timu kutangaza sheria za idhini katika faili la kueleza (declarative file), na kuzisimamia kiotomatiki wakati wa utendaji (runtime).
  • Logi za ukaguzi (Audit logs) zinazoonyesha maamuzi ya kila tendo – Kadiri majukwaa mengi yanavyorekodi kila ukaguzi wa idhini, mashirika yatapata uwezo wa kuona ni vitendo gani vya AI vinavyoruhusiwa au kuzuiwa, jambo litakalosaidia marekebisho ya sera hapo baadaye.

Hitimisho

Kuchukulia kikao kilichoingia (logged-in session) kama ruhusa ya kufanya lolote ni njia ya kusababisha matokeo yasiyotarajiwa. Kwa kuhamisha uamuzi wa idhini kutoka wakati wa kuingia hadi kwenye kila wito wa zana—na kwa kutumia tokeni zenye upeo maalum na zinazodumu kwa muda mfupi—programu za AI zinaweza kudumisha urahisi wa mawakala huru (autonomous agents) huku zikilinda data, zikizingatia kanuni, na kuepuka majanga ya gharama kubwa. Mistari ya ziada ya kodi ni gharama ndogo kwa mfumo unaouliza swali sahihi kila wakati tendo linapojaribiwa.