जेनेरिक HTTP टूल अनुमति की सीमा मिटा देते हैं

एजेंट होस्ट को एक जेनेरिक HTTP कॉल एक टूल जैसा दिखता है। असल काम में उसके भीतर हजारों क्षमताएं हो सकती हैं। URL, क्रेडेंशियल, मेथड, हेडर या बॉडी बदलते ही वही फंक्शन स्टेटस पेज पढ़ सकता है, ग्राहक रिकॉर्ड निर्यात कर सकता है, साइनिंग सीक्रेट बदल सकता है या प्रोडक्शन संसाधन मिटा सकता है।

यह अंतर टूल स्तर की अनुमति को कमजोर सुरक्षा सीमा बना देता है। किसी एजेंट को http_request इस्तेमाल करने की मंजूरी देना यह नहीं बताता कि एजेंट क्या कर सकता है। काम का फैसला एक परत नीचे होना चाहिए, जहां कोई खास क्रेडेंशियल हल किए गए गंतव्य, स्वीकृत मेथड और सीमित अनुरोध विवरण से बांधा जा सके।

यह फर्क तब भी मायने रखता है जब एजेंट ठीक व्यवहार कर रहा हो। प्रॉम्प्ट में गलतियां होती हैं, बाहर से मिला टेक्स्ट नुकसान पहुंचाने वाले निर्देश ला सकता है, और बहुत खुला टूल योजना की छोटी गलती को असली API कार्रवाई बना सकता है। टूल को आसान नाम देने से यह ठीक नहीं होता। नेटवर्क पार करने वाली कार्रवाई को अधिकृत करना पड़ता है।

एक कॉल टूल में कई क्षमताएं होती हैं

कोई टूल तभी क्षमता की सीमा है जब उसके इनपुट उसकी शक्ति को पूरी तरह न बदल सकें। तय अपस्ट्रीम, तय GET मेथड और तय जवाब वाले मौसम टूल को लगभग एक क्षमता माना जा सकता है। कोई फंक्शन जो कोई भी URL, क्रिया, हेडर और बॉडी लेता है, प्रोग्राम किया जा सकने वाला नेटवर्क क्लाइंट है।

पांच आम फील्ड वाले स्कीमा पर विचार करें: url, method, headers, body और credential_name। एजेंट होस्ट इसे टूल सूची में एक ही आइटम दिखा सकता है। फिर भी रीड टोकन के साथ GET /projects/42 और एडमिन टोकन के साथ DELETE /projects/42 को एक जैसी मंजूरी नहीं मिलनी चाहिए। सार्वजनिक API का अनुरोध और निजी नेटवर्क की सेवा पर हल होने वाला अनुरोध भी एक जैसे नहीं हैं।

Model Context Protocol के टूल एनोटेशन इस समस्या को ठीक नहीं करते। MCP टूल स्पेसिफिकेशन रीड ओनली और विनाशकारी व्यवहार जैसे एनोटेशन को संकेत बताता है और क्लाइंट से कहता है कि गैर-विश्वसनीय सर्वर से आने पर उन पर भरोसा न करें। जेनेरिक कॉलर readOnlyHint के लिए एक हमेशा सही मान भी नहीं दे सकता, क्योंकि उसका व्यवहार अभी तक न मिले आर्ग्युमेंट पर निर्भर है।

टीमें अक्सर दो बातों को मिला देती हैं: टूल चुनना बताता है कि कौन सा इम्प्लीमेंटेशन चलेगा, जबकि कार्रवाई को अधिकृत करना बताता है कि बाहर की दुनिया में कौन सा असर होने दिया जाएगा। अगर होस्ट केवल इम्प्लीमेंटेशन के नाम को मंजूरी देता है, तो बहुत अलग अनुरोध भी वही मंजूरी पा लेते हैं। इसलिए साफ-सुथरे टूल पिकर के पीछे लगभग बिना सीमा वाला आउटबाउंड चैनल छिपा हो सकता है।

