Shared developer Macs: agent tool access को नियंत्रित करें

एक shared developer Mac टीम को support कर सकता है, लेकिन अगर हर व्यक्ति और हर local process को credentials का वही ढेर मिल जाता है, तो उस पर autonomous agents को सुरक्षित रूप से चलाना संभव नहीं है। समस्या अक्सर सुविधा के नाम पर शुरू होती है: shell file में project token, एक बार लोड की गई SSH key, पुराने terminal से खोला गया editor और agent से कहा गया, «बस इसे deploy कर दो»। जल्द ही किसी को पता नहीं रहता कि कार्रवाई को किस व्यक्ति ने authorize किया था या किस process के पास अब भी access है।

Identity, credential custody, authorization और evidence को अलग-अलग काम मानें। macOS login बताता है कि process का owner कौन-सा user है। इससे यह साबित नहीं होता कि cloud token का owner कौन है, agent को उसका इस्तेमाल करना चाहिए या नहीं, या lunch के बाद भी चल रहे process को access बनाए रखना चाहिए या नहीं। जो टीमें इन कामों को मिला देती हैं, उनमें privilege creep बहुत चुपचाप बढ़ता है।

Shared machines को अलग identities चाहिए

Shared workstation तभी काम करने लायक है जब हर human, हर credential और हर agent run की अलग identity हो, जिसे आप देख और revoke कर सकें। Machine login पहली सीमा है, पूरा design नहीं।

किसी group के लिए एक «dev» account न दें, भले ही उसे maintain करना आसान लगे। इससे file ownership, shell history, browser sessions, keychain entries और running processes सब साझा हो जाते हैं। Deployment में गड़बड़ी होने पर audit record में केवल यही दिखता है कि shared account ने वह काम किया। यह accountability नहीं है, बल्कि बंद रास्ता है।

हर developer को अलग macOS account दें और unattended work के लिए, जहाँ सच में ज़रूरत हो, अलग service identity इस्तेमाल करें। Service identity का owner, स्पष्ट उद्देश्य, सीमित credential set और retirement plan होना चाहिए। उसे ऐसा छिपा हुआ team account न बनने दें जिसे लोग अपनी setup की असुविधा के कारण इस्तेमाल करने लगें।

Agent के मामले में यह अंतर सबसे ज़्यादा मायने रखता है। Coding agent subprocesses चला सकता है, अपनी working directory पढ़ सकता है, inherited environment देख सकता है और approved tools को call कर सकता है। अगर दो लोग एक ही local account से agents चलाते हैं, तो एक व्यक्ति का पुराना environment या helper process दूसरे व्यक्ति को अनजाने में authority दे सकता है।

Apple Platform Security अलग-अलग user data और system services के आसपास macOS account protections का वर्णन करता है। ये protections महत्वपूर्ण हैं, लेकिन यह तय नहीं करतीं कि repository, shared directory या process environment में कॉपी किया गया token उस process के लिए उचित है या नहीं, जो उसे पा लेता है। File permissions एक तरह की गलती सीमित करती हैं। वे intent स्थापित नहीं करतीं।

हर ऐसे credential के लिए एक सरल ownership record रखें जो production systems, source control, package publishing या customer data में बदलाव कर सकता है:

• एक human owner और एक backup contact का नाम दें।
• Service, allowed operations और environments लिखें।
• Secret कहाँ रखा है और उसे कैसे rotate किया जाता है, दर्ज करें।
• Review date और retirement trigger तय करें।

Record में वास्तविक secret न रखें। उद्देश्य ownership को स्पष्ट करना है, credential की एक और copy बनाना नहीं।

Named owner होने का अर्थ यह नहीं कि हर action उसी व्यक्ति को manually करना होगा। इसका अर्थ है कि कोई सीधे पूछे जाने पर बता सके: यह credential क्यों मौजूद है, इसे authorize कौन कर सकता है और अभी revoke करने पर क्या टूटेगा? अगर कोई जवाब नहीं दे सकता, तो सुरक्षित समय में इसे revoke करें और अधिक स्पष्ट उद्देश्य के साथ access फिर से बनाएं।

