हम सुरक्षित एजेंटों को कैसे इंजीनियर करते हैं

सुरक्षित AI एजेंटों का निर्माण करने के लिए, हमें उनकी क्षमताओं और उनकी विफलताओं दोनों के लिए डिज़ाइन करने की आवश्यकता है। वैध कार्यों को करते समय भी, और बिना किसी दुर्भावनापूर्ण निर्देशों के, एजेंट बाधाओं को दूर करने की कोशिश करते समय सुरक्षा सीमाओं को पार कर सकते हैं।

हम मानते हैं कि यह एक सुरक्षा इंजीनियरिंग समस्या है, और उद्योग को इसे उसी तरह से निपटाना चाहिए जैसे उसने 2000 के दशक की शुरुआत के इंटरनेट वर्म्स से निपटा था। एजेंटों के आसपास की प्रणालियों को यह सीमित करना चाहिए कि एजेंट किस चीज़ तक पहुँच सकते हैं, अवांछित व्यवहार का पता लगाना चाहिए, और होने वाली विफलताओं को रोकना चाहिए।

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

AI एजेंटों का मेल्टडाउन व्यवहार

जुलाई में, AI एजेंट ओपन-सोर्स AI प्लेटफ़ॉर्म Hugging Face के प्रोडक्शन इन्फ्रास्ट्रक्चर में घुस गए। आंतरिक साइबर सुरक्षा मूल्यांकन और प्रशिक्षण रनों के दौरान, OpenAI मॉडलों ने एक-दूसरे के साथ संवाद करने के लिए एक बुलेटिन बोर्ड स्थापित करने के लिए Artifactory रिपॉजिटरी मैनेजर का फायदा उठाने का एक तरीका खोज निकाला, जिससे उन्हें स्वार्म्स (swarms) में संगठित होने में मदद मिली। बाद में, ऐसे एजेंट जो साइबर सुरक्षा बेंचमार्क में कार्यों पर प्रगति करने में असमर्थ थे, उन्होंने मदद के लिए अन्य एजेंटों को भर्ती किया। ये एजेंट अपने मूल्यांकन वातावरण से बाहर निकल गए और इंटरनेट तक पहुँच गए। उन्होंने बेंचमार्क कार्यों के उत्तरों को रिवर्स-इंजीनियर करके धोखा देने के तरीके भी खोजे, लेकिन सोचा कि ग्रेडिंग सिस्टम धोखाधड़ी का पता लगा लेगा। यह बेहतर ढंग से समझने के लिए कि धोखाधड़ी के रूप में पकड़े जाने से बचने के तरीके खोजने के लिए बेंचमार्क मूल्यांकन कैसे काम करता है, उन्होंने अंततः Hugging Face सिस्टम से समझौता कर लिया (Hugging Face; OpenAI)।

यह घटना उस विफलता मोड का एक स्पष्ट उदाहरण है जिसका वर्णन हमने जुलाई में Numbat को ओपन-सोर्स करते समय किया था: आकस्मिक मेल्टडाउन (accidental meltdowns), Cornell Tech के सुरक्षा शोधकर्ताओं द्वारा गढ़ा गया एक शब्द (arXiv)। एक वैध लक्ष्य का पीछा करने वाला एजेंट घर्षण का सामना करता है, जैसे कि एक लापता फ़ाइल, एक विफल API कॉल, एक समाप्त हुआ क्रेडेंशियल, या अनुमति से इनकार, और एक वर्कअराउंड की तलाश में जाता है। ऐसा करने में, यह टोही (reconnaissance), विशेषाधिकार वृद्धि, गुप्त खोज, या डेटा निष्कासन के माध्यम से सुरक्षा सीमाओं को पार कर सकता है। एजेंट खुद प्रभावी रूप से विरोधी बन जाता है, भले ही इसमें कोई दुर्भावनापूर्ण प्रॉम्प्ट या बाहरी हमलावर शामिल न हो।

