Mac के sleep और wake के बाद agent authority

स्वीकृत एजेंट प्रक्रिया को केवल इसलिए अधिकार नहीं मिलना चाहिए कि Mac जाग गया और वही प्रक्रियाएं अब भी मेमोरी में मौजूद हैं। Sleep, display blanking, screen lock, lid close और wake अलग-अलग operating-system events हैं, लेकिन सभी एक ही सुरक्षा सवाल खड़ा करते हैं: क्या इस run को स्वीकृति देने वाला व्यक्ति अब भी मौजूद है और हस्तक्षेप कर सकता है?

इस सवाल को power-management detail नहीं, authorization decision मानें। अगर coding agent के पास API या SSH authority है, तो पुरानी approval एक साधारण कॉफी ब्रेक, यात्रा या रातभर के विराम को बिना निगरानी के credential use में बदल सकती है। समाधान नियमों की भूलभुलैया नहीं है। एक छोटा state model, स्पष्ट expiration policy और ऐसे tests पर्याप्त हैं जो उन असहज transitions को मजबूर करें जिन्हें लोग अक्सर छोड़ देते हैं।

Sleep एक ही घटना नहीं है

macOS system sleep और screen sleep में अंतर करता है। यह अंतर महत्वपूर्ण है, क्योंकि अंधेरा display इस बात का प्रमाण नहीं है कि एजेंट रुक गया। Apple willSleep, didWake, screensDidSleep और screensDidWake के लिए अलग NSWorkspace notifications देता है। Sleep और wake notifications में ऐसा user data नहीं होता जो ऐप को बताए कि transition क्यों हुआ।

लैपटॉप display को धीमा या बंद कर सकता है, जबकि build, network transfer या स्थानीय प्रक्रिया चलती रहे। Desktop Mac बिना active display के काम कर सकता है। Power और peripherals से जुड़े notebook का व्यवहार battery पर चल रहे उसी notebook से अलग हो सकता है। Pixel के काला होने से authority decision का अनुमान नहीं लगाया जा सकता।

अपने design में इन चार अलग तथ्यों का उपयोग करें:

• Display state बताता है कि screen सोई या जागी।
• Power state बताता है कि मशीन sleep की तैयारी कर रही थी या उससे जागी।
• User-presence state बताता है कि session active, locked, logged out या दूसरे user पर switched है।
• Vault state बताता है कि secrets का उपयोग बिल्कुल किया जा सकता है या नहीं।

टीमें अक्सर पहले तीनों को isAwake नाम के Boolean में मिला देती हैं। यह shortcut authority लीक करता है। Screen sleep में होने पर भी एजेंट चल सकता है। मशीन lock screen पर जाग सकती है। User system को sleep में डाले बिना screen lock कर सकता है। हर स्थिति का अपना expected result होना चाहिए।

सही default कठोर है, लेकिन समझाना आसान है: protected action के लिए unlocked vault और current authority epoch से जुड़ी current approval जरूरी है। Wake, lock, user-session change, manual revoke या vault lock उस epoch को आगे बढ़ा सकते हैं। Epoch बढ़ने के बाद पुराने epoch की calls असफल होनी चाहिए।

Screen lock को interactive authority समाप्त करनी चाहिए

Screen lock सबसे स्पष्ट संकेत है कि interactive approval रुकनी चाहिए। Mac चलता रह सकता है और लंबे समय से चल रही terminal प्रक्रिया के sockets और memory अब भी मौजूद हो सकते हैं, लेकिन approval देने वाला user interactive session से जा चुका है। पिछली click के आधार पर API requests या SSH commands भेजते रहना उचित ठहराना कठिन है।

इसका मतलब यह नहीं कि lock होते ही हर agent को बंद कर देना चाहिए। स्थानीय computation बंद करना अलग निर्णय है। अगर credentialed gateway की जरूरत न हो, तो model repository पढ़ना, code compile करना या patch तैयार करना जारी रख सकता है। सीमा external action है। काम रखें, authority हटाएं।

यह अंतर all-or-nothing विकल्प से बचाता है। आपको frozen agent और पूरी तरह खुले agent में से एक चुनने की जरूरत नहीं है। Agent को अपने local workspace में सुरक्षित काम जारी रखने दें और अगली protected call को स्पष्ट denial लौटाने दें:

authorization_denied
reason: authority_epoch_changed
required: unlock_vault_and_approve_session