हर API ऑपरेशन को अलग टूल बनाने से विवरण और योजना बेहतर हो सकते हैं, लेकिन यह पूरा सुरक्षा उपाय नहीं है। बनाए गए टूल को फिर भी नियंत्रण लागू करने वाली जगह चाहिए, क्रेडेंशियल अपनी शक्ति रखते हैं और रीडायरेक्ट किसी सीमित दिखने वाली कार्रवाई को दूसरी जगह ले जा सकता है। खास टूल इस्तेमाल में आसानी के लिए रखें। अंतिम अनुरोध पर अनुमति लागू करें।

अनुमति के लिए चार निर्देशांक चाहिए

सुरक्षित HTTP फैसले के चार निर्देशांक हैं: क्रेडेंशियल, हल किया गया गंतव्य, मेथड और अनुरोध का विवरण। इनमें से कोई एक हटते ही अनुरोध मंजूर किया हुआ दिखते हुए अपना असर बदल सकता है।

क्रेडेंशियल बताता है कि कौन सी शक्ति इस्तेमाल हो रही है। डिप्लॉयमेंट टोकन और बिलिंग टोकन एक ही होस्ट और पाथ पर जा सकते हैं, फिर भी उनकी शक्तियां अलग होती हैं। गंतव्य बताता है कि वह शक्ति कहां पेश की जा सकती है। मेथड HTTP इरादे का मोटा संकेत देता है। पाथ, क्वेरी, चुने गए हेडर, कंटेंट टाइप और बॉडी जैसे बाकी विवरण असली ऑपरेशन तय करते हैं।

एक छोटा प्राधिकरण रिकॉर्ड ऐसा हो सकता है:

credential: issue-tracker-read
origin: https://api.example.test:443
path_prefix: /v2/issues/
methods:
  - GET
redirects: deny
headers:
  allow:
    - Accept
query:
  deny:
    - include_deleted
body: forbidden

यह अंश कई गड़बड़ियों को एक साथ रोकता है। एजेंट अधिक शक्तिशाली क्रेडेंशियल नहीं लगा सकता, क्रेडेंशियल को दूसरे ओरिजिन पर नहीं भेज सकता, रीड को POST में नहीं बदल सकता, रीडायरेक्ट के पीछे नहीं जा सकता, अनुमति जैसा हेडर नहीं जोड़ सकता, क्वेरी स्विच से मिटे रिकॉर्ड नहीं मांग सकता और रीड ओनली समझे गए ऑपरेशन में बॉडी नहीं डाल सकता।

यह पॉलिसी ऑब्जेक्ट हर जगह लगाने वाला टेम्पलेट नहीं है। कुछ API को सटीक पाथ चाहिए, कुछ को पाथ में टेनेंट पहचान चाहिए और कुछ POST बॉडी में ऑपरेशन रखते हैं। फैसले की बनावट मायने रखती है: पार्सिंग और नॉर्मलाइजेशन के बाद चारों निर्देशांक एक साथ जांचें और अनुरोध पास होने पर ही क्रेडेंशियल जोड़ें।

एजेंट को headers के जरिये असली सीक्रेट देने न दें। उसे किसी अपारदर्शी नाम से क्रेडेंशियल बताने दें, फिर विश्वसनीय एक्जीक्यूटर जांच के बाद bearer टोकन, basic क्रेडेंशियल या कस्टम हेडर लगाए। वरना एजेंट सीक्रेट को दूसरे फील्ड, लॉग या दूसरे गंतव्य में कॉपी कर सकता है और आपकी गंतव्य पॉलिसी दिखावा बन जाती है।

शक्ति क्रेडेंशियल तय करते हैं, सुविधा नहीं

क्रेडेंशियल अलग-अलग अनुदान होने चाहिए और उन्हें उतनी ही शक्ति मिलनी चाहिए जितनी अपस्ट्रीम API उस काम के लिए न्यूनतम रूप से दे सकता है। जब एक्जीक्यूटर पूरे संगठन के एक टोकन के बजाय नाम वाले, सीमित क्रेडेंशियल में से चुनता है, तो जेनेरिक HTTP टूल कम खतरनाक होता है।

