CAPMAS, EPFL आणि Swisscom यांचा एक संयुक्त प्रयत्न आहे, जो डेव्हलपर्सना macaroons द्वारे AI child agents ला मर्यादित व्याप्तीचे (narrowly scoped) परवानग्या देण्यास सक्षम करतो. हे token-handling latency ३० पटीने कमी करते आणि पूर्ण-वापरकर्ता (full-user) JWTs एजंट्सच्या आवाक्याबाहेर ठेवते.

हा बदल का महत्त्वाचा आहे

जेव्हा एखादे LLM डाउनस्ट्रीम टूल्सचे ऑर्केस्ट्रेशन करते, तेव्हा टीम्स अनेकदा तयार झालेल्या "child" एजंटला तोच JWT देतात ज्याने वापरकर्त्याने लॉग इन केले आहे. JWT हा एक स्वाक्षरी केलेला (signed) डेटा ब्लॉक आहे ज्यामध्ये वापरकर्त्याकडे असलेल्या प्रत्येक परवानगीची यादी असते—जसे की HR डेटा, प्रोजेक्ट फाइल्स, ॲडमिन अधिकार इत्यादी. जर मॉडेलने एखादी विनाशकारी कमांड 'हॅल्युसिनेट' (hallucinate) केली, तर child agent ती वापरकर्त्याच्या पूर्ण अधिकारांसह कार्यान्वित करू शकतो. एका चुकीमुळे संपूर्ण संस्थेचा डेटा उघड होऊ शकतो.

सध्याच्या पर्यायातील त्रुटी

RFC 8693 token-exchange flow वापरून मागणीनुसार मर्यादित टोकन तयार केल्यामुळे IAM सिस्टममध्ये अनेक राऊंड-ट्रिप्स (round-trips) वाढतात, नेटवर्क ट्रॅफिक वाढते आणि लक्षणीय विलंब (latency) निर्माण होतो. जे टीम्स अनेक अल्पायुषी (short-lived) एजंट्स तयार करतात, त्यांना हा अतिरिक्त भार (overhead) अत्यंत त्रासदायक वाटू लागतो.

CAPMAS कसे कार्य करते

CAPMAS परवानगी देण्याच्या प्रक्रियेचे दोन टप्प्यांत विभाजन करते:

  1. IAM-side encoding – IAM सर्व्हिस एक एन्कोडर चालवते जो नैसर्गिक भाषेतील विनंतीचे (उदा. "finance फोल्डरमधील फाइल्सची यादी करा") संबंधित विशेषाधिकारांच्या (privileges) संचात रूपांतर करतो.
  2. Macaroon creation – ते विशेषाधिकार macaroon मधील caveats बनतात. macaroon हे एक लवचिक टोकन फॉरमॅट आहे जे डाउनस्ट्रीम एजंट्सना अधिक निर्बंध घालू देते, परंतु अस्तित्वात असलेले निर्बंध कधीही काढून टाकू देत नाही.

जेव्हा एखादा एजंट macaroon प्राप्त करतो, तेव्हा तो व्याप्ती अधिक मर्यादित करू शकतो—उदा. फाईल-लिस्ट विनंती एखाद्या सब-डायरेक्टरीपुरती मर्यादित करणे—परंतु तो ती वाढवू शकत नाही. प्रत्येक टप्प्यावर (hop), IAM सर्व्हिस सर्व caveats च्या छेदनबिंदूची (intersection) पडताळणी करते, ज्यामुळे कोणताही एजंट मूळ परवानगीपेक्षा जास्त अधिकार वापरणार नाही याची खात्री मिळते.

स्वतःहून बोलणारे कामगिरीचे आकडे

  • Speed – CAPMAS २० ms पेक्षा कमी वेळात परवानगी विनंतीवर प्रक्रिया करते, जी RFC 8693 एक्सचेंजपेक्षा अंदाजे ३० पट वेगवान आहे.
  • Accuracy – टूल्सच्या मोठ्या कॅटलॉगसह केलेल्या बेंचमार्कमध्ये, एका मानक LLM ने आवश्यक असलेल्या विशेषाधिकारांपैकी ५३% चुकवले. CAPMAS ने केवळ २.१% मिस रेटसह ९०.९% अचूकता गाठली.
  • Bandwidth – macaroon मध्ये केवळ अंतिम caveats चा संच असल्याने, विनिमय केलेला डेटा पूर्ण token-exchange flow मध्ये आवश्यक असलेल्या डेटाच्या तुलनेत अत्यंत कमी असतो.

एक व्यावहारिक अवलंब कार्यप्रवाह

  1. Pre-filter the request – कोणत्याही ऑर्केस्ट्रेटरने टूल कॅटलॉगला स्पर्श करण्यापूर्वी वापरकर्त्याच्या नैसर्गिक भाषेतील हेतूचे (intent) top-k allowlist मध्ये रूपांतर करा.
  2. Seal the allowlist – त्या allowlist ला macaroon मध्ये एन्कोड करा, ज्यामुळे child agent ती वाढवू शकणार नाही.
  3. Verify at the service – विनंती मान्य करण्यापूर्वी, लक्ष्यित (target) सर्व्हिसला सर्व caveats चा छेदनबिंदू (intersection) मोजण्यासाठी IAM ला सांगू द्या.

हे टप्पे "child ला संपूर्ण घराची किल्ली देणे" या पद्धतीऐवजी "एकदाच वापरण्यायोग्य, मर्यादित व्याप्तीची किल्ली देणे" या मॉडेलचा वापर करतात.

CAPMAS काय सुधारत नाही

हे फ्रेमवर्क prompt-injection हल्ले रोखत नाही, जिथे अटॅकर घातक कमांड्स इंजेक्ट करण्यासाठी LLM च्या प्रॉम्प्टमध्ये फेरफार करतो. याचे संरक्षण 'honest-but-curious' एजंट्स आणि अविश्वसनीय LLMs साठी आहे, जे अन्यथा पूर्ण JWT वर आधारित कृती करू शकतात. प्रॉम्प्ट-आधारित धोके हाताळण्यासाठी टीम्सना अजूनही स्वतंत्र संरक्षणाची—जसे की input sanitisation, sandboxing किंवा model-level guardrails—गरज आहे.

कोणाला फायदा होईल

  • Enterprise developers जे अंतर्गत APIs कॉल करणारे AI-driven असिस्टंट्स तयार करत आहेत.
  • Security teams ज्यांना बाधित (compromised) मॉडेलचा 'ब्लास्ट रेडियस' (blast radius) कमी करायचा आहे.
  • Product owners ज्यांना उच्च-वारंवारता (high-frequency) एजंट स्पॉनिंगसाठी जलद आणि विश्वसनीय परवानगी तपासणीची गरज आहे.

पुढे काय

CAPMAS ही एक प्रस्तावित डिझाइन आहे.

Takeaway: पूर्ण-वापरकर्ता JWTs च्या जागी मर्यादित व्याप्तीचे macaroons वापरल्यामुळे डेव्हलपर्सना पारंपारिक token-exchange flows चा विलंब (latency) सोसल्याशिवाय AI एजंट्सना मर्यादेत ठेवण्याचा मार्ग मिळतो. प्रॉम्प्ट-इंजेक्शन संरक्षणाची सतत गरज असणे ही यातील तडजोड (trade-off) आहे.