Claude Code-ஐ server-ல் பாதுகாப்பாக இயக்குவது எப்படி?

Claude Code-ஐ server-ல் பாதுகாப்பாக இயக்குதல்

Claude Code-ஐ server-ல் பாதுகாப்பாக இயக்க, அதன் permission prompts-ஐ எப்போதும் செயல்பாட்டில் வைத்திருக்கவும். இதை ஒரு பிரத்யேகமான, privileged அல்லாத user கணக்கின் கீழ் இயக்கவும். தானியங்கி (unattended) பணிகளுக்கு, நம்பிக்கையை மட்டும் நம்பியிருக்காமல், முறையான எல்லைகளை (boundary) உருவாக்கவும்: அதாவது, உள்ளமைக்கப்பட்ட sandbox, ஒரு container, அல்லது முக்கியமான தரவுகள் ஏதுமற்ற ஒரு தற்காலிக VPS-ஐப் பயன்படுத்தவும். --dangerously-skip-permissions flag, model-க்கும் உங்கள் shell-க்கும் இடையே உள்ள ஒப்புதல் (approval) படிநிலையை நீக்குகிறது. தானியங்கி பணிகளுக்கு இந்த வசதி பயனுள்ளதாக இருக்கலாம், ஆனால் ஒரு தவறான command-ஆல் பாதிப்பு ஏற்படாதவாறு, பாதுகாப்பான எல்லைக்குள் மட்டுமே இதைப் பயன்படுத்த வேண்டும். இந்த flag உண்மையில் எதை மாற்றுகிறது என்பதையும், படிப்படியாக எவ்வாறு பாதுகாப்பான எல்லைகளை உருவாக்குவது என்பதையும் இந்த வழிகாட்டி விளக்குகிறது.

உங்கள் கணினியில் Claude Code செய்யக்கூடியவை

Claude Code என்பது உங்கள் terminal-ல் இயங்கும் ஒரு coding agent ஆகும். இது கோப்புகளைப் படிக்கவும், எழுதவும், அதைத் தொடங்கிய பயனரின் அனுமதியுடன் shell commands-ஐ இயக்கவும் கூடியது. இதுவே இந்த கருவியின் முழுமையான பயன்: ஒரு repository-ஐ clone செய்வது, code-ஐத் திருத்துவது, tests-ஐ இயக்குவது, பிழைகளைப் படிப்பது மற்றும் code-ஐச் சரிசெய்வது என அனைத்தையும் நீங்கள் ஒவ்வொரு கட்டளையையும் தட்டச்சு செய்யாமலேயே ஒரு சுழற்சியாக (loop) இது செய்யும். நீங்கள் இன்னும் ஒரு server-ல் இதை அமைக்கவில்லை என்றால், running Claude Code on a VPS with tmux என்ற பகுதி அதன் நிறுவல் மற்றும் session கையாளுதல் முறைகளை விளக்குகிறது. இந்தப் பக்கம், ஒருமுறை நீங்கள் அதை நிறுவிய பிறகு அதற்கு நீங்கள் வழங்கும் அதிகாரத்தைப் பற்றியது.

இதன் ஆபத்து, அதே வாக்கியத்தை மீண்டும் ஒருமுறை வாசிப்பதில் உள்ளது. உங்கள் பயனர் கணக்கின் அனுமதியுடன் shell commands-ஐ இயக்கும் எந்தவொரு process-ம், உங்கள் பயனர் செய்யக்கூடிய எதையும் செய்ய முடியும். இது ~/.ssh/id_ed25519, ~/.aws/credentials மற்றும் உங்கள் பயனர் திறக்கக்கூடிய ஒவ்வொரு .env கோப்பையும் படிக்க முடியும். இது curl-ஐ இயக்கவும், server அணுகக்கூடிய எந்தவொரு host-க்கும் தரவை அனுப்பவும் முடியும். இது git push --force-ஐ இயக்க முடியும். இந்த agent-க்கு என்று சொந்த நோக்கம் எதுவும் இல்லை. ஒரு பணி தவறாக நடப்பது அல்லது அது வேலை செய்யும்போது வாசிக்கும் உரையில் வேறொருவர் எழுதிய அறிவுறுத்தல்கள் இருப்பதுதான் ஆபத்து: அது fetch செய்த ஒரு web page அல்லது அது சரிசெய்ய வேண்டிய ஒரு issue-ல் உள்ள comment போன்றவை. இரண்டாவது வகை "prompt injection" என்று அழைக்கப்படுகிறது. இதனால்தான் "இந்த model பொதுவாகச் சரியாகச் செயல்படும்" என்பது ஒரு பாதுகாப்புத் திட்டமாகாது. அறிவுறுத்தல்கள் உங்களுக்கு நெருக்கமான இடத்திலிருந்தும் வரலாம், ஏனெனில் two Claude Code sessions on the same box can send text to each other, மேலும் ஒரு sibling session-லிருந்து வரும் செய்தி என்பது, அதைப் பெறும் agent வாசிக்கும் மற்றொரு உரை மட்டுமே. நீங்கள் சராசரி செயல்பாட்டிற்காக அல்ல, தவறான செயல்பாட்டிற்காகவே திட்டமிட வேண்டும்.