OAuth स्कोप मदद करते हैं, लेकिन स्कोप और ऑडियंस अलग सवालों के जवाब देते हैं। स्कोप कह सकता है कि टोकन कॉन्टैक्ट पढ़ सकता है। ऑडियंस बताती है कि कौन सा रिसोर्स सर्वर उसे स्वीकार करे। RFC 8707 OAuth का resource पैरामीटर तय करता है ताकि क्लाइंट किसी खास सुरक्षित संसाधन के लिए टोकन मांग सके, और वह प्राधिकरण सर्वर को जारी टोकन की ऑडियंस सीमित करने की सलाह देता है। उसका सुरक्षा तर्क सीधा है: एक संसाधन पर दिया गया टोकन दूसरे संसाधन पर काम नहीं करना चाहिए।

मौजूदा MCP प्राधिकरण स्पेसिफिकेशन भी यही अलगाव अपनाता है। वह MCP सर्वर से केवल अपने लिए जारी टोकन स्वीकार करने को कहता है और आए हुए MCP टोकन को अपस्ट्रीम API तक भेजने से रोकता है। जब MCP सर्वर किसी दूसरे API को कॉल करता है, तब वह अलग OAuth क्लाइंट बनता है और अलग अपस्ट्रीम टोकन इस्तेमाल करता है। यह साफ सीमा है और जेनेरिक HTTP एक्जीक्यूटर को इसे तब भी बनाए रखना चाहिए जब एजेंट को OAuth फ्लो दिखाई न दे।

API की अक्सर अपनी सीमाएं कमजोर होती हैं। फिर भी हर API key को अलग शक्ति समझें। दर्ज करें कि कौन से ओरिजिन उसे पा सकते हैं, एक्जीक्यूटर उसे किस हेडर रूप में लगाएगा, उसकी अवधि कब खत्म होगी और रोटेशन का मालिक कौन है। केवल नाम staging होने से किसी वॉल्ट एंट्री को सुरक्षित न मानें। अपस्ट्रीम पर उसकी असली अनुमतियां जांचें।

क्रेडेंशियल का चुनाव मंजूरी स्क्रीन पर भी दिखना चाहिए। केवल POST api.example.test बताने वाला प्रॉम्प्ट यह छिपा देता है कि कॉल सैंडबॉक्स key इस्तेमाल करता है या अकाउंट मालिक का टोकन। इंसान को समझ आने वाला क्रेडेंशियल लेबल और उसका अकाउंट या टेनेंट दिखाएं, लेकिन सीक्रेट सामग्री कभी न दिखाएं। अगर एक्जीक्यूटर यह संदर्भ नहीं पहचान सकता, तो अनुदान चुपचाप दोबारा इस्तेमाल करने के लिए बहुत अस्पष्ट है।

सीक्रेट को मॉडल से बाहर रखने से अनचाहा खुलासा कम होता है, लेकिन केवल गोपनीयता इस्तेमाल को सीमित नहीं करती। अगर बहुत खुला एक्जीक्यूटर सीक्रेट को किसी भी अनुरोध से जोड़ देगा, तो एजेंट बिना उसके बाइट देखे भी उसका गलत इस्तेमाल कर सकता है। खुलासा रोकना और न्यूनतम शक्ति अलग समस्याएं हल करते हैं। दोनों जरूरी हैं।

गंतव्य का मतलब हल किया गया एंडपॉइंट है

URL स्ट्रिंग को एक बार जांचना गंतव्य नियंत्रण नहीं है। क्रेडेंशियल लगाने से पहले एक्जीक्यूटर को URL पार्स और नॉर्मलाइज करना, होस्ट हल करना, नेटवर्क नियम लागू करना और हर रीडायरेक्ट पर फैसला दोहराना चाहिए।

सटीक स्कीम, होस्ट और प्रभावी पोर्ट से शुरू करें। https://api.example.test और https://api.example.test:8443 अलग ओरिजिन हैं। URL में यूजर जानकारी, अस्पष्ट एन्कोडिंग, असमर्थित स्कीम और ऐसे होस्टनाम ठुकराएं जो केवल मंजूर सफिक्स जैसे दिखते हों। api.example.test.attacker.invalid को स्वीकार करने वाली सफिक्स जांच अनुमति सूची नहीं है।

