Coding Agent के लिए Disposable VM क्यों दें

आपका laptop disposable VM से बेहतर क्यों नहीं है

किसी coding agent को disposable VM दें। तब वह अधिकतम उस machine को नष्ट कर सकता है, जिसे आप 10 मिनट में फिर से बना सकते हैं। Agent को root access मिलता है, वह packages install कर सकता है और हर चरण के लिए अनुमति मांगे बिना test suite चला सकता है। अंतर यह है कि नुकसान कहां होता है। Laptop पर agent आपके SSH keys, browser profile, .env files और आपके द्वारा कभी clone किए गए हर दूसरे repository के साथ home directory साझा करता है। Throwaway server पर उसके पास shell, checkout और चोरी करने लायक कोई अन्य महत्वपूर्ण चीज नहीं होती।

यही पूरा तर्क है। यह संभावना के बजाय असमान जोखिम के बारे में है। सावधानी से इस्तेमाल किया गया agent, सावधानी से इस्तेमाल किए गए laptop पर, लगभग हर बार ठीक रहता है। लेकिन जिस एक बार ऐसा नहीं होता, उसकी लागत केवल खराब commit नहीं होती। यदि आपके पास backup है, तो आपको उससे restore करना पड़ता है।

इस पर बहस करने से पहले प्रभाव-क्षेत्र निर्धारित करें

प्रभाव-क्षेत्र से आशय उन चीज़ों के समूह से है, जिन तक कोई process पहुँच सकता है। आपके सामान्य user के रूप में आपके सामान्य machine पर चलने वाले agent के लिए यह समूह आपकी कल्पना से बड़ा होता है।

इसमें ~/.ssh/id_ed25519 शामिल है, जो आमतौर पर unencrypted होता है, क्योंकि आप passphrase टाइप करते-करते थक गए। इसमें ~/.aws/credentials और ~/.config/gh/hosts.yml शामिल हैं, जो design के अनुसार plain text होते हैं। इसमें ~/code के अंतर्गत मौजूद हर sibling repository शामिल है, जिसमें local env file में production connection strings वाली repositories भी शामिल हैं। इसमें आपकी shell history भी शामिल है, जिसमें आपके द्वारा एक बार paste किए गए tokens हो सकते हैं। इसमें वह network भी शामिल है, जिससे आपका laptop जुड़ा है। यह अक्सर home या office network होता है, जिस पर unauthenticated services चल रही होती हैं।

इनमें से किसी के लिए भी malicious agent आवश्यक नहीं है। इसके लिए केवल एक ऐसा command पर्याप्त है, जो पूरे confidence के साथ गलत हो। unset variable के कारण / में expand होने वाला rm -rf, गलत directory में चलाया गया git clean -xfd, ऐसा docker system prune -af --volumes जो आपका local database भी हटा दे, या home directory पर चलाया गया उपयोगी समझा जाने वाला chmod -R 777। Agents को उसी internet पर train किया जाता है, जिसने ये commands बाकी सभी लोगों को सिखाए हैं।

आपको सुरक्षित रखने वाला mechanism agent का judgement नहीं है। सुरक्षा इस बात से आती है कि जिस machine पर नुकसान हो सकता है, उसे खोने के लिए आप पहले से तैयार थे।

लागत का गणित उबाऊ है, और यही उद्देश्य है

एक छोटा VPS हर महीने कुछ डॉलर का खर्च आता है। Developer laptop को फिर से तैयार करने में एक दिन लग सकता है। यह तब सबसे अच्छा मामला है, जब आपको समस्या तुरंत पता चल जाए और आपके पास backup हो।

अपने आंकड़ों से इसकी गणना करें। अपनी प्रति घंटा दर लें और उसे इन कामों में लगने वाले घंटों से गुणा करें: operating system को फिर से install करना, home directory को restore करना, SSH key को rotate करना, personal access token को rotate करना और बीस repositories को फिर से clone करना। इसकी तुलना उस provider के सबसे छोटे server के बारह महीनों के खर्च से करें। कई वर्षों में एक incident से कम पर भी लागत बराबर हो जाती है। इसके लिए incident का विनाशकारी होना आवश्यक नहीं है। Corrupted local environment के कारण खोया एक दोपहर भी पूरे वर्ष का खर्च चुका देता है।

