LLM एप्लिकेशन में Authorization

• बड़े भाषा मॉडल (LLM) ऐसे अप्रत्याशित सिस्टम हैं जो मानव उपयोगकर्ताओं के अनिश्चित इनपुट को प्रोसेस करते हैं, इसलिए least privilege सिद्धांत लागू करना अनिवार्य है
• चूँकि LLM वास्तव में internal search, automation आदि कई तरह के कामों में उपयोग हो रहे हैं, इसलिए उन्हें केवल न्यूनतम दिए गए “effective permissions” के भीतर ही काम करना चाहिए ताकि सुरक्षा घटनाओं और दुरुपयोग को रोका जा सके
• RAG (Retrieval-Augmented Generation) आर्किटेक्चर में data embedding और permission check को data source से अलग रखा जाता है, इसलिए resource level पर सटीक access control की आवश्यकता होती है
• जैसे-जैसे external (3rd party) data/RAG, Agent, MCP आदि का जटिल उपयोग बढ़ता है, वैसे-वैसे permissions वास्तव में कहाँ और कैसे लागू किए जाएँ, यह security का मुख्य मुद्दा बनकर उभरता है
• OAuth जैसे token-based authentication में resource unit के स्तर पर सूक्ष्म permissions नियंत्रण की सीमा होती है, इसलिए वास्तविक permission logic को application layer में सीधे implement करना पड़ता है

---

शब्दावली और बुनियादी अवधारणाएँ

• Prompt: LLM को भेजा जाने वाला उपयोगकर्ता का अनुरोध (command, question आदि)
• RAG(Retrieval-Augmented Generation): prompt में अतिरिक्त data जोड़कर LLM के response की accuracy बढ़ाने वाला workflow (उदाहरण: कंपनी की छुट्टियों की सूची अपने-आप जोड़ना)
• Context: prompt के साथ जोड़ा जाने वाला सहायक data (जैसे खोजी गई संबंधित सामग्री)
• Embedding: text का संख्यात्मक vector representation, जिसका उपयोग data search/matching में होता है
• Agent: prompt के आधार पर action करने वाला LLM-आधारित execution engine (जैसे tools का automatic invocation)
• Tool: कोई external function जैसे API/application जिसे LLM सीधे call कर सकता है
• Model Context Protocol(MCP): Anthropic द्वारा प्रस्तावित LLM tool access का standard protocol

LLM permission model के मुख्य सिद्धांत

• Golden Rule:

  LLM को उपयोगकर्ता के अनुरोध को प्रोसेस करने के लिए आवश्यक न्यूनतम permissions के साथ ही काम करना चाहिए

• मानव उपयोगकर्ताओं के लिए कुछ हद तक "रूढ़िगत over-privilege" स्वीकार्य हो सकता है, लेकिन LLM अप्रत्याशित, तेज़ और गलती होने पर बड़े पैमाने पर नुकसान पहुँचा सकते हैं
  → LLM की “effective permissions” को उपयोगकर्ता, LLM और task permissions के intersection तक सीमित किया जाना चाहिए

effective permissions की गणना

• LLM एप्लिकेशन की effective permissions =
  1. LLM के पास मौजूद permissions
  2. उपयोगकर्ता के पास मौजूद permissions
  3. अनुरोधित task के लिए आवश्यक permissions
     इन तीनों का intersection
• उपयोगकर्ता LLM (जैसे chatbot) को अपनी भूमिका “delegate/impersonate” करता है,
  लेकिन LLM और उपयोगकर्ता, दोनों की permission सीमा से बाहर नहीं जाना चाहिए
• permissions Venn diagram के माध्यम से इसे सहज रूप से समझाया जा सकता है
  • execution की अनुमति तभी है जब task permissions पूरी तरह intersection में शामिल हों

RAG (Retrieval-Augmented Generation) और permission processing

1. 1st Party (स्वयं की) data RAG

