AI Coding Agents के लिए सुरक्षित तरीके से अलग Unix Accounts

AI coding agent को अपना Unix login देना ऐसा shortcut है जिसका असर बहुत दूर तक जाता है। Agent को वे files मिल जाती हैं जिनका अस्तित्व आप भूल चुके हैं, वे credentials जिन्हें tooling ने वर्षों पहले cache किया था, ढीली SSH configuration, deployment scripts और किसी गलत बदलाव को आपके सामान्य काम जैसा दिखाने की क्षमता भी। Dedicated remote account agent को harmless नहीं बनाता, लेकिन उसके अधिकारों को दिखाई देने वाला और सीमित करने योग्य जरूर बनाता है।

Account को किसी खास काम की सीमा मानें। अगर agent को एक repository edit करनी है, उसका test suite चलाना है और branch push करनी है, तो ऐसा identity बनाएं जो केवल ये काम कर सके। अपने developer account से शुरू करके बाद में privileges घटाने की कोशिश न करें। Unix permissions groups, mounted directories, shell configuration और उन tools के जरिए बढ़ती जाती हैं जो मान लेते हैं कि सामने इंसान है।

अलग Unix account agent को अलग identity देता है

Dedicated account agent को अलग UID, process owner, home directory, SSH authorization set और audit trail देता है। ये पांच बातें उस clever prompt से कहीं ज्यादा महत्वपूर्ण हैं जिसमें agent को repository के भीतर रहने को कहा गया हो।

जब agent alex के रूप में चलता है, तो उसके शुरू किए हर process का मालिक alex होता है। वह हर वह चीज पढ़ सकता है जिसे alex पढ़ सकता है। Forwarding या sockets खुले हों तो वह alex के SSH agent का इस्तेमाल कर सकता है। वह shell history, Git credentials, cloud configuration, package manager caches और alex के स्वामित्व वाली या उसके लिए readable project directories देख सकता है। आज agent पूरी तरह सही व्यवहार करे, तब भी उसकी भविष्य की permissions आपके अपने account में जोड़ी गई हर सुविधा पर निर्भर हो जाती हैं।

agentbuild जैसा account शुरुआती स्थिति को जांचने योग्य बनाता है:

id agentbuild
getent passwd agentbuild
sudo -u agentbuild sh -lc 'umask; pwd; env | sort'

सामान्य Linux host पर पहली command में UID और छोटी-सी group list दिखनी चाहिए। दूसरी में /srv/agentbuild या /home/agentbuild जैसा home directory दिखना चाहिए, किसी human developer का home नहीं। आखिरी command एक छिपी समस्या पकड़ती है: inherited environment variables credential files, proxies, token caches या असामान्य executable paths की ओर इशारा कर सकते हैं।

यह अंतर अक्सर धुंधला कर दिया जाता है: अलग SSH key, अलग account नहीं होती। नई key अगर आपके मौजूदा account में login करती है, तो वह केवल authentication बदलती है। Login के बाद उपलब्ध files, commands या network configuration कम नहीं होते। अलग authentication और अलग authorization दो अलग समस्याएं हल करते हैं।

स्थिर काम के लिए स्थिर account रखें। एक agent pull requests बनाता है और दूसरा release artifacts deploy करता है, तो उन्हें अलग identities दें। तब आप बिना अनुमान के पूछ सकेंगे: इस account ने कौन-सी file बदली, कौन-सा network connection खोला या कौन-सा process बनाया?

Account boundary हर तरह के नुकसान को नहीं रोकती

Unix account Unix ownership, groups, access control lists और permissions से नियंत्रित access सीमित करता है। यह अपने-आप network destinations, CPU use, disk exhaustion, kernel vulnerabilities, world-readable files या shared service credential से मिली पहुंच को सीमित नहीं करता।

फिर भी यह boundary उपयोगी है। Coding agent के पास source बदलने, package scripts चलाने, configuration पढ़ने और Git इस्तेमाल करने की पर्याप्त क्षमता होती है। Package scripts मनमाने shell commands चला सकते हैं। Build systems environment variables पढ़ सकते हैं। Compromised dependency भी यही कर सकती है। मानकर चलें कि host जिस code को agent चलाने को कहता है, उसे वही permissions मिलती हैं जो उसे चलाने वाले account को मिली हैं।

