Coding agents-க்கு ஏன் disposable VM பயன்படுத்த வேண்டும்?

உங்கள் மடிக்கணினியை விட disposable VM ஏன் சிறந்தது

ஒரு coding agent-க்கு disposable VM-ஐ வழங்கினால், அது செய்யக்கூடிய மிக மோசமான பாதிப்பு, பத்து நிமிடங்களில் மீண்டும் உருவாக்கக்கூடிய ஒரு இயந்திரத்தை அழிப்பது மட்டுமே. அந்த agent-க்கு root அதிகாரம் கிடைக்கும், அது packages-ஐ நிறுவும், ஒவ்வொரு படிக்கும் அனுமதி கேட்காமல் test suite-ஐ இயக்கும். ஆனால், பாதிப்பு எங்கு நிகழ்கிறது என்பதில் தான் வித்தியாசம் உள்ளது. மடிக்கணினியில், அந்த agent உங்கள் SSH keys, browser profile, .env கோப்புகள் மற்றும் நீங்கள் clone செய்த பிற repositories ஆகியவற்றுடன் ஒரே home directory-ஐப் பகிர்ந்து கொள்கிறது. ஒரு throwaway server-ல், அதற்கு ஒரு shell மற்றும் ஒரு checkout மட்டுமே இருக்கும்; திருடுவதற்கு மதிப்புமிக்க வேறு எதுவும் இருக்காது.

இதுவே முழுமையான வாதம்; இது நிகழ்தகவை விட சமச்சீரற்ற தன்மையைப் பற்றிய வாதமாகும். கவனமாகச் செயல்படும் ஒரு agent, கவனமாகப் பயன்படுத்தப்படும் மடிக்கணினியில் பெரும்பாலும் எந்தப் பாதிப்பையும் ஏற்படுத்தாது. ஆனால், ஒருமுறை தவறு நடந்தால், அதன் விளைவு ஒரு மோசமான commit-ஆக இருக்காது. உங்களிடம் backup இருந்தால், அதிலிருந்து தரவுகளை மீட்டெடுப்பதே அதன் விளைவாக இருக்கும்.

விவாதிக்கும் முன் blast radius-ஐ வரையறுக்கவும்

Blast radius என்பது ஒரு process எட்டக்கூடிய அனைத்தையும் குறிக்கும். உங்கள் சாதாரண user கணக்கில், உங்கள் சாதாரண கணினியில் இயங்கும் ஒரு agent-க்கு, இந்த எல்லை பெரும்பாலானோர் நினைப்பதை விட பெரியது.

இதில் ~/.ssh/id_ed25519 அடங்கும், இது பொதுவாக குறியாக்கம் (encryption) செய்யப்படாமல் இருக்கும், ஏனெனில் passphrase-ஐத் தட்டச்சு செய்து நீங்கள் சோர்வடைந்திருப்பீர்கள். இதில் ~/.aws/credentials மற்றும் ~/.config/gh/hosts.yml அடங்கும், இவை வடிவமைப்பிலேயே plain text-ஆக இருப்பவை. இதில் ~/code-க்குக் கீழ் உள்ள அனைத்து sibling repository-களும் அடங்கும், இதில் local env கோப்பில் production connection strings கொண்டவையும் அடங்கும். இதில் உங்கள் shell history அடங்கும், இது நீங்கள் ஒருமுறை paste செய்த tokens-ஐக் கொண்டிருக்கும். உங்கள் மடிக்கணினி இணைக்கப்பட்டுள்ள network-ம் இதில் அடங்கும், இது பெரும்பாலும் authentication இல்லாத சேவைகளைக் கொண்ட வீட்டு அல்லது அலுவலக network-ஆகவே இருக்கும்.

இதற்கு எந்தவொரு தீங்கிழைக்கும் agent-ம் தேவையில்லை. நம்பிக்கையுடன் தவறாக இடப்பட்ட ஒரு command போதுமானது. / என விரியும் unset variable கொண்ட rm -rf, தவறான directory-ல் இயங்கும் ஒரு git clean -xfd, உங்கள் local database-ஐ அழிக்கும் ஒரு docker system prune -af --volumes, அல்லது home directory-ல் இயங்கும் ஒரு பயனுள்ள chmod -R 777 போன்றவை இதற்குப் போதுமானவை. மற்றவர்களுக்குக் கற்றுக்கொடுத்த அதே இணையத்திலிருந்தே இந்த agent-களும் பயிற்சி பெறுகின்றன.

