AI red teaming
कोपायलट, चैटबॉट और एजेंट अब व्यवसाय के भीतर एक काम करती परत हैं, और कई टीमें उन्हें अब भी साधारण ऐप की तरह सुरक्षित करती हैं। वे साधारण नहीं हैं। AI red teaming पूरे AI सिस्टम को विरोधात्मक रूप से परखता है, सिर्फ़ मॉडल को नहीं, ताकि पता चले कि उसे असल में क्या कराया जा सकता है। यहाँ देखें इसका अर्थ और परीक्षण का तरीक़ा।
यह क्या है
AI red teaming किसी AI-सक्षम सिस्टम का विरोधात्मक परीक्षण है: जानबूझकर उसे वैसे ही छेड़ना जैसे कोई हमलावर करेगा, यह देखने के लिए कि उसे किस ओर धकेला जा सकता है। जो शब्द मायने रखता है वह है सिस्टम। लक्ष्य सिर्फ़ भाषा मॉडल नहीं, बल्कि उसके इर्दगिर्द का सब कुछ है——रिट्रीवल परत, प्रॉम्प्ट शृंखला, जिन टूलों को वह बुला सकता है, जो मेमोरी वह रखता है, और जिन अनुमतियों से वह कार्य करता है।

यह मॉडल-सुरक्षा मूल्यांकन से अलग अभ्यास है, जो पूछता है कि मॉडल असुरक्षित टेक्स्ट बनाता है या नहीं। AI red teaming एक तीखा सवाल पूछता है: इस जीवित परिवेश में, इन एकीकरणों और इन अनुमतियों के साथ, सिस्टम को छेड़कर असल में क्या कराया जा सकता है?
पारंपरिक AppSec क्यों कम पड़ता है
पारंपरिक एप्लिकेशन सुरक्षा अपेक्षाकृत पूर्वानुमेय सीमाएँ मानती है: इनपुट आता है, कोड उसे संसाधित करता है, आउटपुट जाता है। जटिल सॉफ़्टवेयर भी इतना परिबद्ध रहता था कि परिचित नियंत्रणों से उस पर तर्क किया जा सके——कोड समीक्षा, स्कैनिंग, मैनुअल परीक्षण, नीति-प्रवर्तन।
AI-सक्षम ऐप इस मॉडल को तोड़ते हैं, क्योंकि व्यवहार अब टूल, रिट्रीवल, मेमोरी और प्रत्यायोजित अनुमतियों पर निर्भर करता है:
- कोई चैटबॉट किसी ज्ञान-आधार से जानकारी खींच सकता है।
- कोई कोपायलट कई आंतरिक सिस्टमों से डेटा संश्लेषित कर सकता है।
- कोई LLM ऐप निर्देशों की व्याख्या कर, API बुला, और निचले वर्कफ़्लो को ट्रिगर कर सकता है।
- कोई एजेंट मेमोरी रखते और प्रत्यायोजित पहुँच से कार्य करते हुए ये सब कर सकता है।
इसीलिए LLM और एजेंटिक ऐप के लिए OWASP सूचियों जैसे ढाँचे अस्तित्व में हैं: ये सिस्टम ऐसे जोखिम ढोते हैं——टूल दुरुपयोग, पहचान व विशेषाधिकार का दुरुपयोग, मेमोरी-विषाक्तन——जिन्हें पुरानी AppSec सोच पूरी तरह नहीं पकड़ती।
सिर्फ़ मॉडल नहीं

