macOS logout security: local agent authority समाप्त करें

Developer का logout local agent authority को समाप्त करना चाहिए, भले ही agent process, network request या menu-bar app को अभी इसका पता न चला हो। Logout को cleanup करने के लिए एक विनम्र अनुरोध मानने से ऐसी खिड़की खुल जाती है जिसमें unattended machine अब भी किसी इंसान के credentials से काम कर सकती है।

यह बात coding agents के लिए खास तौर पर महत्वपूर्ण है, क्योंकि उनका उपयोगी काम एक सीमा पार करता है। वे APIs call करते हैं, SSH sessions खोलते हैं, tickets बनाते हैं, packages publish करते हैं या infrastructure बदलते हैं। अगर उनकी authority keyboard पर बैठे व्यक्ति से मिली थी, तो उस व्यक्ति के macOS session से बाहर जाते ही वह समाप्त होनी चाहिए। System को हुई कार्रवाई का evidence बचाकर रखना चाहिए, लेकिन आगे कुछ करने की क्षमता नहीं।

मुझे बार-बार एक गलती दिखती है: तीन अलग चीज़ों को मिला दिया जाता है, स्थानीय रूप से रखा secret, किसी process को मिली approval और पहले से चल रही action। इन तीनों के लिए shutdown behavior अलग होना चाहिए। एक सामान्य quit handler बहुत देर से चलता है और बहुत अस्पष्ट होता है।

Logout application event नहीं, authority boundary है

macOS logout security का मतलब है कि interactive user session न होने पर future credentialed actions deny होनी चाहिए, चाहे हर application व्यवस्थित रूप से बंद हो या नहीं। सामान्य logout के दौरान desktop application को termination notifications मिल सकती हैं, लेकिन security इस बात पर निर्भर नहीं हो सकती कि notifications आएँगी, पूरी होंगी या सुविधाजनक क्रम में चलेंगी।

User laptop बंद कर सकता है, users बदल सकता है, app को force-quit कर सकता है, power खो सकता है या agent के किसी slow endpoint पर इंतज़ार करते समय logout शुरू कर सकता है। Operating system processes को ऐसे क्रम में भी बंद कर सकता है जिसकी आपके code ने उम्मीद न की हो। ऐसा design जिसमें कहा जाए, "हम applicationWillTerminate में access revoke कर देंगे", पहले ही बहुत अनिश्चितता स्वीकार कर चुका है।

Apple का launchd documentation यहाँ महत्वपूर्ण scope distinction बताता है। इसमें system, user और graphical login domains अलग किए गए हैं। Graphical user domain का job किसी खास logged-in session से जुड़ा होता है, जबकि system job का lifetime और authority model अलग होता है। यह न मानें कि "process अभी चल रहा है" इसलिए उसे departed user की ओर से काम करने की permission भी है।

Authorization check को ऐसे current session fact पर आधारित करें जिसे action gateway call के समय verify कर सके। हर action को इस क्रम में पूछना चाहिए:

1. क्या इस logged-in user session के लिए vault अभी खुला है?
2. क्या यह request उसी session के live, authorized agent process से जुड़ी है?
3. क्या इस credential के लिए इस खास उपयोग पर approval चाहिए?
4. क्या logout या session-revocation event ने session generation को आगे बढ़ा दिया है?

चौथा check एक सूक्ष्म race रोकता है। Request पहले तीन checks पास कर सकती है, queue में रुकी रह सकती है और logout शुरू होने के बाद executor तक पहुँच सकती है। Credential injection या SSH execution से ठीक पहले generation number को फिर से check करने पर ऐसी stale request fail हो जाती है।

Logout behavior को agent के रुकने की सहमति पर निर्भर न करें। Boundary पर agent एक untrusted caller है। वह भ्रमित, व्यस्त, compromised या बिल्कुल गायब हो सकता है।

Cleanup शुरू होने से पहले locked vault को deny करना चाहिए

Vault gate सबसे पहले बंद होना चाहिए और executor के दृष्टिकोण से यह synchronous होना चाहिए। Gate बंद होते ही कोई नया HTTP credential injection और कोई नया SSH authentication शुरू नहीं होना चाहिए। Cleanup उसके बाद हो सकता है, लेकिन system को सुरक्षित बनाने का साधन cleanup नहीं हो सकता।