Hugging Face एकमात्र मामला नहीं था। हाल के हफ़्तों में अधिक एजेंट मेल्टडाउन व्यवहारों की खोज की गई और रिपोर्ट किया गया। 27-28 मई को, Data USA (US सरकार के डेटा तक ओपन एक्सेस प्रदान करने वाला एक प्लेटफ़ॉर्म) से Iowa विश्वविद्यालय का डेटा एकत्र करने की कोशिश करने वाले एजेंटों को एक विकृत क्वेरी के कारण त्रुटियों का सामना करना पड़ा। उन्होंने SQL इंजेक्शन, क्रॉस-साइट स्क्रिप्टिंग, टेम्पलेट इंजेक्शन, पाथ ट्रैवर्सल और कमांड इंजेक्शन सहित जांच के साथ प्रतिक्रिया दी। इस गतिविधि को बाद में OpenAI (SecurityWeek) से जोड़ा गया। 20-21 जून को, Australian Institute of Health and Welfare (AIHW) से विक्टोरिया के स्थानीय क्षेत्रों में दवाओं की एक श्रेणी के लिए प्रति-व्यक्ति सरकारी लागत प्राप्त करने की कोशिश करने वाले OpenAI एजेंटों को एक फ़ाइल डाउनलोड करने से रोक दिया गया। इसके जवाब में, एजेंटों ने प्रक्रिया में साइट की एंटी-बॉट सुरक्षा को दरकिनार करते हुए, AIHW प्री-प्रोडक्शन सर्वर से वह फ़ाइल डाउनलोड कर ली जो पहले से ही सार्वजनिक थी (SecurityWeek)।

यह पैटर्न किसी एक लैब तक सीमित नहीं है। साइबर सुरक्षा परीक्षणों के दौरान, Anthropic मॉडल्स ने एक गलती के बाद तीन कंपनियों को भेद दिया जिससे उन्हें खुला इंटरनेट एक्सेस मिल गया, Google के Gemini ने तीन वेबसाइटों के क्रेडेंशियल्स का अनुमान लगाया, और एक Meta मॉडल ने तृतीय-पक्ष सेवा का फायदा उठाया (Reuters)।

इतिहास से सीखना: इंटरनेट वर्म्स का युग

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

4 मई, 2000 को, लोगों को विषय पंक्ति "ILOVEYOU" के साथ परिचित प्रेषकों से ईमेल प्राप्त होने लगे। ईमेल में अटैचमेंट खोलने के परिणामस्वरूप एक स्क्रिप्ट चली जिसने पीड़ित की Outlook पता पुस्तिका में सभी को अपनी एक प्रति मेल कर दी। उस दिन शाम 6 बजे तक, CERT समन्वय केंद्र को 420,000 से अधिक इंटरनेट होस्ट से जुड़े रिपोर्ट प्राप्त हुए थे (US GAO Report)। कथित तौर पर इस वायरस ने रक्षा विभाग, CIA, NASA, और हाउस और सीनेट सहित कम से कम 14 संघीय एजेंसियों में प्रवेश किया (US GAO Report)। इसने पेंटागन और ब्रिटिश संसद में ईमेल सर्वर भी बंद कर दिए (Wired)। बीमा दिग्गज लॉयड्स ऑफ़ लंदन ने एक प्रारंभिक अनुमान लगाया कि वायरस से नुकसान और खोई हुई उत्पादकता में $15 बिलियन से अधिक का खर्च आएगा (US House Committee Hearing)। कंप्यूटर इकोनॉमिक्स ने बाद में दुनिया भर में $8.75 बिलियन के नुकसान का अनुमान लगाया (Information Week)।