Unix account में कॉपी किया हुआ secret सुरक्षित नहीं हो जाता

macOS account boundaries data की रक्षा तभी करती हैं जब credential उसी boundary के भीतर रहे और किसी दूसरे रास्ते से उपलब्ध न कराया जाए। टीमें अक्सर home directory को सुरक्षित कर देती हैं, फिर वही token project files, terminal history, editor settings, CI exports या लंबे समय से चल रहे agent process में छोड़ देती हैं।

ऐसे inventory से शुरुआत करें जो उन जगहों की जाँच करे जहाँ developers सच में काम करते हैं। यह काम अनुमति और सावधानी से करें: live secret को shared terminal scrollback में print करना उसी समस्या को पैदा कर देता है जिसे आप ढूँढ रहे हैं।

# Search filenames and likely configuration references, not secret values.
find "$HOME" -maxdepth 3 \( -name '.env' -o -name '.netrc' -o -name 'credentials*' \) -print

# Show environment variable names for the current shell only.
env | cut -d= -f1 | grep -E 'TOKEN|SECRET|KEY|PASSWORD' || true

# Show loaded SSH identities without printing private key material.
ssh-add -l

आखिरी command सामान्यतः हर identity के लिए fingerprint, algorithm और comment वाली एक line दिखाती है। अगर यह The agent has no identities. दिखाती है, तो यह उपयोगी परिणाम है। अगर ऐसा fingerprint दिखे जिसे आप समझा नहीं सकते, तो मशीन को clean मानना बंद करें और पता लगाएँ कि उसे किस workflow ने load किया था।

Agent transcript के भीतर env न चलाएँ और output को issue में paste न करें। Agents, terminals, editor logs और support tickets secrets रखने की खराब जगह हैं। पहले variable names और file locations खोजें। अगर आपको लगता है कि secret की value transcript या repository history में पहुँच गई है, तो credential rotate करें।

एक आम असफल सलाह है, «Secrets को local .env file में रखो और उसे Git से बाहर रखो।» यह सलाह लोकप्रिय है क्योंकि पाँच मिनट में काम कर देती है। लेकिन उस directory से शुरू होने वाले हर program को संभावित credential reader भी बना देती है। .gitignore entry commit रोकती है। यह local agent को file पढ़ने, archive tool को उसे collect करने या developer को अगले project में कॉपी करने से नहीं रोकती।

.env files का इस्तेमाल केवल कम-जोखिम वाली local settings या तय cleanup date वाले temporary migration work के लिए करें। Shared systems में बदलाव कर सकने वाले credentials की value protected local store में रखें और agent को raw value देने के बजाय कोई operation उपलब्ध कराएँ।

Process inheritance पर भी उतना ही संदेह करें। Terminal DEPLOY_TOKEN export करता है; editor उसी terminal से शुरू होता है; extension language server शुरू करता है; agent editor के ज़रिए tool चलाता है। मूल developer शायद घंटों पहले token भूल चुका हो, लेकिन हर child process अब भी उसे पढ़ सकता है। macOS permissions ने वही किया जो उनसे कहा गया था। बहुत सारे processes को secret टीम ने दिया था।

Credential custody और action authority अलग चीज़ें हैं

Credential का जवाब है, «कौन authenticate कर सकता है?» Authorization का जवाब है, «यह process अभी यह action कर सकता है या नहीं?» टीमें अक्सर पहले को दूसरे का प्रमाण मान लेती हैं, खासकर API tokens के मामले में।

किसी agent को केवल इसलिए bearer token न दें कि उसे एक API call करनी है। Bearer token अपने scope के लिए उसे रखने वाले को authority देता है। Token एक बार agent के context, tool argument, child process environment या debug output में आ गया, तो मानकर चलें कि उस material को पढ़ सकने वाला हर system उसका फिर इस्तेमाल कर सकता है।