Account separation को container, virtual machine या network firewall न समझें। इनका काम अलग है:

• Unix account local files, process ownership और सामान्य command permissions अलग करता है।
• Container filesystem views और resource usage सीमित कर सकता है, लेकिन गलत तरीके से mount की गई host directory यह लाभ खत्म कर देती है।
• जहां workload की जरूरत हो, वहां virtual machine operating system की मजबूत सीमा देती है।
• Network controls तय करते हैं कि account कहां connect कर सकता है और host से क्या बाहर जा सकता है।

Failure के असर के अनुसार सबसे छोटा उपयुक्त संयोजन चुनें। Disposable test checkout के लिए isolated worker पर dedicated account पर्याप्त हो सकता है। Production deployment host के लिए restricted SSH, सीमित deployment credentials, logging और egress policy के साथ account boundary इस्तेमाल करें। अगर agent production databases या signing material तक पहुंच सकता है, तो केवल अलग UID साफ तौर पर पर्याप्त नहीं है।

एक आम लेकिन गलत सलाह है कि account बनाकर उसे developer जैसे operational groups में जोड़ दें, ताकि builds चल सकें। इससे वही समस्या दूसरे username के नीचे लौट आती है। docker, libvirt, backup groups, device groups और privileged log groups जैसे groups अपने साधारण नामों से कहीं अधिक अधिकार दे सकते हैं। कई systems में docker group की membership host का प्रभावी control देती है, क्योंकि member host filesystem mount करके container शुरू कर सकता है।

Account ऐसी inheritance trail के बिना बनाएं

Remote account को password login के बिना, administrator group के बिना और ऐसे home directory के साथ बनाएं जिसमें केवल वे files हों जिन्हें आप जान-बूझकर रखते हैं। शुरुआत खाली से करें, क्योंकि copied dotfiles accidental authority का आम स्रोत हैं।

Exact commands operating system के अनुसार बदलती हैं। Debian या Ubuntu style host पर administrator dedicated home directory वाला local account इस तरह बना सकता है:

sudo adduser --disabled-password --gecos '' --home /srv/agentbuild agentbuild
sudo passwd -l agentbuild
sudo install -d -m 700 -o agentbuild -g agentbuild /srv/agentbuild/.ssh
sudo -u agentbuild touch /srv/agentbuild/.hushlogin

--disabled-password नए account के लिए सामान्य password authentication रोकता है। passwd -l password locking वाले systems पर इस इरादे को स्पष्ट करता है। इनमें से किसी को भी अपना अकेला SSH control न मानें: SSH server की अपनी password authentication settings होती हैं और install की गई key अभी भी authenticate कर सकती है।

useradd वाले systems पर ऐसे options इस्तेमाल करें जो home directory और private group बनाएं, फिर memory पर भरोसा करने के बजाय परिणाम जांचें। BSD और macOS account management के लिए अलग tools हैं, इसलिए अलग host पर Linux commands paste करने के बजाय स्थानीय dscl, sysadminctl या system administration manual देखें।

Ownership तुरंत जांचें:

namei -l /srv/agentbuild/.ssh
sudo -u agentbuild sh -lc 'touch ~/permission-test && ls -ln ~/permission-test'
sudo rm /srv/agentbuild/permission-test

namei output path के हर component को दिखाता है। किसी parent directory को असंबंधित group को write access नहीं देना चाहिए, क्योंकि इससे कोई .ssh directory बदल सकता है या उसके भीतर की files से छेड़छाड़ कर सकता है। Test file में account का numeric UID और primary GID दिखना चाहिए।

अपने .bashrc, .zshrc, .gitconfig या editor directory को समय बचाने के लिए इस home में copy न करें। इन files में private package registries, helper aliases, SSH settings, credential managers और shell hooks आ सकते हैं। Agent को जरूरत क्यों है, यह समझाने के बाद ही individual settings जोड़ें। Remote automation के लिए सामान्यतः plain noninteractive shell ही default होना चाहिए।