உங்களைக் காக்கும் பொறிமுறை agent-ன் தீர்ப்பு அல்ல. சேதமடையும் அந்த இயந்திரத்தை இழக்க நீங்கள் தயாராக இருக்கிறீர்கள் என்பதே உங்களைக் காக்கும் உண்மையான பாதுகாப்பு.

செலவு கணக்கீடு சலிப்பானது, அதுவே இதன் நோக்கம்

ஒரு சிறிய VPS-க்கு மாதத்திற்கு சில டாலர்கள் மட்டுமே செலவாகும். ஒரு developer laptop-ஐ மீண்டும் சரிசெய்ய ஒரு நாள் முழுவதுமாகத் தேவைப்படும். இது ஒரு நல்ல சூழல், அதாவது பாதிப்பை நீங்கள் உடனடியாகக் கவனித்து, உங்களிடம் backup-ம் இருக்கும்போது நடப்பது.

உங்கள் சொந்த எண்களைக் கொண்டு இதைக் கணக்கிடுங்கள். உங்கள் ஒரு மணி நேர ஊதியத்தை எடுத்துக்கொள்ளுங்கள். ஒரு operating system-ஐ மீண்டும் நிறுவுதல், home directory-ஐ restore செய்தல், SSH key-ஐ மாற்றுதல், personal access token-ஐ மாற்றுதல் மற்றும் இருபது repositories-ஐ மீண்டும் clone செய்தல் ஆகியவற்றுக்குத் தேவைப்படும் மணிநேரங்களுடன் அதைப் பெருக்குங்கள். இந்தத் தொகையை, உங்கள் provider விற்கும் மிகச்சிறிய server-ன் 12 மாதக் கட்டணத்துடன் ஒப்பிட்டுப் பாருங்கள். பல ஆண்டுகளுக்கு ஒருமுறை ஏற்படும் ஒரு பாதிப்பு கூட, இந்தச் செலவை ஈடுகட்டிவிடும். ஒரு பாதிப்பு பெரிய அளவில் இருக்க வேண்டிய அவசியமில்லை. சிதைந்த local environment-ஐச் சரிசெய்யும் ஒரு மதியப் பொழுது வீணாவதே, அந்த ஆண்டிற்கான server செலவை ஈடுகட்டிவிடும்.

இந்தக் கணக்கீட்டின் இரண்டாம் பகுதி snapshots ஆகும். ஒரு ஆபத்தான செயலைச் செய்வதற்கு முன் எடுக்கப்படும் snapshot, "என் வாழ்க்கையை மீண்டும் மீட்டெடுப்பது" என்ற மோசமான நிலையை, "roll back செய்துவிட்டு வேறு வழியில் முயற்சிப்பது" என்ற எளிமையான நிலைக்கு மாற்றும். நீங்கள் இப்போது பயன்படுத்திக்கொண்டிருக்கும் laptop-ல் இந்த வசதி இல்லை, ஏனெனில் நீங்கள் பயன்படுத்தும் ஒரு கணினியை அதே நேரத்தில் snapshot எடுக்க முடியாது.

ஜூலை 2026 நிலவரப்படி தற்போதைய சூழல்

"ஏஜென்ட் (agent) எங்கு இயங்க வேண்டும்" என்ற கேள்விக்கு மூன்று நேர்மையான பதில்கள் உள்ளன. இவை இரண்டு விஷயங்களுக்கு இடையே சமநிலையை ஏற்படுத்துகின்றன: எல்லை (boundary) எவ்வளவு வலிமையானது மற்றும் எவ்வளவு அமைப்புகளை (setup) நீங்கள் பொறுத்துக்கொள்ள முடியும் என்பது.