इसके बजाय action contract तय करें। Agent structured inputs के साथ किसी named operation का अनुरोध करे। Trusted local component credential अपने पास रखे, allowed destination और request shape की जाँच करे, call करे और परिणाम लौटाए। Agent को कोई खाली placeholder भी न दें जिसे वह बाद में किसी दूसरे source से भर सके। उसे credential बिल्कुल न मिले।

उदाहरण के लिए, release agent को deployment record बनाने की ज़रूरत हो सकती है। उसका request ऐसा दिख सकता है:

{
  "action": "create_deployment",
  "environment": "staging",
  "revision": "7c31f4a",
  "summary": "Fix request timeout handling"
}

Trusted component create_deployment को एक approved endpoint और एक stored credential से map कर सकता है। उसे ऐसे input को reject करना चाहिए जो host, path, authorization header या arbitrary request body देने की कोशिश करे। अगर action contract arbitrary URLs और headers स्वीकार करता है, तो उसने अधिक औपचारिकता के साथ सामान्य network access फिर बना दिया है।

Credential का scope इतना छोटा रखें कि गलती का परिणाम सीमित रहे। Read access और write access अलग करें। Staging और production अलग रखें। जहाँ upstream service support करे वहाँ short lived credentials को प्राथमिकता दें, लेकिन कम lifetime को broad scope का इलाज न समझें। थोड़े समय तक जीवित रहने वाला token भी अपने पहले ही second में irreversible call कर सकता है।

यही अंतर SSH पर भी लागू होता है। SSH private key किसी principal पर control साबित करती है। वह यह नहीं बताती कि local agent को इस समय किसी host पर command क्यों चलानी चाहिए। Host और command selection को authorization decision का हिस्सा बनाएं। Agent को generic shell pathway देकर यह उम्मीद न करें कि repository instructions उसे रोक लेंगी।

Local processes आपकी अपेक्षा से अधिक authority उधार ले सकते हैं

Local process environment variables, open file descriptors, Unix sockets, browser sessions और helper services के ज़रिए authority inherit कर सकता है। जोखिम वाला process अक्सर malicious नहीं होता। वह stale, misconfigured या ऐसे व्यक्ति द्वारा शुरू किया गया हो सकता है जिसे पता ही नहीं था कि उसके parent ने पहले से क्या access दे रखा है।

संदिग्ध process को kill करने से पहले उसका निरीक्षण करें। macOS पर ये commands credential values उजागर किए बिना उपयोगी संकेत देती हैं:

ps -axo pid,ppid,user,command | grep -i '[a]gent\|[c]laude\|[n]ode\|[p]ython'
lsof -nP -p <PID> | grep -E 'cwd|unix|TCP|IPv4|IPv6'

पहली command process ID, parent process ID, account और launch command दिखाती है। दूसरी आम तौर पर current working directory, Unix socket paths और खुले network connections दिखाती है। पुराने project के भीतर working directory और किसी पुराने session का parent terminal, exotic malware से अधिक incidents समझाते हैं।

Window गायब हो जाने पर यह न मानें कि process भी खत्म हो गया। Editors language servers चालू रखते हैं। Terminal multiplexers shells को बनाए रखते हैं। Build tools watchers शुरू करते हैं। Local MCP client developer का ध्यान हट जाने के काफी बाद तक connection बनाए रख सकता है।

Access खत्म करना एक जानबूझकर किया जाने वाला काम बनाएं। Agent client बंद करें, उसे शुरू करने वाला terminal session रोकें और उस run के लिए मिली temporary authorization हटा दें। अगर कोई helper चलता रहना ज़रूरी है, तो उसका उद्देश्य दर्ज करें और उसकी process identity उस व्यक्ति के लिए स्पष्ट रखें जो access approve कर रहा है।

एक व्यावहारिक handoff test समस्याएँ जल्दी पकड़ लेता है। Developer A staging action के access के साथ agent चलाता है, फिर agent बंद करके sign out करता है। Developer B अपने account में sign in करता है और harmless request चलाता है। B को A की project directory, environment variables, SSH socket, browser session या active authorization में से कुछ भी नहीं मिलना चाहिए। अगर B इनमें से किसी तक पहुँच सकता है, तो टीम के पास shared state है जिसे हटाने की ज़रूरत है।