Agent के execution environment में conservative creation mask रखें। umask को 077 रखने पर नई regular files account तक private रहती हैं, जब तक कोई command अलग permissions स्पष्ट रूप से न चुने। इससे कभी-कभी build की कोई धारणा सामने आएगी। यह अच्छी बात है। हर local user के लिए generated files readable बनाने के बजाय build के sharing point को जान-बूझकर ठीक करें।

Shared repositories के लिए ownership rule पहले तय करें

Agent को ऐसे checkout में काम करना चाहिए जिसका मालिक वही account हो, या ऐसे project directory में जिसकी group और permissions आप समझा सकें। Developers, deployment tools और agents जब अलग users के रूप में एक ही directory में लिखते हैं, तो पहली जल्दबाजी वाली permission fix के बाद स्थिति समझना मुश्किल हो जाती है।

सबसे साफ तरीका है कि checkout पूरी तरह agent account के स्वामित्व में हो। Human version control के जरिए changes review करता है या नियंत्रित group access से files पढ़ता है। इससे local collaboration की अधिकतर उलझन दूर होती है और Git आपको सही handoff mechanism देता है।

कभी-कभी agent को common build tree में लिखना पड़ता है। तब dedicated project group बनाएं और shared directory पर group ID bit लगाएं, ताकि नई files group inherit करें:

sudo groupadd projectbuild
sudo usermod -aG projectbuild agentbuild
sudo install -d -m 2770 -o releasebot -g projectbuild /srv/project-build
sudo setfacl -m u:agentbuild:rwx /srv/project-build
sudo setfacl -d -m g:projectbuild:rwx /srv/project-build

इस example को अपने ownership model के अनुसार बदलना होगा। बात यह नहीं कि access control lists fashionable हैं। बात यह है कि collaboration surface को नाम दें और write access उसी तक सीमित रखें। Permission error पर chmod -R 777 चलाकर या पूरे source tree को shared administrator group में डालकर जवाब न दें। दोनों तरीके समस्या छिपाते हैं, जब तक कोई ऐसी जगह लिख न दे जहां उसे नहीं लिखना चाहिए।

Build directory में symlinks होने पर एक छिपी समस्या आती है। Agent के पास /srv/project-build के लिए write permission हो सकती है, जबकि उसके भीतर का symlink /etc, release directory या किसी human home की ओर जाता हो। Broad recursive access देने से पहले setup scripts और generated directories जांचें। Account boundary केवल उन्हीं paths को सुरक्षित करती है जिन्हें filesystem वास्तव में उस account की permissions के तहत evaluate करता है।

Git से जुड़ी ownership check भी है। Modern Git उस repository को dubious ownership कहकर अस्वीकार कर सकता है जो किसी दूसरे user की लगती हो। Agent की global safe.directory settings में मनमानी directories जोड़कर समस्या हल न करें। Checkout का मालिक वही account बनाएं जो Git चला रहा है। Shared checkout जरूरी हो तो उसका ownership document करें और कारण समझने के बाद केवल वही specific path जोड़ें।

SSH access controller की पहचान करे और session सीमित रखे

Agent controller के लिए dedicated SSH public key इस्तेमाल करें। Workflow अनुमति दे तो authorized_keys में उसी key पर restrictions लगाएं। Dedicated account और unrestricted interactive shell, developer login साझा करने से बेहतर हैं, लेकिन autonomous process को तब भी commands का बड़ा surface मिलता है।

OpenSSH उपलब्ध controls को sshd_config(5) और authorized_keys में document करता है। PasswordAuthentication no server level पर password logins बंद करता है। AllowUsers तय कर सकता है कि कौन login करे। Per-key options port forwarding, agent forwarding, X11 forwarding और pseudo terminal allocation बंद कर सकते हैं। ये सामान्य controls हैं, कोई अजीब SSH setup नहीं।

जिस agent को केवल Git command लेना या fixed wrapper चलाना हो, उसके लिए authorized_keys entry ऐसी हो सकती है:

restrict,command="/usr/local/libexec/agent-git-wrapper" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... agent-controller

