Local AI agent actions के लिए Fast User Switching security

Shared Mac पर «local» authority का अर्थ बदल जाता है। Fast User Switching से कई user sessions एक साथ logged in रह सकते हैं। इसका मतलब है कि keyboard पर बैठा व्यक्ति, agent process, credential vault और approval prompt अलग-अलग security contexts से जुड़े हो सकते हैं। इन्हें एक ही identity मानना ऐसा है जैसे सामान्य handoff अचानक बिना समीक्षा वाले production call में बदल जाए।

व्यावहारिक नियम सीधा है: account ownership, vault access और approval authority एक ही macOS user session से जुड़े रहने चाहिए। User switch किसी और के agent run को जारी रखने की अनुमति नहीं है। यह संकेत है कि आपको देखना चाहिए कि कौन-सी process अब भी मौजूद है, वह किसके credentials मांग सकती है और अगला prompt कौन देख या पूरा कर सकता है।

Fast User Switching security का संबंध concurrent sessions से है

Fast User Switching security इसलिए महत्वपूर्ण है क्योंकि macOS पिछले account को logged in रखते हुए किसी दूसरे व्यक्ति को उसी hardware का उपयोग करने दे सकता है। Apple के macOS User Guide में Fast User Switching को दूसरे उपयोगकर्ता को log out किए बिना accounts के बीच जाने के तरीके के रूप में बताया गया है। यही इसकी सुविधा है। इसका यह भी अर्थ है कि switch होने से यह साबित नहीं होता कि पहले का काम रुक गया है।

लोग अक्सर laptop को एक कुर्सी की तरह देखते हैं: एक व्यक्ति उठता है, दूसरा बैठता है और control transfer हो जाता है। Switching enabled वाला shared Mac एक इमारत में बने कई कमरों जैसा व्यवहार करता है। दिखाई देने वाला desktop बताता है कि अभी console किसके पास है। वह यह नहीं बताता कि किसी दूसरे logged-in account में terminal, editor extension, local service या agent launcher अब भी चल रहा है या नहीं।

जब agent API call कर सकता हो या SSH से connect कर सकता हो, तब यह अंतर गंभीर हो जाता है। Alex ने दोपहर से पहले अपने account में agent शुरू किया हो सकता है। बाद में Sam अपने account में switch करके साफ desktop देख सकता है। Alex की process अब भी मौजूद हो सकती है, उसकी job queue में काम बचा हो सकता है और उस run के लिए approval state अब भी valid हो सकती है। Mac ने वह authority Sam को नहीं दी, लेकिन लापरवाह software इस अंतर को छिपा सकता है।

Screen lock, user switching और process termination को एक-दूसरे का पर्याय न मानें। ये अलग समस्याएं हल करते हैं।

• Screen lock वर्तमान दिखाई देने वाले desktop के casual use को रोकता है।
• User switch active console account बदलता है, जबकि दूसरा login session खुला रहता है।
• Log out करने पर macOS उस उपयोगकर्ता का graphical session और उसकी processes समाप्त करने की कोशिश करता है।
• Agent run को revoke करने से उस run की आगे external calls करने की अनुमति हट जाती है।

आखिरी control को टीमें अक्सर भूल जाती हैं। Agent session की अपनी lifetime और अपना revocation path होना चाहिए। अगर वह केवल terminal window की lifetime या «developer के computer» की अस्पष्ट धारणा पर निर्भर है, तो कई लोगों द्वारा उपयोग किए जाने वाले Mac पर वह गलत व्यवहार करेगा।

Fast User Switching अपने आप unsafe नहीं है। यह तब unsafe बनता है जब कोई local action system यह मान ले कि हर live process और मशीन को छू सकने वाला हर व्यक्ति एक ही व्यक्ति है। यह मान्यता केवल उस personal Mac पर सही बैठती है जहां एक ही account सक्रिय हो। वहां भी यह उस क्षण विफल हो जाती है जब किसी और को login password पता हो या वह unlocked desk का उपयोग कर रहा हो।

Active console user को दूसरे account की authority नहीं मिलनी चाहिए

