क्या IDE एक्सटेंशन होस्ट की पहचान किसी एजेंट की पहचान साबित कर सकती है?

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

यह बात तब महत्वपूर्ण हो जाती है जब कोई AI कोडिंग एजेंट IDE के ज़रिए चलता है। होस्ट कई एक्सटेंशन लोड कर सकता है, वर्कस्पेस से कमांड ले सकता है और काम ऐसे गेटवे को सौंप सकता है जो किसी API या SSH टारगेट तक पहुंच रखता हो। अगर गेटवे होस्ट को एक बार मंज़ूरी देकर उसे किसी खास एक्सटेंशन की मंशा का सबूत मान लेता है, तो वह उपलब्ध सबूत से ज्यादा अधिकार दे देता है।

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

होस्ट सिग्नेचर कंटेनर की पहचान करता है, उसके भीतर मौजूद लोगों की नहीं

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

यह साबित नहीं करता कि «उस प्रक्रिया के भीतर किस एक्सटेंशन फ़ंक्शन ने अनुरोध किया?» किसी सीमा पर एक प्रक्रिया की एक ही एक्जीक्यूटेबल पहचान होती है। अगर कोई एडिटर एक्सटेंशन होस्ट शुरू करता है और होस्ट दस प्लगइन लोड करता है, तो कर्नेल उनके JavaScript, बाइटकोड, कॉलबैक या एक्सटेंशन API कॉल के लिए दस अलग कोड-साइनिंग पहचान नहीं बनाता।

इस अंतर का व्यावहारिक असर पड़ता है। गेटवे ऐसा बचाव योग्य रिकॉर्ड बना सकता है:

caller executable: /Applications/Editor.app/.../extension-host
signing authority: Example Software Team ID ABC123
process id: 8421
parent process: Editor.app pid 8304

लेकिन केवल सिग्नेचर से वह यह हासिल नहीं कर सकता:

extension: publisher.cloud-deploy
command: deployCurrentProject
prompt source: chat request 18

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

लोग अक्सर दोनों को «पहचान» कहते हैं और फिर लागू करते समय यह अंतर खो देते हैं। ऐसा न करें। साइनर बताता है कि बॉक्स किसने बनाया। यह नहीं बताता कि नियंत्रणों तक पहुंचने वाला यात्री कौन था।

साझा एक्सटेंशन होस्ट कई प्राधिकरणों को एक में मिला देते हैं

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

मान लीजिए कोई गेटवे एडिटर के सिग्नेचर की जांच के बाद HTTPS कॉल की अनुमति देता है। एक्सटेंशन A होस्ट से डिप्लॉयमेंट एंडपॉइंट कॉल करने को कहता है। एक्सटेंशन B के पास ऐसी एक्सटेंशन API है जिससे वह उसी होस्ट को बाहर की ओर काम करने के लिए प्रेरित कर सकता है, शायद सीधे और शायद A द्वारा रजिस्टर की गई कमांड के ज़रिए। गेटवे पर दोनों अनुरोध एक ही प्रक्रिया पहचानकर्ता और साइनिंग अथॉरिटी के साथ पहुंचते हैं। होस्ट सिग्नेचर की जांच करके गेटवे दोनों को अलग नहीं कर सकता।

जब एक्सटेंशन साझा होस्ट सेवाओं के ज़रिए संवाद करते हैं, तो अस्पष्टता और बढ़ जाती है। कोई प्लगइन एक कमांड रजिस्टर कर सकता है और दूसरा उसे चला सकता है। चैट एक्सटेंशन किसी रिपॉजिटरी फ़ाइल, इश्यू बॉडी या चिपकाए गए टर्मिनल परिणाम से निर्देश लेकर फिर कमांड भेज सकता है। अब स्रोत-संदर्भ की कई परतें हैं: हस्ताक्षरित होस्ट, कॉल करने वाला एक्सटेंशन, इनपुट देने वाला एक्सटेंशन और वह व्यक्ति या अविश्वसनीय सामग्री जिसने इसे प्रभावित किया।

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

एक्सटेंशन नाम तभी स्रोत-संदर्भ है जब होस्ट उसे अनुरोध से बांधे

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

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

उपयोगी जांच सरल है। पूछें कि हर फ़ील्ड कहां से आया और उसे कौन बदल सकता था।

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

सत्र मंज़ूरी की उपयोगी सीमा और स्पष्ट सीमा है

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

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

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

सत्र मंज़ूरी का इस्तेमाल उसी सवाल के लिए करें जिसका वह जवाब दे सकती है: «क्या यह हस्ताक्षरित होस्ट प्रक्रिया, जब तक चल रही है, इस श्रेणी की पहुंच इस्तेमाल कर सकती है?» इसे बदलकर यह सवाल न बना दें: «क्या यह खास एक्सटेंशन यह खास अपरिवर्तनीय कार्रवाई कर सकता है?»