ஒரு உள்ளூர் மைக்ரோ VM (A local micro VM). இந்த வகையைச் சேர்ந்த கருவிகள் உங்கள் சொந்த வன்பொருளில் ஒரு உண்மையான மெய்நிகர் இயந்திரத்தை (virtual machine) துவக்குகின்றன. உங்கள் களஞ்சியத்தை (repository) அதில் இணைத்து, ஏஜென்ட்டிற்கு அதனுள் root அனுமதியை வழங்குகின்றன. clawk இதற்கு தற்போதைய உதாரணமாகும். இந்த இடுகையின் மையக்கருத்து இதுதான்: கோடிங் ஏஜென்ட்டுகளுக்கு உங்கள் மடிக்கணினியைத் தராமல், ஒரு தற்காலிக Linux VM-ஐ வழங்கவும். ஜூலை 2026 நிலவரப்படி, இது Apple silicon-ல் macOS 14 மற்றும் அதற்குப் பிந்தைய பதிப்புகளை இலக்காகக் கொண்டுள்ளது. Firecracker மூலம் Linux-க்கான சோதனை ஆதரவும் உள்ளது. இதை brew install clawkwork/tap/clawk மூலம் நிறுவலாம். ஒரு களஞ்சியத்திற்குள் clawk கட்டளையை இயக்கி sandbox-ஐத் துவக்கி ஏஜென்ட்டை இணைக்கலாம், clawk down மூலம் அதை நிறுத்தலாம், மற்றும் clawk destroy மூலம் அதை நீக்கலாம். இதன் எல்லை ஒரு ஹைப்பர்வைசர் (hypervisor) ஆகும், இது மிகவும் வலிமையானது. இதன் வரம்பு என்னவென்றால், இந்த VM நீங்கள் எடுத்துச் செல்லும் இயந்திரத்திலேயே இயங்குகிறது. எனவே, இது உங்கள் நினைவகத்தைப் (memory) பகிர்ந்து கொள்கிறது மற்றும் நீங்கள் மடிக்கணினியை மூடும்போது இதுவும் நின்றுவிடும்.

ஒரு கொள்கலன் (A container). பெரும்பாலானோர் ஏற்கனவே நிறுவியிருக்கும் Docker இதற்கான தீர்வாகும், இது மிகவும் பயனுள்ளது.

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

--rm வெளியேறும்போது கொள்கலனை நீக்கிவிடும் மற்றும் --network none அதற்கு எந்த நெட்வொர்க் அணுகலையும் வழங்காது. இது ஒரு build அல்லது test run-க்குச் சிறந்த இயல்புநிலை அமைப்பாகும். இது எதைச் செய்யாது என்பதில் தெளிவாக இருங்கள்: ஒரு கொள்கலன் host kernel-ஐப் பகிர்ந்து கொள்கிறது. எனவே, ஒரு kernel bug மூலம் வெளியேற முடியும். நீங்கள் --privileged-ஐச் சேர்த்தாலோ அல்லது /var/run/docker.sock-ஐ மவுண்ட் (mount) செய்தாலோ ஏஜென்ட் "Docker-ஐப் பயன்படுத்த" முடியும், அப்போது இந்த எல்லை மறைந்துவிடும். Docker socket-ஐ ஒரு கொள்கலனுக்குள் மவுண்ட் செய்வது, அந்தக் கொள்கலனுக்கு host-ல் root அனுமதியை வழங்குவதற்குச் சமம்.

மீண்டும் உருவாக்கக்கூடிய ஒரு சாதாரண VPS. புதிய கருவி தேவையில்லை, உண்மையான kernel எல்லை உள்ளது, வழங்குநரின் snapshots வசதி உள்ளது, மேலும் உங்கள் மடிக்கணினியை நீங்கள் மூடினாலும் இது தொடர்ந்து இயங்கும். இந்த வழிகாட்டியின் மீதமுள்ள பகுதி இந்த முறையைத்தான் விவரிக்கிறது. நீண்ட நேரம் இயங்கும் ஏஜென்ட் பணிகளுக்கு இதுவே சிறந்தது, ஏனெனில் நான்கு மணிநேரம் எடுக்கும் ஒரு பணிக்கு நீங்கள் வீட்டிற்குச் செல்வது ஒரு பொருட்டல்ல.

VPS மாதிரி: ஏஜெண்டிற்கு எனத் தனி பயனர் கணக்கை உருவாக்குதல்

பாதுகாக்கப்பட்ட (hardened) சர்வரிலிருந்து தொடங்கவும். புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற பகுதியில் ஏஜெண்ட் சார்ந்தவை அல்லாத அடிப்படைப் பாதுகாப்பு அம்சங்கள் உள்ளன: updates, non-root login, key-only SSH, மற்றும் firewall.