Developers को administrators बनाकर इस समस्या को हल न करें। System management के लिए administrator rights ज़रूरी हो सकते हैं, लेकिन वे careless installer या local script का blast radius बढ़ा देते हैं। Daily agent work के लिए standard account इस्तेमाल करें, जब तक किसी खास task को elevation की ज़रूरत न हो। तब केवल उसी task के लिए elevation लें और फिर सामान्य उपयोग पर लौट आएँ।

SSH agents को private keys जितनी ही सावधानी चाहिए

SSH agent local socket के पीछे signing authority रखता है, इसलिए जिस process को उस socket तक पहुँच मिलती है वह private key file पढ़े बिना signatures का अनुरोध कर सकता है। यह private keys को disk पर बिखेरने से बेहतर है, लेकिन workstation के हर process के लिए खुली छूट नहीं है।

OpenSSH SSH_AUTH_SOCK को agent socket के path के रूप में document करता है। इस environment variable को संवेदनशील routing information मानें। अगर agent इसे inherit करता है, तो वह SSH agent में इस समय loaded identities से signatures माँग सकता है। Private key छिपी रहती है, लेकिन operational risk बना रहता है।

Remote system पर automation चलाने से पहले यह command चलाएँ:

printf '%s\n' "${SSH_AUTH_SOCK:-SSH_AUTH_SOCK is unset}"
ssh-add -l
ssh -G [email protected] | grep -E '^(hostname|user|identityfile|forwardagent) '

ssh -G effective OpenSSH client configuration print करता है। Output में user deploy, identityfile ... और forwardagent no जैसी lines होती हैं। आखिरी line को ध्यान से जाँचें। Agent forwarding remote host को forwarded connection के ज़रिए आपके local agent का इस्तेमाल करने देता है। जब तक आप exact remote hop और उसकी ज़रूरत स्पष्ट न कर सकें, इसे बंद रखें।

OpenSSH ssh_config manual ForwardAgent का वर्णन करता है और चेतावनी देता है कि forwarding remote host पर पर्याप्त access रखने वाले users के सामने local agent को उजागर कर सकती है। टीमें फिर भी इसे व्यापक रूप से enable करती हैं क्योंकि इससे keys copy करने की ज़रूरत नहीं पड़ती और jump host सुविधाजनक लगता है। सुविधा वास्तविक है। यह भी वास्तविक है कि compromised या बहुत permissive remote environment forwarded session के दौरान signatures माँग सकता है।

अलग access classes के लिए अलग identities इस्तेमाल करें। Production deployment identity को personal source control identity के साथ एक ही agent में केवल इसलिए न रखें कि development के दौरान दोनों उपयोगी हैं। काम पूरा होने पर identities हटाएँ, जहाँ यह व्यावहारिक हो:

ssh-add -d ~/.ssh/id_staging_deploy
# Or clear every identity after a short, dedicated session.
ssh-add -D

सभी identities clear करने से अन्य legitimate work बाधित हो सकता है, इसलिए इसे dedicated session के अंत में इस्तेमाल करें, न कि किसी ऐसे shared shell tab में जिस पर कोई और निर्भर हो। बेहतर तरीका है कि shared shells का इस्तेमाल ही न करें।

Private key paths, host aliases और permissive forwarding rules को ऐसी repository configuration में न रखें जिसे हर developer बिना सोचे अपनाता हो। Repository अपेक्षित host और account document कर सकती है। कौन-सी local identity वहाँ पहुँच सकती है, यह निर्णय हर developer को स्वयं लेना चाहिए।

Approval में process और action दोनों का नाम होना चाहिए

Approval prompt तभी मदद करता है जब कोई human caller की पहचान कर सके, requested operation समझ सके और काम खत्म होने के बाद permission revoke कर सके। «allow access» कहने वाला prompt लोगों को noise approve करना सिखाता है।

सामान्य development work के लिए per-session approval उपयुक्त है। Newly launched agent process की पहली call पर caller identity दिखे और user तय करे कि उस run को action channel इस्तेमाल करने देना है या नहीं। Process exit होते ही authorization खत्म हो जानी चाहिए, किसी छिपी preference की तरह बनी नहीं रहनी चाहिए।