Active console user को केवल अपने account को दिए गए credentials और approvals नियंत्रित करने चाहिए। Local credential vault physical computer का नहीं, identity का होता है। अगर कोई app vault को machine-wide बना देती है, तो app के interface तक पहुंच रखने वाले किसी भी उपयोगकर्ता के पास दूसरे उपयोगकर्ता की authority तक पहुंचने का रास्ता बन जाता है।

यहां टीमें दो अलग दावों को मिला देती हैं। «Secret agent में कभी नहीं जाता» secret exposure के बारे में है। «केवल सही व्यक्ति action को authorize कर सकता है» authority के बारे में है। दोनों जरूरी हैं। Secret boundary सही होने पर भी कोई लाभ नहीं, अगर दूसरा logged-in user उसके उपयोग को approve कर सकता हो या owner के desk से हटने के बाद पुराना session approved रह जाए।

अपने design और operating rules में यह binding स्पष्ट रखें:

1. हर व्यक्ति के credentials उसके macOS account के अंतर्गत रखें, अलग vault material और अलग local authentication के साथ।
2. किसी external action से पहले vault को उस credential के मालिक account से unlock करना जरूरी बनाएं।
3. Approval को एक account में चल रही एक agent process पर लागू करें। Process बंद होने या operator द्वारा revoke किए जाने पर approval समाप्त हो जाए।
4. दूसरे account में switch होने पर पहले account से शुरू हुए prompt को पूरा न करने दें।
5. हर authorization और call के साथ account context और originating process दर्ज करें।

एक असहज स्थिति वह support worker है जिसके पास Mac पर administrator access है। Administrator access कई local conditions बदल सकता है, लेकिन उसे किसी और के API credentials के casual use में नहीं बदलना चाहिए। पूछें कि क्या system credential owner के लिए नया authentication event मजबूर करता है और क्या audit record account change को स्पष्ट दिखाता है। यदि उत्तर साफ नहीं है, तो design भी साफ नहीं है।

Touch ID इस मुद्दे को सरल नहीं, बल्कि अधिक स्पष्ट बनाता है। Fingerprint approval को active account और prompt में दिखाए गए action के लिए अधिकृत व्यक्ति की पुष्टि करनी चाहिए। यह सामान्य physical-presence signal नहीं बनना चाहिए जिसे कोई भी enrolled व्यक्ति दूसरे account की authority खर्च करने के लिए इस्तेमाल कर सके। Hardware-backed local authentication मजबूत gate तभी देता है, जब app उस gate के दूसरी ओर identity को बनाए रखे।

इसे «हम user switch तभी करते हैं जब दूसरा व्यक्ति दूर हो» जैसे अनौपचारिक नियम से हल न करें। Shared machines पर interruptions, maintenance work, उधार लिए गए chargers और जल्दबाजी वाले handoffs होते रहते हैं। Controls को सामान्य मानवीय व्यवहार के बीच भी काम करना चाहिए, क्योंकि तभी लोग लिखे न गए नियमों को याद रखना बंद करते हैं।

छिपी हुई process desk पर मौजूद व्यक्ति से अधिक समय तक चल सकती है

User switch के बाद local agent चलता रह सकता है। आपको अपनी टीम द्वारा agents शुरू करने के ठीक उसी तरीके से इसकी जांच करनी चाहिए। Parent terminal बंद होने पर कुछ processes रुक जाती हैं। दूसरी processes editor, task runner, login item या background launch mechanism के जरिए चलती रहती हैं। macOS account boundaries उनकी पहुंच सीमित करती हैं, लेकिन यह गारंटी नहीं देतीं कि login window तक किसी दूसरे उपयोगकर्ता के पहुंचते ही हर process गायब हो जाएगी।

Shared hardware पर autonomous work की अनुमति देने से पहले एक छोटा test करें। ऐसा harmless agent task चलाएं जो हर मिनट पहचानने योग्य local record बनाए और कोई credential अपने पास न रखे। इसे उसी terminal, editor या launcher से शुरू करें जिसे developers वास्तविक काम में इस्तेमाल करते हैं। Log out किए बिना user switch करें, कुछ देर रुकें, वापस switch करें और देखें कि task जारी रहा या नहीं। Screen lock करने और log out करने के बाद भी यही दोहराएं।

