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

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

पिछले तीन महीनों में हमने macOS, Linux और Windows पर एजेंट सैंडबॉक्सिंग रोल आउट करके इस समस्या का समाधान किया है। सैंडबॉक्स्ड एजेंट एक नियंत्रित परिवेश के भीतर स्वतंत्र रूप से चलते हैं और केवल तब स्वीकृति का अनुरोध करते हैं, जब उन्हें उसके बाहर जाना होता है — ज़्यादातर मामलों में इंटरनेट तक पहुँचने के लिए।

इससे रुकावटें काफ़ी कम हो जाती हैं। सैंडबॉक्स्ड एजेंट, बिना सैंडबॉक्स वाले एजेंट की तुलना में 40% कम रुकते हैं, जिससे उपयोगकर्ताओं के मैनुअल समीक्षा और स्वीकृति में लगने वाले घंटों बचते हैं।

#हमारे सैंडबॉक्स लक्ष्य

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

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

#कार्यान्वयन

हम एक समान सैंडबॉक्स API उपलब्ध कराते हैं, जिसे हर प्लेटफ़ॉर्म पर अलग-अलग तरीके से लागू किया जाता है। macOS, Linux, और Windows सैंडबॉक्सिंग के अलग-अलग आदिम घटक प्रदान करते हैं, और इन्हीं ने अंतर्निहित डिज़ाइन विकल्पों को प्रभावित किया है।

#macOS

हमने macOS पर सैंडबॉक्सिंग के चार तरीकों का मूल्यांकन किया: App Sandbox, containers, virtual machines, और Seatbelt। App Sandbox को Mac App Store के लिए डिज़ाइन किया गया है, और इसका मतलब यह होता कि Cursor को हर उस binary पर हस्ताक्षर करने पड़ते जिसे कोई एजेंट चला सकता है। इससे काफ़ी जटिलता बढ़ जाती और दुरुपयोग के नए रास्ते खुल जाते, क्योंकि इससे एजेंट द्वारा जनरेट की गई या संशोधित binaries को Cursor का विश्वास विरासत में मिल जाता। Containers हमें Linux binaries तक सीमित कर देते, और virtual machines अस्वीकार्य स्टार्टअप देरी और मेमोरी ओवरहेड पैदा करते हैं।

इससे Seatbelt ही बचता है, जिसे sandbox-exec के ज़रिए एक्सेस किया जाता है। इसे 2007 में पेश किया गया था और 2016 में deprecated कर दिया गया, लेकिन Chrome जैसे महत्वपूर्ण तृतीय-पक्ष एप्लिकेशन आज भी इसका उपयोग करते हैं। यह किसी कमांड को ऐसे sandbox profile के तहत चलाने की अनुमति देता है, जो पूरे subprocess tree के व्यवहार को सीमित करता है।

यह profile बहुत सूक्ष्म स्तर पर अनुमतियाँ परिभाषित करता है और एक विशेष policy language के माध्यम से syscalls के साथ-साथ विशिष्ट फ़ाइलें और डायरेक्टरियों पर read या write को सीमित करता है। हम इस policy को runtime पर कार्यस्थान-level और admin-level सेटिंग्स, साथ ही उपयोगकर्ता की .cursorignore, के आधार on गतिशील रूप से जनरेट करते हैं।

(deny file-write* (regex "^.*\/\\\.vscode($|\/.*)")
)
(deny file-write* (require-all
    (regex "^.*\/\\\.cursor($|\/.*)")
    (require-not (regex "^.*\/\\\.cursor/(rules|commands|worktrees|skills|agents)($|\/.*)")))
)
(deny file-write* (regex "^.*\\\.code-workspace$"))
(deny file-write* (regex "^.*\/\\\.cursorignore$"))
(deny file-write* (regex "^.*\/\\\.git/config$"))
(deny file-write* (regex "^.*\/\\\.git/hooks($|\/.*)")
)
(deny file-write* (regex "^(/private)?/var/folders/.*-cursor(-[a-z]+)?-zsh($|\/.*)")
)

#Linux

Linux, macOS की तुलना में, कुछ मामलों में आसान है और कुछ में अधिक कठिन। कर्नेल Landlock और seccomp के ज़रिए आवश्यक आदिम घटक उपलब्ध कराता है, लेकिन उन्हें मिलाकर एक उपयोग योग्य सैंडबॉक्स बनाना userspace की ज़िम्मेदारी होती है। हालांकि कई ओपन-सोर्स प्रोजेक्ट इन तंत्रों को प्रभावी ढंग से जोड़ते हैं, लेकिन उनमें से कोई भी .cursorignore जैसी सुविधाओं का समर्थन नहीं करता।

हमने Landlock और seccomp का सीधे उपयोग करने का फैसला किया। Seccomp असुरक्षित syscalls को ब्लॉक करता है, जबकि Landlock फ़ाइलसिस्टम पर प्रतिबंध लागू करता है, जिससे हम अनदेखा की गई फ़ाइलों को सैंडबॉक्स्ड प्रक्रिया के लिए पूरी तरह अगम्य बना सकते हैं। हम उपयोगकर्ता कार्यस्थानों को एक overlay filesystem में मैप करते हैं और अनदेखा की गई फ़ाइलों को Landlocked प्रतियों से बदल देते हैं, जिन्हें न पढ़ा जा सकता है और न ही बदला जा सकता है।

इन फ़ाइलों को खोजकर फिर से mount करना Linux सैंडबॉक्सिंग का सबसे धीमा हिस्सा है। macOS की तरह फ़ाइलसिस्टम ऑपरेशनों को lazy तरीके से फ़िल्टर करना आसान होता, लेकिन Linux seccomp-bpf संदर्भ में फ़ाइल पाथ तक आसान पहुँच नहीं देता।

#Windows

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

#एजेंट को सैंडबॉक्स का उपयोग करना सिखाना

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

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

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

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

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

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

अगर आप कोडिंग के भविष्य से जुड़ी गहरी तकनीकी समस्याओं पर काम करने में रुचि रखते हैं, तो hiring@cursor.com पर संपर्क करें।