அனுமதி முறைமை (permission system) குறித்த எளிய விளக்கம்

இயல்பாகவே, Claude Code ஒரு செயலைச் செய்வதற்கு முன்பு உங்களிடம் அனுமதி கேட்கும். திட்டத்தில் உள்ள கோப்புகளைப் படிப்பது பின்னணியில் அமைதியாக நடக்கும், ஆனால் ஒரு கோப்பைத் திருத்துவதற்கோ அல்லது shell command-ஐ இயக்குவதற்கோ, அது முதலில் துல்லியமான மாற்றம் அல்லது கட்டளையைக் காட்டிவிட்டு உங்கள் ஒப்புதலுக்காகக் காத்திருக்கும். நீங்கள் ஒரு செயலுக்கு மட்டும் ஒப்புதல் அளிக்கலாம் அல்லது அந்த session முழுவதும் அத்தகைய செயல்களுக்கு அனுமதி வழங்கலாம். இந்த ஒப்புதல்கள் அந்த session-க்கு மட்டுமே பொருந்தும்: CLI-ஐ விட்டு வெளியேறிவிட்டால், அடுத்த session மீண்டும் எச்சரிக்கையுடனேயே தொடங்கும். நீங்கள் நிரந்தரமாக வைத்திருக்க விரும்பும் விதிகளுக்கு, settings கோப்பில் persistent allow, ask, மற்றும் deny பட்டியல்கள் உள்ளன. உதாரணமாக: git status-ஐ அனுமதிக்கலாம், git push-க்கு அனுமதி கேட்கலாம், .env-ஐப் படிக்க மறுக்கலாம். Deny விதிகள் எப்போதும் முன்னுரிமை பெறும். 14 August 2026 அன்று auto mode இயல்பான அமைப்பாக (default) மாறவிருப்பதால், இந்த அடிப்படை முறைமை மாறிக் கொண்டிருக்கிறது. எனவே, நீங்கள் கண்காணிக்க முடியாத ஒரு server-ல் எந்த mode-ஐ இயக்க வேண்டும் என்று முடிவு செய்வதற்கு முன்பு, ஒவ்வொரு அனுமதி முறைமையும் எதை அனுமதிக்கிறது என்பதைத் தெரிந்துகொள்வது அவசியம்.

இந்த வடிவமைப்பு, ஒரு மனிதர் terminal-ஐக் கவனித்துக்கொண்டிருப்பார் என்ற அனுமானத்தில் உருவாக்கப்பட்டுள்ளது; மடிக்கணினியில் இது உண்மையாக இருக்கலாம். ஆனால் server-ல், பெரும்பாலும் யாரும் கவனிப்பதில்லை என்பதே உண்மை. நீங்கள் tmux-க்குள் ஒரு நீண்ட பணியைத் தொடங்கிவிட்டு உறங்கச் சென்றால், நள்ளிரவு 2 மணிக்கு ஒரு கேள்வியைக் கேட்டு நிற்கும் agent, காலை வரை எந்த முன்னேற்றமும் அடையாது. இந்தத் தாமதம் நேரத்தை மட்டுமல்ல, பணத்தையும் வீணாக்குகிறது, ஏனெனில் செயலற்ற Claude Code session அதன் warm prompt cache-ஐ இழக்கிறது, அடுத்த முறை அதை மீண்டும் உருவாக்கக் கூடுதல் செலவாகும். server-களில் மக்கள் skip flag-ஐப் பயன்படுத்துவதற்கு இதுவே உண்மையான காரணம், அது தீர்க்கும் சிக்கலும் உண்மையானது. இந்த வழிகாட்டியின் மீதிப் பகுதி, அனைத்துப் பாதுகாப்பு அம்சங்களையும் கைவிடாமல் இந்தச் சிக்கலை எவ்வாறு தீர்ப்பது என்பதை விளக்குகிறது.