फिर DNS हल करें और लौटे हर पते की जांच करें। सार्वजनिक दिखने वाला होस्टनाम loopback, link-local, निजी रेंज या cloud instance metadata पर हल हो सकता है। वैलिडेशन और कनेक्शन के बीच रिजॉल्यूशन बदल भी सकता है। जांच करने वाला कंपोनेंट खुद कनेक्शन नियंत्रित करे और असल में इस्तेमाल हुआ पता जांचे, URL किसी दूसरे क्लाइंट को न सौंपे जो उसे फिर से हल करे।

OWASP की Server Side Request Forgery Prevention Cheat Sheet ज्ञात विश्वसनीय गंतव्यों को अनुमति सूची में रखने की सलाह देती है, जब एप्लिकेशन उन्हें पहचान सकता हो। वह अपने आप रीडायरेक्ट के पीछे जाने को बंद रखने की सलाह भी देती है, क्योंकि रीडायरेक्ट इनपुट वैलिडेशन को पार कर सकता है। एजेंट टूल के लिए यह खास तौर पर सही है: URL अक्सर मॉडल देता है और अनुरोध ऐसा क्रेडेंशियल ले जा सकता है जिसे केवल पहला गंतव्य मिलना चाहिए था।

रीडायरेक्ट के लिए नया प्राधिकरण फैसला चाहिए। RFC 9110 कहता है कि असुरक्षित मेथड वाले अपने आप रीडायरेक्ट में सावधानी चाहिए और आगे जाते समय Authorization तथा Cookie जैसे संसाधन से जुड़े फील्ड हटाने की सलाह देता है। सुरक्षित एक्जीक्यूटर सरल रास्ता अपना सकता है: प्रमाणित कॉल के रीडायरेक्ट डिफॉल्ट रूप से मना करे या नया गंतव्य नई कार्रवाई के रूप में दिखाए और पॉलिसी पास करने पर ही फिर क्रेडेंशियल लगाए।

मंजूर ओरिजिन के भीतर भी पाथ नियंत्रण जरूरी है। मल्टी-टेनेंट गेटवे, साझा SaaS होस्ट और प्रशासनिक रूट एक होस्टनाम के पीछे रह सकते हैं। RFC 8707 बताता है कि मल्टी-टेनेंट सिस्टम में टेनेंट पहचानने वाला पाथ भी संसाधन पहचान का हिस्सा हो सकता है। इसलिए पाथ या टेनेंट सीमा के बिना ओरिजिन अनुमति सूची समीक्षक की उम्मीद से बहुत बड़ी हो सकती है।

HTTP मेथड संकेत हैं, अंतिम फैसला नहीं

मेथड की सीमा बहुत सी गलतियां हटाती है, लेकिन मेथड का नाम अनुरोध को हानिरहित साबित नहीं कर सकता। RFC 9110 GET, HEAD, OPTIONS और TRACE को safe कहता है क्योंकि उनके तय अर्थ मुख्य रूप से पढ़ने तक सीमित हैं। वह PUT, DELETE और safe मेथड को idempotent कहता है, जिसका अर्थ है कि एक ही अनुरोध कई बार करने का अपेक्षित असर उसे एक बार करने जैसा होगा।

Safe और idempotent एक बात नहीं हैं। DELETE idempotent होकर भी संसाधन मिटा सकता है। POST आम तौर पर न safe है, न idempotent, लेकिन कोई API लंबी क्वेरी के कारण रीड ओनली खोज के लिए POST इस्तेमाल कर सकता है। जोखिम को GET बनाम POST तक घटाने वाला मंजूरी सिस्टम दोनों मामलों को गलत समझेगा।

असल API कभी-कभी मेथड के अर्थ तोड़ते भी हैं। RFC 9110 खास तौर पर ऐसे संसाधन के बारे में चेतावनी देता है जो GET क्वेरी में मिटाने जैसी कार्रवाई रखते हैं, और संसाधन मालिक से safe मेथड में असुरक्षित व्यवहार बंद करने को कहता है। आपका एक्जीक्यूटर यह नहीं मान सकता कि हर अपस्ट्रीम उस नियम का पालन करता है। अगर GET /jobs?id=7&action=cancel स्थिति बदलता है, तो सभी GET की अनुमति रीड ओनली अनुदान नहीं है।