பிறகு, ஏஜெண்டிற்காக மட்டுமே ஒரு கணக்கை உருவாக்கவும். இதன் மூலம், அந்த ஏஜெண்டிற்குள் ஏற்படும் பிழை சர்வரின் பிற பகுதிகளைப் பாதிக்காது.

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 என்பது ஊகிக்க கடவுச்சொல் இல்லை என்பதைக் குறிக்கிறது. நீங்கள் sudo -u agent அல்லது SSH key மூலம் அந்தக் கணக்கை அணுகலாம். agent வேண்டுமென்றே sudo குழுவில் சேர்க்கப்படவில்லை என்பதைக் கவனிக்கவும். sudo கொண்ட ஏஜெண்டிற்கு root அதிகாரம் இருக்கும். root பயனர் மற்ற அனைத்து பயனர்களின் கோப்புகளையும் படிக்க முடியும் என்பதால், நீங்கள் உருவாக்கிய இந்தத் தனிமைப்படுத்தல் வெறும் பெயரளவில் மட்டுமே இருக்கும். ஏஜெண்டிற்கு மென்பொருள் தொகுப்புகளை (packages) நிறுவ வேண்டிய அவசியம் இருந்தால், அதற்குத் தனி சர்வரைப் பயன்படுத்துவதே சிறந்தது; மாறாக, பகிரப்பட்ட சர்வரில் அதற்கு sudo அதிகாரத்தை வழங்கக்கூடாது. பொதுவான விதிகள் VPS-ல் Linux பயனர்களுக்கான குறைந்தபட்ச அதிகாரம் (least privilege) என்ற பகுதியில் உள்ளன.

அதை நம்புவதற்கு முன் எல்லையைச் சரிபார்க்கவும். agent பயனராக, உங்கள் சொந்தக் கணக்கிற்குச் சொந்தமான ஒரு கோப்பைப் படிக்க முயற்சிக்கவும்:

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

நீங்கள் cat: /home/you/.ssh/id_ed25519: Permission denied என்ற செய்தியைக் காண வேண்டும். அதற்குப் பதிலாக key விவரங்களைக் கண்டால், உங்கள் home directory 755 என்ற நிலையில் உள்ளது என்று அர்த்தம்; அதாவது தனிமைப்படுத்தல் இன்னும் சரியாகச் செயல்படவில்லை. அதைச் சரிசெய்ய sudo chmod 700 /home/you கட்டளையைப் பயன்படுத்தவும்.

நற்சான்றிதழ்களை (credentials) அந்த இயந்திரத்தில் சேமிக்க வேண்டாம்

நீங்கள் ஒரு தற்காலிக இயந்திரத்தைப் பயன்படுத்தும் நோக்கமே, அதில் உங்கள் production ரகசியங்களை நகலெடுத்தால் வீணாகிவிடும். விதி எளிதானது: அந்த இயந்திரத்தில் உள்ள எந்தவொரு நற்சான்றிதழும், இன்று மதியமே அதை மாற்ற வேண்டிய சூழல் ஏற்பட்டாலும் உங்களுக்குப் பாதிப்பை ஏற்படுத்தாததாக இருக்க வேண்டும்.

Git-க்கு, உங்கள் SSH key-ஐ நகலெடுப்பதற்குப் பதிலாக, SSH agent-ஐ forward செய்யுங்கள். Private key உங்கள் மடிக்கணினியிலேயே இருக்கும்; கையொப்பமிடுவதற்கான கோரிக்கைகள் (signature requests) மட்டுமே இணைப்பின் வழியாகச் செல்லும்.

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

இரண்டாவது கட்டளை Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. என்பதற்குப் பதிலளிக்க வேண்டும். சர்வரில் எந்தவொரு key கோப்பும் இல்லாமலேயே git push வேலை செய்யும் என்பதை இது உறுதிப்படுத்துகிறது. அதன் பிறகு அந்த இயந்திரத்தில் ls -la ~/.ssh-ஐ இயக்கி, அதில் எந்தவொரு private key-யும் இல்லை என்பதை உறுதிப்படுத்தவும்.