अच्छा denial agent को बताता है कि क्या हुआ, बिना secret उजागर किए और बिना यह दिखावा किए कि request network समस्या के कारण असफल हुई। Agent blocker दर्ज करके रुक सकता है और user की प्रतीक्षा कर सकता है, बजाय उसी destructive command को बार-बार आजमाने के।

Idle timer से आया lock होने पर अपवाद न बनाएं। यही वह स्थिति होती है जब user अक्सर भूल जाता है कि agent अभी भी चल रहा है। Explicit lock और automatic lock के पीछे मानवीय इरादा अलग हो सकता है, लेकिन इनमें से कोई भी यह साबित नहीं करता कि व्यक्ति production change को मंजूरी देने के लिए उपलब्ध है।

Lock के बाद authority बनाए रखने का एक सीमित मामला है: जानबूझकर unattended job, जिसे अलग से दी गई और कड़ाई से सीमित capability मिली हो। यह अलग run type होना चाहिए, interactive approval का छिपा अपवाद नहीं। अगर आपका overnight automation दिन में chat-driven agent की तरह ही व्यवहार करता है, तो आपने जोखिम अलग नहीं किए हैं।

Wake event से नया authority epoch शुरू होता है

Wake को interactive approval अमान्य कर देनी चाहिए, भले ही approved process बची रहे। प्रक्रिया sleep से पहले रुक सकती है और बाद में उसी PID, environment variables और खुले file descriptors के साथ जारी हो सकती है। इनमें से कोई भी बात यह साबित नहीं करती कि पुराना मानवीय निर्णय अब भी लागू है।

Authority epoch एक monotonic value है, जो उस लगातार अवधि को चिन्हित करती है जिसमें grant valid हो सकता है। जब system आपकी तय की हुई सीमा पार करे, तो अगली action serve करने से पहले epoch बढ़ाएं। प्रक्रिया इससे बातचीत नहीं करती। अगली request पर उसे बदलाव का पता चलता है।

एक न्यूनतम authorization record ऐसा दिख सकता है:

{
  "session_nonce": "6a018d62-2e94-4d4a-9e79-1f4e4b5ca501",
  "process_id": 84172,
  "process_start_marker": "2026-07-22T14:03:18Z",
  "signing_authority": "approved-agent-binary",
  "authority_epoch": 27,
  "approved_at": "2026-07-22T14:04:01Z",
  "per_call_approval": false
}

Process ID केवल एक field है। प्रक्रिया बंद होने के बाद macOS PID दोबारा इस्तेमाल कर सकता है। इसलिए अगर gateway पुराना record भूल जाए और वही संख्या फिर देखे, तो केवल PID खतरनाक हो जाता है। Approval को नए nonce और देखी गई process instance से जोड़ें। Executable के identity signal के रूप में code-signing authority का उपयोग करें, फिर भी हर नई process run के लिए नई per-session approval आवश्यक रखें।

जब event handler को willSleep दिखे, तो revoke करने का इरादा दर्ज करें और नई protected calls स्वीकार करना तुरंत रोक दें। Apple के अनुसार observer sleep handling में 30 सेकंड तक देरी कर सकता है, लेकिन उस समय का उपयोग pending actions की queue पूरी करने में न करें। उन्हें deny करें या interrupted चिह्नित करें। Lid बंद होते समय user ने आखिरी burst of work की अनुमति नहीं दी है।

जब मशीन wake रिपोर्ट करे, तो जरूरत होने पर epoch फिर बढ़ाएं और user के unlock requirement पूरी करने तक vault gate बंद रखें। इससे event ordering की खामियां संभलती हैं। Power events किनारों पर अव्यवस्थित हो सकते हैं। Transition के दौरान secret वाली call निकल जाने से बेहतर है कि एक अतिरिक्त approval मांग ली जाए।

Lid close के लिए अलग test case रखें

Notebook का lid बंद करना व्यक्ति को sleep command जैसा लगता है, लेकिन software को यह नहीं मानना चाहिए कि physical gesture साफ तौर पर एक ही operating-system event में बदलता है। Power source, external displays, docking gear और settings मशीन का व्यवहार बदल सकते हैं। ईमानदार उत्तर यही है कि आपकी टीम जिन hardware और configuration का उपयोग करती है, उन पर test करें।

Security policy फिर भी सरल हो सकती है: जैसे ही कोई भरोसेमंद संबंधित boundary दिखे, lid close interactive authority समाप्त कर दे। सामान्य portable setup में willSleep नई actions रोकने का शुरुआती अवसर देता है। अगर कोई configuration lid बंद होने के बाद system को जागा रखती है, तो conservative fallback के रूप में user-session या display boundary इस्तेमाल करें। lidClosed नाम के किसी perfect semantic label की प्रतीक्षा न करें। आपको unattended credential use रोकना है।