मेथड को एक इनपुट मानें। उसके साथ पाथ और जरूरत पर ऑपरेशन के खास अनुरोध नियम लगाएं। अच्छी तरह वर्णित API के लिए OpenAPI ऑपरेशन उपयोगी नक्शा दे सकता है: OpenAPI Specification ऑपरेशन को सुरक्षा आवश्यकताएं बताने देता है और OAuth एंट्री जरूरी स्कोप सूचीबद्ध करती है। यह जानकारी कॉन्फिगरेशन में लाएं, फिर अपस्ट्रीम वास्तव में क्या जारी और स्वीकार करता है उससे मिलाएं। केवल विवरण फाइल नियंत्रण लागू नहीं करती।

रीट्राई का व्यवहार भी इसी फैसले में आता है। POST के बाद नेटवर्क टाइमआउट यह नहीं बताता कि सर्वर ने कार्रवाई लागू की या नहीं। किसी असुरक्षित, non-idempotent अनुरोध को अपने आप दोबारा न भेजें, जब तक API idempotency का तरीका न दे या कॉलर यह साबित न कर सके कि पहला अनुरोध लागू नहीं हुआ। Idempotence रीट्राई को संचालन में सुरक्षित बना सकती है, लेकिन मूल कार्रवाई को अधिकृत नहीं करती।

अनुरोध का विवरण असली असर तय करता है

एक ही क्रेडेंशियल, ओरिजिन, पाथ और मेथड वाले दो अनुरोध भी उलटे काम कर सकते हैं। बॉडी, क्वेरी और चुने हुए हेडर में अक्सर वह ऑपरेशन होता है जो मायने रखता है।

कोई बिलिंग एंडपॉइंट सीट घटाने और अकाउंट को महंगे प्लान पर ले जाने, दोनों के लिए POST /v1/subscriptions/update ले सकता है। रिपॉजिटरी एंडपॉइंट एक mutation रूट में operation फील्ड से archive, transfer या delete चुन सकता है। include_deleted=true आने पर खोज एंडपॉइंट छिपे या मिटे रिकॉर्ड दे सकता है। इन फील्ड को सीमित किए बिना रूट की अनुमति देना उसके हर मोड की अनुमति देना है।

हेडर पर भी उतना ही शक करें। एक्जीक्यूटर को Authorization, Proxy-Authorization, Host और हर कस्टम क्रेडेंशियल हेडर अपने नियंत्रण में रखना चाहिए। एजेंट को इन्हें सेट करने से सामान्यतः रोकें। अकाउंट चुनने, किसी यूजर का रूप लेने, मेथड बदलने, asynchronous काम मांगने या conditional write नियंत्रण ले जाने वाले हेडर शक्ति या असर बदल सकते हैं। कोई भी हेडर आगे भेजना पहले जेनेरिक टूल के अंदर दूसरा जेनेरिक टूल रखना है।

कंटेंट टाइप पार्सिंग तय करता है। अगर पॉलिसी JSON जांचती है लेकिन क्लाइंट form data, multipart content या compressed bytes भेज सकता है, तो एजेंट संवेदनशील फील्ड को पार्सर से बाहर रख सकता है। घोषित टाइप लागू करें, बफर करने से पहले आकार सीमा तय करें, दोहराए या अस्पष्ट फील्ड ठुकराएं और उसी बाइट रूप को अधिकृत करें जो एक्जीक्यूटर भेजेगा। एक ऑब्जेक्ट की जांच करके दूसरा serialize करने से खाली जगह बनती है।

जवाब संभालना भी सीमा का हिस्सा है, भले ही वह बाहर जाने वाले असर का अनुमति निर्देशांक न हो। जवाब का आकार सीमित करें, कंटेंट टाइप पहचानें और लौटे निर्देशों को गैर-विश्वसनीय डेटा मानें। मंजूर GET भी prompt injection, सीक्रेट या बहुत बड़ा payload वाला पेज ला सकता है। बाहर जाने की अनुमति जवाब को एजेंट में वापस भेजने के लिए सुरक्षित नहीं बनाती।