परिणाम को operational terms में लिखें। «Agent रुक जाता है» पर्याप्त नहीं है। Launcher, account, उसे रोकने वाली घटना और इसमें लगा समय दर्ज करें। Switch के बाद जारी रहने वाली process local lint job के लिए स्वीकार्य हो सकती है। लेकिन अगर वह hosted environment बदलने वाली request भेज सकती है, तो उसकी कहीं अधिक सावधानी से समीक्षा करनी होगी।

एक सामान्य failure शुरुआत में harmless लगता है। Developer ऐसा autonomous coding run शुरू करता है जो issue comments बना सकता है और test environment update कर सकता है। वह दोपहर के लिए process को approve करता है। फिर किसी दूसरे व्यक्ति के लिए Mac पर account switch कर देता है। Coding run transient error के बाद retry loop में पहुंचता है और बाद में फिर शुरू हो जाता है। दूसरे व्यक्ति ने इसे शुरू नहीं किया और शायद उसे इसके अस्तित्व का पता भी नहीं है। फिर भी run के पास valid approval रहता है, क्योंकि software ने approval को originating process के बजाय calendar, device या broad user session से बांध दिया था।

इसका समाधान केवल छोटा approval timeout नहीं है। छोटे timeouts वास्तविक काम में रुकावट डालते हैं और लोगों को prompts पर बिना पढ़े click करना सिखाते हैं। Approval को process instance से बांधें। Process समाप्त होते ही grant समाप्त हो जाए। जब कोई व्यक्ति जानबूझकर काम किसी और को सौंपे, तो पुराना run revoke करके नया शुरू करें। नई process नए accountable owner के साथ नया approval event बनाए।

आपके पास यह जानने का स्पष्ट तरीका भी होना चाहिए कि «मेरे account के अंतर्गत अब भी क्या चल रहा है?» इसका उत्तर याददाश्त पर निर्भर नहीं होना चाहिए। Operators को ऐसा session journal दें जिसमें run, उसकी authorization की स्थिति और direct revoke action दिखाई दे। Personal machine पर यह सुविधा है। Shared Mac पर यह safety boundary का हिस्सा है।

Approval prompts को friendly label नहीं, process identity चाहिए

Approval prompt में caller को imitation से अलग पहचानने के लिए पर्याप्त जानकारी होनी चाहिए। «coding assistant» जैसा label बेकार है, क्योंकि दो extensions, दो shells या copied script यही label इस्तेमाल कर सकते हैं। Operator को originating process और जहां macOS यह जानकारी देता हो, उसकी code-signing authority दिखनी चाहिए।

Code-signing authority एक सीमित लेकिन महत्वपूर्ण सवाल का उत्तर देती है: इस process पर किस developer identity ने sign किया? इससे यह साबित नहीं होता कि process अच्छे निर्णय लेगी। लेकिन इससे operator unsigned tool, अलग build या अनपेक्षित helper की request पहचान सकता है। व्यस्त दोपहर में दिखाई देने वाली anonymous request को approve करने से यह काफी बेहतर है।

Prompt में credential या action category भी ऐसे शब्दों में होनी चाहिए जिन्हें कोई व्यक्ति समझकर निर्णय ले सके। «Use credential X» पढ़कर लोग मानसिक spreadsheet खोजने लगते हैं। «Staging publisher credential का उपयोग करके deployment API को HTTP request भेजें» उन्हें निर्णय लेने योग्य जानकारी देता है। हर prompt में पूरा request body दिखाने से बचें। बड़े prompts approval fatigue बढ़ाते हैं और ऐसी data expose कर सकते हैं जिसे desktop notification में नहीं होना चाहिए। Action, destination, method और credential identity ऐसी जगह रखें जहां उपयोगकर्ता उन्हें जल्दी पढ़ सके।

Per-session approval और per-call approval अलग समस्याएं हल करते हैं। Per-session approval कहता है, «मैं इस agent process को पहचानता हूं और इसके सीमित run की अनुमति देता हूं।» Per-call approval कहता है, «मैं इस credential के इस खास उपयोग की जांच कर रहा हूं।» केवल इसलिए दूसरे को पहले से न बदलें कि पहला कम interruptive लगता है।

