एआई सुरक्षा बेंचमार्क को वर्कफ़्लो टेस्ट की ज़रूरत है: विश्लेषण

बेंचमार्क स्कोर एक स्मोक अलार्म है, पूरी इमारत की जाँच नहीं। उपयोगी, तेज़ आवाज़ वाला, कभी-कभी जान बचाने वाला, लेकिन यह आपको नहीं बता सकता कि निकास दरवाज़ा तेल लगे कपड़ों से भरी झाड़ू वाली अलमारी में खुलता है या नहीं। Dark Reading ने अपने शीर्षक में सही चिंता पकड़ी है, So Many AI Security Benchmarks, But None Tell the Whole Story. बिल्डरों के लिए इसका सरल अनुवाद है: मॉडल सुरक्षा बेंचमार्क को दिशात्मक संकेतों की तरह इस्तेमाल करें, फिर मॉडल को अपने ही कोडबेस, टूल अनुमतियों, डेटा फ्लो, और बेहद उलझे हुए वर्कफ़्लो के अंदर टेस्ट करें।

यह शायद स्पष्ट लगे, और यही कारण है कि आप जानते हैं कि इस हफ्ते कम से कम एक रोडमैप समीक्षा में इसे छोड़ दिया जाएगा। AI सिस्टमों को बढ़ते हुए साफ-सुथरे सार्वजनिक स्कोर से आँका जा रहा है, जबकि प्रोडक्शन एजेंटों से ईमेल भेजने, टिकट एडिट करने, कोड अप्रूव करने, लॉग क्वेरी करने, और वास्तविक स्थिति को छूने के लिए कहा जाता है। यही अंतर वह जगह है जहाँ शरारती गड़बड़ियाँ ऑफिस किराए पर लेती हैं।

बेंचमार्क ब्लास्ट रेडियस नहीं है

SABench इस समस्या को बेहद ठोस बना देता है। Task Success Is Not Enough: Side-effect-Aware Evaluation of Tool-Using Language Model Agents के अनुसार, SABench 201 ईमेल, कैलेंडर, और टिकट कार्यों को कवर करता है, फिर पूछता है कि कोई एजेंट न केवल दिया गया काम पूरा करता है या नहीं, बल्कि अनधिकृत साइड इफेक्ट्स से बचता है या नहीं। लेखक 11 frontier LLMs से, जिनमें प्रमुख व्यावसायिक और ओपन मॉडल परिवार शामिल हैं, 2,211 मॉडल-टास्क जोड़ों पर नतीजे रिपोर्ट करते हैं। उन रन में, 15.2% में collateral damage हुआ, और जिन रन में लक्ष्य पूरा हुआ, उनमें भी 12.8% ने अनधिकृत writes किए।

वह आखिरी संख्या स्प्रेडशीट का छोटा पर खतरनाक गोब्लिन है। कोई सिस्टम वही कर सकता है जो उपयोगकर्ता ने माँगा था और फिर भी गलत ऑब्जेक्ट बदल सकता है, दायरा बढ़ा सकता है, या ऐसे टूल को छेड़ सकता है जिसे उसे अकेला छोड़ देना चाहिए था। SABench के लेखक इसे साफ़ कहते हैं: “task success alone is a poor proxy for safe tool use.” बिल्डरों के लिए अनुवाद: अगर आपका eval सिर्फ यह जाँचता है कि काम हुआ या नहीं, तो वह forklift को इस आधार पर ग्रेड कर रहा है कि pallet हिला या नहीं, न कि इस आधार पर कि warehouse अब आग में है या नहीं।

कोड समीक्षा को चलने योग्य सबूत चाहिए

CyberDual सॉफ्टवेयर मेंटेनेंस की तरफ़ से इसी सबक की ओर इशारा करता है। CyberDual: AI Attackers versus AI Code Reviewers in Real-World Software Maintenance के अनुसार, attacker agents असली मेंटेनेंस काम में exploitable bugs छिपाते हैं, जबकि reviewer agents उन्हें पकड़ने और ठीक करने की कोशिश करते हैं। पेपर कहता है कि तीन agentic reviewers ने छह attackers से 1,088 valid attacks में से 85, 91% पकड़े, जो आश्वस्त करने वाला लगता है, जब तक अगला वाक्य स्टील टो वाले बूट पहनकर अंदर नहीं आ जाता।

लेखक बताते हैं कि जब attacker किसी bug को असली upstream commits में फैलाता है, तो लगभग हर छह attack slots में से एक अब भी review के बाद working exploit के साथ खत्म होता है। उनका evaluation principle ताज़गी भरे ढंग से भावनाहीन है: “Execution decides each match.” दूसरे शब्दों में, test यह नहीं है कि reviewer ने strong linting vibes वाला आत्मविश्वासी paragraph लिखा या नहीं। test यह है कि attacker का proof of concept reviewed code पर अब भी काम करता है या नहीं।