restrict OpenSSH का shorthand है, जो कई forwarding और session features बंद करता है, हालांकि यह server version और manual page पर निर्भर है। Forced command का अर्थ है कि server client के अनुरोधित command के बजाय wrapper चलाएगा। भरोसा करने से पहले अपने installed OpenSSH version को जांचें, क्योंकि पुराने hosts हर restriction को support नहीं कर सकते।

Wrapper को अपने inputs खुद validate करने चाहिए। Forced command किसी लापरवाह script को security boundary नहीं बनाता। अगर वह client से मिले unquoted command को sh -c में भेजता है, तो client फिर command execution पा सकता है। Wrapper छोटा रखें, fixed paths इस्तेमाल करें, unexpected arguments अस्वीकार करें और request log करें।

General coding agent को inspect, edit, build और test करने के लिए shell चाहिए हो तो forced commands बहुत restrictive हो सकती हैं। Dedicated key और account बनाए रखें, गैरजरूरी forwarding बंद करें और network topology अनुमति दे तो source addresses सीमित करें। केवल इसलिए remote account में अपनी personal SSH key स्वीकार न करें कि वह आपके laptop पर पहले से मौजूद है।

Effective SSH configuration देखें, केवल edit की गई file नहीं:

sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin|allowusers|allowgroups'
ssh -vvv agentbuild@build-host true

पहली command server की effective settings दिखाती है। दूसरी client side से authentication path और rejected methods दिखाती है। Actual agent key से test करें। अपनी key से किया test बहुत कम साबित करता है।

Sudo rules जो सुरक्षा जोड़ी है उसे अक्सर मिटा देती हैं

Agent account को unrestricted sudo न दें। agentbuild ALL=(ALL) NOPASSWD: ALL अलग UID को लगभग दिखावटी बना देता है, क्योंकि agent की हर command या script root बन सकती है।

जब build को एक privileged action चाहिए होता है, लोग यह rule जोड़ते हैं और build चलने के बाद उसे छोड़ देते हैं। इसी तरह सीमित exception स्थायी host control बन जाती है। अगर किसी task को सच में elevation चाहिए, तो पहले देखें कि root-owned service, deployment worker या अलग administrator action वह काम कर सकता है या नहीं।

sudoers(5) manual बताता है कि command matching की सीमाएं हैं। Arguments महत्वपूर्ण हैं। Wildcards administrator की अपेक्षा से अधिक match कर सकते हैं। Editor, interpreter, package manager, agent द्वारा writable shell script या writable directory से configuration लोड करने वाली command की अनुमति सीधे arbitrary root execution तक ले जा सकती है।

सुरक्षित pattern fixed behavior वाला root-owned wrapper है। मान लें agent को fixed directory में पहले से reviewed artifact रखने के बाद एक ज्ञात service restart करनी है। Wrapper को absolute command paths इस्तेमाल करने चाहिए, arguments अस्वीकार करने चाहिए, inputs का ownership और permissions सत्यापित करना चाहिए और केवल वही restart करना चाहिए। फिर sudo rule में उसी wrapper का exact नाम दें:

Cmnd_Alias AGENT_RELEASE = /usr/local/sbin/restart-project-service
agentbuild ALL=(root) NOPASSWD: AGENT_RELEASE

Rule को visudo से managed file में रखें। Wrapper और उसके parent directory दोनों का मालिक root हो और agentbuild के लिए writable न हो। इससे सुरक्षा की गारंटी नहीं मिलती, लेकिन सीमित दावा जांचने योग्य बनता है: account caller-controlled command string के बिना एक root-owned program चला सकता है।

अगर आप allowed privileged action को एक वाक्य में नहीं बता सकते, तो अभी sudo न दें। काम को तब तक बांटें जब तक ऐसा कर सकें। यह असुविधा design signal है, broad rule paste करने का कारण नहीं।

Credentials को login account से अलग सीमा चाहिए

Restricted account भी खतरनाक बन जाता है अगर उसके home directory में cloud credential file, broad deployment token या हर host तक पहुंचने वाली SSH private key रखी हो। अपने personal home से credential pile उठाकर agent home में रखना समाधान नहीं है।