वे वर्म्स जिन्हें किसी मानव क्लिक की आवश्यकता नहीं थी, इसके बाद आए। 19 जुलाई, 2001 को, Code-Red वर्म ने 14 घंटे से भी कम समय में 359,000 से अधिक कंप्यूटरों को संक्रमित कर दिया (CAIDA)। 25 जनवरी, 2003 को, SQL Slammer हर 8.5 सेकंड में आकार में दोगुना हो गया और इसके प्रति संवेदनशील 90% से अधिक इंटरनेट होस्टों को 10 मिनट के भीतर संक्रमित कर दिया (CAIDA), एक ऐसे छेद का फायदा उठाते हुए जिसके लिए Microsoft ने छह महीने पहले एक पैच जारी किया था (CNET)। अगस्त 2003 में, Blaster वर्म और Sobig ईमेल वर्म लगभग एक हफ्ते के अंतराल पर दिखाई दिए (Microsoft, F-Secure)।

उस समय, यह पूछना उचित था कि क्या नेटवर्क वाले कंप्यूटरों को बिल्कुल सुरक्षित बनाया जा सकता है। ILOVEYOU वायरस के छह दिन बाद, अमेरिकी हाउस उपसमिति ने इस पर एक सुनवाई की। कई सुरक्षा विशेषज्ञों ने ऐसे कानून की मांग की जिससे सॉफ्टवेयर कंपनियों को उनके उत्पादों में कमियों के कारण होने वाले नुकसान के लिए जवाबदेह बनाया जा सके। वाशिंगटन ने एक अलग रास्ता अपनाया। राष्ट्रीय साइबरस्पेस सुरक्षा रणनीति में कहा गया कि “संघीय विनियमन साइबरस्पेस को सुरक्षित करने का प्राथमिक साधन नहीं बनेगा।” इसने चेतावनी दी कि व्यापक जनादेश “साइबर सुरक्षा के लिए न्यूनतम-सामान्य-भाजक दृष्टिकोण” पैदा कर सकते हैं (CISA)।

उद्योग ने इंजीनियरिंग के साथ जवाब दिया। ILOVEYOU के ग्यारह दिन बाद, Microsoft ने एक Outlook अपडेट की घोषणा की जिसने निष्पादित अटैचमेंट्स को ब्लॉक कर दिया। जनवरी 2002 में, कंपनी ने सुरक्षा को सर्वोच्च प्राथमिकता दी (Seattle Times)। स्वचालित पैचिंग, सुरक्षित डिफ़ॉल्ट, बग बाउन्टी प्रोग्राम और समन्वित प्रकटीकरण (coordinated disclosure) मानक अभ्यास बन गए। 2008 में, Chrome ने एक सैंडबॉक्स में वेब सामग्री चलाना शुरू किया जो "बग का फायदा उठाने के बाद हमलावर क्या कर सकता है उसे सीमित करता है" (Chromium Blog)। एन्क्रिप्शन, जो कभी अपवाद हुआ करता था, डिफ़ॉल्ट बन गया। बहु-कारक्टर प्रमाणीकरण, फ़ायरवॉल, ज़ीरो ट्रस्ट, और सुरक्षा सूचना और घटना प्रबंधन (SIEM) सहित सुरक्षा प्रौद्योगिकियां व्यापक रूप से उपयोग की जाने लगीं। सूचना सुरक्षा पर 2026 में दुनिया भर के संगठनों द्वारा लगभग 240 बिलियन डॉलर खर्च करने का अनुमान है (Gartner)। वर्म कभी पूरी तरह से गायब नहीं हुए, लेकिन नियमित इंटरनेट-व्यापी प्रकोपों का युग फीका पड़ गया। साथ ही, अगले दो दशकों में विनियमन से काफी हद तक मुक्त इंटरनेट, नवाचार और आर्थिक विकास का एक शक्तिशाली इंजन बन गया।

AI एजेंटों के लिए सुरक्षा इंजीनियरिंग

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

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

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

डिफ़ेंस-इन-डेप्थ सुरक्षा सिद्धांत