यह क्रम तब तक स्पष्ट लगता है, जब तक app request queue न संभालती हो। आम failure कुछ ऐसा होता है: agent पाँच deploy calls भेजता है, UI logout cleanup शुरू करता है, app दिखाई देने वाला session card हटा देती है और worker thread चौथी call को ऐसे credential reference के साथ queue से निकाल लेता है जिसे उसने पहले ही resolve कर लिया था। App logged out दिखती है, लेकिन action बाहरी service तक पहुँच जाती है।

Secret use का नियंत्रण रखने वाले process में एक ही authority object रखें। उसमें opaque session identifier, generation counter और enabled state होनी चाहिए। Workers को secret bytes कभी न दें। उन्हें action request मिले और vault के action करने से ठीक पहले fresh authorization lease लेना अनिवार्य हो।

एक छोटा-सा ढाँचा पर्याप्त है:

AuthorityState {
  sessionID: 6C17...
  generation: 41
  vaultOpen: true
  logoutStarted: false
}

execute(request):
  lease = authority.issueLease(request, generation: 41)
  vault.perform(request, lease)

beginLogout():
  authority.logoutStarted = true
  authority.vaultOpen = false
  authority.generation = 42
  cancelPendingRequests()

vault.perform को lease तब reject करनी चाहिए, जब उसकी generation अब match न करे। यह दूसरी तुलना उस बिंदु के जितना संभव हो उतना पास होनी चाहिए जहाँ vault HTTP header देता है, SSH helper शुरू करता है या request sign करता है। केवल request के queue में प्रवेश करते समय check करने से ऐसी race बचती है जो सचमुच नुकसान कर सकती है।

Secure Enclave और Touch ID से vault सुरक्षित रखने वाली macOS app के लिए hardware-gated access उपयोगी है, क्योंकि इससे gate का स्पष्ट local owner मिलता है। इससे session state की ज़रूरत समाप्त नहीं होती। Logout से पहले स्वीकार किया गया biometric prompt logout के बाद किसी call को authorize नहीं कर सकता।

Sallyport का vault gate इसी नियम पर चलता है: जब तक vault locked है, हर action deny होती है। यह निश्चित boundary shutdown exception list से बेहतर है, क्योंकि exception lists फैलती जाती हैं और अंत में कोई नहीं बता पाता कि कौन-सी call अब भी उनसे बाहर निकल रही है।

Active approval एक process और एक session से जुड़ी होती है

User approval को किसी खास agent process, उसकी code-signing authority और current macOS login session से bind करना चाहिए। इसका अर्थ कभी यह नहीं होना चाहिए कि "इस account ने इस tool को कभी पहले approve किया था।"

Process identity केवल process ID नहीं होती। Process IDs दोबारा इस्तेमाल हो सकती हैं। केवल PID 4812 दर्ज करने वाला caller पर्याप्त churn के बाद किसी unrelated process को गलती से bless कर सकता है। PID के साथ process start time और code-signing identity भी दर्ज करें। अगर process किसी terminal या editor integration का child है, तो approval record में route समझाने के लिए पर्याप्त parent information रखें, लेकिन ancestry को अकेला trust signal न बनाएँ। Shell wrappers और process supervisors इसे लगातार बदलते रहते हैं।

Approval card में signing authority को सबसे ऊपर रखें, क्योंकि इससे developer एक सार्थक सवाल पूछ सकता है: "क्या मैं इस signed agent process को इस session में काम करने देना चाहता हूँ?" MCP के ज़रिए दिया गया package name या कोई मनमाना string इस सवाल का जवाब नहीं देता।

Logout शुरू होते ही उस session की हर active approval discard करें। उसे suspend न करें। अगले login के लिए serialize न करें। Same binary restart के बाद लौटे तो भी उसे फिर से न बनाएँ। Developer को नए run को नए run की तरह approve करना चाहिए।

यह उन approval dialogs पर भी लागू होता है जो screen पर पहले से खुले हों। Session बदलने पर उन्हें गायब हो जाना चाहिए या inert हो जाना चाहिए। पुराने card पर देर से किया गया click अब समाप्त authorization को फिर सक्रिय न कर सके। हर approval prompt की expiration को उसी session generation से जोड़ें जो requests की रक्षा करती है।

एक उपयोगी distinction है जिसे कई implementations धुंधला कर देती हैं:

• Vault unlock local gateway को actions पर विचार करने की अनुमति देता है।
• Session authorization एक पहचाने गए agent process को actions submit करने की अनुमति देता है।
• Per-use approval किसी खास credential use की अनुमति देता है।