Agent को केवल उस action, scope और environment के credentials दें जिसकी उसे सच में जरूरत है। एक repository में push कर सकने वाला source control credential production registry credential से अलग है। एक host तक सीमित deployment key पूरे estate में स्वीकार होने वाली private key से अलग है। इन फर्कों को account names, comments और revocation records में साफ रखें।

Shell environment variables में long-lived secrets रखने से बचें। Environment variables diagnostic output, child processes, crash reports और operating system के अनुसार बदलने वाले process inspection rules से आसानी से leak हो सकते हैं। कभी-कभी वे अपरिहार्य होते हैं, लेकिन उनका lifetime छोटा और launch path कड़ाई से नियंत्रित होना चाहिए।

Sallyport HTTP और SSH credentials को अपने encrypted vault में रखता है और requested action चलाता है, बिना MCP-capable agent को credential plaintext दिए। यह तब उपयोगी है जब agent को authenticated call करना हो, लेकिन उसके remote account में token file या private key नहीं पहुंचनी चाहिए।

इससे दो स्वतंत्र checks बनते हैं। Remote Unix account तय करता है कि process उस machine पर क्या कर सकता है। Action gateway तय करता है कि agent process HTTP या SSH action वाले credential का अनुरोध कर सकता है या नहीं। इन्हें एक control न समझें: credential gateway उस remote account को ठीक नहीं कर सकता जो production files पढ़ सकता है, और limited account agent को दिए गए token के इस्तेमाल से नहीं रोक सकता।

SSH automation के लिए अपनी personal private key को /srv/agentbuild/.ssh में copy न करें। Dedicated credential बनाएं और जिस server पर उसे स्वीकार किया जाए उसे सीमित करें। Remote target forced commands या source restrictions support करता हो तो उनका उपयोग करें। नहीं करता हो तो उस target पर account को सीमित करें। Revocation का अर्थ एक agent credential हटाना होना चाहिए, ordinary administration में इस्तेमाल होने वाली key बदलना नहीं।

Logs में intent और execution का फर्क दिखना चाहिए

Agent session, जहां संभव हो account की commands और उसके किए changes record करें। केवल agentbuild logged in कहने वाले logs तब मदद नहीं करेंगे जब आपको पता लगाना हो कि action human ने मांगा, agent ने प्रस्तावित किया या remote script ने चलाया।

Unix पहले से उपयोगी evidence देता है। SSH authentication logs स्वीकार की गई key और source address दिखाते हैं। Host के अनुसार process accounting या audit facilities execution track कर सकती हैं। Version control commits और बदली files record करता है। Build logs commands और artifacts record करते हैं। Timestamps synchronized रखें ताकि records की तुलना हो सके।

केवल shell history पर निर्भर न रहें। Noninteractive commands history में नहीं आ सकतीं, users उसे बदल सकते हैं और agent ऐसे tools चला सकता है जो अपनी commands शुरू करते हैं। Shell history debugging की सुविधा है, भरोसेमंद record नहीं।

हर run के बाद review में चार सीधे सवाल पूछें:

1. Agent account के रूप में किस controller ने authenticate किया?
2. उस UID के तहत कौन-सी commands या build jobs चलीं?
3. Intended workspace के बाहर कौन-सी files बदलीं?
4. Process ने किन remote systems और authenticated services से संपर्क किया?

तीसरे सवाल का उत्तर permission creep को जल्दी पकड़ता है। Incident से पहले account के writable paths की तुलना intended workspace से करें। Process list भी surprise दिखा सकती है: अगर छोटा-सा build agent background workers छोड़ जाता है, तो orchestration session खत्म होने के बाद भी वे workers account की permissions रखते हैं।

Sallyport agent sessions और individual actions को hash chained encrypted audit log में record करता है। sp audit verify vault key के बिना offline chain verify कर सकता है। यह record तब सबसे मजबूत होता है जब आप remote host का evidence भी बचाकर रखें, जो दिखाए कि authorized SSH action पहुंचने के बाद उसने क्या किया।

Shared developer login अनुमानित तरीकों से विफल होता है