यह trial किसी harmless credentialed capability वाले agent के साथ चलाएं, जैसे test API में marker लिखना या disposable SSH host पर harmless command चलाना:

1. नई agent process शुरू करें और उसके session को approve करें।
2. Confirm करें कि एक protected call सफल होती है, फिर agent को दूसरी call के लिए तैयार छोड़ दें।
3. Expected power behavior trigger होने तक lid बंद रखें, फिर उसे खोलें।
4. दोबारा unlock या approve किए बिना agent को protected call retry करने दें।
5. Confirm करें कि gateway retry को deny करता है और denial से पहले authority transition दर्ज करता है।

इसी trial को docked स्थिति, battery और external display के साथ दोहराएं, अगर लोग इन modes का उपयोग करते हैं। Test endpoint harmless रखें। उद्देश्य authority behavior देखना है, यह पता लगाना नहीं कि production deployment बीच में रुक सकता है या नहीं।

यहां failure अक्सर बहुत साफ दिखाई देता है: action log में sleep के दौरान कोई call नहीं है, फिर wake के बाद पहली call सफल हो जाती है। अगर user को lock screen दिखी थी और उसने resumed run को approve नहीं किया, तो यह फिर भी failure है। Test का पूरा उद्देश्य इसी समय के अंतर को जांचना है।

Display sleep अपने आप में कमजोर revocation trigger है

केवल display sleep पर revoke करना सुरक्षित है, लेकिन desktop Mac पर यह बहुत बाधक हो सकता है, जहां सामान्य काम के दौरान display सो जाता है। केवल display sleep के दौरान authority बनाए रखना सुविधाजनक है, लेकिन जब display timeout unattended user का संकेत भी हो, तो इसे गलत समझना आसान है।

एक नियम चुनें और tradeoff स्पष्ट रखें। High-impact credentials के लिए केवल display sleep पर नहीं, बल्कि screen lock और system sleep पर revoke करें। अगर आपके machine setup में display sleep lock से ठीक पहले भरोसेमंद ढंग से होता है, तो अतिरिक्त सुरक्षा के रूप में display sleep पर भी revoke कर सकते हैं और अधिक approval prompts स्वीकार कर सकते हैं। किसी भी विकल्प को obvious न कहें। चुनाव deployment और credential की क्षमता पर निर्भर है।

Apple की अलग screen और system notifications यह मानने के विरुद्ध चेतावनी हैं कि दोनों का अर्थ एक ही है। दोनों को monitor करें, दोनों दर्ज करें और हर एक से जुड़ी policy की जांच करें।

एक व्यावहारिक matrix इस विषय को लोककथा बनने से रोकती है:

User Mac को unlock करके desktop वापस पाता है। इस action से agent की पिछली authority चुपचाप वापस नहीं आनी चाहिए। Computer unlock करना और external action approve करना जुड़े हुए हैं, लेकिन दोनों अलग सवालों का उत्तर देते हैं।

Overnight runs के लिए अलग contract चाहिए

Overnight agent run को दोपहर के interactive session की permissions विरासत में नहीं मिलनी चाहिए। लोग interactive work को diff, terminal या request card देखते हुए approve करते हैं। Overnight work का अर्थ है ऐसी चीज को तत्काल निगरानी के बिना चलने देना, जिसके लिए स्पष्ट निर्णय लिया गया है।

Job का contract इतना सीमित रखें कि उसे एक वाक्य में समझाया जा सके। Run tests and prepare a pull request समझने योग्य है। Finish the task के लिए जो भी जरूरी हो करो कोई contract नहीं, blank check है।

Unattended work में local और external actions अलग करें। जब local actions सीमित हों, तो उन्हें अनुमति दें: repository analysis, branch पर edits, test execution और artifact generation। Sensitive external effects के लिए fresh human approval लें, जैसे production API mutation, deployment, package publish, shared database में write या महत्वपूर्ण machine तक SSH access।

कुछ overnight runs को external service call करनी ही पड़ सकती है। इसके लिए dedicated credential या ऐसा test environment इस्तेमाल करें जिसका blast radius job के अनुरूप हो। Administrator credential केवल इसलिए reuse न करें कि वह vault में पहले से मौजूद है। यह कहना कि user ने उसी शाम agent को approve किया था, पर्याप्त नहीं है। वह approval दिखाई दे रहे interactive run के लिए थी, उनके सो जाने के बाद बचे काम के लिए नहीं।

