CAPMAS, juhudi ya pamoja kutoka EPFL na Swisscom, inawawezesha watengenezaji kuwapa wakala wadogo wa AI (AI child agents) ruhusa zenye upeo finyu kupitia macaroons. Inapunguza ucheleweshaji (latency) wa kushughulikia token kwa mara 30 na kuweka JWT za mtumiaji kamili mbali na ufikiaji wa wakala hao.

Kwa nini mabadiliko haya ni muhimu

Wakati LLM inaparatibu zana za chini (downstream tools), timu mara nyingi humpa wakala "mtoto" aliyetengenezwa JWT ile ile ambayo mtumiaji alitumia kuingia. JWT ni kifurushi kilichotiwa saini (signed blob) kinachoorodhesha kila ruhusa ambayo mtumiaji anayo—data za HR, faili za miradi, haki za admin, na kadhalika. Ikiwa modeli itatengeneza amri ya uharibifu (hallucinate a destructive command), wakala mtoto anaweza kuitekeleza kwa mamlaka kamili ya mtumiaji. Kosa moja linaweza kuweka data za shirika zima hatarini.

Mapungufu ya njia ya sasa ya kutatua tatizo

Kutengeneza token yenye upeo finyu kwa mahitaji kwa kutumia mtiririko wa RFC 8693 token-exchange huongeza mizunguko kadhaa (round-trips) kwenye mfumo wa IAM, huongeza msongamano wa mtandao, na huleta ucheleweshaji unaoonekana. Timu zinazozalisha wakala wengi wenye muda mfupi hukuta mzigo huo unazuia utendaji.

Jinsi CAPMAS inavyofanya kazi

CAPMAS inagawanya utoaji wa ruhusa katika hatua mbili:

  1. IAM-side encoding – Huduma ya IAM huendesha kiongezi (encoder) ambacho hutafsiri ombi la lugha ya asili (kwa mfano, “orodhesha faili katika folda ya fedha”) kuwa seti ya upendeleo unaoendana.
  2. Macaroon creation – Upendeleo huo unakuwa caveats ndani ya macaroon, mfumo wa token unaobadilika unaowaruhusu wakala wa chini kuongeza vizuizi zaidi lakini kamwe kuondoa vilivyopo.

Wakala anapopokea macaroon, anaweza kufinya upeo—kwa mfano, kuwekea ukomo ombi la orodha ya faili kwenye kielelezo cha folda (sub-directory)—lakini hawezi kuupanua. Katika kila hatua, huduma ya IAM huhakiki muingiliano wa caveats zote, ikihakikisha kuwa hakuna wakala anayevuka ruhusa ya awali.

Takwimu za utendaji zinazojieleza

  • Speed – CAPMAS inashughulikia ombi la ruhusa ndani ya chini ya ms 20, takriban mara 30 zaidi ya haraka kuliko kubadilishana kwa RFC 8693.
  • Accuracy – Katika kipimo (benchmark) chenye orodha kubwa ya zana, LLM ya kawaida ilikosa 53 % ya upendeleo iliyohitaji. CAPMAS ilifikia usahihi wa 90.9 % ikiwa na kiwango cha kukosa cha 2.1 % pekee.
  • Bandwidth – Kwa sababu macaroon hubeba seti ya mwisho tu ya caveats, data inayobadilishana ni sehemu ndogo sana ya kile ambacho mtiririko kamili wa token-exchange ungehitaji.

Mtiririko wa utekelezaji wa kiutendaji

  1. Pre-filter the request – Badilisha nia ya lugha ya asili ya mtumiaji kuwa orodha ya kuruhusiwa (top-k allowlist) kabla ya anyaye mratibu (orchestrator) kugusa orodha ya zana.
  2. Seal the allowlist – Encode orodha hiyo ya kuruhusiwa kuwa macaroon ambayo wakala mtoto hawezi kuipanua.
  3. Verify at the service – Ruhusu huduma inayolengwa kuiomba IAM kupiga hesabu ya muingiliano wa caveats zote kabla ya kutekeleza ombi.

Hatua hizi zinachukua nafasi ya mfumo wa “mpe mtoto ufunguo mzima wa nyumba” na badala yake kutumia mfumo wa “mpe ufunguo wa matumizi mara moja, wenye upeo mdogo.”

Kile ambacho CAPMAS hakirekebishi

Mfumo huu hauzuia mashambulizi ya prompt-injection, ambapo mshambuliaji anabadilisha amri (prompt) ya LLM ili kuingiza amri zenye nia mbaya. Ulinzi wake unahusu wakala waaminifu lakini wenye udadisi (honest-but-curious agents) na LLM zisizoziamini ambazo zingeweza kutenda kwa kutumia JWT kamili. Timu bado zinahitaji ulinzi wa ziada—usafishaji wa ingizo (input sanitisation), sandboxing, au vizuizi vya kiwango cha modeli (model-level guardrails)—ili kukabiliana na vitisho vinavyotokana na prompt.

Nani anayefaidika

  • Enterprise developers wanaotengeneza wasaidizi wanaoendeshwa na AI wanaotumia API za ndani.
  • Security teams zinazotafuta kupunguza athari (blast radius) za modeli iliyoingiliwa.
  • Product owners wanaohitaji uhakiki wa ruhusa wa haraka na wa kuaminika kwa ajili ya uzalishaji wa wakala wenye mzunguko mkubwa.

Nini kinafuata

CAPMAS ni usanifu unaopendekezwa.

Muhtasari: Kubadilisha JWT za mtumiaji kamili na macaroons zenye upeo finyu kunawapa watengenezaji njia ya kuweka wakala wa AI waaminifu bila kulipia gharama ya ucheleweshaji wa mitiririko ya kawaida ya token-exchange. Changamoto inayobaki ni hitaji la kuendelea kuwa na ulinzi dhidi ya prompt-injection.