जहां परिणामों को पलटना कठिन हो, वहां per-call approval रखें: ऐसा credential जो production data बदल सकता हो, resources हटा सकता हो, बाहरी रूप से publish कर सकता हो या व्यापक administrative interface तक पहुंच सकता हो। हर call पर approval friction बढ़ाता है। यह friction वहीं होना चाहिए जहां इंसान को रुककर सोचना चाहिए।

Per-session approval उस काम के लिए रखें जहां process पहचानी जा सके और credential का प्रभाव सीमित हो। Process समाप्त होते ही session भी समाप्त होना चाहिए। «इस Mac पर मौजूद agents» के लिए blanket grant एक policy loophole है, भले उसका नाम कितना भी friendly क्यों न हो।

Trusted local development machine पर approvals बंद करने की लोकप्रिय सलाह shared Macs के लिए गलत है। यह सलाह लोकप्रिय है क्योंकि prompts flow रोकते हैं और developers local processes को private मानते हैं। Fast User Switching इस धारणा को हटा देता है। Local machine में कई live user contexts हो सकते हैं और familiar process owner के keyboard छोड़ने के काफी बाद तक चल सकती है।

Shared Macs को ऐसा handoff procedure चाहिए जो authority समाप्त करे

सही handoff अगले व्यक्ति का काम शुरू होने से पहले पुराने व्यक्ति की authority समाप्त करता है। Terminal tab, task description या chat message आगे भेजना accountability transfer नहीं करता। नए व्यक्ति को fresh process और किसी भी credential उपयोग के लिए अपनी authorization चाहिए।

जब किसी और को local agent task संभालना हो, तो यह procedure अपनाएं:

1. यदि current agent अब भी decisions ले रहा है, तो उसे रोकें। उसे सामान्य working files लिखने दें, लेकिन handoff के दौरान external systems को call न करने दें।
2. Session record से पुराने agent session को revoke करें। मूल उपयोगकर्ता के जाने से पहले पुष्टि करें कि revoke से session state बदल गई है।
3. यदि मशीन लंबे समय तक अगले व्यक्ति के पास रहेगी, तो पुराने उपयोगकर्ता का vault लॉक करें या उस account को log out करें।
4. आने वाला व्यक्ति अपने macOS account में switch करे और वहीं नई agent process शुरू करे।
5. नई process की पहचान वाली नई authorization मांगें। External actions की अनुमति देने से पहले task state की समीक्षा करें।

यह procedure तब तक सख्त लगता है जब तक कोई अस्पष्ट handoff पहली request न भेज दे। Agent को restart करने की लागत उस बाद की उलझन से बहुत कम है जिसमें यह पता लगाना पड़े कि बदलाव को किसने authorize किया था। यदि कोई workflow restart सहन नहीं कर सकता, तो उसे shared desktop के accidental handoff के बजाय जानबूझकर बनाए गए multiuser design की जरूरत है।

Handoff तेज करने के लिए account साझा न करें। Shared login बाद में जरूरी evidence नष्ट कर देता है। आप यह नहीं बता पाएंगे कि vault किस व्यक्ति ने unlock किया, process किस terminal से शुरू हुई या call को किसके निर्णय ने approve किया। अलग macOS accounts हर समस्या हल नहीं करते, लेकिन वे उपयोगी boundary और काम का record बनाए रखते हैं।

टीमों को absent owners के लिए भी नियम चाहिए। यदि कोई agent process ऐसे व्यक्ति के account में चल रही है जो उपलब्ध नहीं है, तो किसी को उसके account में click करते हुए उसे जीवित नहीं रखना चाहिए। उसे रोकें, revoke करें और मौजूद owner के account में फिर शुरू करें। काम प्रतीक्षा कर सकता है। External systems बदलने वाली unattended permission को नहीं रहना चाहिए।

Prompts दिखाई देने से पहले vault लॉक होने पर actions रुक जाने चाहिए

Vault gate को locked रहते हुए हर action deny करना चाहिए, भले agent process को पहले session approval मिल चुका हो। यही run करने की authorization और अभी credential इस्तेमाल करने की permission के बीच का अंतर है। पहली बात यह तय करती है कि human किस process को पहचानता है। दूसरी पूछती है कि credential store इस समय उपलब्ध है या नहीं।