--dangerously-skip-permissions எதை மாற்றுகிறது

claude --dangerously-skip-permissions இது ஒப்புதல் அளிக்கும் படிநிலையை முடக்குகிறது. எந்தவொரு தூண்டுதலும் (prompt) இன்றி மாற்றங்கள் நிகழும். Shell commands எந்தக் கேள்வியும் இன்றி இயங்கும். முக்கியமான கோப்புகளைப் பாதுகாக்கும் protected-path சோதனைகளும் தவிர்க்கப்படும். நீங்கள் தெளிவாகக் குறிப்பிட்ட deny விதிகள் தொடர்ந்து செயல்படும், சில தீவிரமான செயல்கள் மட்டுமே இன்னும் உறுதிப்படுத்தலைக் கேட்கும். ஆனால் இதன் சுருக்கம் இதுதான்: model எதை இயக்க முடிவு செய்கிறதோ, அது அப்படியே இயங்கும்.

ஒரு server-ல் இந்த flag-ஐப் பயன்படுத்தும்போது இரண்டு விஷயங்களைக் கவனிக்க வேண்டும். முதலாவதாக, Linux மற்றும் macOS-ல் root பயனராகவோ அல்லது sudo மூலமாகவோ Claude Code இயங்கும்போது இது தடுக்கப்படும். ஏனெனில், எந்தக் கட்டுப்பாடும் இல்லாத root பயனர், கணினியில் உள்ள எந்தவொரு கோப்பையும் அல்லது service-ஐயும் மாற்ற முடியும். முகவர் (agent) தனக்கென ஒரு unprivileged account-ஐக் கொண்டிருக்க வேண்டும், இந்த flag அதை உறுதிப்படுத்துகிறது. இரண்டாவதாக, இந்த flag model-ன் செயல்பாட்டை எந்த வகையிலும் மாற்றாது. இது மனிதரின் தலையீட்டை மட்டுமே நீக்குகிறது; எனவே, ஒரு prompt மூலம் தடுக்கப்பட்டிருக்கக்கூடிய தவறுகள் அனைத்தும் இப்போது நேரடியாகச் செயல்படுத்தப்படும்.

இதன் விளைவு இதுதான்: நீங்கள் permissions-ஐத் தவிர்க்கும்போது, "முகவர் தவறான ஒன்றைச் செய்யுமா" என்ற பாதுகாப்பு கேள்வி, "ஒரு தவறான செயல் எவ்வளவு பாதிப்பை ஏற்படுத்தும்" என்று மாறுகிறது. ஒவ்வொரு முடிவையும் கட்டுப்படுத்துவதை நிறுத்திவிட்டு, பாதிப்பின் எல்லையை (blast radius) கட்டுப்படுத்தத் தொடங்க வேண்டும். இதற்குத் தீர்வாக, containment முறைகளை அடுக்கு வாரியாகப் பயன்படுத்த வேண்டும்.

உள்ளமைக்கப்பட்ட Claude Code sandbox

கட்டளைகளை இயக்குவதற்கு முன்பு, Claude Code இப்போது தான் இயக்கும் கட்டளைகளுக்காக OS-நிலை sandbox-ஐ வழங்குகிறது என்பதைத் தெரிந்துகொள்ளுங்கள். இது, மக்கள் skip flag-ஐப் பயன்படுத்திய பெரும்பாலான காரணங்களை நீக்குகிறது. Linux-ல் இது filesystem isolation-க்காக bubblewrap-ஐயும், network traffic-ஐ proxy வழியாக அனுப்ப socat-ஐயும் பயன்படுத்துகிறது. Sandbox-க்குள், ஒரு கட்டளையானது project directory மற்றும் session temp directory-ல் மட்டுமே எழுத முடியும். ஒரு allow list-ல் உள்ள domain-களுக்கு மட்டுமே proxy வழியாக network அணுகல் கிடைக்கும். ஒரு கட்டளை புதிய domain-ஐ அணுக முயலும் முதல்முறை, Claude Code உங்களிடம் அனுமதி கேட்கும்.