Agent forwarding-ல் ஒரு முக்கியமான எச்சரிக்கை உள்ளது, அதைத் தெளிவாகக் கவனிக்கவும்: நீங்கள் இணைப்பில் இருக்கும்போது, அந்த சர்வரில் root அனுமதி உள்ள எவரும், அந்த forwarded socket-ஐப் பயன்படுத்தி உங்களைப் போலவே அங்கீகாரம் (authenticate) பெற முடியும். நீங்கள் மட்டுமே பயன்படுத்தும் சர்வரில் இது ஏற்றுக்கொள்ளக்கூடிய ஒரு சமரசம். ஆனால், பகிரப்பட்ட சர்வரில் இது பாதுகாப்பானது அல்ல; அத்தகைய சூழலில், ஒரு குறிப்பிட்ட repository-க்கு மட்டும் வரையறுக்கப்பட்ட deploy key-ஐப் பயன்படுத்துவதே சிறந்த தீர்வாகும். இதற்கான தேர்வுகள் SSH key management basics பகுதியில் விளக்கப்பட்டுள்ளன.

API keys-க்கு, அந்த agent-க்கு எனத் தனிப்பட்ட key-ஐ உருவாக்கி, அதற்குச் செலவு வரம்பை (spending limit) நிர்ணயிக்கவும். அதை agent பயனர் உரிமையுள்ள, 600 mode-ல் உள்ள கோப்பில் சேமிக்கவும். இயந்திரத்தை அழிக்கும்போது, அந்த key கசிந்ததா என்று கவலைப்படுவதற்குப் பதிலாக, அதை உடனடியாக ரத்து (revoke) செய்துவிடவும். ஒவ்வொரு key-க்கும் எவ்வளவு செலவாகிறது என்பதைக் கண்காணிப்பதன் மூலமே AI agent cost control on a VPS பகுதியில் உள்ள எண்களைக் கணிக்க முடியும்.

Agent அணுகக்கூடிய network வரம்புகளைக் கட்டுப்படுத்துதல்

Filesystem isolation என்பது பாதுகாப்பின் ஒரு பகுதி மட்டுமே. மற்றொரு பகுதி egress ஆகும்: அதாவது, ஒரு process எதனுடன் தொடர்பு கொள்ள அனுமதிக்கப்படுகிறது என்பது. Linux-ல், ஒரு process-ஐ உருவாக்கிய user-ஐக் கொண்டு outbound traffic-ஐ வடிகட்ட முடியும்; இது இந்த முறைக்குச் சரியாகப் பொருந்தும்.

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

விதிகள் வரிசைப்படி வாசிக்கப்படுகின்றன, எனவே இறுதி REJECT முந்தைய வரிகள் அனுமதிக்காத அனைத்தையும் தடுத்துவிடும். இதை agent-ஆக இருந்து சோதிக்கவும்:

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

இது curl: (7) Failed to connect to example.com port 80: Connection refused பிழையுடன் தோல்வியடைய வேண்டும், ஏனெனில் connection-ஐத் தாமதப்படுத்தாமல், reject விதி உடனடியாகப் பதிலளிக்கிறது. அதே host-க்குச் செய்யப்படும் HTTPS கோரிக்கை தொடர்ந்து வெற்றிபெற வேண்டும்.

இரண்டு முக்கியமான வரம்புகள் உள்ளன. முதலாவதாக, sudo apt install -y iptables-persistent மற்றும் sudo netfilter-persistent save மூலம் சேமிக்காவிட்டால், அடுத்த reboot-ன் போது இந்த விதிகள் அழிந்துவிடும். இரண்டாவதாக, இது ports மற்றும் addresses-ஐ மட்டுமே வடிகட்டுகிறது, domain names-ஐ அல்ல. Port 443-ஐ அனுமதிக்கும் ஒரு விதி, இணையத்தில் உள்ள அனைத்து HTTPS host-களையும் அனுமதிக்கிறது; இது model API-ஐ அணுகப் போதுமானது, அதே சமயம் pastebin-ஐ அணுகவும் போதுமானது. ஒரு முறையான domain allow-list-க்கு, கோரப்பட்ட hostname-ஐ வாசிக்கும் proxy வழியாக traffic செல்ல வேண்டும்; இது பெரும்பாலான தனிப்பட்ட developer அமைப்புகளுக்குத் தேவையானதை விட அதிகப்படியான கட்டமைப்பாகும். உங்களிடம் உள்ளதை மட்டும் உறுதிப்படுத்திக் கொள்ளுங்கள்: port-அடிப்படையிலான egress கட்டுப்பாடு, அதுவும் நீங்கள் இழக்கத் தயாராக இருக்கும் ஒரு machine-ல்.