प्रति-इस्तेमाल मंज़ूरी सही समय पर अस्पष्टता की भरपाई करती है

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

मान लीजिए कोई होस्ट स्थानीय एक्शन गेटवे को यह अनुरोध भेजता है:

{
  "channel": "http",
  "credential": "production-deploy",
  "method": "POST",
  "url": "https://deploy.example.internal/releases",
  "body": {"service": "billing", "version": "a1b2c3d"}
}

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

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

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

सीमित क्रेडेंशियल सही मंज़ूरी के नुकसान को घटाते हैं

मंज़ूरी क्रेडेंशियल के दायरे का विकल्प नहीं है। कोई व्यक्ति सही होस्ट और सही अनुरोध को मंज़ूरी दे सकता है, फिर भी पता चल सकता है कि क्रेडेंशियल इच्छित कार्रवाई से कहीं अधिक अनुमति देता है। यह क्रेडेंशियल डिज़ाइन की विफलता है, मंज़ूरी की नहीं।

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

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

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

एक परिचित विफलता हानिरहित कमांड पैलेट कार्रवाई से शुरू होती है

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

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

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

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

ऑडिट रिकॉर्ड में सबूत का कॉलम चाहिए, मनभावन कहानी नहीं

जब लॉग सत्यापित तथ्यों और खुद बताए गए संदर्भ को एक ही वाक्य में मिला देते हैं, तो वे भ्रामक बन जाते हैं। «प्लगइन X ने सेवा Y को डिप्लॉय किया» सटीक लगता है, लेकिन इसमें बिना सत्यापित प्लगइन लेबल और अज्ञात कारण-श्रृंखला छिपी हो सकती है। कच्ची घटना को उसके सत्य-स्रोत के साथ दर्ज करें।

घटना का एक उपयोगी रूप इन दावों को अलग रखता है:

{
  "time": "2026-07-24T10:16:43Z",
  "caller": {
    "signing_authority": "Example Software Team ID ABC123",
    "pid": 8421,
    "started_at": "2026-07-24T09:58:03Z"
  },
  "host_reported_context": {
    "extension_id": "publisher.cloud-deploy",
    "workspace": "/work/payments"
  },
  "action": {
    "channel": "http",
    "method": "POST",
    "destination": "https://deploy.example.internal/releases",
    "credential": "production-deploy"
  },
  "authorization": {
    "session_approved": true,
    "per_use_approved": true
  }
}

मुद्दा लॉग में और ज्यादा फ़ील्ड जोड़ना नहीं है। मुद्दा उस सीमा को बनाए रखना है जो सिस्टम द्वारा सत्यापित तथ्य और होस्ट द्वारा दिए गए बयान के बीच है। किसी घटना के दौरान यही अंतर तय करता है कि जांचकर्ता कार्रवाई का पता लगा सकते हैं या केवल एक लेबल दोहरा सकते हैं।

छेड़छाड़ का सबूत भी महत्वपूर्ण है। जिस स्थानीय जर्नल को समझौता की गई प्रक्रिया फिर से लिख सकती है, वह उसके अपने व्यवहार के बारे में कमजोर सबूत है। Sallyport एन्क्रिप्टेड, हैश-चेन वाले ऑडिट लॉग से सत्र और गतिविधि दृश्य तैयार करता है, और sp audit verify वॉल्ट कुंजी के बिना ऑफलाइन चेन की जांच कर सकता है। इससे एक्सटेंशन की पहचान की समस्या हल नहीं होती, लेकिन बाद में किए गए बदलाव को चुपचाप कहानी सुधारने से रोका जा सकता है।

जब पहचान बिल्कुल सटीक चाहिए, तो कार्रवाई को अलग करें

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

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

प्रक्रियाओं को अलग करना कोई जादुई समाधान नहीं है। अगर होस्ट हेल्पर को मनमाने अनुरोध भेज सकता है, तो वही अस्पष्टता बस नई प्रक्रिया में चली गई है। इंटरफ़ेस को उन विकल्पों को हटाना होगा जो होस्ट के पास नहीं होने चाहिए। अलग हस्ताक्षरित हेल्पर के साथ «कुछ भी चलाएं» जैसा खुला अनुरोध केवल दिखावा है।

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

मंज़ूरी की भाषा को पहुंच की सीमा का हिस्सा मानें

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

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

हर उस क्रेडेंशियल की सूची बनाकर शुरू करें जो IDE होस्ट से पहुंच योग्य है। हर क्रेडेंशियल के लिए लिखें कि वह सुरक्षित रूप से कौन-सी होस्ट-स्तरीय मंज़ूरी अपना सकता है, किस कार्रवाई के लिए नया निर्णय चाहिए और ऑडिट रिकॉर्ड कौन-सा सटीक सबूत सुरक्षित रखता है। अगर «यह किस एक्सटेंशन ने किया?» का जवाब अनुमान है, तो उसे तथ्य मानकर अधिकार न दें।