Base URL, API कुंजी और मॉडल ID देकर 84 मानक जाँच चलाएँ। 2 वैकल्पिक जाँच के साथ अधिकतम 86 जाँच होती हैं। रिपोर्ट मॉडल पहचान, टोकन गणना, Prompt Injection, सप्लाई-चेन जोखिम और स्ट्रीमिंग जाँचती है।
किसी ग्राहक ने गलत सवाल पूछा, तो ब्लॉक होती है आपकी API key। हर अनुरोध पहले BazaarLink की content review से गुजरता है; high-risk सवाल सीधे रुक जाते हैं और upstream तक पहुँचते ही नहीं, जिससे उल्लंघनकारी सामग्री के कारण आपका खाता ब्लॉक होने का जोखिम काफी कम होता है।
BYOK के बारे में जानें →एक API key. नोड सीमा पर पहुँचे, जवाब न दे या डिस्कनेक्ट हो जाए तो अनुरोध दूसरा उपलब्ध स्रोत आज़मा सकता है; उपलब्ध न हो तो त्रुटि लौटती है। आपके अपने नोड से संभाले गए ट्रैफ़िक पर BazaarLink शुल्क नहीं लेता।
पूरी installation guide →हम किसी एंडपॉइंट से यह नहीं पूछते कि वह कौन-सा मॉडल है — कोई भी एंडपॉइंट कोई भी नाम बता सकता है। हम 84 मानक जाँचें भेजकर उससे असल काम कराते हैं, और फिर उसके काम करने के ढंग की तुलना जाने-पहचाने मॉडलों के आधार-चिह्नों से करते हैं। निर्णय पाँच चरणों में होता है, मोटे से बारीक की ओर, और हर चरण को यह कहने की छूट है कि प्रमाण पर्याप्त नहीं हैं और वह निर्णय नहीं देगा।
क्या इस एंडपॉइंट को नापा भी जा सकता है?
निर्णय की पहली शर्त यह है कि प्रश्नों के उत्तर सचमुच मिले हों। छूटे हुए उत्तर केवल कम आँकड़े नहीं होते: जो उत्तर मिले, वे संयोग से एक ही ओर झुके हो सकते हैं, और वह प्रमाण नहीं, प्रतिचयन-पूर्वाग्रह है।
यदि एंडपॉइंट उत्तर ही न दे, या कुंजी अथवा मॉडल का नाम ही काम न करे, तो हम वहीं रुक जाते हैं और बचे-खुचे टुकड़ों से निष्कर्ष नहीं गढ़ते।
यह मॉडल किसका बनाया हुआ है?
सबसे आम अदला-बदली परिवारों के आर-पार होती है: सस्ता मॉडल महँगे नाम में। परिवार-स्तर का व्यवहार सबसे स्थिर होता है और उसकी नकल सबसे कठिन है, इसलिए हम यह परत पहले पूछते हैं। हम उत्तरों की शैली और आदतों की तुलना करते हैं, उसके अपने दावे की नहीं; पूरी रिपोर्ट में स्वयं का दावा ही सबसे आसानी से गढ़ा जा सकता है।
पर्याप्त पारिवारिक प्रमाण न हो तो हम मौन रह जाते हैं, ज़बरदस्ती नाम नहीं लेते। जब एंडपॉइंट चीनी में एक निर्माता का नाम ले और व्यवहार किसी और जैसा हो, तो हम उस दावे को ज़ुबान की फिसलन मानते हैं और व्यवहार के प्रमाण पर लौट आते हैं। स्वयं के दावे को हटाने के बाद का ‘व्यवहार कॉलम’ केवल सहायक प्रमाण है: अकेला यही कॉलम दावे से अलग हो, तो उसे कभी जालसाज़ी नहीं माना जाता।
उसी परिवार के भीतर यह कौन-सा मॉडल है?
आपने एक निश्चित मॉडल खरीदा है, उस निर्माता का कोई भी मॉडल नहीं। जिसे लोग गुणवत्ता गिरना कहते हैं, वह प्रायः इसी परत पर होता है: परिवार वही रहता है और उसकी जगह सस्ता सहोदर ले लेता है। हम परिवार के भीतर की तुलना और परिवारों के बीच की तुलना साथ-साथ चलाते हैं और दोनों से एक-दूसरे की जाँच कराते हैं — परिवार एक बार गलत बैठे, तो भीतर की तुलना बड़े आत्मविश्वास से गलत मॉडल का नाम देगी। निर्णय करते समय हम पहले उस निकट-संबंधी समूह से तुलना करते हैं जिसमें दावा किया गया मॉडल आता है, और मेल पर्याप्त अच्छा हो तभी उसे मानते हैं; फिर उस मेल की तुलना दूसरे परिवारों के समूहों से करते हैं — किसी दूसरे समूह का मेल साफ़ तौर पर बेहतर हो, तभी इसे अदला-बदली कहते हैं। दावा किए गए मॉडल का बेसलाइन न हो तो हम आरोप नहीं लगाते।
जब प्रमाण केवल परिवार-स्तर तक पहुँचें, तो रिपोर्ट यही स्पष्ट लिखती है कि निर्माता पहचाना गया, मॉडल नहीं। हम सबसे मिलते-जुलते उम्मीदवार से खाली जगह नहीं भरते।
पिछले चरण ने जो मॉडल चुना, क्या वह अपने निकटतम सहोदरों से सचमुच अलग किया जा सकता है?
कुछ मॉडल जुड़वाँ होते हैं: शैली, क्षमता और वाक्य-आदतें इतनी अधिक मिलती हैं कि पिछले चरण में उनके बीच लगभग कोई भेद-क्षमता नहीं बचती, और अंक पास-पास आ जाते हैं बिना उस निकटता का कोई अर्थ हुए। यह चरण एक ही काम करता है: ऐसे निकट-संबंधी समूहों के लिए वह उसी तुलना हेतु बने अलग प्रश्न-समूह से दोबारा प्रतिदर्श लेता है और किसी एक उत्तर के बजाय पूरा वितरण पढ़ता है। पास हुआ तो पिछला चरण या तो पक्का होता है या पलट जाता है; न हुआ तो पिछले चरण का परिणाम बना रहता है।
इस चरण में एक जानबूझकर रखी गई असमानता है: यदि प्रमाण निर्णायक न हों और पिछले चरण का परिणाम संयोग से विक्रेता के दावे से मेल खाता हो, तो हम उसे नहीं पलटते। ईमानदार विक्रेता पर झूठा आरोप लगाने की कीमत, एक बेईमान को चूक जाने से अधिक है।
मापा हुआ परिणाम विक्रेता के दावे से कहाँ अलग है?
पहचानने की प्रक्रिया स्वयं विक्रेता के दावे को नहीं देखती — पिछले चरण केवल व्यवहार के प्रमाणों की तुलना करते हैं। दावा ठीक दो जगह आता है: जब चौथा चरण यह तय करता है कि पलटना है या नहीं, और यहाँ। यह क्रम जानबूझकर है — प्रश्न पढ़ने से पहले उत्तर निकाल लेने पर दावा आपको खींच नहीं सकता। निष्कर्ष होते हैं: पूर्ण मेल, केवल परिवार का मेल, सही परिवार में गलत मॉडल, मॉडल बदला गया, स्वयं का दावा गढ़ा गया, व्यवहार प्रेरित किया गया, आँकड़े अपर्याप्त, और अनिर्णीत।
जब संकेत आपस में टकराएँ और कोई स्थिर बहुमत न बने, तो निष्कर्ष अनिर्णीत होता है। यह एक विधिवत निष्कर्ष है, कोई खराबी नहीं।
क्योंकि दोनों दिशाओं की भूल की कीमत बराबर नहीं है। किसी ईमानदार रिले पर मॉडल बदलने का आरोप लगाना एक अभियोग है और उससे असली लोगों को असली नुकसान होता है; दूसरी ओर एक बार चूक जाने पर आप दोबारा जाँच सकते हैं या उसका इतिहास देख सकते हैं। इसलिए जब प्रमाण पतले हों, हम निर्णय न देना चुनते हैं।
कोड में इसका ठोस रूप है: रिपोर्ट मॉडल के मेल न खाने की बात तभी दिखाती है जब दावा किए गए मॉडल का बेसलाइन हो और फ़िंगरप्रिंट का प्रमाण अदला-बदली का समर्थन करे; बेसलाइन-रहित दावे पर कभी आरोप नहीं लगता। सबसे मिलता-जुलता मॉडल संयोग से दावे से अलग निकले, तो उसे कभी आरोप की तरह नहीं दिखाया जाता — वह केवल हमारा अनुमान है। जब आपको अनिर्धारित दिखे, तो सही पाठ यही है कि इस बार के प्रमाण निर्णय के लिए पर्याप्त नहीं हैं। यह न तो निर्दोषता का प्रमाणपत्र है, न दोषसिद्धि।
ये वे सीमाएँ हैं जिन्हें हम जानते हैं। हम इन्हें लिखते हैं क्योंकि अपनी सीमाएँ छिपाने वाली रिपोर्ट पर लोग उससे अधिक भरोसा कर बैठते हैं जितनी वह हकदार है।
एक जाँच एक प्रतिदर्श है। कोई रिले अपने ट्रैफ़िक के केवल एक हिस्से पर मॉडल बदल सकता है, या जब भी ट्रैफ़िक जाँच जैसा दिखे तब असली माल दे सकता है। एक बार पास होना लंबे समय की ईमानदारी नहीं है — नियमित अंतराल पर दोबारा जाँचिए, और किसी एक रिपोर्ट के बजाय उसका इतिहास पढ़िए।
जब नकल करने वाला जानबूझकर आधे से अधिक व्यवहार की नकल करता है, तो लगभग आधे प्रमाण संरचनात्मक रूप से दावा की गई पहचान की ओर ही इशारा करते हैं। यह प्रश्नों की कमी नहीं, एक संरचनात्मक सीमा है — हमने इसे नापा है: प्रश्न बढ़ाने पर लागत तेज़ी से बढ़ी और भेद-क्षमता लगभग नहीं हिली।
मेल का निर्णय यह कहता है कि इस बार के प्रमाण अदला-बदली का समर्थन नहीं करते, यह नहीं कि अदला-बदली हुई ही नहीं। जो भी जाँच दूसरी बात की गारंटी का दावा करे, वह अपना बखान कर रही है।
निर्णय का मार्ग बाद में संचित आँकड़ों से पुनर्निर्मित किया जाता है; इंजन उस समय यह दर्ज नहीं करता कि उसने कौन-सा नियम लिया। कुछ शाखाएँ ऐसा कोई विशिष्ट चिह्न नहीं छोड़तीं जिससे उन्हें पहचाना जा सके, और वहाँ हम केवल परिणाम दिखाते हैं, नियम की संख्या नहीं लिखते। अनुमान लगाने से कम कहना बेहतर है।
उत्तर इस जाँच की baseline और सुरक्षा सीमा पूरी करता है।
संकेत अधूरा या सीमा के पास है; विवरण और मूल उत्तर देखें।
Baseline अंतर, protocol त्रुटि या अखंडता जोखिम की पुष्टि हुई है।
दावा किए गए मॉडल से family fingerprint, submodel गुण और anti-spoofing संकेत मिलाए जाते हैं।
Token संख्या, SSE framing, latency और response संरचना में बढ़ोतरी या relay त्रुटि खोजी जाती है।
System Prompt injection, secret leakage, dependency hijacking और signature tampering की जाँच होती है।
यह Probe arXiv 2604.08407 में वर्णित 3 प्रमुख relay-attack श्रेणियों — dependency hijacking, conditional System Prompt injection और credential exfiltration — का पता लगाती है। यह पहचान के प्रमाण और व्यवहार चेतावनियाँ दिखाती है; सुरक्षा स्कोर नहीं देती।
The proxy modifies tool-call or text content during response parsing, causing the agent to execute attacker-specified operations. Common tactics include tampering with npm/pip/go/cargo install commands, injecting typosquatting packages, and rewriting shell command parameters. Detection compares the proxy's response to direct-connect tool-call payloads to surface silent rewrites.
The proxy conditionally injects a system message based on prompt content — malicious instructions for requests containing sensitive terms like "bank", "password", or "transfer", silence for everything else. The skew shows up statistically. Detection uses Proxy Monitor to compare the system-prompt offset between baseline and the relay under test.
The proxy silently scans both requests (request) and responses (response) for API keys, access tokens, personal data, and trade secrets. Because the content itself is not modified, generic diff tools miss it. Detection injects a honeypot token and verifies whether it surfaces in proxy logs, Telegram bots, or external endpoints.
Suite में 84 मानक और 2 वैकल्पिक जाँच हैं, अधिकतम 86। वैकल्पिक जाँच तभी चलती हैं जब setting और endpoint क्षमता अनुमति दें।
यह model family, submodel fingerprint, ज्ञान और क्षमता के संकेत तथा self-claim हटाने के बाद व्यवहार की तुलना करता है। एक कमजोर संकेत को प्रमाण नहीं माना जाता।
API कुंजी केवल आपकी माँगी जाँच के लिए उपयोग होती है और रिपोर्ट या सार्वजनिक लिंक में नहीं दिखाई जाती। कम सीमा वाली, वापस ली जा सकने वाली test key इस्तेमाल करें।
ज़रूरी नहीं। इसका अर्थ प्रमाण अधूरा या असामान्य है। विवरण और मूल उत्तर देखें; मजबूत mismatch के लिए कई एक-जैसे संकेत चाहिए।