सुरक्षा नेताओं को जो विचार सबसे अधिक आत्मसात करना चाहिए: हमलावर को आम तौर पर मॉडल को हराना नहीं पड़ता। अक्सर उसे मॉडल का किसी स्पष्ट तरीक़े से बिगड़ना भी नहीं चाहिए। उसे बस इर्दगिर्द के सिस्टम का दुरुपयोग करना है——रिट्रीवल परत, प्रॉम्प्ट शृंखला, निष्पादन पथ, अनुमति मॉडल, मेमोरी, या वह एप्लिकेशन लॉजिक जो आउटपुट को क्रिया में बदलता है।
AI सिस्टम ठीक इसलिए आक्रमण-सतह का हिस्सा बन रहे हैं क्योंकि वे डेटा, भरोसे, स्वचालन और क्रिया के संगम पर बैठते हैं। स्कैनर शायद कोई कोड बग ढूँढ ले। मॉडल रेड-टीम शायद कोई असुरक्षित आउटपुट पकड़ ले। इनमें से कोई नहीं बताता कि चलते परिवेश में हमलावर आद्योपांत क्या कर सकता है——और उसी दरार में असली उजागरता बसती है।
बुरे आउटपुट से बुरे नतीजे तक
AI जोखिम को “प्रॉम्प्ट इंजेक्शन” तक सीमित करना इसका सिर्फ़ एक हिस्सा पकड़ता है। किसी उद्यम में, छेड़ा गया संदर्भ छेड़े गए व्यवहार की ओर ले जाता है, जो डेटा उजागरता, टूटे प्राधिकरण, असुरक्षित टूल उपयोग और वर्कफ़्लो दुरुपयोग की ओर ले जाता है। मुद्दा अब बुरा आउटपुट नहीं, बुरा नतीजा बन जाता है।
ये प्रोडक्शन AI सिस्टमों में पहचाने जा सकने वाले, बार-बार लौटने वाले विफलता-प्रतिरूप हैं:
- किसी कोपायलट के विरुद्ध प्रत्यक्ष प्रॉम्प्ट इंजेक्शन।
- सिस्टम जो पढ़ता है, उस अंतर्निहित या तृतीय-पक्ष सामग्री के ज़रिए अप्रत्यक्ष इंजेक्शन।
- सिस्टम प्रॉम्प्ट या संवेदनशील निर्देशों का रिसाव।
- किसी साझा AI ऐप के ग्राहकों के बीच क्रॉस-टेनेंट डेटा उजागरता।
- टूल-निष्पादन शृंखलाओं के ज़रिए विशेषाधिकार वृद्धि।
- AI-जनित व्यापार-लॉजिक में टूटा प्राधिकरण, और AI-सहायित विकास के दौरान उजागर हुए आंतरिक API।
इनमें से किसी को भी कार्टूनी अर्थ में मॉडल के “जेलब्रेक” होने की ज़रूरत नहीं। ये नई सतह ओढ़े साधारण सुरक्षा-विफलताएँ हैं।
परीक्षण असल में क्या माँगता है
सार्थक AI red teaming सतत है और पूरे निष्पादन पथ को ढकता है——इनपुट संचालन, रिट्रीवल, मेमोरी, टूल, अनुमतियाँ, व्यापार-लॉजिक और निचले वर्कफ़्लो——क्योंकि यही एकमात्र तरीक़ा है यह बताने का कि कोई कमज़ोरी महज़ दिलचस्प है या सचमुच शोषण-योग्य।
इसका अर्थ है पूरी शृंखला का पीछा करना: क्या प्रॉम्प्ट छेड़छाड़ व्यवहार बदल सकती है; क्या बदला व्यवहार किसी टूल को ट्रिगर कर सकता है; क्या वह टूल उपयोग किसी सीमा को पार करता है; और क्या नतीजा असली व्यापार-जोखिम रचता है। यह शोषण-क्षमता का परीक्षण है, स्थैतिक विश्लेषण या मॉडल-मूल्यांकन अंक नहीं। और चूँकि प्रॉम्प्ट, मॉडल, एकीकरण और वर्कफ़्लो रोज़ बदलते हैं, एक-बारगी मूल्यांकन लगभग तुरंत बासी हो जाता है——परीक्षण को गति बनाए रखनी होती है।
पूछने लायक सवाल
इसलिए किसी सुरक्षा नेता के लिए उपयोगी सवाल यह नहीं कि कोई AI सिस्टम अमूर्त रूप से “सुरक्षित” है या नहीं। वह परिचालनात्मक है, और वही समूह है जिसे हमलावर सबसे पहले परखेगा:
- क्या किसी चैटबॉट को प्रतिबंधित जानकारी उगलवाने के लिए छेड़ा जा सकता है?
- क्या कोई कोपायलट किसी टेनेंट सीमा को पार कर सकता है?
- क्या किसी एजेंट को ऐसी कार्रवाई की ओर धकेला जा सकता है जो संगठन ने कभी नहीं चाही?
ईमानदार ढाँचा विनम्र है: AI एक जीवित परिचालन परत है——कुछ सॉफ़्टवेयर, कुछ निर्णय-इंजन, कुछ संचालक। सबसे मज़बूत स्थिति में वे टीमें होंगी जो न अपनाने को धीमा करती हैं, न इसे “बस एक और फ़ीचर” मानती हैं; बल्कि वे जो इस परत में इतना साफ़ देख पाती हैं कि जान सकें इसे क्या कराया जा सकता है, और जो इसके बदलते रहने पर इसे लगातार जाँचती रहती हैं।
CyberStrike एक AI-संवर्धित पेनिट्रेशन टेस्टिंग प्लेटफ़ॉर्म है, फ़िलहाल अर्ली एक्सेस में। प्लेटफ़ॉर्म पर AI red teaming देखें या प्रतीक्षा-सूची में जुड़ें।
इसके पीछे का परीक्षण-मॉडल भी?