AI एजेंटों को सुरक्षित करने के लिए लागू किए जाने वाले सबसे महत्वपूर्ण सुरक्षा सिद्धांतों में से एक डिफ़ेंस-इन-डेप्थ है, जो एक स्तरित सुरक्षा वास्तुकला की वकालत करता है, जहाँ सिस्टम संसाधनों की रक्षा के लिए कई, विविध और अतिरेक (redundant) रक्षात्मक उपायों को नियोजित किया जाता है। कोई भी एक सुरक्षा उपाय सही नहीं होता है। लोग सोशल-इंजीनियरिंग हमलों के शिकार हो सकते हैं और अपने लॉगिन क्रेडेंशियल्स का खुलासा कर सकते हैं, शून्य-दिवसीय (zero-day) सॉफ़्टवेयर कमजोरियों की खोज की जाती है और उनका फायदा उठाया जाता है, और घुसपैठ का पता लगाने वाली प्रणाली नए हमले के रूपों को चूक जाती है। डिफ़ेंस-इन-डेप्थ इसे स्वीकार करता है और रक्षा की कई स्वतंत्र परतों को स्टैक करता है। यदि एक रक्षात्मक परत को दरकिनार कर दिया जाए, तो घुसपैठ का मुकाबला करने या उसका पता लगाने के लिए अन्य परतें अपनी जगह पर बनी रहती हैं।

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

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

बड़ा करें

अतिरिक्त सुरक्षा उपायों के लिए डिज़ाइन नियम

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

1. स्वतंत्रता। प्रत्येक परत को स्वतंत्र कारणों से विफल होना चाहिए। समान धारणा को साझा करने वाले दो नियंत्रणों को एक ही हमले द्वारा हराया जा सकता है। मॉनिटर और प्रवर्तन बिंदु एजेंट की पहुँच से बाहर होने चाहिए।
2. एजेंट के नीचे प्रवर्तन। कम से कम एक परत नियतिवादी (deterministic) होनी चाहिए: पारंपरिक, सत्यापन योग्य कोड जो मॉडल जो भी उत्पन्न करता है उसकी परवाह किए बिना निषिद्ध कार्यों को रोकता है। एक ऐसा सुरक्षा उपाय जिसे एजेंट आह्वान करने से मना कर सकता है, या पुनर्व्यवस्थित कर सकता है, वह सुरक्षा उपाय नहीं है।
3. सिग्नल केवल अधिकार को कम कर सकते हैं। डिटेक्शन को ऐसी प्रतिक्रियाओं को ट्रिगर करना चाहिए जो एजेंट क्या कर सकता है उसे सीमित करती हैं, जैसे कि रोकना, क्रेडेंशियल्स को रद्द करना, नेटवर्क एक्सेस काटना, या सत्र को समाप्त करना। कोई भी जोखिम सिग्नल कभी भी अतिरिक्त पहुँच प्रदान नहीं करना चाहिए।

हम Open Secure AI Alliance में अपने भागीदारों के साथ इन सिद्धांतों को साझा करते हैं, जिसमें NVIDIA भी शामिल है, जिसने तर्क दिया है कि हार्नेस मार्गदर्शन करता है कि एक एजेंट क्या प्रयास करता है जबकि बुनियादी ढांचा नियंत्रित करता है कि यह क्या कर सकता है (NVIDIA)।

Perplexity के उत्पादों में डिफ़ेंस-इन-डेप्थ

Perplexity चार प्रकार के वातावरण में एजेंटों को चलाता है: हमारे एजेंट प्लेटफ़ॉर्म Computer के माध्यम से क्लाउड में, Comet के माध्यम से ब्राउज़र में, Portable Computer के माध्यम से उपयोगकर्ता उपकरणों पर, और कर्मचारी लैपटॉप पर, जहाँ हमारे इंजीनियर तृतीय-पक्ष कोडिंग एजेंटों का उपयोग करते हैं। प्रत्येक वातावरण के अपने जोखिम हैं, और प्रत्येक को सुरक्षा की कई परतें मिलती हैं।