Sallyport इस क्रम का जानबूझकर उपयोग करता है: उसका vault gate absolute है और macOS पर locked actions को deny करते हुए Secure Enclave और Touch ID का उपयोग करता है। इससे user के session लॉक करने के बाद stale agent authorization vault access का विकल्प नहीं बन पाती।

Controls को अपने mental model में अलग रखें। Vault gate credential material तक पहुंच बचाता है। Session authorization किसी खास agent run को पहचानता है। Per-call approval चुने हुए credentials पर direct review जोड़ता है। यदि एक control दूसरे का काम करने लगे, तो operators के लिए denial का कारण समझना कठिन हो जाता है।

उदाहरण के लिए, broad credential की एकमात्र सुरक्षा per-call prompts को न बनाएं। Crowded desktop पर वापस आने के बाद कोई व्यक्ति गलती से गलत request approve कर सकता है। Locked vault को credential owner के locally authenticate करने तक action पहले ही deny कर देना चाहिए। उसके बाद per-call prompt संकरा सवाल पूछ सकता है: क्या इस credential का यह खास उपयोग अनुमति के योग्य है?

इसी तरह vault को हमेशा unlocked न रखें, सिर्फ इसलिए कि लंबे coding task को बाद में इसकी जरूरत पड़ सकती है। इससे ध्यान में आए छोटे अंतराल का रूप बदलकर ऐसा समय बन जाता है जिसमें पुरानी process action कर सकती है। Supervised work के लिए unlock करें और owner के हटने या Mac किसी और को देने पर lock कर दें। यदि job को वास्तव में unattended authority चाहिए, तो उसे service identities, सीमित credentials और स्पष्ट operational ownership वाले environment में ले जाएं। Shared personal session server का दिखावा करने की सही जगह नहीं है।

«Human in the loop» शब्द अक्सर identity का सवाल छिपा देता है। कौन-सा human? किस account के अंतर्गत? किस process को approve किया जा रहा है? जो prompt इन सवालों का उत्तर नहीं दे सकता, वह meaningful control नहीं देता। वह केवल किसी के button click करने का record बनाता है।

Audit records timeline स्पष्ट करते हैं, permission decision नहीं

Tamper-evident audit trail disputed action के बाद agent run को फिर से समझने देता है, लेकिन घटना के समय गलत authorization को रोक नहीं सकता। Sequence और ownership स्पष्ट करने के लिए log का उपयोग करें, फिर उस control को ठीक करें जिसने action की अनुमति दी। Audit history को locked vault या स्पष्ट approval boundary का विकल्प न मानें।

Record के दो views होने चाहिए, क्योंकि operators दो अलग सवाल पूछते हैं। Session journal जवाब देता है, «कौन-सा agent run authorized था और क्या मैं उसे revoke कर सकता हूं?» Activity journal जवाब देता है, «कौन-सी call हुई, किस channel पर और कब?» दोनों records को एक append-only source से बनना चाहिए, न कि दो असंबंधित databases से जो समय के साथ अलग हो जाएं।

Sallyport दोनों journals को write-blind encrypted, hash-chained audit log से project करता है। इसलिए activity history और run history एक ही source of record साझा करते हैं। इसकी offline जांच इस command से की जा सकती है:

sp audit verify

Machine archive करते समय, disputed handoff की जांच में या exported audit store मिलने पर यह check चलाएं। Verifier ciphertext पर chain की जांच करता है और उसे decryption credential की जरूरत नहीं होती। Shared Macs पर यह गुण महत्वपूर्ण है: Investigator यह देख सकता है कि records अब भी valid history बनाते हैं या नहीं, बिना उन API tokens या SSH material को हासिल किए जिनसे history संबंधित है।

Verification बताता है कि chain internally consistent रही है या नहीं। यह साबित नहीं करता कि हर event समझदारी भरा था, व्यक्ति ने हर prompt समझकर approve किया था या device में कोई compromise नहीं हुआ था। दावे को सटीक रखें। Verified chain पुराने records में छेड़छाड़ को छिपाना कठिन बनाती है। वह unsafe shared account को safe नहीं बनाती।