इस गणना का दूसरा भाग snapshots है। किसी जोखिमपूर्ण run से पहले snapshot लेने पर खराब परिणाम "मेरी पूरी व्यवस्था restore करें" से बदलकर "roll back करें और अलग prompt आजमाएं" हो जाता है। जिस laptop पर आप यह लिख रहे हैं, उसमें यह विकल्प उपलब्ध नहीं है, क्योंकि जिस machine का उपयोग आप अपना कार्यस्थल बनाने के लिए कर रहे हैं, उसका snapshot उसी समय नहीं ले सकते।

जुलाई 2026 की स्थिति

"एजेंट कहाँ चलना चाहिए" के तीन स्पष्ट उत्तर हैं। इन सभी में वही दो बातों का संतुलन करना पड़ता है: सीमा कितनी मजबूत है, और आप कितना सेटअप स्वीकार कर सकते हैं।

एक स्थानीय micro VM। इस श्रेणी के tools आपके अपने hardware पर एक वास्तविक virtual machine शुरू करते हैं, उसमें आपका repository mount करते हैं, और एजेंट को उसके भीतर root access देते हैं। clawk इसका वर्तमान उदाहरण है। इसका मुख्य विचार इस लेख के निष्कर्ष के बिल्कुल अनुरूप है: coding agents को आपके laptop के बजाय एक अस्थायी Linux VM दें। जुलाई 2026 तक यह Apple silicon वाले macOS 14 और बाद के versions को target करता है। Firecracker के माध्यम से Linux support experimental है। इसे brew install clawkwork/tap/clawk से install किया जाता है। किसी repository के भीतर clawk चलाने पर sandbox शुरू होता है और agent attach होता है। इसे रोकने के लिए clawk down और हटाने के लिए clawk destroy चलाएँ। इसकी सीमा hypervisor है, जो मजबूत है। इसकी कमी यह है कि VM उसी machine पर चलता है जिसे आप साथ लेकर चलते हैं। इसलिए यह आपकी memory के लिए प्रतिस्पर्धा करता है और lid बंद करने पर रुक जाता है।

एक container। Docker वह विकल्प है जिसे अधिकांश लोगों ने पहले से install किया हुआ है। यह वास्तव में उपयोगी है।

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm exit पर container को हटा देता है और --network none उसे network access बिल्कुल नहीं देता। build या test run के लिए यह एक अच्छा default है। यह स्पष्ट रखें कि इससे क्या नहीं होता: container host kernel साझा करता है। इसलिए kernel bug बाहर निकलने का मार्ग बन सकता है। जैसे ही आप --privileged जोड़ते हैं या /var/run/docker.sock mount करते हैं, ताकि agent "Docker का उपयोग कर सके", boundary समाप्त हो जाती है। किसी container में Docker socket mount करना उस container को host पर root access देने के बराबर है।

एक साधारण VPS जिसे आप फिर से बना सकते हैं। इसमें किसी नए tool की आवश्यकता नहीं होती, वास्तविक kernel boundary मिलती है, provider snapshots उपलब्ध होते हैं, और laptop बंद करने पर भी यह चलता रहता है। इस guide का बाकी भाग इसी pattern का वर्णन करता है। लंबी agent runs के लिए यही विकल्प बना रहता है, क्योंकि चार घंटे चलने वाले job को इस बात से कोई फर्क नहीं पड़ता कि आप घर चले गए हैं।

VPS पैटर्न: agent के लिए अपना user बनाएँ

एक hardened server से शुरू करें। नए VPS पर पहले दस मिनट में वे चरण शामिल हैं जो agent के लिए विशिष्ट नहीं हैं: updates, non-root login, केवल key से SSH access और firewall।