क्लाउड में: Computer और SPACE

हर Computer कार्य SPACE में चलता है, जो हमारा सैंडबॉक्स प्लेटफ़ॉर्म है, जो डिफ़ॉल्ट रूप से एजेंट को अनट्रस्टेड मानता है। प्रत्येक कार्य को अपना खुद का microVM मिलता है, क्रेडेंशियल्स सैंडबॉक्स के बाहर रहते हैं और केवल तभी इंजेक्ट किए जाते हैं जब आवश्यक हो, आउटबाउंड ट्रैफ़िक को गेस्ट के बाहर नियंत्रित किया जाता है, और स्नैपशॉट हमें विनाशकारी परिवर्तनों को रोल बैक करने देते हैं (Making SPACE)। एंटरप्राइज़ ग्राहक अपनी खुद की एन्क्रिप्शन कुंजियाँ भी ला सकते हैं। किसी कुंजी को रद्द करने से सुरक्षित डेटा अपठनीय हो जाता है, और एजेंट उस निर्णय को ओवरराइड नहीं कर सकता है।

हम यह भी परीक्षण करते हैं कि क्या ये परतें टिकी हुई हैं। Escaping SPACE: Part I में, हमने नौ फ़्रंटियर मॉडल्स को SPACE सैंडबॉक्स के अंदर रूट एक्सेस दिया और उन्हें बाहर निकलने के लिए कहा। कोई भी VM से बाहर नहीं भागा, लेकिन जब आंशिक नेटवर्क एक्सेस की अनुमति दी गई थी, तो कुछ को नेटवर्क नीति के आसपास के रास्ते मिल गए। हमने उन कमियों को ठीक किया, री-टेस्ट में सुधारों की पुष्टि की, और अन्य 10 सैंडबॉक्स प्लेटफ़ॉर्म में से 8 में पाई गई समान कमजोरियों को उनके वेंडर को डिस्क्लोज़ कर दिया।

ब्राउज़र में: Comet और BrowseSafe

लॉन्च के बाद से Comet ने एक स्तरित प्रॉम्प्ट-इंजेक्शन रक्षा का उपयोग किया है: क्लासिफायर पुनर्प्राप्त सामग्री की जाँच करते हैं, संरचित प्रॉम्प्ट इसे अनट्रस्टेड के रूप में चिह्नित करते हैं, ईमेल भेजने या ऑर्डर देने जैसे संवेदनशील कार्यों के लिए उपयोगकर्ता की पुष्टि की आवश्यकता होती है, और जब कुछ ब्लॉक किया जाता है तो उपयोगकर्ताओं को सूचित किया जाता है (Comet prompt-injection defenses)। पहली परत के पीछे का ओपन-सोर्स डिटेक्शन मॉडल BrowseSafe, हमारे BrowseSafe-Bench बेंचमार्क पर फ़्रंटियर मॉडलों से बेहतर प्रदर्शन करता है, फिर भी वही बेंचमार्क दिखाता है कि कोई भी डिटेक्टर फुल-प्रूफ़ नहीं है, यही वजह है कि डिटेक्शन कभी भी एकमात्र परत नहीं होती है (BrowseSafe research)। Computer इन defenses को विरासत में लेता है, जिनका Trail of Bits द्वारा ऑडिट किया गया है (Perplexity)।

डिवाइस पर: Portable Computer