Investigation के दौरान account context, process identity, session authorization time, vault unlock event और individual call order की तुलना करें। उपयोगी सवाल केवल «क्या agent ने यह किया?» नहीं है। पूछें कि क्या vault, agent process और approval एक ही account के ownership में थे। यदि ये अलग हैं, तो आपको वह boundary मिल गई जिस पर ध्यान देने की जरूरत है।

HTTP और SSH calls shared-session के अलग risks लाती हैं

HTTP और SSH actions दोनों authority खर्च करते हैं, लेकिन उनका operational footprint और failure mode अलग होता है। HTTP credentials अक्सर व्यापक API scope वाली remote service तक पहुंच देते हैं। SSH credentials remote host पर shell दे सकते हैं, जहां एक accepted connection कई commands चला सकती है। दोनों एक ही local agent से शुरू हों, फिर भी उन्हें एक जैसा approval treatment न दें।

HTTP के लिए destination, method और credential scope देखें। Narrow development API को भेजी गई read request और environment-management endpoint को भेजी गई write request के लिए अलग rule होना चाहिए। Agent को local gateway के जरिए action मांगना चाहिए, जो credential खुद जोड़ता है। Agent को bearer token के बजाय परिणाम मिलता है। इससे secret exposure सीमित होता है, लेकिन approved destructive request का प्रभाव कम नहीं होता।

SSH के लिए host identity, account identity और command intent पर ध्यान दें। Restricted account वाले development host से connection और shared production account से connection में बड़ा अंतर है। यदि credential interactive shell देता है, तो उसे high-impact permission मानें, भले पहली command harmless दिखे। अगली command वैसी नहीं हो सकती।

Fast User Switching दोनों channels में एक local condition जोड़ता है। एक account की live agent process केवल इसलिए HTTP requests जारी न रखे या SSH sessions न खोले क्योंकि दूसरे उपयोगकर्ता ने Mac को active बना दिया है। Gateway को request को originating process से जोड़ना चाहिए और vault owner से gate पूरा करवाना चाहिए। दूसरे उपयोगकर्ता की screen पहले उपयोगकर्ता के run के लिए approval surface नहीं बननी चाहिए।

जहां accountability महत्वपूर्ण हो, वहां अलग-अलग लोगों के लिए अलग credentials रखें। Shared deployment token से यह समझना कठिन हो जाता है कि समस्या process की थी या human handoff की। Individual credentials और account-scoped vault entries audit history को उपयोगी बनाते हैं, जब वास्तविक owner ढूंढना हो।

कुछ workloads shared workstation पर नहीं होने चाहिए

Narrow credentials और deliberate approvals के साथ supervised local development work के लिए shared Mac ठीक जगह है। ऐसे लंबे समय तक चलने वाले autonomous agent के लिए यह खराब जगह है जिसे production systems बदलने, broad administrative APIs तक पहुंचने या किसी व्यक्ति की मौजूदगी के बिना remote shells बनाए रखने का अधिकार हो।

सीमा यह नहीं है कि agent कितना clever है। सवाल यह है कि accountable owner के console से हटने के बाद भी काम action कर सकता है या नहीं। यदि कर सकता है, तो ऐसा environment इस्तेमाल करें जो उस काम के लिए बनाया गया हो। Workload को dedicated service identity, defined owner, सीमित credentials और ऐसे records दें जिन्हें operations staff किसी के desktop session को उधार लिए बिना देख सके।

Server design को local app design न समझें। Server का threat model, lifecycle controls और unattended execution की अपेक्षाएं अलग होती हैं। Mac menu bar app developer को local actions पर मजबूत human control दे सकती है। उसे headless automation system जैसा व्यवहार नहीं करना चाहिए, केवल इसलिए कि कोई task रात भर चलता रहे।

आपके पास मौजूद shared Mac के लिए पहला policy rule स्पष्ट रखें: कोई agent unowned handoff के बाद external authority बनाए नहीं रखेगा। User switch के बाद क्या बचता है, इसकी जांच करें। Credential owner के जाने पर vault locking लागू करें और पुराने runs को revoke करें, इस उम्मीद पर न रहें कि अगला व्यक्ति उन्हें देख लेगा। यही वह बिंदु है जहां Fast User Switching केवल desktop convenience नहीं रहता और उसे आवश्यक security treatment मिलता है।