फिर ऐसा account बनाएँ जो केवल agent के लिए हो। इससे उसके भीतर हुई गलती server की किसी अन्य चीज़ को प्रभावित नहीं कर सकेगी।

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password का अर्थ है कि अनुमान लगाने के लिए कोई password नहीं है। आप इस account में sudo -u agent या SSH key से पहुँचते हैं। ध्यान दें कि agent को जानबूझकर sudo group में शामिल नहीं किया गया है। sudo वाले agent के पास root access होता है। root हर दूसरे user की files पढ़ सकता है। इसलिए अभी बनाया गया separation केवल दिखावटी रह जाएगा। यदि agent को वास्तव में packages install करने की आवश्यकता है, तो यह उसके लिए पूरे server का उपयोग करने का कारण है, न कि shared server पर उसे sudo देने का। सामान्य नियम VPS पर Linux users के लिए least privilege में दिए गए हैं।

उस पर भरोसा करने से पहले boundary जाँचें। agent user के रूप में अपने account की file पढ़ने का प्रयास करें:

sudo -u agent cat /home/you/.ssh/id_ed25519

आपको cat: /home/you/.ssh/id_ed25519: Permission denied दिखाई देना चाहिए। यदि इसके बजाय key material दिखाई देता है, तो आपकी home directory का mode 755 है और isolation अभी वास्तविक नहीं है। इसे sudo chmod 700 /home/you से ठीक करें।

क्रेडेंशियल को मशीन से पूरी तरह बाहर रखें

यदि आप अपने production secrets इस मशीन पर कॉपी कर देते हैं, तो disposable machine का उद्देश्य समाप्त हो जाता है। नियम सरल है: उस मशीन पर ऐसी कोई credential नहीं होनी चाहिए जिसे आपको आज दोपहर rotate करने में आपत्ति हो।

git के लिए key कॉपी करने के बजाय अपना SSH agent forward करें। Private key आपके laptop पर रहती है और connection के माध्यम से केवल signature requests भेजी जाती हैं।

ssh -A agent@203.0.113.10
ssh -T git@github.com

दूसरे command का उत्तर Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. होना चाहिए। इससे प्रमाणित होता है कि git push server पर कोई key file मौजूद न होने पर भी काम करेगा। इसके बाद उस मशीन पर ls -la ~/.ssh चलाएँ और पुष्टि करें कि उसमें कोई private key नहीं है।

Agent forwarding में एक महत्वपूर्ण जोखिम है, इसलिए इसे स्पष्ट रूप से समझें: आपके connected रहने के दौरान, उस server पर root access रखने वाला कोई भी व्यक्ति forwarded socket का उपयोग करके आपकी पहचान से authenticate कर सकता है। ऐसे server पर जिसका एकमात्र अन्य user आप हैं, यह स्वीकार्य समझौता है। Shared box पर ऐसा नहीं है। वहाँ केवल एक repository तक सीमित deploy key बेहतर विकल्प है। विकल्पों का विवरण SSH key management की मूल बातें में दिया गया है।

API keys के लिए agent को उसकी अपनी key दें और उसकी अपनी spending limit निर्धारित करें। इसे ऐसी file में रखें जिसका स्वामी agent user हो और जिसका mode 600 हो। मशीन नष्ट होने पर यह सोचने के बजाय कि key leak हुई या नहीं, उसे revoke करें। प्रत्येक key का model spend अलग से दिखाई देना ही वह तरीका है जिससे VPS पर AI agent की लागत का नियंत्रण में दिए गए आंकड़े पूर्वानुमानित रहते हैं।

नेटवर्क पर agent की पहुंच सीमित करें

Filesystem isolation सीमा का केवल आधा हिस्सा है। दूसरा आधा egress है: process को किन endpoints से संपर्क करने की अनुमति है। Linux, outbound traffic को उसे बनाने वाले user के आधार पर filter कर सकता है। यह इस pattern के लिए ठीक उपयुक्त है।

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

Rules को क्रम से पढ़ा जाता है। इसलिए अंतिम REJECT उन सभी connections को रोकता है जिन्हें पिछली lines ने अनुमति नहीं दी। इसे agent के रूप में test करें:

sudo -u agent curl -sS -m 5 http://example.com

यह curl: (7) Failed to connect to example.com port 80: Connection refused के साथ fail होना चाहिए, क्योंकि reject rule तुरंत उत्तर देती है और connection को hang नहीं होने देती। उसी host को HTTPS request अभी भी सफल होनी चाहिए।

दो महत्वपूर्ण सीमाएँ हैं। पहली, अगला reboot होने पर ये rules खो जाती हैं, जब तक कि आप उन्हें sudo apt install -y iptables-persistent और फिर sudo netfilter-persistent save के साथ save न करें। दूसरी, यह names के बजाय ports और addresses को filter करता है। Port 443 की अनुमति देने वाला rule internet पर मौजूद हर HTTPS host को अनुमति देता है। इससे model API तक पहुंचना संभव होता है और pastebin तक पहुंचना भी। वास्तविक domain allow-list के लिए traffic को ऐसे proxy से गुजरना होगा जो requested hostname पढ़ता हो। अधिकांश single-developer setups के लिए यह अपेक्षा से अधिक machinery है। केवल वही दावा करें जो आपके पास वास्तव में है: ऐसी machine पर port-level egress control, जिसे खोने के लिए आप तैयार थे।

कार्यों के बीच स्वच्छ स्थिति पर रीसेट करें

प्रत्येक कार्य के लिए स्वच्छ स्थिति बनाए रखना अक्सर कम आंका जाने वाला लाभ है। पिछले टिकट पर तीन घंटे काम करने वाले agent ने installed packages, आधी लागू की गई migrations, एक पुराना node_modules, और ऐसा git working tree छोड़ दिया है जिसमें किसी ने समीक्षा नहीं की। अगला कार्य यह सब विरासत में पाता है, और आप अपना review budget यह पता लगाने में खर्च करते हैं कि कौन-सी गड़बड़ी किस run की है।

सस्ता विकल्प प्रत्येक कार्य के लिए fresh checkout है।

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

अधिक मजबूत विकल्प provider snapshot है, जिसे machine के सेट अप होने के तुरंत बाद और किसी भी agent के उसे छूने से पहले एक बार लिया जाता है। उस snapshot को restore करने पर packages सहित पूरा system ज्ञात स्थिति में लौट आता है। अधिकांश providers इसे box पर command के रूप में नहीं, बल्कि control panel या API के माध्यम से उपलब्ध कराते हैं। इसलिए सटीक चरण आपके provider पर निर्भर करते हैं। snapshot उस समय लें जब machine अभी भी बिना किसी बदलाव के हो।

जिस भी चीज़ की आपको आवश्यकता है, उसे disposable machine से बाहर रखें। इसका मुख्य अर्थ है branches को locally जमा करने के बजाय push करना। यदि box में ऐसी कोई चीज़ रह जाती है जिसकी कमी आपको महसूस होगी, तो VPS पर restic backups का उपयोग करके उसका सही backup लें। ऐसी machine को नष्ट कर पाना तभी उपयोगी है जब उसे नष्ट करना वास्तव में बिना किसी समस्या के हो।

यदि आप कई servers के लिए भुगतान किए बिना कई isolated environments चाहते हैं, तो एक बड़ा VPS guest VMs को सीधे host कर सकता है। VPS पर Nested virtualisation में बताया गया है कि यह कैसे काम करता है और यह भी कि आपका provider इसकी अनुमति देता है या नहीं।

जब सावधानी के साथ laptop का उपयोग वास्तव में पर्याप्त हो

इस बारे में ईमानदार रहें, क्योंकि isolation को बढ़ा-चढ़ाकर प्रस्तुत करने से लोग आपकी बात सुनना बंद कर देते हैं।

यदि कोई command चलने से पहले आप उसकी समीक्षा करते हैं, तो laptop पर्याप्त है। permission prompt एक वास्तविक नियंत्रण है, और server पर Claude Code को सुरक्षित रूप से चलाना बताता है कि इसका प्रत्येक स्तर वास्तव में क्या रोकता है। यदि आपका काम एक ही repository तक सीमित है और machine पर कहीं भी production credentials नहीं हैं, तो संभावित नुकसान का दायरा पहले से ही छोटा है। यदि आपके agent sessions छोटे और supervised हैं, तो exposure window भी छोटी रहती है।