अगर job का कोई वास्तविक recurring external task है, तो bounded action budget रखें। उसे vague confidence score के बजाय destination, method और effect से सीमित करें। उदाहरण के लिए unattended test job को एक staging endpoint पर fixed request भेजने दें, लेकिन host बदलने, HTTP method बदलने या SSH का उपयोग करने न दें। अधिक आवश्यकता होने पर job रुक जाए।

Sallyport की per-session authorization हर नई agent process के लिए अपना approval boundary देती है। Overnight work को नई शुरू की गई process में रखें और उसकी protected actions को किसी भी अन्य unattended run की तरह जांच से गुजरने दें।

Logs में activity ही नहीं, denial भी साबित होना चाहिए

Mac woke कहने वाला record यह प्रमाण नहीं है कि authority समाप्त हुई। Boundary के दोनों ओर का evidence चाहिए: policy transition शुरू करने वाला operating-system event और उसके बाद gateway द्वारा अस्वीकार की गई अगली protected action।

Power side की जांच के लिए macOS एक उपयोगी शुरुआत देता है:

pmset -g log | grep -E 'Sleep|Wake|DarkWake|Display'

Hardware और macOS release के अनुसार exact lines बदलेंगी, लेकिन output में Sleep, Wake, DarkWake या display transitions जैसे event names के साथ timestamped records होने चाहिए। हर trial की matching window सुरक्षित रखें। इसे authorization का source of truth न बनाएं, क्योंकि यह आपके vault या agent identity को नहीं जानता।

आपका अपना journal अलग सवालों का उत्तर दे:

14:20:16.402 session_approved process=84172 epoch=27 authority=approved-agent-binary
14:22:04.118 power_will_sleep epoch=27
14:22:04.119 authority_revoked old_epoch=27 new_epoch=28 reason=system_sleep
14:25:38.771 power_did_wake epoch=28
14:25:44.025 action_denied process=84172 request=ssh.exec reason=authority_epoch_changed

क्रम महत्वपूर्ण है। अगर action revocation entry से पहले दिखाई देती है, तो race मिला है। अगर test agent चुपचाप बंद हो गया और कोई denied action नहीं दिखी, तो persistent process के बारे में कुछ साबित नहीं हुआ। Trial इस तरह रखें कि वही लंबे समय तक चलने वाली process हर transition के बाद protected call आजमाए।

Tamper-evident audit trail का दूसरा लाभ भी है: बाद में जांच सकते हैं कि event और action sequence को सुंदर कहानी बनाने के लिए बदला नहीं गया। Sallyport अपने Sessions और Activity journals को write-blind encrypted, hash-chained audit log से बनाता है और sp audit verify ciphertext पर offline उस chain की जांच करता है। इस test में यह उपयोगी है, क्योंकि successful verification बताता है कि recorded sequence चुपचाप बदली नहीं गई। यह कमजोर revocation policy को सही नहीं बनाता।

Race conditions boundary पर होती हैं

खतरनाक bug आम तौर पर उस request में होता है जो Mac के sleep में जाने या user के screen lock करने के समय पहले से in flight हो। अगर gateway connection स्वीकार करते समय ही approval check करता है, तो queued work authority transition के बाद execute हो सकता है। अगर gateway credential inject करने के बाद check करता है, तो revoke का पता चलने से पहले credential helper तक पहुंच सकता है।

Privileged operation से ठीक पहले authority check करें। इसका अर्थ है credential injection से पहले, usable key वाले SSH helper को खोलने से पहले और HTTP request भेजने से पहले। अगर operation में कई privileged phases हैं, तो हर ऐसी phase पर दोबारा check करें जहां system authority boundary पार कर सकता है।

सरल रूप कुछ ऐसा है:

receive request
identify process and session nonce
read current authority epoch
compare request grant epoch to current epoch
check vault gate
check per-call approval when required
inject credential and execute action
append result to audit log

Epoch read और privileged execution की commitment को implementation में जितना संभव हो, उतना पास रखें। Mac से bytes बाहर चले जाने के बाद distributed HTTP action को पूरी तरह वापस नहीं लिया जा सकता। लेकिन आप पुराने grant को उसे शुरू करने से रोक सकते हैं।

हर edge case को sleep delay करके हल करने की कोशिश न करें। Apple का willSleep notification थोड़ी देर की handling अनुमति देता है, लेकिन agent actions पूरी करने के लिए laptop को sleep से रोकना प्राथमिकता उलट देता है। मशीन interactive state से बाहर जा रही है। Access revoke करें, interruption दर्ज करें और user को तय करने दें कि क्या resume होगा।