பணிகளுக்கு இடையே சுத்தமான நிலைக்கு திரும்புதல்

ஒவ்வொரு பணிக்கும் ஒரு சுத்தமான நிலையைப் பராமரிப்பது கவனிக்கப்படாத ஒரு நன்மையாகும். முந்தைய டிக்கெட்டில் மூன்று மணிநேரம் செலவிட்ட ஒரு agent, நிறுவப்பட்ட packages, பாதியில் நின்ற migrations, பழைய node_modules, மற்றும் யாரும் சரிபார்க்காத மாற்றங்களைக் கொண்ட git working tree ஆகியவற்றை விட்டுச் செல்கிறது. அடுத்த பணி இவை அனைத்தையும் அப்படியே பெற்றுக்கொள்கிறது; எந்தக் குழப்பம் எந்த run-க்கு உரியது என்பதைக் கண்டறியவே உங்கள் review நேரம் வீணாகிறது. ஒரு குறுகிய நோக்கமுடைய agent குறைந்த அளவிலான மாற்றங்களையே உருவாக்குகிறது. எனவே, ஒரு disposable machine-ஐ குறைந்தபட்ச மாற்றங்களைச் செய்யும் திறன் கொண்ட ஒரு கருவியுடன் இணைப்பது, diff மற்றும் எஞ்சியிருக்கும் கோப்புகளைச் சரிபார்க்கும் அளவுக்குச் சிறியதாக வைத்திருக்க உதவுகிறது.

இதற்கான எளிமையான வழி, ஒவ்வொரு பணிக்கும் ஒரு புதிய checkout-ஐ உருவாக்குவதாகும்.

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

இதன் வலுவான வடிவம், machine அமைக்கப்பட்ட பிறகு, எந்த agent-ம் அதைத் தொடுவதற்கு முன்பாக எடுக்கப்படும் provider snapshot ஆகும். அந்த snapshot-ஐ மீண்டும் பதிவேற்றுவது, packages உட்பட முழு அமைப்பையும் ஒரு தெரிந்த நிலைக்குக் கொண்டு வரும். பெரும்பாலான providers இதை control panel மூலமாகவோ அல்லது API மூலமாகவோ வழங்குகிறார்கள்; இது machine-க்குள் இயக்கும் command அல்ல. எனவே, இதற்கான துல்லியமான வழிமுறைகள் உங்கள் provider-ஐப் பொறுத்தது. machine சாதாரணமாக இருக்கும்போதே snapshot எடுப்பதே சிறந்த நடைமுறை.

உங்களுக்குத் தேவையான எதையும் இந்த disposable machine-ல் வைக்காதீர்கள்; அதாவது, கிளைகளை (branches) உள்ளூரில் சேமித்து வைப்பதற்குப் பதிலாக, அவற்றை உடனுக்குடன் push செய்யுங்கள். ஒருவேளை அந்த machine-ல் நீங்கள் இழக்க விரும்பாத தரவுகள் இருந்தால், restic backups on a VPS மூலம் முறையாக backup எடுங்கள். ஒரு machine-ஐ அழிப்பது எவ்வித பாதிப்பையும் ஏற்படுத்தாது என்ற நிலை இருந்தால் மட்டுமே, அதைத் தாராளமாகப் பயன்படுத்த முடியும்.

பல servers-க்கு பணம் செலுத்தாமல் பல தனித்தனி சூழல்களை (isolated environments) உருவாக்க விரும்பினால், ஒரு பெரிய VPS-ல் நேரடியாக guest VM-களை இயக்கலாம். Nested virtualisation on a VPS என்பது இது எவ்வாறு செயல்படுகிறது என்பதையும், உங்கள் provider இதை அனுமதிக்கிறதா என்பதை எவ்வாறு சரிபார்ப்பது என்பதையும் விளக்குகிறது. இந்தத் தனிமைப்படுத்துதல் இருபுறமும் செயல்படும்; ஒரே machine-ல் உள்ள இரண்டு agents ஒன்றையொன்று பிரிந்து செயல்படுவதற்குப் பதிலாக, அவற்றுக்கிடையே ஒருங்கிணைப்பு தேவைப்பட்டால், one Claude Code session can send text straight to another என்பதைப் பயன்படுத்தி, ஒவ்வொரு handoff-ஐயும் உங்கள் வழியாக அனுப்பாமல் நேரடியாகத் தொடர்புகொள்ளச் செய்யலாம்.