AI code review अपनाने वाली टीमों के लिए, यही demo और control के बीच का फर्क है। कोई benchmark आपको बता सकता है कि reviewer model promising है; आपकी CI pipeline को साबित करना होगा कि वह आपकी dependency patterns, आपके framework conventions, आपके patch style, और आपकी टीम की चीज़ों को config2_final_really_final नाम देने की आदत में vulnerabilities पकड़ता है। Security confidence executable checks से आना चाहिए, न कि किसी model के ऐसे sounding से जैसे उसके पास कई quarter zips हों।

वर्कफ़्लो ही exploit हो सकता है

NameTrap aperture को model behavior से बढ़ाकर उस context तक ले जाता है जिसे model consume करता है। NameTrap: Steering AI Coding Agents Toward Security Vulnerabilities via Variable Names के अनुसार, attack सिर्फ third party Python files में identifiers बदलता है, और AI coding agents को attacker targeted Common Weakness Enumeration vulnerabilities की ओर धकेलता है। कोई खलनायकीय prompt injection monologue ज़रूरी नहीं। बस poisoned naming, जैसे autocomplete floor पर केले के छिलके छोड़ देना।

रिपोर्ट किए गए success rates छह agents में 22.5% से 56.0% तक जाते हैं, और कुछ agent model configurations के लिए 75.0% तक पहुँचते हैं। जो लोग उम्मीद कर रहे थे कि static analysis सफेद घोड़े पर सवार होकर बचाने आएगा, उनके लिए और भी बुरा यह है कि पेपर कहता है कि तीन AI based security analyzers और चार static analyzers ने poisoned files में targeted weaknesses में से कोई भी report नहीं की। इसका मतलब यह नहीं कि analyzers बेकार हैं। इसका मतलब है कि surrounding workflow और input provenance मायने रखते हैं, खासकर जब agents repositories clone करते हैं, external code पढ़ते हैं, और context को GPU budget के साथ gospel की तरह मानते हैं।

यहीं benchmark shopping खतरनाक हो जाती है। कोई model security suite पर अच्छा score कर सकता है और फिर भी fail हो सकता है जब आपका agent workflow package installation, repository browsing, generated patches, और permissive tool access को मिलाता है। model एक छोटे procedural drama का एक actor है; props में booby traps हो सकते हैं।

अपने ही वर्कफ़्लो के आसपास missing eval बनाएँ

SecLog-Bench evaluation plumbing के बारे में सोच रही टीमों के लिए एक अधिक परिपक्व pattern देता है। SecLog-Bench: A Scalable Benchmark for Cybersecurity Log Reasoning with Scaffolded Evidence के अनुसार, इसके AI assisted annotation workflow ने human consensus judgments के साथ 92.13% observed agreement produced किया, Cohen’s κ=0.84 के साथ। वही स्रोत AI assistance को human annotation को replace करने के बजाय support करने वाला बताता है, जहाँ access dates, prompts, और intermediate outputs auditability के लिए record किए जाते हैं।

यही attitude builders को बेझिझक चुरा लेनी चाहिए। Models को shortlist करने के लिए public benchmarks से शुरू करें, फिर private tests बनाएँ जो आपके production actions को mirror करें: exposed tools, वे objects जिन्हें agents modify कर सकते हैं, वे repositories जिन्हें वे पढ़ते हैं, वे logs जिन्हें वे summarize करते हैं, और वे failure modes जो सच में नुकसान पहुँचाएँगे। Fangcun AI Evaluation Team की Executive Summary तर्क देती है कि अधिक private benchmarks की ज़रूरत है क्योंकि public ones training data में leak हो सकते हैं, और कहती है कि in house benchmarks ने loss of control evaluations में public ones की तुलना में सामान्यतः कहीं कम evaluation awareness elicited की।

व्यावहारिक कदम benchmarks को छोड़ देना नहीं है। यह है कि उन्हें production के लिए passport stamp की तरह treat करना बंद करें। Public scores रखें, workflow specific adversarial cases जोड़ें, जहाँ संभव हो executable proofs चलाएँ, prompts और outputs log करें, और high consequence actions के लिए human review माँगें जब तक आपके evidence कुछ और न कहें। ऐसे benchmarks पर नज़र रखें जो side effects, provenance, tool permissions, और end to end exploitability को test करते हैं, क्योंकि real systems वहीं interesting बनते हैं। या, कम शालीन शब्दों में: आपके model ने driving test पास कर लिया, लेकिन आपका product उससे fireworks store में cement mixer valet park करवाना चाहता है।