Production deletion, package publication, payment setting बदलने या sensitive host पर command चलाने जैसी asymmetric consequences वाली कार्रवाइयों के लिए per-call approval उपयुक्त है। यह जानबूझकर friction जोड़ता है। केवल comforting ritual बनाने के लिए इसे read-only status call पर लागू न करें, वरना लोग उसे बिना पढ़े approve करने लगेंगे।

Approval card को इन सवालों का सरल भाषा में जवाब देना चाहिए:

• किस local process ने access माँगा, और जहाँ उपलब्ध हो वहाँ उसकी signing authority क्या है?
• कौन-सा stored credential या action category इस्तेमाल होगी?
• Request किस destination, host या environment को भेजी जाएगी?
• कौन-सा operation होगा और कौन-से inputs उसके प्रभाव को महत्वपूर्ण रूप से बदलते हैं?
• Approval केवल इस call के लिए है या process exit होने तक?

ऐसी approval system स्वीकार न करें जो caller को केवल «terminal» या «agent» बताती हो। Local machine पर कई terminals और कई agent processes चल सकते हैं। Approve करने वाले व्यक्ति को इतना विवरण चाहिए कि वह नए work run को किसी जीवित पुराने process से अलग पहचान सके।

Sallyport एक fixed decision ladder इस्तेमाल करता है: locked vault हर action को deny करता है, नया agent process default रूप से session authorization माँगता है और चुने गए credentials के लिए हर इस्तेमाल पर approval अनिवार्य किया जा सकता है। Developer laptop पर यह सीमित model किसी जटिल local policy language से बेहतर है, क्योंकि अस्पष्ट rules समय के साथ पुराने पड़ते हैं और कोई भरोसे से नहीं बता पाता कि इनमें से कौन-सा लागू होगा।

Approval scope का विकल्प नहीं है। Human गलत चीज़ approve कर सकता है। पहले destinations, credentials और action shapes सीमित करें, फिर वहाँ approval माँगें जहाँ human judgment वास्तविक control जोड़ता है।

Audit log को बाद में ownership के सवालों के जवाब देने चाहिए

एक उपयोगी audit record से engineer यह पता लगा सके कि किसने क्या चलाया, किस local process को authority मिली, कौन-सी external action हुई और access कब वापस लिया गया। Terminal scrollback यह standard पूरा नहीं कर सकता, क्योंकि users उसे edit कर सकते हैं, shells उसे rotate करते हैं और अलग processes एक history file में मिल जाते हैं।

एक ही event stream के दो views रखें। पहला sessions को track करे: agent process identity, start और end time, approvals और revocation। दूसरा actions को track करे: timestamp, destination, method या command, credential reference, result और error। इन्हें session identifier के ज़रिए जोड़ें, लेकिन information ऐसी रखें जिसे database archaeology के बिना भी समझा जा सके।

Tamper evidence incident के बाद बातचीत की गुणवत्ता बदल देता है। Chained hashes वाला write-once sequence silent edits को detectable बनाता है। यह साबित नहीं करता कि हर recorded action समझदारी भरी थी और न ही उन records को वापस ला सकता है जिन्हें आपने collect ही नहीं किया। लेकिन «किसी ने log साफ़ कर दिया» जैसी बात को चुनौती देना आसान बनाता है।

Audit trail को स्वतंत्र रूप से verify करें। Sallyport अपने session और activity journals को encrypted hash-chained audit log से project करता है और sp audit verify vault keys के बिना offline chain check करता है। यह separation महत्वपूर्ण है, क्योंकि verification command को उसी secret store की ज़रूरत नहीं होनी चाहिए जिसकी use की जाँच की जा रही है।

Logs को भी secrets की रक्षा करनी चाहिए। Credential reference, action name, destination और outcome record करें। Bearer tokens, request authorization headers, private key material या passwords वाले command arguments record न करें। हर secret को दोहराने वाला complete log खराब access control वाला दूसरा credential vault है।