Portable Computer एक स्थानीय-प्रथम (local-first) एजेंट है: मॉडल, हार्नेस, बातचीत और प्रक्षेपवक्र डिफ़ॉल्ट रूप से उपयोगकर्ता की मशीन पर रहते हैं। एक नियतिवादी ऑर्केस्ट्रेटर, जो LLM के बजाय हार्नेस कोड है, लूप चलाता है और नीति लागू करता है। मॉडल कार्यों का प्रस्ताव करता है, और स्वीकृत टूल कॉल एक OS-स्तरीय सैंडबॉक्स में चलते हैं जो प्रक्रियाओं, फ़ाइल पथों और नेटवर्क एक्सेस को प्रतिबंधित करता है। सैंडबॉक्स हमेशा चालू रहता है और विफल होने पर बंद हो जाता है: यदि यह उपलब्ध नहीं है, तो हार्नेस उपयोगकर्ता की अनुमति के साथ कमांड चलाने के बजाय खुद को अक्षम कर देता है। डिवाइस की सीमा को पार करने वाले कार्य, जैसे वेब खोज, कनेक्टर, और एक मजबूत क्लाउड सलाहकार मॉडल तक वृद्धि, केवल तभी होते हैं जब उपयोगकर्ता उन्हें सक्षम और स्वीकृत करता है। सलाहकार कॉल से पहले, एक PII क्लासिफायर संवेदनशील जानकारी को फ़्लैग करता है और उपयोगकर्ता देखता है कि क्या भेजा जाएगा। सलाहकार को केवल वह स्वीकृत संदर्भ प्राप्त होता है और डिवाइस की फ़ाइलों या टूल तक बिना किसी पहुँच के पाठ मार्गदर्शन लौटाता है।

एंडपॉइंट पर: Numbat

डेवलपर लैपटॉप पर कोडिंग एजेंट सोर्स कोड, क्रेडेंशियल्स और प्रोडक्शन सिस्टम तक पहुँच के साथ घंटों तक चलते हैं। Numbat, हमारा ओपन-सोर्स एजेंट सुरक्षा सूट, एक स्वतंत्र परत जोड़ਦਾ है जो किसी भी एक एजेंट के बाहर रहता है। यह Claude Code, Codex, OpenCode और Pi जैसे हार्नेस के साथ काम करता है, चलने से पहले खतरनाक कार्यों को ब्लॉक करता है, संदिग्ध बहु-चरणीय अनुक्रमों जैसे कि एक गुप्त को पढ़ना और फिर डेटा बाहर भेजना को फ़्लैग करता है, और जांच के लिए सत्र की समयसीमा को संरक्षित करता है। Numbat हमारे ओपन-सोर्स सप्लाई-चेन स्कैनर Bumblebee के साथ हजारों Perplexity एंडपॉइंट्स पर चलता है। Computer नियमित रूप से उनके निष्कर्षों की समीक्षा करता है और बेहतर पहचान नियमों का प्रस्ताव करता है, और शिप होने से पहले एक इंसान हर बदलाव को मंजूरी देता है।

पूरे उद्योग के लिए एक काम

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

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

इन चुनौतियों पर व्यापक समुदाय के साथ काम करने के लिए, Perplexity ने अग्रणी AI प्रणालियों की सुरक्षा, विश्वसनीयता और व्यावहारिक रक्षा का अध्ययन करने के लिए मार्च 2026 में Secure Intelligence Institute लॉन्च किया (Perplexity)। Perplexity वर्तमान में स्टैनफोर्ड, CMU, ड्यूक, कोलंबिया, ओहायो स्टेट और वर्जीनिया विश्वविद्यालय में अकादमिक शोधकर्ताओं का सहयोग और/या वित्तपोषण कर रहा है। हम एजेंट सुरक्षा अनुसंधान की सीमा को आगे बढ़ाने, उन प्रगति को Perplexity की प्रणालियों में ठोस सुधारों में अनुवादित करने, और व्यापक AI पारिस्थितिकी तंत्र को मजबूत करने में मदद करने वाले ज्ञान और संसाधनों को साझा करने के लिए आंतरिक अनुसंधान भी कर रहे हैं। सुरक्षित एजेंट ऐसी चीज़ है जिसे उद्योग इंजीनियर कर सकता है। हम अपनी भूमिका निभाते रहना चाहते हैं, और हम दूसरों को हमारे साथ निर्माण करने के लिए आमंत्रित करते हैं।