ஒரு session-க்குள் /sandbox கட்டளையைப் பயன்படுத்தி இதை இயக்கலாம். Ubuntu மற்றும் Debian-ல், இதற்குத் தேவையான இரண்டு packages-ஐ முதலில் நிறுவவும்:

sudo apt install bubblewrap socat

Ubuntu 24.04 மற்றும் அதற்குப் பிந்தைய பதிப்புகளில், இயல்புநிலை AppArmor policy, bubblewrap-க்குத் தேவையான user namespaces-ஐ உருவாக்குவதைத் தடுக்கிறது. ஏதேனும் விடுபட்டிருந்தால் sandbox panel உங்களுக்குத் தெரிவிக்கும். Claude Code sandboxing ஆவணத்தில் இதைச் சரிசெய்யும் சிறிய AppArmor profile உள்ளது.

Sandbox-ல் auto-allow mode உள்ளது: அமல்படுத்தப்பட்ட எல்லைகள் (enforced boundary) முன்பு கேட்கப்பட்ட கேள்விகளின் வேலையைச் செய்வதால், sandbox கட்டளைகள் எந்தவிதக் கேள்வியும் இன்றி இயங்கும். Sandbox-க்குள் இயங்க முடியாத கட்டளைகள் சாதாரண அனுமதி முறைக்குத் (normal permission flow) திரும்பும், எனவே வழக்கத்திற்கு மாறான செயல்களுக்கு மட்டும் அனுமதி கேட்கப்படும். பெரும்பாலான server பணிகளுக்கு இதுவே skip flag-க்குச் சரியான மாற்றாகும், ஏனெனில் எந்தக் கேள்வியும் கேட்கப்படாமல் இருப்பதற்குப் பதிலாக, OS-ஆல் அமல்படுத்தப்பட்ட எல்லையுடன் மிகக் குறைவான கேள்விகளே கேட்கப்படும்.

இதன் வரம்புகளைப் புரிந்துகொள்ளுங்கள். இயல்பாக, ஒரு sandboxed கட்டளை filesystem-ன் பெரும்பாலான பகுதிகளை, credential files உட்பட வாசிக்க முடியும்; நீங்கள் அந்தப் பாதைகளைத் (paths) தடுக்கவில்லை என்றால் இது நடக்கும். இதற்காகவே sandbox.credentials அமைப்பு உள்ளது. Network proxy domain பெயர்களை மட்டுமே சரிபார்க்கும், traffic-ஐ ஆய்வு செய்யாது. எனவே, github.com போன்ற பரந்த அனுமதி, தரவை வெளியேற்ற வாய்ப்பளிக்கும். இதற்குள் Docker இயங்காது. Sandbox பாதுகாப்பை கணிசமாக உயர்த்துகிறது. இது முழுமையான isolation boundary அல்ல, அதனால்தான் கீழே உள்ள பாதுகாப்பு நிலைகள் (rungs) இன்னும் முக்கியத்துவம் பெறுகின்றன.

தனிமைப்படுத்தல் ஏணி (Containment ladder)

மூன்று நிலைகள், தனிமைப்படுத்தல் அதிகரிக்கும் வரிசையில். உங்கள் server-ல் ஏற்கனவே உள்ளவற்றுடன் ஒத்துப்போகும் மிகக் குறைந்த நிலையைத் தேர்ந்தெடுக்கவும்.

நிலை 1: பிரத்யேகமான unprivileged user. Agent-க்கு எனத் தனி account, தனி home directory, தனி project directory மற்றும் sudo அனுமதி கிடையாது:

sudo adduser --disabled-password --gecos "" agent

இந்த account எல்லை, உங்கள் கோப்புகளிலிருந்து agent-ஐத் தள்ளி வைக்கிறது: உங்கள் SSH keys மற்றும் server-ல் உள்ள பிற projects பாதுகாக்கப்படுகின்றன. இது skip flag-ஐப் பயன்படுத்தவும் வழிவகை செய்கிறது, ஏனெனில் root-ஆக இயங்கும்போது இந்த flag இயங்காது. இது ஒவ்வொரு service-ஐயும் unprivileged user-ஆக இயக்குதல் என்ற கொள்கையின் அடிப்படையில், agent-க்குச் செயல்படுத்தப்படுகிறது. நிலை 1 எவற்றைக் கட்டுப்படுத்தாது: network மற்றும் server-ல் world-readable நிலையில் உள்ள கோப்புகள்.