सटीक बॉडी स्कीमा संभालना महंगा है, इसलिए मेहनत उन रूट पर करें जहां ज्यादा शक्ति जमा है। कम जोखिम वाले रीड में बॉडी रोकना और क्वेरी नाम सीमित करना काफी हो सकता है। अकाउंट बदलाव, डिप्लॉयमेंट, सीक्रेट रोटेशन, पैसे की आवाजाही या विनाशकारी कार्रवाई के लिए ऑब्जेक्ट, टेनेंट, रकम, वातावरण और मांगे गए बदलाव वाले फील्ड जांचें। API अगर अधिक सीमित एंडपॉइंट या क्रेडेंशियल देता है, तो जटिल स्थानीय नियम के बजाय उसे चुनें।

मंजूरी में हल की गई कार्रवाई दिखनी चाहिए

काम का मंजूरी प्रॉम्प्ट नॉर्मलाइजेशन के बाद विश्वसनीय एक्जीक्यूटर जो भेजने वाला है, वह दिखाता है, मॉडल का प्रस्तावित टूल कॉल नहीं। समीक्षक को क्रेडेंशियल लेबल, अकाउंट या टेनेंट, हल किया गया गंतव्य, मेथड, पाथ, सार्थक क्वेरी फील्ड, असरदार बॉडी फील्ड और रीडायरेक्ट व्यवहार चाहिए।

इसका अर्थ डायलॉग में कच्चा JSON भरना नहीं है। कच्चा payload खतरनाक फील्ड को timestamps और defaults के बीच छिपा देता है। पहले ऑपरेशन का सार दिखाएं, फिर canonical अनुरोध देखने दें। डिप्लॉयमेंट मंजूरी कह सकती है कि production-deployer क्रेडेंशियल प्रोडक्शन टेनेंट में रिलीज 2026.07.24 बनाएगा, फिर सटीक होस्ट, POST पाथ और बॉडी diff दिखाए।

मंजूरी को canonical कार्रवाई के digest से बांधें। क्लिक के बाद होस्ट, मेथड, पाथ, सुरक्षित हेडर या बॉडी बदले तो अलग digest निकालें और नया फैसला मांगें। इससे आम time-of-check खाली जगह बंद होती है, जहां इंटरफेस एक अनुरोध मंजूर करता है और middleware बाद में रीडायरेक्ट के पीछे जाता, default जोड़ता या बॉडी बदलता है।

दोबारा इस्तेमाल की सीमा सोचकर चुनें। एक सीमित क्रेडेंशियल और गंतव्य पर बार-बार पढ़ने के लिए session मंजूरी ठीक हो सकती है। संसाधन मिटा सकने वाले क्रेडेंशियल को हर कॉल पर मंजूरी या बहुत सीमित पहले से मंजूर ऑपरेशन चाहिए। बार-बार आने वाले प्रॉम्प्ट को scoping का विकल्प न बनाएं। सभी कार्ड एक जैसे दिखें तो लोग जल्दी बिना पढ़े क्लिक करने लगते हैं।

जरूरी संदर्भ न मिलने पर मंजूरी डिफॉल्ट रूप से इनकार होनी चाहिए। न हल हुआ होस्टनाम, अनजान कंटेंट टाइप, न पहचाना गया मेथड override या पॉलिसी के लिए न पढ़ी जा सकने वाली बॉडी कम जोखिम नहीं है। सिस्टम उस कार्रवाई को ठीक से बता ही नहीं सकता।

हानिरहित योजना भी खतरनाक कॉल बन सकती है

गड़बड़ी अक्सर सामान्य काम से शुरू होती है और अलग परतों से गुजरते हुए अनुरोध का अर्थ बदल जाता है। मान लें एजेंट को एक issue पढ़ना और छोटा status note पोस्ट करना है। दोनों काम एक project service इस्तेमाल करते हैं, इसलिए होस्ट पूरे session के लिए generic caller मंजूर कर देता है।

