CAPMAS, EPFL और Swisscom का एक संयुक्त प्रयास है, जो डेवलपर्स को macaroons के माध्यम से AI child agents को सीमित दायरे वाली (narrowly scoped) अनुमतियाँ देने की सुविधा देता है। यह token-handling latency को 30 गुना कम कर देता है और full-user JWTs को agents की पहुँच से बाहर रखता है।

यह बदलाव क्यों महत्वपूर्ण है

जब एक LLM downstream tools को संचालित (orchestrate) करता है, तो टीमें अक्सर बनाए गए "child" agent को वही JWT सौंप देती हैं जिससे उपयोगकर्ता ने लॉग इन किया था। JWT एक signed blob है जो उपयोगकर्ता के पास मौजूद हर अनुमति को सूचीबद्ध करता है—जैसे HR डेटा, प्रोजेक्ट फ़ाइलें, एडमिन अधिकार, इत्यादि। यदि मॉडल कोई विनाशकारी कमांड (destructive command) हैलुसिनेट (hallucinate) करता है, तो child agent उसे उपयोगकर्ता के पूर्ण अधिकार के साथ निष्पादित कर सकता है। एक भी गलती पूरे संगठन के डेटा को उजागर कर सकती है।

वर्तमान वर्कअराउंड की कमियाँ

RFC 8693 token-exchange flow के साथ मांग पर एक सीमित टोकन (narrow token) बनाना IAM सिस्टम में कई round-trips जोड़ता है, नेटवर्क ट्रैफिक को बढ़ाता है, और ध्यान देने योग्य latency पैदा करता है। जो टीमें कई short-lived agents बनाती हैं, उन्हें जल्द ही यह overhead बहुत भारी लगने लगता है।

CAPMAS कैसे काम करता है

CAPMAS अनुमति देने की प्रक्रिया को दो चरणों में विभाजित करता है:

  1. IAM-side encoding – IAM सर्विस एक encoder चलाती है जो प्राकृतिक भाषा (natural language) के अनुरोध (जैसे, "finance folder में फ़ाइलें सूचीबद्ध करें") को मेल खाने वाले विशेषाधिकारों (privileges) के एक सेट में अनुवादित करती है।
  2. Macaroon creation – वे विशेषाधिकार एक macaroon के भीतर caveats बन जाते हैं, जो एक लचीला token format है। यह downstream agents को और अधिक प्रतिबंध जोड़ने की अनुमति देता है, लेकिन मौजूदा प्रतिबंधों को कभी हटाने नहीं देता।

जब एक agent को macaroon प्राप्त होता है, तो वह दायरे को और सीमित कर सकता है—उदाहरण के लिए, फ़ाइल-सूची अनुरोध को एक sub-directory तक सीमित करना—लेकिन वह इसे बढ़ा नहीं सकता। प्रत्येक स्टेप (hop) पर, IAM सर्विस सभी caveats के प्रतिच्छेदन (intersection) को सत्यापित करती है, यह सुनिश्चित करते हुए कि कोई भी agent मूल अनुमति से अधिक कार्य न करे।

प्रदर्शन के आंकड़े जो स्वयं बोलते हैं

  • Speed – CAPMAS 20 ms से भी कम समय में अनुमति अनुरोध को प्रोसेस करता है, जो RFC 8693 exchange की तुलना में लगभग 30 × तेज़ है।
  • Accuracy – टूल्स के एक बड़े कैटलॉग के साथ किए गए बेंचमार्क में, एक मानक LLM अपने आवश्यक विशेषाधिकारों में से 53% को मिस कर गया। CAPMAS ने केवल 2.1% मिस रेट के साथ 90.9% सटीकता हासिल की।
  • Bandwidth – क्योंकि macaroon में केवल caveats का अंतिम सेट होता है, इसलिए विनिमय (exchange) किया गया डेटा एक पूर्ण token-exchange flow की आवश्यकता के मुकाबले बहुत कम होता है।

एक व्यावहारिक अपनाना कार्यप्रवाह (adoption workflow)

  1. Pre-filter the request – किसी भी orchestrator द्वारा टूल कैटलॉग को छूने से पहले उपयोगकर्ता के natural-language इरादे को top-k allowlist में बदलें।
  2. Seal the allowlist – उस allowlist को एक macaroon में encode करें जिसे child agent बढ़ा न सके।
  3. Verify at the service – अनुरोध को स्वीकार करने से पहले target service को सभी caveats के intersection की गणना करने के लिए IAM से पूछने दें।

ये चरण "बच्चे को पूरे घर की चाबी दे दो" वाले पैटर्न को "एक बार उपयोग होने वाली, सीमित दायरे वाली चाबी सौंप दो" मॉडल से बदल देते हैं।

CAPMAS क्या ठीक नहीं करता है

यह फ्रेमवर्क prompt-injection हमलों को नहीं रोकता है, जहाँ हमलावर दुर्भावनापूर्ण कमांड (malicious commands) डालने के लिए LLM के प्रॉम्प्ट में हेरफेर करता है। इसका सुरक्षा कवच "honest-but-curious" agents और अविश्वसनीय LLMs को कवर करता है जो अन्यथा एक पूर्ण JWT पर कार्य कर सकते हैं। प्रॉम्प्ट-आधारित खतरों से निपटने के लिए टीमों को अभी भी अलग सुरक्षा उपायों—जैसे input sanitisation, sandboxing, या model-level guardrails—की आवश्यकता है।

किसे लाभ होगा

  • Enterprise developers जो AI-driven assistants बना रहे हैं जो internal APIs को कॉल करते हैं।
  • Security teams जो एक समझौता किए गए (compromised) मॉडल के प्रभाव क्षेत्र (blast radius) को कम करना चाहती हैं।
  • Product owners जिन्हें उच्च-आवृत्ति (high-frequency) agent spawning के लिए तेज़ और विश्वसनीय अनुमति जाँच की आवश्यकता है।

आगे क्या है

CAPMAS एक प्रस्तावित डिज़ाइन है।

Takeaway: पूर्ण-उपयोगकर्ता JWTs को सीमित दायरे वाले macaroons से बदलना डेवलपर्स को पारंपरिक token-exchange flows की latency की कीमत चुकाए बिना AI agents को ईमानदार रखने का एक तरीका देता है। इसके बदले में prompt-injection सुरक्षा उपायों की निरंतर आवश्यकता बनी रहेगी।