Logout इन तीनों को invalidate करता है, लेकिन इनके evidence और timing एक जैसे नहीं होते। Vault तुरंत बंद होता है। Session approvals एक group के रूप में invalid हो जाती हैं। Per-use prompts अलग-अलग fail होते हैं, क्योंकि उनकी session generation बदल गई है। इन सबको एक Boolean में समेटने से यह audit करना कठिन हो जाता है कि कोई call क्यों सफल या असफल हुई।

Running tools को cancellation और ईमानदार uncertainty चाहिए

Logout को उस work को रोकना चाहिए जिसने external boundary पार नहीं की है और उस work को रोकने की कोशिश करनी चाहिए जिसने boundary पार कर ली है। Remote service द्वारा स्वीकार की जा चुकी operation को यह वापस नहीं कर सकता।

Action को ऐसे states में बाँटें जिनका operational अर्थ हो:

queued -> authorized -> dispatched -> response received
                    \-> cancelled

Queued action अभी Mac से बाहर नहीं गई है। उसे queue से हटाएँ और cancelled_before_dispatch report करें। Authorized action के पास केवल short-lived internal lease हो सकती है। Dispatch से पहले lease invalidate करें और अगर worker बहुत देर से पहुँचे तो revoked_before_dispatch report करें।

Dispatched action अलग होती है। Remote system ने उसे प्राप्त कर लिया हो सकता है, भले ही local process को कभी response न मिले। केवल socket बंद करने या helper को kill करने के कारण उसे cancelled report न करें। logout_during_dispatch दर्ज करें, remote protocol request identifier देता हो तो उसे capture करें और user को बताएँ कि remote system की जाँच होने तक outcome unknown है।

HTTP requests पर विशेष सावधानी चाहिए। Client connection बंद करने से upload server के पढ़ने से पहले रुक सकता है, या यह server द्वारा change commit करने के बाद भी हो सकता है। Idempotency tokens user के बाद में retry करने पर नुकसान घटाते हैं, लेकिन uncertain request को cancelled request में नहीं बदलते। External resource बनाने वाली operations के लिए ऐसा idempotency identifier भेजें जिसे remote API सचमुच स्वीकार करती हो, फिर credential store किए बिना उस identifier को log करें।

SSH इससे भी कम व्यवस्थित है। Local helper को signal भेजने से local process तो बंद हो सकता है, लेकिन remote command अपने process group में चलती रह सकती है। जब remote environment आपके नियंत्रण में हो, तो लंबे work को explicit job identifier और cancellation path वाले remote job supervisor के तहत चलाएँ। जब वह आपके नियंत्रण में न हो, तो activity record में यह स्पष्ट लिखें। Local terminal बंद होने के कारण remote migration cancel होने का दिखावा करना खराब incident को और खराब करता है।

Cleanup के लिए logout को अनिश्चित समय तक न रोकें। पहले authority बंद करें, workers से cancel करने को कहें, application को छोटा और सीमित cleanup interval दें और operating system को logout पूरा करने दें। Security property future use को deny करना है। Graceful exit केवल best-effort सुविधा है।

Background persistence threat model बदल देती है

User के logout के बाद भी काम करती रहने वाली per-user app desktop assistant से बदलकर unattended service बन गई है। जानबूझकर बनाए गए service account के लिए यह उचित हो सकता है। Menu-bar application के अनजाने side effect के रूप में यह उचित नहीं है।

किसी agent को logout के दौरान जीवित रखने के लिए privileged helper या system-domain launch job install करने से बचें। यह कदम लोकप्रिय है, क्योंकि इससे long jobs reliable दिखती हैं। लेकिन इससे action path उस व्यक्ति से अलग हो जाता है जिसने उसे approve किया था और access अक्सर original user session से बाहर तक फैल जाता है।

अगर team को सचमुच developer के जाने के बाद work जारी रखना है, तो उस work को अलग जगह दें। Explicit service identity, सीमित remote scope और expiry वाले credentials, defined ownership, audit trail और ऐसा cancellation procedure इस्तेमाल करें जिसे दूसरा operator चला सके। Handoff को visible रखें। Local agent को चुपचाप यह भूमिका न लेने दें।

Fast User Switching भी यही समस्या दिखाता है। User A graphical session खुला छोड़ सकता है, जबकि User B sign in करता है। User B को User A की agent authority approve या देख नहीं पाना चाहिए। हर gateway instance, approval record और vault access check को सही user और graphical session से bind करें। Machine-wide daemon अगर दोनों users को लापरवाही से multiplex करता है तो बहुत सावधानी से isolation करना होगा। अधिकांश desktop tools को इस architecture से बचना चाहिए।