रीड क्रेडेंशियल POST पर असफल होता है, तो planner दूसरा vault entry चुनता है जिसके विवरण में project automation लिखा है। वह टोकन webhook भी संभाल सकता है। पढ़े गए issue comment में एजेंट को किसी बाहरी callback को सूचना देने का निर्देश मिलता है और planner उस callback URL को status target बना देता है। generic tool को अब भी session मंजूरी है, credential नाम संबंधित लगता है और method अब भी POST है। tool-level permission को कोई सीमा पार होती नहीं दिखती।

पहला callback निजी पते पर 307 redirect देता है। सुविधाजनक HTTP library उस status पर POST body बचा सकती है। वह अपने आप बना Authorization header हटा सकती है, लेकिन calling code का custom credential header तब तक बच सकता है जब तक client उसे खास तौर पर न संभाले। अनुरोध अब project authority और issue content लेकर ऐसे गंतव्य की ओर जा रहा है जिसे किसी ने नहीं देखा। निजी service credential ठुकरा दे, तब भी body data खोल सकती है या बिना authentication वाली कार्रवाई शुरू कर सकती है।

चार तालमेल वाली जांचें इसे अलग जगह रोकती हैं। रीड credential POST अधिकृत नहीं कर सकता। automation credential अनजान callback host तक नहीं पहुंच सकता। redirect पर नया destination फैसला चाहिए। request rules arbitrary callback destination वाली body ठुकराते हैं। कोई एक जांच पूरी रक्षा नहीं करती और tool या credential का सरल नाम जरा भी रक्षा नहीं करता।

इसीलिए मैं generic caller को session में एक बार मंजूर करने के खिलाफ हूं। यह तरीका लोकप्रिय है क्योंकि बार-बार approval card काम रोकते हैं और स्थिर tool name स्थिर जोखिम जैसा दिखता है। ऐसा नहीं है। session grant को constrained operations वाले credential और destination तक सीमित करें, फिर किसी coordinate के बदलने पर दोबारा पूछें।

बिना किसी नुकसान पहुंचाने वाले comment के भी यही क्रम बिगड़ सकता है। agent पुरानी documentation से endpoint का अंदाजा लगा सकता है, error response से URL कॉपी कर सकता है या सही credential के 403 लौटाने पर मिलता-जुलता credential चुन सकता है। planner के लिए ये सामान्य recovery behavior हैं। सुरक्षा डिजाइन को इनकी उम्मीद रखनी चाहिए और recovery attempt को मूल grant के भीतर रखना चाहिए।

तुलना से पहले canonicalization जरूरी है। percent-encoded path segment को एक लिखे हुए नियम से decode करें, allowed prefix से बाहर जाने वाले dot segment रोकें, effective port normalize करें और तय करें कि API repeated query names को कैसे समझता है। अगर policy /v2/issues/%2e%2e/admin को issue path माने और server उसे /v2/admin हल करे, तो दोनों अलग resource अधिकृत कर रहे हैं। हर intermediary की व्याख्या का अंदाजा लगाने के बजाय ambiguous form ठुकराएं।

credential injection यह सब होने के बाद और transmission के जितना पास हो सके, वहीं होनी चाहिए। canonical request बनाएं, अधिकृत करें, approval digest बांधें, approved connection खोलें, फिर trusted executor secret जोड़े। injection के बाद middleware host, method या body बदल सकता हो तो उसके output को authorization में शामिल करें या उससे rewrite की आजादी हटाएं।

विफलता का रास्ता भी बंद होना चाहिए। चुने credential को 401 या 403 मिले तो वही result agent को लौटाएं, vault की हर entry अपने आप न आजमाएं। credential fallback छोटी failure को privilege discovery बना देता है। अगला प्रयास दूसरे credential को स्पष्ट रूप से नाम दे और उसकी authority तथा account context के साथ नया decision पास करे।

upstream error message भी data है। API अक्सर URL, operation name या सुझाया retry action वापस देते हैं। planner उस text से अगली call बनाए, यह उचित है, लेकिन approved host से आने भर से text को authority नहीं मिलती। अगला request फिर वही destination और request checks पास करेगा।