நிலை 2: ஒரு container. Anthropic ஒரு reference devcontainer-ஐ வழங்குகிறது; இது Claude Code-ஐ non-root user-ஆக இயக்குகிறது. இதில் உள்ள firewall விதிகள், agent அணுகக்கூடிய hosts-ஐக் கட்டுப்படுத்துகின்றன. நீங்களே உருவாக்கும் container-ம் இதே பணியைச் செய்யும். நீங்கள் mount செய்யும் volumes-க்கு மட்டுமே filesystem சுருங்கும், container-ன் விதிகளுக்கு உட்பட்டே egress அமையும். உங்கள் server-ல் பிற முக்கியமான services இயங்கும்போது, இதுவே சரியான இடைநிலைத் தீர்வாகும். இதன் குறைபாடு என்னவென்றால், containers அனைத்தும் host kernel-ஐப் பகிர்ந்து கொள்கின்றன; கவனக்குறைவாகச் செய்யப்படும் ஒரு mount இந்த எல்லையைத் தகர்த்துவிடும்; container-க்கு /var/run/docker.sock வழங்கினால், அது முழு host-ஐயும் அணுக முடியும்.

நிலை 3: பிரத்யேகமான VPS. மிக வலுவான மற்றும் நேரடியான வழி: உங்களுக்கு முக்கியமில்லாத ஒரு முழு இயந்திரத்தை agent-க்கு ஒதுக்குங்கள். ஒரு சிறிய VPS-க்கு மாதத்திற்குச் சில டாலர்கள் மட்டுமே செலவாகும். புதிய VPS-க்கான முதல் பத்து நிமிட runbook-ஐப் பின்பற்றி அதை அமைக்கவும், அதன் clean state-ஐ snapshot எடுத்துக்கொள்ளவும், பிறகு agent-ஐ வேலை செய்ய விடவும். அங்கு வேறு எதுவும் இருக்காது. தனிப்பட்ட SSH key கிடையாது, அந்த ஒரு repository-க்கு மட்டும் வரையறுக்கப்பட்ட deploy key மட்டுமே இருக்கும். Cloud credentials கிடையாது, production தரவுகள் கிடையாது. ஒரு பணி தவறாக நடந்தாலோ அல்லது உங்களுக்கு ஒரு புதிய தொடக்கம் தேவைப்பட்டாலோ, snapshot-ஐ restore செய்யவும் அல்லது சில நிமிடங்களில் server-ஐ அழித்துவிட்டு மீண்டும் உருவாக்கவும். பாதிப்பு என்பது நீங்கள் செலுத்தும் வாடகைக்கு உட்பட்டது. இந்த அமைப்பில் --dangerously-skip-permissions அச்சமூட்டுவதாக இருக்காது, ஏனெனில் மோசமான சூழலிலும் ஒரு server-ஐ மீண்டும் உருவாக்குவதும், ஒரு token-ஐ ரத்து செய்வதுமே நடக்கும்.

இந்த நிலைகளை ஒன்றன் மேல் ஒன்றாகப் பயன்படுத்தலாம். ஒரு disposable VPS-ல், unprivileged user-ஆக இயங்கும் sandboxed agent-க்குக் கூடுதல் செலவு ஏதுமில்லை, இது தோல்விகளைச் சாதாரணமானதாக மாற்றுகிறது. சலிப்பூட்டும் வகையிலான பாதுகாப்பே நமது இலக்கு.

நற்சான்றிதழ்களைப் பாதுகாத்தல்

மற்ற அனைத்தையும் விட முக்கியமான விதி இது: ஏஜெண்டின் பயனர் கணக்கு, தனக்குச் சொந்தமில்லாத எந்தவொரு ரகசியத்தையும் (secrets) படிக்க அனுமதிக்கப்படக்கூடாது.

API key-ஐ ஏஜெண்டிற்கு மட்டும் வழங்கவும், வேறு எதற்கும் வழங்க வேண்டாம். ஏஜெண்டின் பயனர் கணக்கிற்குச் சொந்தமான ஒரு கோப்பில் அதை வைத்து, mode 600-ஐ அமைக்கவும். shell தொடங்கும் போது அதை load செய்யவும்:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

