CAPMAS, EPFL અને Swisscomનો એક સંયુક્ત પ્રયાસ છે, જે ડેવલપર્સને macaroons દ્વારા AI child agents ને મર્યાદિત વ્યાપ્તિ (narrowly scoped) ધરાવતી પરવાનગીઓ આપવા દે છે. તે token-handling latency ને 30 ગણો ઘટાડે છે અને full-user JWTs ને એજન્ટ્સની પહોંચથી દૂર રાખે છે.

આ ફેરફાર શા માટે મહત્વપૂર્ણ છે

જ્યારે એક LLM downstream tools ને સંચાલિત (orchestrate) કરે છે, ત્યારે ટીમો ઘણીવાર પેદા થયેલા "child" એજન્ટને તે જ JWT આપે છે જેનાથી યુઝરે લોગિન કર્યું હોય. JWT એ એક signed blob છે જે યુઝર પાસે રહેલી દરેક પરવાનગીની યાદી આપે છે—જેમ કે HR ડેટા, પ્રોજેક્ટ ફાઇલો, એડમિન અધિકારો વગેરે. જો મોડેલ કોઈ વિનાશક કમાન્ડનું hallucinate કરે, તો child એજન્ટ યુઝરના સંપૂર્ણ અધિકાર સાથે તેને અમલમાં મૂકી શકે છે. એક ભૂલ આખી સંસ્થાનો ડેટા ખુલ્લો પાડી શકે છે.

વર્તમાન ઉપાયોની ખામીઓ

RFC 8693 token-exchange flow સાથે માંગણી મુજબ સાંકડો (narrow) token બનાવવાથી IAM સિસ્ટમમાં અનેક round-trips ઉમેરાય છે, નેટવર્ક ટ્રાફિક વધે છે અને નોંધપાત્ર latency આવે છે. જે ટીમો ઘણા બધા ટૂંકા ગાળાના એજન્ટ્સ બનાવે છે, તેઓને આ overhead ખૂબ જ નુકસાનકારક લાગે છે.

CAPMAS કેવી રીતે કામ કરે છે

CAPMAS પરવાનગી આપવાની પ્રક્રિયાને બે તબક્કામાં વિભાજિત કરે છે:

  1. IAM-side encoding – IAM સર્વિસ એક encoder ચલાવે છે જે કુદરતી ભાષાની વિનંતી (દા.ત., “list files in the finance folder”) ને મેળ ખાતા અધિકારોના સેટમાં રૂપાંતરિત કરે છે.
  2. Macaroon creation – તે અધિકારો macaroon ની અંદર caveats બની જાય છે, જે એક લવચીક (flexible) token format છે જે downstream એજન્ટ્સને વધુ પ્રતિબંધો ઉમેરવા દે છે પરંતુ હાલના પ્રતિબંધોને ક્યારેય દૂર કરવા દેતું નથી.

જ્યારે એજન્ટને macaroon મળે છે, ત્યારે તે વ્યાપ્તિને વધુ મર્યાદિત કરી શકે છે—દાખલા તરીકે, file-list વિનંતીને સબ-ડાયરેક્ટરી સુધી મર્યાદિત કરવી—પરંતુ તે તેને વિસ્તારી શકતું નથી. દરેક સ્ટેપ (hop) પર IAM સર્વિસ તમામ caveats ના છેદન (intersection) ને ચકાસે છે, જે ખાતરી આપે છે કે કોઈ પણ એજન્ટ મૂળ મંજૂરી કરતા વધી ન જાય.

પ્રદર્શનના આંકડા જે જાતે જ બોલે છે

  • Speed – CAPMAS પરવાનગી વિનંતીને 20 ms થી ઓછા સમયમાં પ્રોસેસ કરે છે, જે RFC 8693 exchange કરતા અંદાજે 30 ગણું ઝડપી છે.
  • Accuracy – સાધનોના મોટા કેટલોગ સાથેના બેન્ચમાર્ક માં, એક સ્ટાન્ડર્ડ LLM એ તેને જરૂરી 53% અધિકારો ચૂકી ગયા હતા. CAPMAS એ માત્ર 2.1% miss rate સાથે 90.9% ચોકસાઈ હાંસલ કરી.
  • Bandwidth – કારણ કે macaroon માં માત્ર અંતિમ caveats નો સેટ હોય છે, તેથી વિનિમય કરવામાં આવતો ડેટા સંપૂર્ણ token-exchange flow ની જરૂરિયાત કરતા ઘણો ઓછો હોય છે.

વ્યવહારુ અમલીકરણ વર્કફ્લો

  1. Pre-filter the request – કોઈપણ orchestrator ટૂલ કેટલોગને સ્પર્શ કરે તે પહેલાં યુઝરના કુદરતી ભાષાના ઈરાદાને top-k allowlist માં રૂપાંતરિત કરો.
  2. Seal the allowlist – તે allowlist ને macaroon માં એન્કોડ કરો જેને child એજન્ટ વિસ્તારી શકતું નથી.
  3. Verify at the service – વિનંતી સ્વીકારતા પહેલા લક્ષ્ય સેવા (target service) ને તમામ caveats ના છેદન (intersection) ની ગણતરી કરવા માટે IAM ને કહેવા દો.

આ પગલાં "બાળકને આખા ઘરની ચાવી આપો" પેટર્નને બદલે "એકવાર ઉપયોગ માટેની, મર્યાદિત-વ્યાપ્તિવાળી ચાવી આપો" મોડેલ સાથે બદલે છે.

CAPMAS શું ઠીક નથી કરતું

આ ફ્રેમવર્ક prompt-injection હુમલાઓને રોકતું નથી, જ્યાં હુમલાખોર LLM ના prompt માં ફેરફાર કરીને હાનિકારક કમાન્ડ ઇન્જેક્ટ કરે છે. તેનું રક્ષણ honest-but-curious એજન્ટ્સ અને અવિશ્વાસપાત્ર LLMs ને આવરી લે છે જે કદાચ અન્યથા સંપૂર્ણ JWT પર કામ કરી શકે છે. prompt-આધારિત જોખમોને પહોંચી વળવા માટે ટીમોને હજુ પણ અલગ સુરક્ષાની જરૂર છે—જેમ કે input sanitisation, sandboxing, અથવા model-level guardrails.

કોને ફાયદો થશે

  • Enterprise developers જે AI-driven assistants બનાવી રહ્યા છે જે આંતરિક APIs નો ઉપયોગ કરે છે.
  • Security teams જે કમ્પ્રમાઇઝ્ડ (compromised) મોડેલના blast radius ને ઘટાડવા માંગે છે.
  • Product owners જેમને ઉચ્ચ-આવૃત્તિ (high-frequency) એજન્ટ સ્પૉનિંગ માટે ઝડપી, વિશ્વસનીય પરવાનગી તપાસની જરૂર છે.

આગળ શું છે

CAPMAS એ એક સૂચિત ડિઝાઇન છે.

Takeaway: સંપૂર્ણ-યુઝર JWTs ને બદલે મર્યાદિત-વ્યાપ્તિવાળા macaroons નો ઉપયોગ કરવાથી ડેવલપર્સને પરંપરાગત token-exchange flows ની latency પેનલ્ટી ચૂકવ્યા વિના AI એજન્ટ્સને પ્રમાણિક રાખવાનો માર્ગ મળે છે. આમાં prompt-injection સુરક્ષાની સતત જરૂરિયાત એ એક trade-off તરીકે રહે છે.