• उदाहरण: कोई internal chatbot internal source code में “secret key शामिल फाइलें” खोजकर बताए
• Embedding: सभी files को vector में बदलकर DB में store किया जाता है, और prompt को भी vector में बदलकर similarity-based matching की जाती है
• permissions लागू करने की जगह:
  • search result के रूप में लौटी “file” के वास्तविक owner organization, type, repository और user permissions को तुरंत verify करना
  • यह जाँचना कि उपयोगकर्ता उस file तक पहुँच सकता है या नहीं (resource-level permission)
  • embedding → source data mapping की प्रक्रिया में application layer पर permission check करना
• permission logic को सीधे LLM के भीतर रखना अस्थिर है (उसकी probabilistic प्रकृति के कारण इसकी गारंटी नहीं दी जा सकती)
• सार:
  • RAG का मूल बिंदु यह है कि embedding को original data से जोड़ने के बाद user-wise/resource-wise permissions को सख्ती से लागू किया जाए

2. 3rd Party (external) data RAG

• external API/system (जैसे wiki, ticket system आदि) के data को embed करके उपयोग करना
• समस्या: embedding और original data अलग-अलग systems में मौजूद होते हैं → permissions कहाँ लागू हों, यह अस्पष्ट हो जाता है
• permission handling के तीन तरीके
  1. permissions को external system को delegate करना (हर API request पर वास्तविक permission verification, लेकिन response धीमा हो सकता है और rate limit की समस्या आती है)
  2. ACL (access control list) को application में sync करना (accuracy/reliability अधिक, लेकिन ACL management/synchronization की लागत बढ़ती है)
  3. external permission logic को अंदरूनी रूप से फिर से implement करना (management/synchronization का बोझ और logic complexity बढ़ती है)
• निष्कर्ष: वास्तविक परिस्थिति के अनुसार “permissions लागू करने की जगह” और तरीके के trade-off महत्वपूर्ण हैं
  (performance-सादगी, management cost-सटीकता आदि के बीच चयन आवश्यक है)

Agent-आधारित LLM (AI Agent) और permissions

• उदाहरण: chatbot द्वारा repository branch delete करना, issue close करना आदि automatic maintenance tasks
• MCP (Model Context Protocol) के माध्यम से tools (function/API) को standardized तरीके से LLM के सामने expose किया जाता है
• MCP की हर request पर effective permission model लागू होना चाहिए
  (उपयोगकर्ता/agent/task permissions का intersection)
• OAuth जैसे token-based authentication की सीमाएँ
  • permission जानकारी token में हो सकती है, लेकिन यह real-time asset/resource-level permissions को पूरी तरह cover नहीं कर पाती
  • व्यवहार में token में केवल कुछ जानकारी रखी जाती है, बाकी के लिए application layer में अलग permission logic implement करना पड़ता है

निष्कर्ष और व्यावहारिक सारांश

• LLM/RAG/Agent वातावरण में permission management का मुख्य बिंदु “permissions कहाँ और कैसे लागू किए जाएँ” यह तय करना है

• effective permission model के माध्यम से LLM को केवल “उपयोगकर्ता+LLM+task” के intersection के भीतर ही काम करने तक सीमित करना चाहिए

• OAuth जैसे authentication token का उपयोग केवल “request किसने किया” यह पहचानने के लिए करें,
  वास्तविक resource-wise permission verification हमेशा application में ही किया जाना चाहिए

• external systems के साथ integration करते समय,
  1) permissions delegate करना (performance गिरती है), 2) ACL sync करना (operations जटिल होते हैं), 3) permission logic फिर से implement करना (maintenance अधिक)
  जैसे विभिन्न trade-off को ध्यान में रखकर design करना आवश्यक है

• अंतिम सारांश:

  LLM को उपयोगकर्ता के अनुरोध को प्रोसेस करने के लिए आवश्यक न्यूनतम permissions के भीतर ही काम करना चाहिए,
  और effective permissions को LLM permissions, user permissions और task permissions के intersection के रूप में परिभाषित किया जाना चाहिए
  वास्तविक permission verification resource-wise, application layer पर अनिवार्य रूप से की जानी चाहिए