கவனத்துடன் பயன்படுத்தப்படும் மடிக்கணினி எப்போது பாதுகாப்பானது

இதைப் பற்றி வெளிப்படையாக இருங்கள், ஏனெனில் தனிமைப்படுத்துதலை (isolation) மிகைப்படுத்திக் கூறுவதுதான் மக்கள் அதைக் கவனிக்காமல் போகக் காரணமாகிறது.

ஒவ்வொரு கட்டளையையும் (command) இயக்கும் முன் நீங்கள் சரிபார்த்தால், மடிக்கணினி பாதுகாப்பானது. அனுமதி கோரும் prompt ஒரு உண்மையான கட்டுப்பாட்டு கருவியாகும், மேலும் server-ல் Claude Code-ஐ பாதுகாப்பாக இயக்குவது என்பது அதன் ஒவ்வொரு நிலையும் எதைத் தடுக்கிறது என்பதை விளக்குகிறது. உங்கள் பணி ஒரு தனி repository-ஆக இருந்து, அந்த கணினியில் production credentials எதுவும் இல்லை என்றால், பாதிப்பு ஏற்படும் எல்லை (blast radius) ஏற்கனவே சிறியதுதான். உங்கள் agent sessions குறுகிய காலமாகவும், உங்கள் கண்காணிப்பிலும் இருந்தால், ஆபத்துக்கான கால அவகாசமும் குறைவு.

நீங்கள் prompts-ஐத் தவிர்க்கத் தொடங்கும் தருணத்தில் இந்த நிலைமை மாறுகிறது. 14 August 2026 அன்று Claude Code-ல் auto mode இயல்பான அமைப்பாக (default) மாறுகிறது என்பதையும், புதிய நிறுவலில் (fresh install) கோப்புகளைத் திருத்துவதற்கு முன்போ அல்லது கட்டளைகளை இயக்குவதற்கு முன்போ அது கேட்காது என்பதையும் இப்போது சிந்திப்பது அவசியம். கவனிக்கப்படாத இயக்கங்கள் (unattended runs), இரவு நேர வேலைகள் மற்றும் நீங்கள் ஒரு திட்டத்திற்கு ஒப்புதல் அளித்துவிட்டுச் செல்லும் எந்தவொரு பணிப்பாய்வும் (workflow), பாதுகாப்பை உறுதி செய்த மனிதக் கட்டுப்பாட்டை நீக்கிவிடுகின்றன. அந்தச் சூழலில், கணினியே அதைப் பாதுகாக்க வேண்டிய கட்டாயம் ஏற்படுகிறது. இது, VPS-ல் coding agent-ஐ இயக்குவது போன்ற, agent-ன் அணுகல் எல்லையை விரிவுபடுத்தும் அனைத்துச் செயல்களுக்கும் பொருந்தும்.

இந்த முடிவு, நீங்கள் அந்த model-ஐ எவ்வளவு நம்புகிறீர்கள் என்பதைப் பற்றியது அல்ல. மாறாக, அந்த model தவறு செய்யும்போது, அதன் அருகில் என்ன இருக்கிறது என்பதைப் பற்றியது.

FAQ

ஒரு coding agent-க்கு container-ல் உள்ள isolation போதுமானதா?

பெரும்பாலான பணிகளுக்கு, ஆம், இரண்டு நிபந்தனைகளுக்கு உட்பட்டு. Container-ஐ --privileged உடன் இயக்கக்கூடாது, மேலும் அதில் /var/run/docker.sock-ஐ mount செய்யக்கூடாது. ஏனெனில் இவை இரண்டில் எது இருந்தாலும், அந்த process-க்கு host-ல் root access கிடைத்துவிடும். Container-கள் host kernel-ஐப் பகிர்ந்துகொள்வதால், virtual machine-ஐ விட இதன் பாதுகாப்பு எல்லை பலவீனமானது. இணையத்திலிருந்து பெறப்பட்ட நம்பகத்தன்மையற்ற code-ஐ agent இயக்குகிறது என்றால், ஒரு உண்மையான VM அல்லது தனி server-ஐப் பயன்படுத்துவது சிறந்தது.