जैसे ही आप prompts को छोड़ देते हैं, उत्तर बदल जाता है। Unattended runs, overnight jobs और ऐसे सभी workflows जिनमें आप किसी plan को approve करके चले जाते हैं, उस human check को हटा देते हैं जो containment कर रहा था। उस स्थिति में machine को यह काम करना पड़ता है। यही बात agent की पहुंच बढ़ाने वाली किसी भी चीज़ पर लागू होती है, जिसमें एक साथ कई repositories पर VPS पर coding agent चलाना भी शामिल है।

निर्णय वास्तव में इस बात पर निर्भर नहीं करता कि आप model पर कितना भरोसा करते हैं। यह इस बात पर निर्भर करता है कि model के गलत होने पर उसके साथ कौन-से नियंत्रण मौजूद हैं।

FAQ

क्या किसी coding agent के लिए container पर्याप्त isolation देता है?

अधिकांश कार्यों के लिए हाँ, लेकिन 2 शर्तों के साथ। container को --privileged के साथ नहीं चलना चाहिए और उसमें /var/run/docker.sock mount नहीं होना चाहिए, क्योंकि इनमें से कोई भी प्रक्रिया को host के root तक पहुँचने का मार्ग देता है। container host kernel साझा करता है, इसलिए इसकी सीमा virtual machine की तुलना में कमजोर होती है। यदि agent इंटरनेट से प्राप्त untrusted code चला रहा है, तो वास्तविक VM या अलग server का उपयोग करें।

क्या agent को server पर sudo की आवश्यकता है?

नहीं। उसे sudo देने से बनाया गया isolation समाप्त हो जाता है, क्योंकि root server पर मौजूद हर दूसरे account को पढ़ सकता है। agent user को sudo के बिना बनाएं और उसे केवल उसकी अपनी work directory में write access दें। यदि कार्य के लिए package installation वास्तव में आवश्यक है, तो agent को साझा machine पर root देने के बजाय उसकी अपनी पूरी machine दें।

अपने SSH key को server पर रखे बिना agent को git पर push करने की अनुमति कैसे दूँ?

Connect करते समय ssh -A के साथ अपना SSH agent forward करें। Signature requests connection के माध्यम से भेजी जाती हैं, जबकि private key आपके laptop पर रहती है। इसलिए ssh -T git@github.com authenticate करता है और git push server पर private key के बिना काम करता है। ध्यान रखें कि आपके connected रहने के दौरान उस server का root forwarded socket का उपयोग कर सकता है। इसलिए ऐसी किसी machine पर, जिसे आप अन्य लोगों के साथ साझा करते हैं, repository-scoped deploy key का उपयोग करें।

agent को किस आकार के VPS की आवश्यकता है?

Agent का कार्य मुख्यतः files edit करना, builds चलाना और tests चलाना होता है। इसलिए machine का आकार model के बजाय build के अनुसार तय करें। Hosted model provider के hardware पर चलता है, जिससे network traffic बढ़ता है और local load लगभग नहीं बढ़ता। Scripting work के लिए 2 GB RAM से शुरू करें। यदि repository containers build करती है या कोई substantial compilation करती है, तो 8 GB पर जाएँ।

machine को कितनी बार destroy और rebuild करना चाहिए?

जब state का कारण स्पष्ट न रहे, तब rebuild करें। कम से कम तब भी rebuild करें, जब यह संभव हो कि machine पर मौजूद कोई credential exposed हो गया हो। Tasks के बीच fresh checkout day-to-day drift को संभालता है। पहले agent run से पहले लिया गया snapshot आपको वापस लौटने के लिए clean system image देता है। यदि rebuilding महँगा लगता है, तो यह संकेत है कि जिस machine को आपने disposable कहा था, उस पर कुछ महत्वपूर्ण मौजूद है।