Sleep logout नहीं है। Sleeping Mac उसी user session को resume कर सकता है, इसलिए teams को sleep और screen lock के लिए अलग निर्णय चाहिए। Sensitive credentials के लिए screen lock पर vault बंद करना अक्सर उचित है। कम संवेदनशील local work के लिए gateway vault state बनाए रख सकता है, लेकिन wake के बाद fresh approval माँग सकता है। जो policy चुनें, उसे logout behavior न कहें। Users और incident reviewers को सटीक शब्द चाहिए।

Logs को authority से अधिक समय तक रहना चाहिए, लेकिन दूसरा secret store नहीं बनना चाहिए

जिस authority का अंत हुआ उसका durable record ज़रूरी है, खास तौर पर जब network action logout के साथ overlap करे। Tokens, request bodies या SSH private material से भरा दूसरा database बनाने की ज़रूरत नहीं है।

Lifecycle events को facts की तरह लिखें: session opened, agent process approved, request submitted, credential use authorized, dispatch began, logout observed, lease revoked, helper termination requested और final outcome। ऐसे stable identifiers शामिल करें जिनसे operator events को आपस में जोड़ सके, लेकिन user content कम से कम रखें। Activity record यह बता सकता है कि configured endpoint को HTTP call सफल हुई, बिना authorization header या sensitive response body को बचाए।

Hash-chained audit log में सामान्य application logging से अलग एक गुण होता है: offline verifier हटाए गए या बदले गए records का पता लगा सकता है। Disputed deployment या suspected local compromise के बाद यह उपयोगी है, लेकिन इससे log अपने-आप truthful नहीं बन जाता। Log केवल अपने भीतर मौजूद records के बीच continuity साबित करता है। यह साबित नहीं कर सकता कि malicious process ने action करने से पहले logging कभी बंद नहीं की।

इसी कारण किसी भी best-effort process cleanup से पहले revocation event लिखें। अगर helper को kill करते समय app crash हो जाए, तो record में फिर भी दिखना चाहिए कि local authority समाप्त हो गई थी और action outcome uncertain हो सकता है। केवल clean completions दर्ज करने वाला audit trail operators को गलत सीख देता है।

Sallyport अपने session और activity journals को एक ही write-blind encrypted, hash-chained audit log से project करता है और sp audit verify ciphertext पर offline रूप से उस chain की जाँच कर सकता है। इससे team केवल यह देखने के लिए vault खोले बिना continuity जाँच सकती है कि logout ने run revoke किया या नहीं।

उपयोगी audit question विशिष्ट होता है: "किस process के पास authority थी, उसने कौन-सा credential path माँगा और user के जाने के समय gateway को क्या पता था?" बहुत बड़ा debug log शायद ही इसका जवाब देता है।

Clean quit की जगह races को test करें

Logout test में किसी action को boundary के साथ overlap कराएँ। सभी workers के खत्म होने के बाद application shutdown method call करने वाले tests केवल यह साबित करते हैं कि normal cleanup काम करती है।

सबसे पहले अपने नियंत्रण वाले endpoint से शुरू करें जो request स्वीकार करे, उसके मिलने का record बनाए और फिर response में delay करे। Agent gateway के ज़रिए action submit करें और gateway द्वारा action को dispatched mark करने के बाद, लेकिन response लौटने से पहले logout शुरू करें। अगली login पर local audit state की तुलना endpoint के record से करें। Expected result हमेशा "cancelled" नहीं होता। वह logout_during_dispatch जैसी accurate state और जाँच करने योग्य request identifier हो सकता है।

Queued work के लिए अलग test रखें। Worker को queue से item लेने के बाद, लेकिन action lease के लिए vault से पूछने से पहले pause करें। Logout शुरू करें, worker को release करें और assert करें कि उसे कुछ भेजने के बजाय revocation result मिलता है। यह test उस आम गलती को पकड़ता है जिसमें authorization केवल request के queue में प्रवेश करते समय check की जाती है।

फिर कठिन स्थितियों को आज़माएँ:

• Original session खुला रखते हुए दूसरे user पर switch करें।
• Screen lock करें, machine को wake करें और इस transition के लिए चुनी हुई policy test करें।
• Approval का इंतज़ार कर रहे agent को force-quit करें, फिर नए process को reused PID के साथ शुरू करें, अगर आपका harness ऐसा कर सकता हो।
• Shutdown के दौरान gateway को interrupt करें और देखें कि audit record unresolved work की पहचान अब भी करता है या नहीं।
• ऐसी SSH command भेजें जो remote work शुरू करे, फिर local helper के exit status पर भरोसा करने के बजाय remote-side behavior की पुष्टि करें।

macOS पर test setup के दौरान launch domains देखें, ताकि आपको पता हो कि वास्तव में क्या शुरू किया गया है:

uid="$(id -u)"
launchctl print "gui/$uid" | grep -E "(agent-gateway|your-test-label)"

Output installed job और macOS version के अनुसार बदलता है, लेकिन इसमें matching job current gui/<uid> domain के भीतर दिखना चाहिए। अगर आपका test job इसके बजाय system domain में दिखे, तो उसका logout result सामान्य desktop application के session behavior के बारे में बहुत कम बताता है।

किसी developer के primary account पर पहले real logout automate न करें। Disposable local account, disposable API credential और ऐसा endpoint इस्तेमाल करें जहाँ आप हर request देख सकें। Logout tests unsaved work नष्ट कर सकती हैं और remote state को आधा बदला हुआ छोड़ सकती हैं। यह उन्हें छोड़ने का कारण नहीं है। यह उन्हें केवल unit test मानना बंद करने का कारण है।

Remote credentials को late call का blast radius सीमित करना चाहिए

Local revocation समय पीछे जाकर उस bearer token को revoke नहीं कर सकती जिसे remote service पहले ही स्वीकार कर चुकी है। Remote credential design नुकसान सीमित करती है, अगर gateway request बहुत देर से पहचानता है, app crash हो जाती है या logout से पहले machine compromise हो जाती है।

जहाँ target इसका समर्थन करता हो, वहाँ सीमित permissions और short lifetimes वाले remote credentials को प्राथमिकता दें। अलग environments के लिए अलग credentials इस्तेमाल करें। Staging deployment update कर सकने वाले agent को केवल इसलिए ऐसा credential न दें जो production data delete कर सके कि दोनों endpoints एक ही API vendor का इस्तेमाल करते हैं।

SSH के लिए dedicated remote account इस्तेमाल करें और उस account की क्षमताएँ सीमित रखें। अगर किसी command को long-running task शुरू करना है, तो remote side पर task का ownership और cancellation स्पष्ट रखें। Broad shell access वाली personal SSH identity तब सुविधाजनक लगती है, जब तक आपको ऐसे job का स्पष्टीकरण न देना पड़े जो अपने local parent के गायब होने के बाद भी चलता रहा।

Credentials को agent तक environment variables, configuration text, placeholder substitutions या shell arguments के रूप में न पहुँचाएँ। Secret caller में पहुँचने के बाद logout future local actions रोक सकता है, लेकिन process memory, shell history, crash reports या transcript में मौजूद उस copy को गायब नहीं कर सकता। Gateway को credential केवल उसी action में inject करना चाहिए जिसे वह execute कर रहा है और result agent को लौटाना चाहिए।

इस design से logout का काम साफ़ रहता है: vault बंद करना, active grants invalidate करना, stale leases reject करना, pending work रोकना और पहले भेजे जा चुके work के लिए uncertainty दर्ज करना। यह internet को undo करने का वादा नहीं कर सकता। यह उस व्यक्ति की authority उधार लेकर होने वाली अगली call को रोक सकता है जो अब वहाँ नहीं है।

Exit condition को समझाना आसान होना चाहिए

इस rule को ऐसे वाक्य में लिखें जिसे कोई थका हुआ developer incident के दौरान इस्तेमाल कर सके: जब macOS user session समाप्त हो जाता है, तो कोई भी local agent process उस user की authority के तहत दूसरी credentialed action शुरू नहीं कर सकता।

बाकी सब इसी rule से निकलता है। Cleanup से पहले vault gate बंद होता है। Approvals उस process और session के साथ समाप्त हो जाती हैं जिसने उन्हें अर्जित किया था। Queued request अपना lease खो देती है। Dispatched request को तब तक ईमानदार unknown state मिलती है, जब तक remote system result की पुष्टि न कर दे। Logs review के लिए उपलब्ध रहते हैं, जबकि secrets और executable authority नहीं।

अगर किसी product को logout के बाद authority चाहिए, तो अपनी identity वाली explicit unattended service बनाएँ। इस निर्णय को desktop application's shutdown path में छिपाकर न रखें।