इस behavior को अलग-अलग request के बजाय sequence की तरह test करें। allowed read से शुरू करें, crafted redirect या error suggestion लौटाएं, planner को follow-up बनाने दें और देखें कि session reuse सीमा न बढ़ाए। फिर intended credential fail करें और verify करें कि executor silent fallback से इनकार करता है। ये test permission inheritance पकड़ते हैं जिसे single policy match की साधारण unit test छोड़ सकती है।

लॉग में फैसला और कॉल दोनों दर्ज होने चाहिए

घटना की जांच के लिए टूल invocation लॉग बहुत मोटे होते हैं। केवल यह दर्ज करना कि एजेंट ने http_request कॉल किया था, मुख्य सवालों को छोड़ देता है: कौन सा क्रेडेंशियल लगा, अनुरोध कहां गया, कौन सा ऑपरेशन मंजूर हुआ और भेजा गया अनुरोध मंजूर अनुरोध से मिला या नहीं।

session या process identity, tool call identifier, credential identifier, canonical destination, resolved address, method, redacted request summary, policy version, approval identity, action digest, response status, समय और अंतिम परिणाम दर्ज करें। secret bytes और संवेदनशील response body को सामान्य log से बाहर रखें। सबूत के लिए जरूरी field का digest रखें या अलग access control में encrypt करें।

सफलता के साथ इनकार भी log करें। private address या दूसरे host पर बार-बार ठुकराए प्रयास किसी बाहरी असर से पहले prompt injection या खराब planner दिखा सकते हैं। policy denial, user denial, network failure, upstream rejection और local cancellation अलग रखें ताकि responder failed connection को blocked action न समझे।

सबूत को कार्रवाई करने वाला एजेंट आसानी से न बदल सके। append-only storage, सीमित writer और integrity check से workstation या process पर सवाल उठने के बाद भी रिकॉर्ड काम आता है। Sallyport एक write-blind encrypted, hash-chained audit log से agent session और अलग-अलग call दर्ज करता है, और sp audit verify बिना key के ciphertext chain को offline जांचता है। वह API और SSH credential encrypted vault में रखता है और secret सामग्री एजेंट को दिए बिना खुद कार्रवाई करता है।

बहुत खुला अनुदान एक्जीक्यूटर पर बदलें

आप generic HTTP interface रख सकते हैं, बिना generic authority रखे। credential injection और enforcement विश्वसनीय executor में ले जाएं, फिर model से बिना credential वाला request और opaque credential reference लें।

काम का migration काल्पनिक call नहीं, असली call की सूची से शुरू होता है। हाल के request को credential, origin, method और operation से group करें। ऐसे broad credential और destination जिन्हें कभी साथ इस्तेमाल नहीं किया गया, अलग किए जा सकते हैं। एक body में कई destructive mode रखने वाले route को अपने request constraint या upstream credential चाहिए।

फिर मौजूदा traffic को report-only evaluation में रखें। हर request canonicalize करें, destination resolve करें और दिखाएं कि proposed grant उसे allow करेगा या deny, लेकिन अभी execution न बदलें। unexpected match देखें। issue read की अनुमति जैसा rule shared host से export, deleted record या दूसरे tenant को भी जाने दे सकता है।

इसके बाद आसान सीमाएं पहले लागू करें: executor-owned credential, exact HTTPS origin, कोई automatic redirect नहीं, explicit method और private address का denial, जब तक किसी खास integration को उसकी जरूरत न हो। high-impact operation पर path, query, header और body constraint जोड़ें। escape path रखें जिसमें साफ per-call approval और अलग दिखने वाला audit entry बने, पुराने unrestricted tool पर चुपचाप वापस न जाएं।

अंत में known-good request के mutation से boundary test करें। host suffix, port, DNS answer, redirect target, credential reference, method, content type, tenant field, operation field और encoded path बदलें। हर mutation intentional grant से मिले या credential लगने से पहले fail हो। यह भी test करें कि logged, approved और sent bytes में एक ही action digest हो।

टूल सूची अब भी एजेंट को समझदार ऑपरेशन चुनने में मदद करती है। वह केवल authorization खत्म करने की जगह नहीं है। developer को सुविधाजनक call surface पसंद हो तो रखें, लेकिन हर network effect को तभी permission मिले जब credential, destination, method और request details सब मालूम हों।