महंगे या irreversible effects वाली keys के लिए per-call approval साफ समाधान है। हर उपयोग के समय user से पूछे जाने के कारण sleep और wake कम महत्वपूर्ण हो जाते हैं। फिर भी यह session revocation छोड़ने का कारण नहीं है। यह credentials के छोटे समूह के लिए दूसरी सुरक्षा सीमा है।

उन transitions की जांच करें जो लोग वास्तव में करते हैं

अच्छा test plan notification handler के unit tests से शुरू नहीं होता। वे उपयोगी हैं, लेकिन failures वास्तविक power transitions, वास्तविक lock screens और ऐसी agent processes में होते हैं जो terminal window से अधिक समय तक चलती हैं।

एक test agent बनाएं जो wait कर सके, signal ले सके और फिर harmless protected action मांग सके। हर trial को नया run identifier दें। चलाने से पहले expected result लिखें, क्योंकि बाद में चौंकाने वाले परिणाम को probably fine कह देना आसान होता है।

हर supported Mac configuration पर कम से कम ये cases test करें:

• Agent idle होने पर screen lock करें, फिर unlock से पहले और बाद में approved action retry करें।
• Apple menu से system को sleep में डालें, उसे lock screen पर जगाएं और original process के साथ retry करें।
• System को awake रखते हुए display sleep होने दें और देखें कि व्यवहार आपकी चुनी display policy से मेल खाता है या नहीं।
• Notebook lid बंद और फिर खोलें, battery पर भी और लोगों के desk setup में भी।
• जानबूझकर लंबे agent run को रातभर छोड़ें, फिर power log, action journal और लौटने के बाद पहली protected call जांचें।

हर run के लिए छोटी result sheet रखें: expected epoch, observed power events, original process बची या नहीं, vault locked था या नहीं और पहली protected call deny हुई या नहीं। इससे एक आम गलती पकड़ी जाती है: टीमें जांचती हैं कि app ने event देखा या नहीं, लेकिन यह नहीं जांचतीं कि action layer ने उसके बाद call reject की या नहीं।

भद्दे timing cases भी जांचें। Protected action शुरू करें, network response की प्रतीक्षा के दौरान screen lock करें और देखें कि retry या follow-up action पुराने grant के तहत चलती है या नहीं। Sleep से ठीक पहले action शुरू करें। Dock disconnect और reconnect करें। Wake के बाद agent process restart करें और सुनिश्चित करें कि वह पुरानी process का approval record उधार न ले सके।

इन tests को पास कराने के लिए विशाल policy engine जरूरी नहीं है। एक strict vault gate, per-process approval record, revocable epoch और ऐसा action path चाहिए जो credential इस्तेमाल करने से ठीक पहले इन सभी की जांच करे।

पहले outcomes में policy लिखें, फिर उसे लागू करें

अच्छी authority policy एक पेज में आ जाती है, क्योंकि वह अनुमानित operating-system labels की सूची नहीं, observable outcomes बताती है। Lock, sleep, wake, lid close, logout और manual revoke के बाद protected actions के साथ क्या होगा, यह लिखें। यह भी लिखें कि local work जारी रह सकता है या नहीं और resume करने के लिए user को क्या करना होगा।

अधिकांश interactive AI coding agents के लिए policy कुछ ऐसी होनी चाहिए:

Protected action के लिए unlocked vault और current authority epoch में current process की approval जरूरी है। Lock, sleep, user-session loss, vault lock और manual revoke उस approval को समाप्त करते हैं। Wake और unlock उसे वापस नहीं लाते। अगली protected action से पहले agent को नई approval मांगनी होगी।

इस नियम की एक कीमत है: Mac पर लौटने के बाद लोग फिर से approval देंगे। यह कीमत स्वीकार करें। दूसरा विकल्प user से यह याद रखने को कहता है कि lid बंद करने से पहले कौन-कौन सी agent processes चल रही थीं और घंटों बाद machine जागने पर उन पर समझदारी से व्यवहार करने का भरोसा करने को कहता है।

Agent setup को unattended work के लिए सुरक्षित कहने से पहले tests चलाएं। Lock या wake के बाद user के नए निर्णय के बिना कोई request सफल हो जाती है, तो आपको ऐसा authority मिल गया है जो दिए गए क्षण से अधिक समय तक जीवित रही।