Server-ல் agent-க்கு sudo தேவைப்படுமா?

தேவையில்லை. Sudo வழங்கினால், நீங்கள் உருவாக்கிய isolation பயனற்றுப் போய்விடும், ஏனெனில் root பயனர் அந்த machine-ல் உள்ள மற்ற அனைத்து account-களையும் அணுக முடியும். Sudo இல்லாத ஒரு agent பயனர் கணக்கை உருவாக்கி, அதற்கு அதன் சொந்த வேலை செய்யும் directory-ல் மட்டும் எழுதும் உரிமையை (write access) வழங்கவும். ஒரு பணிக்குக் கண்டிப்பாக package installation தேவைப்பட்டால், அந்த agent-க்கு ஒரு முழு machine-ஐ வழங்கவும்; மாறாக, பகிரப்பட்ட machine-ல் root உரிமையை வழங்க வேண்டாம்.

எனது SSH key-ஐ server-ல் வைக்காமல், agent-ஐ எப்படி git-ல் push செய்ய வைப்பது?

நீங்கள் connect செய்யும்போது ssh -A மூலம் உங்கள் SSH agent-ஐ forward செய்யவும். Private key உங்கள் laptop-லேயே இருக்கும், signature கோரிக்கைகள் மட்டும் connection வழியாகச் செல்லும். இதனால் ssh -T git@github.com மூலம் authentication நடக்கும் மற்றும் git push வேலை செய்யும். இதில் உள்ள சிக்கல் என்னவென்றால், நீங்கள் connected-ல் இருக்கும்போது அந்த server-ல் உள்ள root பயனர் forwarded socket-ஐப் பயன்படுத்த முடியும். எனவே, மற்றவர்களுடன் பகிரும் எந்த machine-லும் repository-scoped deploy key-ஐப் பயன்படுத்தவும்.

Agent-க்கு எந்த அளவுள்ள VPS தேவை?

Agent-ன் வேலை பெரும்பாலும் கோப்புகளைத் திருத்துவது (editing), build செய்வது மற்றும் test செய்வது மட்டுமே. எனவே, model-ன் தேவைக்கு ஏற்ப அல்லாமல், build-ன் தேவைக்கு ஏற்ப machine-ன் அளவைத் தீர்மானிக்கவும். Hosted model, அந்த provider-ன் hardware-ல் இயங்குகிறது, இது network traffic-ஐ மட்டுமே அதிகரிக்கும், local load-ஐ அதிகரிக்காது. Scripting வேலைகளுக்கு 2 GB RAM-ல் தொடங்கி, repository-ல் containers build செய்தாலோ அல்லது பெரிய அளவில் compile செய்தாலோ 8 GB-க்கு உயர்த்தவும்.

Machine-ஐ எவ்வளவு அடிக்கடி அழித்து மீண்டும் உருவாக்க வேண்டும்?

Machine-ன் நிலை (state) விளக்க முடியாததாக மாறும்போது அதை மீண்டும் உருவாக்கவும். குறைந்தபட்சம், அந்த machine-ல் உள்ள ஏதேனும் ஒரு credential வெளிப்பட்டிருக்கலாம் என்று சந்தேகிக்கும்போதாவது மீண்டும் உருவாக்க வேண்டும். பணிகளுக்கு இடையே ஒரு fresh checkout செய்வது அன்றாட மாற்றங்களைச் (drift) சரிசெய்யும். முதல்முறை agent-ஐ இயக்கும் முன் எடுக்கப்பட்ட snapshot, நீங்கள் மீண்டும் பழைய நிலைக்குத் திரும்ப உதவும். மீண்டும் உருவாக்குவது கடினமாகத் தோன்றினால், நீங்கள் 'disposable' என்று கருதிய machine-ல் ஏதோ முக்கியமான ஒன்று இயங்குகிறது என்று அர்த்தம்.