अक्सर शुरुआत एक उचित request से होती है: agent को वही tests चलाने दें जो आप चलाते हैं। Developer agent को मौजूदा remote host पर भेजता है और अपनी normal SSH key authorize कर देता है, क्योंकि checkout, package caches और build dependencies पहले से काम कर रहे होते हैं।

Agent test command चलाता है। Test bootstrap developer का environment पढ़ता है और registry token पा लेता है। Dependency install postinstall script चलाता है। वह script developer की home directory पढ़ सकती है, SSH configuration देख सकती है, उपलब्ध credential helper इस्तेमाल कर सकती है और developer की मौजूदा network reach से connect कर सकती है। Kernel bug की जरूरत नहीं। Process के पास developer जितने ही अधिकार हैं।

बाद में deployment script fail होती है क्योंकि उसे writable artifact path चाहिए। कोई broad group change से उसे ठीक कर देता है। Account अब release directory में लिख सकता है। दूसरी fix passwordless sudo जोड़ देती है क्योंकि service restart रुक गया था। तब तक agent setup developer identity, व्यापक filesystem write access, reuse किए जा सकने वाले credentials और root escalation अपना चुका होता है।

Dedicated account इस failure path को बदल देता है। शुरुआती test fail हो सकता है क्योंकि account registry configuration पढ़ या पुराना shared cache लिख नहीं सकता। यह उपयोगी failure है। इससे पता चलता है कि restricted registry credential देना है, owned cache directory बनानी है या build को redesign करना है। हर repair एक स्पष्ट grant बनती है जिसकी समीक्षा की जा सकती है।

शुरुआत में friction की उम्मीद रखें। अगर नया account mature developer setup पर पहली कोशिश में ही पूरी तरह काम करने लगे, तो उसे ध्यान से जांचें। हो सकता है host ने पहले से हर local user के लिए बहुत अधिक data और authority उपलब्ध कर रखी हो।

Agent के रूप में boundary जांचें, फिर surprises हटाएं

Unattended work की अनुमति देने से पहले अलग administrator session से account test करें। केवल shell prompt बदलकर यह न मानें कि identity साफ तौर पर बदल गई है। Dedicated key से authenticate करें, actual startup command इस्तेमाल करें और session के बाहर से परिणाम देखें।

हर महत्वपूर्ण access change के बाद यह छोटा acceptance check चलाएं:

ssh -i ./agentbuild_key agentbuild@build-host 'id; umask; pwd; find ~ -maxdepth 1 -printf "%M %u %g %p\\n"'
ssh -i ./agentbuild_key agentbuild@build-host 'sudo -n true; echo sudo_status=$?'
ssh -i ./agentbuild_key agentbuild@build-host 'find /srv/project-build -xdev -type f -perm -0002 -print'

पहली line identity, working directory, creation mask और home permissions की पुष्टि करती है। दूसरी सामान्यतः nonzero status लौटानी चाहिए, क्योंकि account के पास general sudo नहीं होना चाहिए। तीसरी shared project directory में world-writable regular files खोजती है। जिन systems के find में GNU -printf नहीं है, वहां ls -ld और stat इस्तेमाल करें।

फिर जान-बूझकर denied actions test करें। Human home directory पढ़ने, workspace के बाहर लिखने, personal deployment key path इस्तेमाल करने और forwarding बंद होने पर SSH forwarding session खोलने की कोशिश करें। जिस restriction को आपने test नहीं किया वह configuration में लिखी हुई केवल इच्छा है।

Real jobs के बाद भी account review करें। Stale authorized keys, group memberships, caches, temporary access control lists और deployment permissions तब हटा दें जब task को उनकी जरूरत न रहे। Deadline के दौरान permission cleanup शायद ही कभी होता है। इसे job की completion criteria में शामिल करें।

Account को अपने home और test checkout से आगे बिना access के बनाकर शुरू करें। कोई वास्तविक command fail होने पर ही एक capability जोड़ें और जरूरी permission को सटीक शब्दों में बताएं। Setup के दौरान यह तरीका धीमा लगता है। किसी autonomous process ने developer login से क्या copy किया, इस्तेमाल किया या नुकसान पहुंचाया, यह सुलझाने की तुलना में यह बहुत तेज है।