பின்பு மற்ற வழிகளை மூடவும். Debian மற்றும் Ubuntu-வில், home directories பெரும்பாலும் கணினியில் உள்ள அனைத்து பயனர்களும் படிக்கும் வகையில் உருவாக்கப்படுகின்றன. எனவே, உங்களுடையதை இறுக்கமாக்குங்கள்: chmod 750 /home/youruser. ls -ld /home/* மூலம் சரிபார்த்து, ஏஜெண்டின் கணக்கினால் பட்டியலிடக்கூடிய எதையும் சரிசெய்யவும்.

ஒவ்வொரு token-க்கும் வரம்புகளை நிர்ணயிக்கவும். ஒரு repository-க்கு மட்டும் கட்டுப்படுத்தப்பட்ட GitHub token அல்லது ஒவ்வொரு repository-க்கும் தனித்தனி deploy key-ஐப் பயன்படுத்துவது, ஒரு நற்சான்றிதழ் கசிந்தால் ஒரு திட்டத்தை மட்டுமே பாதிக்கும், உங்கள் முழு கணக்கையும் பாதிக்காது. நீங்கள் sandbox-ஐப் பயன்படுத்தினால், அதன் நற்சான்றிதழ் அமைப்புகளைச் சேர்க்கவும், இதனால் ~/.ssh மற்றும் ~/.aws ஆகியவை வாசிப்பு அனுமதியைக் கூட பெற முடியாது. மேலும், production நற்சான்றிதழ்களை இந்த கணினியில் வைக்க வேண்டாம்; ஏனெனில், இல்லாத ஒரு ரகசியத்தை ஏஜெண்டால் கசியவிட முடியாது. அந்த ரகசியங்கள் ஒரு self-hosted password manager-ல் இருந்தால், அதை ஏஜெண்ட் இருக்கும் கணினியிலிருந்து வேறொரு கணினியில் வைக்கவும். அதற்குத் தனிப்பட்ட தணிக்கையை மேற்கொள்ளவும், ஏனெனில் Vaultwarden-ன் பலவீனமான புள்ளிகள் அதன் admin token மற்றும் backup கோப்பு ஆகும், குறியாக்கம் செய்யப்பட்ட vault அல்ல.

Git ஒரு பாதுகாப்பு வலை

ஏஜென்ட் செய்யும் ஒவ்வொரு மாற்றமும் மறுஆய்வு செய்யக்கூடியதாகவும், பழைய நிலைக்கு மாற்றக்கூடியதாகவும் இருக்க வேண்டும். ஏஜென்ட் ஒரு தனி branch-ல் வேலை செய்தால், git இந்த இரண்டு வசதிகளையும் இலவசமாக வழங்குகிறது:

git switch -c agent/refactor-auth

ஏஜென்ட் செய்த மாற்றங்களை git diff main...agent/refactor-auth மூலம் மறுஆய்வு செய்யுங்கள். சரியான மாற்றங்களை merge செய்யுங்கள், ஏஜென்ட்டின் செயல்பாடு பலனளிக்கவில்லை என்றால் அந்த branch-ஐ நீக்கிவிடுங்கள். மூன்று கோப்புகளை மட்டும் மாற்றிய ஒரு செயல்பாட்டை, ஒரு module-ன் பாதியையே மாற்றிய செயல்பாட்டை விட, காலை நேரத்தில் படிப்பது மிகவும் எளிது. இதுவே ஏஜென்ட்டை மிகச்சிறிய மாற்றங்களை மட்டும் செய்ய வைக்கும் திறன் என்பதற்கான நடைமுறைச் சான்றாகும். உங்கள் code forge தளத்தில் main branch-ஐப் பாதுகாக்கவும்; இதன் மூலம் ஏஜென்ட்டின் token-ஆல் main branch-ல் நேரடியாக மாற்றங்களைச் செய்யவோ அல்லது force-push செய்யவோ முடியாது. நீங்கள் உறங்கிக்கொண்டிருந்தபோது என்ன நடந்தது என்பதற்கான தணிக்கை பதிவாக (audit log) இந்த commit history அமைகிறது. இது terminal-ல் நீங்கள் பின்னோக்கிச் சென்று பார்ப்பதை விட அதிக மதிப்புடையது.

நெட்வொர்க் என்பது பாதிப்பு எல்லைக்குள் (blast radius) அடங்கும்

ஒரு agent curl-ஐ இயக்க முடியும். அந்த வாக்கியமே egress சிக்கலின் முழுமையாகும்: agent எதைப் படிக்க முடியுமோ, அதை எங்காவது அனுப்பவும் முடியும்; prompt-injection செய்யப்பட்ட ஒரு agent இதைச் செய்யக்கூடும். சாதாரண unprivileged user-ஆல் இதைத் தடுக்க முடியாது, ஏனெனில் server அணுகக்கூடிய எதையும் எந்தவொரு பயனரும் அணுக முடியும். Sandbox அதன் proxy மூலம் இதை domain அடிப்படையில் கட்டுப்படுத்துகிறது. ஒரு container அதன் சொந்த firewall விதிகள் மூலம் இதைக் கட்டுப்படுத்தலாம். மூன்றில், ஒரு பிரத்யேக VPS-ஐப் பயன்படுத்துவதே கசிவைத் தடுப்பதற்கான மிகவும் வலுவான தீர்வாகும்.

Egress சிக்கலைத் தீர்க்க ufw-ஐ மட்டும் நம்ப வேண்டாம். ufw இயல்பாகவே அனைத்து வெளிச்செல்லும் (outgoing) போக்குவரத்தையும் அனுமதிக்கிறது. apt, npm, git மற்றும் Claude API ஆகியவற்றை அனுமதிக்கும் வகையில் outbound விதிகளை எழுதுவது கடினமான வேலை, மேலும் அது அமைதியாகச் செயலிழக்கக்கூடும். அதற்குப் பதிலாக sandbox, container அல்லது machine மட்டத்தில் எல்லையைத் தீர்மானியுங்கள்; அங்கு ஒரு domain allow list அல்லது தனி machine மூலம் இதைச் சுத்தமாகச் செய்ய முடியும்.

நீங்கள் Claude Code-ஐ இயக்காமல், API-ஐப் பயன்படுத்தி சொந்தமாக agent-ஐ உருவாக்குகிறீர்கள் என்றால், இதே கொள்கையே பொருந்தும். VPS-ல் Claude உடன் AI agent-ஐ உருவாக்குதல் என்ற பகுதி அந்த வழியை விளக்குகிறது. அந்த agent-க்கும் அதே பிரத்யேக பயனர், அதே வரையறுக்கப்பட்ட tokens மற்றும் அதே disposable box ஆகியவற்றைப் பயன்படுத்துவது அவசியம்.

முதலில் server-ஐ பலப்படுத்தவும்

நீங்கள் எந்த முறையைத் தேர்ந்தெடுத்தாலும், agent-ஐ நிறுவும் முன் server-க்கு அடிப்படைப் பாதுகாப்பு அவசியம்: SSH keys-ஐ மட்டுமே பயன்படுத்தவும், root login-ஐ முடக்கவும், default-deny firewall-ஐ அமைக்கவும், automatic security updates-ஐச் செயல்படுத்தவும். உங்கள் சரிபார்ப்புப் பட்டியலை (checklist) இங்கே உருவாக்கி, ஒவ்வொன்றாகச் செய்து முடிக்கவும்:

FAQ

--dangerously-skip-permissions-ஐ server-ல் பயன்படுத்துவது பாதுகாப்பானதா?

அதுவாக மட்டும் பாதுகாப்பானது அல்ல. இந்த flag அனைத்து உறுதிப்படுத்தல் கோரிக்கைகளையும் (approval prompts) நீக்கிவிடுகிறது, எனவே model ஒரு தவறான கட்டளையை உருவாக்கியவுடன் அது உடனடியாக இயங்கிவிடும். பாதிப்பு ஏற்படும் எல்லை (blast radius) கட்டுக்குள் இருக்கும்போது மட்டுமே இதை ஒரு நியாயமான தேர்வாகக் கருதலாம்: குறைந்தபட்சம் ஒரு unprivileged user-ஐப் பயன்படுத்துவது அவசியம். உண்மையான unattended பணிகளுக்கு, ஒரு project மற்றும் குறிப்பிட்ட token-ஐ மட்டும் கொண்ட container அல்லது disposable VPS-ஐப் பயன்படுத்துங்கள். production credentials அல்லது இழக்கக்கூடாத தரவுகள் உள்ள எந்தவொரு machine-லும் இதை ஒருபோதும் பயன்படுத்த வேண்டாம்.

Claude Code-ல் sandbox உள்ளதா?

ஆம். Claude Code-ல் shell கட்டளைகளுக்காக உள்ளமைக்கப்பட்ட (built-in) sandbox உள்ளது, இதை /sandbox கட்டளை மூலம் திறக்கலாம். இது Linux-ல் bubblewrap-ஐயும், macOS-ல் Seatbelt-ஐயும் பயன்படுத்துகிறது. இது project directory-க்குள் மட்டுமே எழுதும் உரிமையை மட்டுப்படுத்துகிறது மற்றும் அங்கீகரிக்கப்பட்ட domains-க்கு மட்டுமே network access-ஐ அனுமதிக்கிறது. இதன் auto-allow mode, sandbox-க்குள் கட்டளைகளை உறுதிப்படுத்தல் இன்றி இயக்கும். இது skip flag செய்வது போலவே இடையூறுகளைக் குறைக்கிறது, அதே சமயம் OS-ஆல் அமல்படுத்தப்பட்ட ஒரு எல்லையைத் தக்கவைக்கிறது. இது முழுமையான தனிமைப்படுத்தப்பட்ட எல்லை அல்ல, எனவே unattended பணிகளுக்கு இதை ஒரு dedicated user அல்லது dedicated machine-உடன் சேர்த்துப் பயன்படுத்துங்கள்.

skip flag ஏன் root-ஆக இயங்குவதை மறுக்கிறது?

ஏனெனில், உறுதிப்படுத்தல் கோரிக்கைகள் இல்லாத root பயனர், கணினியில் உள்ள எந்தவொரு கோப்பையும் எந்தவொரு சேவையையும் மாற்றியமைக்க முடியும். எனவே, Linux மற்றும் macOS-ல் root-ஆகவோ அல்லது sudo மூலமாகவோ இயங்கும்போது Claude Code --dangerously-skip-permissions-ஐத் தடுக்கிறது. இந்தச் சோதனையைத் தவிர்க்க முயற்சி செய்யாதீர்கள். agent-க்காக ஒரு unprivileged user-ஐ உருவாக்கி, அங்கு அதை இயக்குங்கள்; அந்த account எல்லைதான் பாதுகாப்பின் முதல் மற்றும் மலிவான அடுக்கு.

Claude Code எனது SSH keys மற்றும் .env கோப்புகளைப் படிக்க முடியுமா?

அது எந்தப் பயனராக இயங்குகிறதோ, அந்தப் பயனர் படிக்கக்கூடிய அனைத்தையும் அது படிக்க முடியும். sandbox-ன் இயல்புநிலை கொள்கை கூட, நீங்கள் மறுக்கும் வரை credential பாதைகளைப் படிக்க அனுமதிக்கிறது. எனவே, agent-ஐ அதன் சொந்த பயனர் கணக்கில் இயக்குங்கள், உங்கள் home directory-ஐ 750 அல்லது அதற்கும் குறைவான mode-ல் வைத்திருங்கள், sandbox அமைப்புகளில் credential பாதைகளை மறுத்துவிடுங்கள், மேலும் production secrets-ஐ அந்த machine-ல் வைக்காதீர்கள். ஒரு secret அந்தப் பெட்டிக்குள் ஒருபோதும் இருக்கவில்லை என்றால், அதை வாசிக்கவோ அல்லது கசியவிடவோ முடியாது.

Claude Code-ஐ unattended முறையில் இயக்க மிகவும் பாதுகாப்பான வழி எது?

agent பணிகளுக்காக மட்டுமே பயன்படுத்தப்படும் ஒரு மலிவான dedicated VPS: பத்து நிமிடங்களில் hardened செய்யப்பட்டு, clean snapshot எடுக்கப்பட்டு, unprivileged user-ன் கீழ் sandbox-உடன் Claude Code-ஐ இயக்குவது. API key-ஐ mode-600 கோப்பில் வைத்திருங்கள், ஒவ்வொரு repository-க்கும் தனித்தனி deploy key-ஐப் பயன்படுத்துங்கள், மேலும் அனைத்து வேலைகளையும் நீங்கள் merge செய்வதற்கு முன் review செய்யும் branches-ல் செய்யுங்கள். ஒருவேளை செயல்பாடு தவறாக நடந்தால், ஒரு token-ஐ revoke செய்துவிட்டு snapshot-ஐ restore செய்யுங்கள்; இதனால் உங்களுக்குச் சொந்தமான மற்றவை பாதிக்கப்படாது.