AI एजेंट सुरक्षा एक ही नियम से शुरू होती है: आपके AI एजेंट को कभी आपके क्रेडेंशियल नहीं रखने चाहिए। यह रहा 38 साल पुराना broker पैटर्न जो इसे लागू करता है।
AI एजेंट confused deputy हैं। यह 38 साल पुराना सुरक्षा पैटर्न है, और जवाब भी उतना ही पुराना है: एजेंट और जिन SaaS API को उसे कॉल करने की ज़रूरत है, उनके बीच एक broker रखें — एक भरोसेमंद, अवलोकन योग्य, नियतात्मक, ऑडिट योग्य, अजेय, स्कोप-संकुचित, नीति-संचालित, गैर-AI मध्य परत — जो वे क्रेडेंशियल रखती है जो आपके एजेंट के पास नहीं होने चाहिए।
1988 में, Norm Hardy ने एक संक्षिप्त पेपर प्रकाशित किया जिसमें Tymshare में उनके समय की एक असली घटना का वर्णन था। FORT नामक एक Fortran कंपाइलर SYSX नामक एक सिस्टम डायरेक्टरी में रहता था। उपयोग आँकड़े इकट्ठा करने के लिए, कंपाइलर को (SYSX)STAT में लिखना पड़ता था, इसलिए ऑपरेटिंग सिस्टम ने FORT को एक "home files license" दे दी थी, जो उसे SYSX के अंदर किसी भी फ़ाइल में लिखने का अधिकार देती थी। सिस्टम की बिलिंग फ़ाइल, (SYSX)BILL, भी वहीं रहती थी। कंपाइलर को इनवोक करने वाला कोई उपयोगकर्ता वैकल्पिक डीबग आउटपुट पाने के लिए एक फ़ाइलनाम दे सकता था। एक दिन एक उपयोगकर्ता ने (SYSX)BILL दिया। कंपाइलर ने OS से उस फ़ाइल को लिखने के लिए खोलने को कहा; OS ने, home files license को देखते हुए, इसकी अनुमति दे दी। बिलिंग डेटा ऊपर से लिख दिया गया। कंपाइलर ने ठीक वही किया जिसके लिए उसे डिज़ाइन किया गया था। खामी आर्किटेक्चरल थी।
Hardy ने इसे confused deputy problem नाम दिया: एक विशेषाधिकार प्राप्त प्रोग्राम (deputy) के पास अपना खुद का अधिकार होता है; एक कम-विशेषाधिकार वाला कॉलर उससे कुछ करने को कहता है; deputy इस बारे में भ्रमित हो जाता है कि वह किसके अधिकार पर काम कर रहा है, और अपने खुद के अधिकार का उपयोग करता है। इसका समाधान है उस अधिकार को deputy से पूरी तरह हटा देना और उसे एक अलग परत के पीछे रखना जो माँग पर कॉल की मध्यस्थता करती है। वह परत broker है।
अड़तीस साल बाद, आपकी कंपनी जो भी AI एजेंट चलाती है, वह एक confused deputy है। और उनमें से ज़्यादातर बिना किसी broker के चल रहे हैं।
AI एजेंट सुरक्षा समस्या को और बदतर क्यों बनाते हैं
Hardy के FORT के पास एक इनपुट चैनल था: कमांड लाइन। एक आधुनिक AI एजेंट के पास दर्जनों होते हैं: ईमेल बॉडी, पुनः प्राप्त वेब पेज, अपलोड की गई PDF, MCP सर्वर से टूल आउटपुट, मल्टी-एजेंट सिस्टम में सहकर्मी एजेंट से संदेश। जो कुछ भी context window में आता है, वह निर्देश जारी कर सकता है, और डिज़ाइन के अनुसार एजेंट उन सबको वैध मानता है।
यह एक ऐसी धारणा को तोड़ता है जिस पर पारंपरिक एक्सेस कंट्रोल निर्भर करता है: कॉलर इनपुट को नियंत्रित करता है। किसी वेब ऐप में, कॉलर (प्रमाणित सेशन) और इनपुट (HTTP अनुरोध बॉडी) एक ही जगह से आते हैं। किसी एजेंट के लिए, कॉलर वह है जो प्रॉम्प्ट को आकार देता है, जिसका मतलब है कि एक हमलावर जो एक ईमेल लिख सकता है या एक सर्च रिज़ल्ट बो सकता है, वह भी एक कॉलर है।
नवंबर 2025 में, PromptArmor के सुरक्षा शोधकर्ताओं ने दिखाया कि प्रोडक्शन में यह कैसा दिखता है। उन्होंने एक इंटीग्रेशन गाइड पर 1-पिक्सेल फ़ॉन्ट में दुर्भावनापूर्ण निर्देश छिपा दिए। जब एक डेवलपर ने Google के Antigravity IDE को उस पर इंगित किया, तो एजेंट ने cat को शेल-आउट करके अपने ही .gitignore-आधारित फ़ाइल सुरक्षा को दरकिनार कर दिया। फिर इसने Antigravity के अपने ही ब्राउज़र सबएजेंट के माध्यम से .env फ़ाइलों की सामग्री को एक हमलावर-नियंत्रित webhook.site URL पर लीक कर दिया। उपयोगकर्ता ने सब कुछ सही तरीके से सेट किया था। सैंडबॉक्स टिका रहा। एजेंट बस यह नहीं बता सका कि उपयोगकर्ता ने क्या माँगा था और इनपुट ने उसे क्या करने को कहा।
Hardy के FORT जैसा ही आकार, दशकों बाद: व्यापक अधिकार, अविश्वसनीय इनपुट, दोनों को अलग करने का कोई तरीका नहीं।
समुदाय के पास जवाब हैं। वे बस बिखरे हुए हैं।
यह कोई नई समस्या नहीं है। सुरक्षा समुदाय दशकों से जवाब लिखता रहा है:
Capability-based security (Dennis & Van Horn, 1966; बाद में E भाषा और Google पर Mark Miller का Caja कार्य)। सिद्धांत: पहचान या स्थान के आधार पर परिवेशी अधिकार न दें; प्रोग्राम जिस प्रत्येक संसाधन को छूने की अनुमति है, उसके लिए स्पष्ट, अजेय capability पास करें। एक capability आप क्या कर सकते हैं को आप उसे किस पर कर सकते हैं के साथ बाँधती है, और इसे किसी और चीज़ से भ्रमित नहीं किया जा सकता।
Brokered Credentials (OWASP LLM Top 10 द्वारा संहिताबद्ध)। API टोकन को LLM के context में न रखें। एक भरोसेमंद मध्य परत एजेंट की ओर से कॉल करती है; मॉडल तय करता है कि क्या करना है, broker संभालता है कि कैसे। प्रॉम्प्ट इंजेक्शन जो मॉडल से उसके क्रेडेंशियल प्रिंट करने को कहता है, उसे कुछ उपयोगी नहीं मिलता। क्रेडेंशियल वहाँ हैं ही नहीं।
Phantom Token Pattern (Curity, मूल रूप से माइक्रोसर्विसेज में OAuth के लिए)। एजेंट एक अपारदर्शी सेशन हैंडल रखता है, असली bearer टोकन नहीं। एक प्रॉक्सी हैंडल को सत्यापित करती है, नेटवर्क एज पर असली क्रेडेंशियल को स्वैप करती है, और अपस्ट्रीम फ़ॉरवर्ड करती है। अगर एजेंट अपना एनवायरनमेंट लीक कर देता है, तो हमलावर को एक स्ट्रिंग मिलती है जो सेशन समाप्त होने पर एक्सपायर हो जाती है।
Just-in-time credential injection (Aembit जैसे workload identity सिस्टम)। लंबे समय तक चलने वाले टोकन जारी करने के बजाय प्रति-कॉल एक अल्पकालिक, स्कोप-संकुचित क्रेडेंशियल बनाएँ।
इनमें से कुछ भी साहित्य से गायब नहीं है। यह डिफ़ॉल्ट से गायब है। ज़्यादातर एजेंट प्लेटफ़ॉर्म अब भी मॉडल को एक OAuth टोकन थमा देते हैं, बीच में कोई broker नहीं, और बेहतरी की उम्मीद करते हैं।
Zero का broker कैसे काम करता है
हमने ऊपर के किसी भी पैटर्न का आविष्कार नहीं किया। हमने उन्हें एक एकल broker में जोड़ा जो Zero पर हर एजेंट के लिए डिफ़ॉल्ट रूप से चलता है। यह वही भरोसेमंद मध्य परत है जिसका वे पैटर्न वर्णन करते हैं, एक AI एजेंट प्लेटफ़ॉर्म के लिए बनाई गई। एजेंट जो भी कॉल किसी connector को करता है, वह इसके माध्यम से जाती है। प्रत्येक connector एक बाहरी SaaS है (Slack, GitHub, Notion, और इसी तरह)।
broker हर एजेंट और हर connector के बीच बैठता है। असली क्रेडेंशियल केवल बिंदीदार रेखा के broker वाले हिस्से में रहते हैं।
इसे तीन परतों के रूप में सोचें।
1. Credential isolation
एजेंट का सैंडबॉक्स कभी कोई असली connector क्रेडेंशियल नहीं रखता। जब आप किसी SaaS को Zero से कनेक्ट करते हैं, तो OAuth टोकन या API कुंजी broker वाले हिस्से में रहती है। सैंडबॉक्स को एक placeholder स्ट्रिंग मिलती है जो किसी एनवायरनमेंट सीक्रेट जैसी लगती है ताकि मौजूदा टूल काम करते रहें, लेकिन कोई भी अपस्ट्रीम SaaS इसे स्वीकार नहीं करेगा।
जब एजेंट किसी पंजीकृत connector होस्ट को अनुरोध करता है, तो broker अनुरोध का मिलान करता है, connector के auth टेम्पलेट को हल करता है, और नेटवर्क एज पर असली क्रेडेंशियल इंजेक्ट करता है। अनुरोध वैध auth के साथ अपस्ट्रीम जाता है; एजेंट के पास कभी कुछ उपयोगी नहीं था। एक प्रॉम्प्ट-इंजेक्टेड एजेंट जो अपने एनवायरनमेंट वेरिएबल डंप करता है, वह हमलावर को एक placeholder देता है, SaaS टोकन नहीं।
यह phantom token पैटर्न है, AI एजेंट पर लागू।
2. Connector policy gate
Zero में एक connector किसी ऑन/ऑफ़ स्विच से ज़्यादा होना चाहिए। प्रत्येक connector वर्णन करता है कि यह किन API बेस को कवर करता है और auth को कैसे इंजेक्ट किया जाना चाहिए। जहाँ अपस्ट्रीम सेवा एक स्थिर scope-to-endpoint मैपिंग प्रकाशित करती है, वहाँ यह यह भी वर्णन कर सकता है कि कौन सी नामित अनुमति प्रत्येक मेथड और पाथ को कवर करती है। Slack का slack-api-ref एक अच्छा उदाहरण है।
इसलिए जब Slack से जुड़ा एक एजेंट chat.postMessage कॉल करता है, तो broker उस अनुरोध को chat:write पर मैप कर सकता है। जब यह ऑडिट लॉग पढ़ता है, तो वह admin.analytics:read होता है। प्रत्येक एजेंट के लिए, permission_policies परिभाषित करता है कि वे नामित अनुमतियाँ कैसे व्यवहार करती हैं: allow, deny, या ask। नीति को auth इंजेक्शन से पहले broker पर लागू किया जाता है, मॉडल के लिए किसी संकेत के रूप में नहीं। अगर एजेंट किसी अस्वीकृत अनुमति द्वारा कवर की गई कॉल करने की कोशिश करता है, शायद इसलिए कि यह प्रॉम्प्ट-इंजेक्टेड था, तो वह कॉल कभी अपस्ट्रीम नेटवर्क तक नहीं पहुँचती।
हर connector को आज वह रिज़ॉल्यूशन नहीं मिलता। कुछ अपस्ट्रीम API एक स्थिर scope-to-endpoint मैपिंग प्रकाशित नहीं करते। GitHub का GraphQL सरफ़ेस इसका विहित उदाहरण है: REST पक्ष को मैप किया जा सकता है, लेकिन GraphQL पक्ष को अभी नहीं। उन connector के लिए, broker अब भी क्रेडेंशियल इंजेक्शन और नेटवर्क पाथ को नियंत्रित करता है, जबकि अनुमति गेट उस मोटे connector- या होस्ट-स्तरीय नीति पर वापस आ जाता है जिसे प्लेटफ़ॉर्म वास्तव में लागू कर सकता है। जैसे-जैसे अपस्ट्रीम डेटा उपलब्ध होता है, हम इन्हें भरते जाते हैं। हम ऐसी कवरेज का दावा नहीं करते जो हमने बनाई नहीं है।
टोकन परिवेशी अधिकार नहीं ढोते। अधिकार प्रति एजेंट, जिस भी रिज़ॉल्यूशन पर अपस्ट्रीम सपोर्ट करता है, उस पर brokered होता है। यह जवाब का capability-based आधा हिस्सा है।
3. Operational loop और audit
Least privilege तभी काम करता है जब फ़ेलियर मोड उपयोग योग्य हो। एजेंट बढ़ते हैं। छह हफ़्ते बाद, एक रिसर्च एजेंट जिसने Notion से पढ़ने से शुरुआत की, उसे शायद वापस एक सारांश लिखने की ज़रूरत हो। कहीं और के सामान्य फ़ेलियर मोड: एजेंट नई अनुमति के बिना चुपचाप चलता है और टूट जाता है, या ऑपरेटर घबराहट में ज़्यादा अनुमति दे देता है और उसे कभी वापस नहीं लेता।
एक अस्वीकृत connector अनुरोध एक संरचित 403 लौटाता है: connector, मेथड, पाथ, बेस URL, और जब broker उन्हें पहचान सके तो मिलान करने वाली अनुमति नाम। एजेंट का सिस्टम प्रॉम्प्ट उसे बताता है कि अस्वीकृति का निदान कैसे करें और ठीक वही अनुमति कैसे माँगें जिससे वह अभी टकराया था, जिससे उपयोगकर्ता या एडमिन के लिए एक one-click ग्रांट URL बनता है। यह एस्केलेशन पथ को ठीक उसी अनुमति से बाँधे रखता है जिसका अनुरोध किया जा रहा है, न कि "बस सब कुछ दे दो" में बदल जाने देता है।
अनुमति बदलने के अनुरोध एक कतार में बैठते हैं। मालिक और एडमिन उन्हें डैशबोर्ड से स्वीकृत या अस्वीकृत कर सकते हैं; स्वीकृत अनुरोध एजेंट की नीति अपडेट करते हैं, और अगली रिट्राई पास हो जाती है। ज़्यादातर प्लेटफ़ॉर्म इस लूप को छोड़ देते हैं। इसके बिना, "least privilege" प्रोडक्शन में चलने के बजाय स्लाइड डेक पर ही रह जाता है।
वही broker पथ audit को फ़ीड करता है। प्रति-रन नेटवर्क लॉग HTTP, TCP, DNS, और गैर-TCP ट्रैफ़िक के लिए निम्न-स्तरीय पैकेट अवलोकनों के माध्यम से सैंडबॉक्स नेटवर्क गतिविधि रिकॉर्ड करते हैं। Connector-मिलान किए गए अनुरोधों में संरचित broker मेटाडेटा शामिल होता है: connector, उपलब्ध होने पर मिलान की गई अनुमति, allow/deny परिणाम, auth रिज़ॉल्यूशन मेटाडेटा, और billable फ़्लैग। अगर कोई बाद में पूछता है कि "इस एजेंट ने मंगलवार दोपहर 3 बजे क्या किया?", तो आप उन रिकॉर्ड से जवाब का पुनर्निर्माण करते हैं। रोकथाम चीज़ें चूक जाती है। ऑडिट ट्रेल वही है जिससे आप पता लगाते हैं कि क्या हुआ।
हमने क्या हल नहीं किया है
ऊपर की हर चीज़ के बावजूद, एक वैध chat:write वाले एजेंट को अब भी किसी ऐसे चैनल पर शर्मनाक संदेश पोस्ट करने के लिए मनाया जा सकता है जिस तक उसकी पहले से पहुँच है। broker ब्लास्ट रेडियस को संकुचित करता है; इसे ख़त्म नहीं करता।
जवाब का दूसरा आधा हिस्सा है high-stakes-action अप्रूवल, आउटपुट सत्यापन, और टूल रिटर्न को डिफ़ॉल्ट रूप से अविश्वसनीय मानना। वह काम रोडमैप पर है, अभी प्रोडक्ट में नहीं। जो कोई दावा करता है कि उसने confused deputy को end-to-end हल कर लिया है, वह आपको कुछ बेच रहा है।
यह फ़र्श होना चाहिए, कोई फ़ीचर नहीं
Capability-based security 1970 के दशक से मौजूद है। Brokered credentials OWASP LLM Top 10 में हैं। Phantom tokens LLM युग से पहले के हैं। इनमें से कुछ भी इसलिए गायब नहीं है कि किसी को जवाब पता नहीं था। यह इसलिए गायब है क्योंकि शुरुआती एजेंट प्लेटफ़ॉर्म ने "डेमो को काम कराने" के लिए ऑप्टिमाइज़ किया और सुरक्षा को किसी बाद के रिलीज़ पर टाल दिया, जो अक्सर कभी नहीं आया।
प्लेटफ़ॉर्म की अगली पीढ़ी को ऊँचा लक्ष्य रखना चाहिए। टोकन को मॉडल context में नहीं घुसना चाहिए। अधिकार प्रति एजेंट गिनाया जाना चाहिए। विशेषाधिकार वृद्धि किसी मनुष्य से होकर गुज़रनी चाहिए। हर कार्रवाई end to end ऑडिट योग्य होनी चाहिए। इनमें से कुछ भी नया नहीं है। यह सब आधार रेखा होनी चाहिए।
जब आप कोई एजेंट प्लेटफ़ॉर्म चुन रहे हों, तो "क्या यह सुरक्षित है?" आपको कहीं नहीं ले जाता। हर वेंडर हाँ कहता है। एक बेहतर सवाल: मुझे अपना broker दिखाओ, और मुझे समझाओ कि जब कोई एजेंट किसी ऐसे scope की माँग करता है जो उसके पास नहीं है तो क्या होता है।
broker Zero पर हर एजेंट के सामने डिफ़ॉल्ट रूप से बैठता है। Connector इन्वेंटरी, scope मैपिंग, अनुमति नीतियाँ, और broker लॉजिक सब Zero की सोर्स रिपॉज़िटरी में रहते हैं। कोई connector मिला जो हमने कवर नहीं किया? एक issue फ़ाइल करें।
संदर्भ
आधारभूत
- Norm Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review 22(4), 1988. DOI 10.1145/54289.871709
- Dennis & Van Horn, Programming Semantics for Multiprogrammed Computations, CACM 1966 (संस्थापक capability-systems पेपर)
- Mark Miller et al., Caja: वेब के लिए capability-based security, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
उद्धृत वास्तविक घटनाएँ
- PromptArmor, Google Antigravity Exfiltrates Data, नवंबर 2025
- Simon Willison, कवरेज और विश्लेषण, 25 नवंबर 2025