केवल successful actions नहीं, failed actions की भी समीक्षा करें। लगातार denials बता सकती हैं कि agent obsolete action contract आज़मा रहा है, developer गलत account इस्तेमाल कर रहा है या background process अपने task से अधिक समय तक चल रहा है। एक unexplained successful action पर ध्यान देना ज़रूरी है, लेकिन failures वे सीमाएँ दिखाती हैं जहाँ आपके controls वास्तविक काम से मेल नहीं खाते।

Team Mac के लिए काम करने वाला operating model

Teams local agents को serious work के लिए पर्याप्त सुरक्षित रूप से चला सकती हैं, अगर shared hardware से अधिक महत्व individual identity और explicit action authority को दें। Operating model में daily habits चाहिए, ऐसा security document नहीं जो केवल onboarding के समय दिखाई दे।

Shared office machine पर agent workflow जोड़ते समय यह sequence अपनाएँ:

1. हर credential के लिए human owner, allowed service, environment और retirement condition तय करें।
2. Generic token या shell session expose करने के बजाय agent के लिए dedicated action contract बनाएं।
3. Agent को intended developer account से empty या minimal credential environment के साथ launch करें।
4. उसकी identity और requested destination जाँचने के बाद ही नए process को approve करें।
5. Run खत्म करें, ज़रूरत हो तो उसे revoke करें और पुष्टि करें कि helper processes और SSH identities हट चुकी हैं।

यह sequence popular shell profile में एक production token रखने से जानबूझकर कम सुविधाजनक है। वह shortcut तब तक efficient लगता है जब तक कोई contractor मशीन इस्तेमाल न करे, editor environment inherit न कर ले या पुराना process अगले व्यक्ति की shift तक चलता न रहे।

Outage से पहले emergency access तय करें। Team को ऐसे documented व्यक्ति की ज़रूरत है जो break-glass action approve कर सके, सीमित emergency scope वाला अलग credential हो और उसके इस्तेमाल का कारण बताने वाला log record हो। Powerful permanent token को «emergencies» के लिए shared folder में न छोड़ें। वहाँ मौजूद होने के कारण वह ordinary access बन जाएगा।

जिस काम के लिए local action gateway चाहिए, gateway को developer के अपने account पर रखें और process boundary स्पष्ट बनाएं। Shared Mac समय के साथ कई users को host कर सकता है, लेकिन उसे authority के एक अविभाजित pool को host नहीं करना चाहिए।

Agent के चलते रहने के दौरान revocation का परीक्षण करें

Revocation तभी विश्वसनीय है जब वह ऐसे process की अगली action रोक सके जिसे पहले permission मिल चुकी थी। हर client quit करने के बाद किया गया test बहुत कम साबित करता है।

एक harmless staging action तैयार करें जो ज्ञात response लौटाए। Agent process launch करें, उसे session के लिए approve करें और action एक बार चलाएँ। फिर process के जीवित रहते session revoke करें या credential store lock करें। वही action दोबारा request करें।

Expected result active process या locked state से जुड़ी denial है। Agent को अपने environment में मौजूद token, existing SSH socket या cached browser session पर fallback नहीं करना चाहिए। अगर action सफल हो जाए, तो अधिक prompts या policies जोड़ने से पहले वह path जाँचें जिसका उसने इस्तेमाल किया।

Developer के sign out करने और किसी दूसरे के sign in करने के बाद यही test फिर चलाएँ। Machine sleep और wake होने के बाद भी test करें, क्योंकि local helper connections और SSH agents कभी-कभी ऐसे assumptions उजागर करते हैं जो केवल लंबे workday में दिखाई देते हैं। Results का छोटा record रखें, जिसमें exact process identity और tested action शामिल हो।

सबसे उपयोगी पहला बदलाव बड़ा secret manager या लंबी approval checklist नहीं है। Agent की पहुँच से एक broad credential हटाएँ, उसकी जगह narrow action path दें और साबित करें कि revocation अभी चल रहे process को रोकती है। यही test बताता है कि team access को control करती है या केवल उसका documentation रखती है।