# रीबूट के बाद एजेंट authorization: समाप्त होने वाली अनुमतियां

Mac को रीबूट करने से टीमों को एक साफ तकनीकी सीमा मिलती है। इसका इस्तेमाल करें। एजेंट प्रोसेस बंद हो जाता है, उसकी मेमोरी गायब हो जाती है और उस खास रन से जुड़ी हर अनुमति भी वहीं खत्म होनी चाहिए। रीस्टार्ट के बाद autonomous work को बिना दिखे जारी रखने की कोशिश अक्सर सीमित और जांच योग्य अनुमति को स्थायी access में बदल देती है, जिसकी समाप्ति स्पष्ट नहीं होती।

इसका मतलब यह नहीं कि रीबूट सब कुछ मिटा दे। टीमों को पिछली कार्रवाइयों का प्रमाण, भविष्य के काम के लिए सुरक्षित एन्क्रिप्टेड क्रेडेंशियल और काम को सोच-समझकर फिर शुरू करने के लिए पर्याप्त संदर्भ चाहिए। नियम सरल है: रिकॉर्ड और सुरक्षित सामग्री बचाएं, सक्रिय अधिकार हटाएं। फिर नए शुरू हुए प्रोसेस को बाहरी दुनिया से बात करने से पहले किसी व्यक्ति की अनुमति लेनी होगी।

## रीबूट के बाद एजेंट authorization रनटाइम की खाली स्थिति से शुरू होना चाहिए

रीबूट के बाद एजेंट authorization की शुरुआत किसी सक्रिय प्रोसेस ग्रांट, अनलॉक वॉल्ट, विरासत में मिले सत्र सीक्रेट या ऐसी याद रखी अनुमति के बिना होनी चाहिए जिसे नया प्रोसेस इस्तेमाल कर सके। रीस्टार्ट उस ऑब्जेक्ट को समाप्त कर देता है जिसे अनुमति मिली थी। केवल इसलिए बदले हुए प्रोसेस को वही मानना कि वह उसी checkout, command या agent name का इस्तेमाल करता है, पहचान की गलती है।

लोग अक्सर कहते हैं कि इससे operating system update या बिजली जाने के बाद परेशानी बढ़ेगी। एक जानबूझकर रखा गया छोटा विराम जरूर आएगा। यही विराम किसी व्यक्ति को उस प्रोसेस को देखने का मौका देता है जो अब अधिकार मांग रहा है, न कि उस प्रोसेस को जिसे उसने घंटों पहले अलग परिस्थितियों में मंजूर किया था।

एक साफ restart boundary के चार फायदे हैं:

- यह memory में मौजूद access token, decrypted key handle, queued confirmation और process identifier जैसी अस्थायी सामग्री साफ कर देती है।
- यह एजेंट को ऐसे unattended समय में अनुमति साथ ले जाने से रोकती है, जब ऑपरेटर शायद मौजूद न हो।
- यह टीम को भरोसेमंद audit marker देती है, जिससे पता लगाया जा सकता है कि कार्रवाई रीबूट से पहले हुई या बाद में।
- यह local cache, background helper और connection multiplexer पर छिपी निर्भरता सामने लाती है।

रीबूट को user logout न समझें। Logout से भी एजेंट का अधिकार खत्म होना चाहिए, लेकिन रीबूट की जांच आसान है क्योंकि यह लगभग हर सामान्य प्रोसेस को बंद कर देता है। अगर कोई grant इसके बाद भी बचा रहता है, तो किसी ने उसे जानबूझकर सुरक्षित रखा है या ऐसा helper बनाया है जो एजेंट के lifecycle से बाहर चलता है। दोनों स्थितियों की जांच जरूरी है।

यह नियम तब भी लागू होता है जब agent binary code signed हो और बदली न हो। Code signing से ऑपरेटर प्रोग्राम के publisher की पहचान कर सकता है। इससे यह साबित नहीं होता कि चल रहे प्रोसेस में वही instructions, environment variables, repository state, tool configuration या operator intent है जो पिछले रन में था। Signed process को रीबूट के बाद भी खतरनाक prompt मिल सकता है।

यही नियम planned task पर भी लागू होता है। मान लें कि एजेंट ने database migration तैयार की, अनुमति मांगी और execution से पहले Mac रीस्टार्ट हो गया। योजना work directory में सुरक्षित रह सकती है। उसे चलाने का अधिकार सुरक्षित नहीं रहना चाहिए। रीबूट के बाद एजेंट को intended operation फिर दिखाना चाहिए और ऑपरेटर को तय करना चाहिए कि काम अब भी सही है या नहीं।

यहीं कई designs लापरवाह हो जाते हैं। वे durable record में «approved» लिखकर उसे session कह देते हैं। यह record transferable permission बन जाता है, क्योंकि बाद का प्रोसेस इसका दावा कर सकता है। Session grant का किसी process instance से सक्रिय संबंध और छोटा, स्पष्ट lifetime होना चाहिए। प्रोसेस खत्म होते ही authorization record में दिखना चाहिए कि वह समाप्त हो चुका है, न कि यह कि उसे फिर इस्तेमाल किया जा सकता है।

## प्रमाण और configuration रखें, सक्रिय grants हटाएं

टीम को काम समझाने वाले तथ्य और सुरक्षित रूप से दोबारा इस्तेमाल की जा सकने वाली configuration रखनी चाहिए, जबकि तुरंत अधिकार देने वाली हर वस्तु को हटाना या invalid करना चाहिए। इन श्रेणियों को अलग storage और lifecycle buckets में रखें। उन्हें मिलाने से वह आम समस्या पैदा होती है जिसमें audit record गलती से authorization token बन जाता है।

व्यवहार में यह विभाजन अच्छा काम करता है:

| रीबूट के बाद सुरक्षित रखें | रीबूट पर समाप्त करें |
|---|---|
| Append-only action history और approval decisions | Agent process grant और उसका run identifier |
| Encrypted API और SSH credential material | Unlocked-vault state और decrypted credential handles |
| Endpoint definitions, allowed credential selection और task references | In-memory bearer tokens और HTTP connection state |
| पुराने runs के लिए दर्ज process signing authority | SSH control sockets और running helper processes |
| लंबित task description और उसकी पिछली स्थिति | Approval dialogs, queued actions और retry permission |

पहला कॉलम continuity देता है। दूसरा continuity को चुपचाप privilege retention बनने से रोकता है।

रुके हुए काम की स्थिति रखें, लेकिन उसे वर्णनात्मक बनाएं। अच्छा record कहता है कि run `R-1842` ने SSH command के लिए अनुमति मांगी, अनुमति मिली और host restart होने के कारण execution से पहले रुक गया। खराब record कहता है कि run `R-1842` अगली launch के बाद बाकी actions चला सकता है। पहला ऑपरेटर को फैसला लेने देता है। दूसरा बाद के प्रोसेस की जानकारी के बिना पहले ही फैसला कर देता है।

Credential storage के लिए भी ऐसी ही स्पष्ट भाषा जरूरी है। Vault में encrypted API key रीबूट के बाद रखी जा सकती है। उसका decrypted रूप केवल इसलिए उपलब्ध नहीं रहना चाहिए कि मशीन जल्दी रीस्टार्ट हो गई। Vault lock एक स्पष्ट बिंदु बनाता है, जहां Mac पर मौजूद व्यक्ति अपनी उपस्थिति फिर साबित करता है। यह इस निर्णय से अलग है कि एजेंट प्रोसेस को किसी खास credential का इस्तेमाल करने दिया जाए या नहीं।

Sallyport इसी अलगाव का पालन करता है: vault gate लॉक होने पर हर action रोक देता है, और per-session authorization किसी याद रखे task label के बजाय नए connected agent process पर लागू होती है। ये दो अलग फैसले हैं। इन्हें मिला देने पर incident review काफी कठिन हो जाता है।

सुविधा वाली features में approval छिपाकर उसे सुरक्षित रखने की कोशिश न करें। कुछ उदाहरण शुरुआत में harmless लगते हैं, लेकिन साथ मिलकर जोखिम पैदा कर सकते हैं:

- Launch agent MCP client को फिर शुरू करता है और पुरानी session file उसे दे देता है।
- SSH client `/tmp` या user cache directory में control socket बचाए रखता है।
- Retry को रीबूट के बाद चलाने के लिए कोई script bearer token को environment file में कॉपी कर देती है।
- Task runner unfinished job देखकर target बदलने की जांच किए बिना उसे चला देता है।

हर feature progress बचाने का दावा करती है। हर feature बिना ऑपरेटर को दिखाए authority भी बचा सकती है।

इसके बजाय interruption record इस्तेमाल करें। उसमें task reference, पुराना run identifier, intended action list का digest, target names और `stopped_by_reboot` जैसी status रखें। Usable credential, cookie, approval token या ऐसा instruction शामिल न करें जिसे launcher चला सके। अगले रन में इस record को किसी व्यक्ति के लिए context की तरह दिखाएं। Context review में मदद करता है, authority ताजा निर्णय से आनी चाहिए।

## रीबूट credential rotation event नहीं है

रीबूट को एजेंट permissions समाप्त करनी चाहिए, लेकिन API keys या SSH keys को अपने आप rotate नहीं करना चाहिए। ये नियंत्रण अलग तरह की विफलताओं से निपटते हैं। Authorization expiry यह सीमित करती है कि मौजूदा credential का इस्तेमाल कौन और कितनी देर कर सकता है। Rotation credential को बदलती है, क्योंकि exposure, loss, misuse या बदली हुई access need का संदेह होता है।

हर restart को exposure event मानने पर टीम का समय जाता है और integrations टूटती हैं। दूसरी ओर, routine rotation leaked credential को छिपाकर सुरक्षा का झूठा भरोसा दे सकती है, अगर यह पता ही न चले कि वह बाहर कहां निकली। Key बदलने से वह design ठीक नहीं होता जिसने key एजेंट को दी, transcript में रखी या shell history में लिख दी।

NIST Special Publication 800-63B session management को authenticator lifecycle से अलग रखता है। उसके guidance में session termination और reauthentication को स्पष्ट controls माना गया है, जबकि authenticator replacement अलग समस्या का समाधान है। यह अंतर agent systems पर अच्छी तरह लागू होता है। रीबूट पर active agent run खत्म करें। Underlying credentials को केवल evidence या policy की मांग पर rotate करें।

रीबूट के बाद rotation तब करें जब restart खुद किसी विश्वसनीय exposure event के बाद हुआ हो। उदाहरणों में secret का prompt log तक पहुंचना, agent environment तक पहुंच रखने वाला अज्ञात process मिलना, laptop खो जाना या किसी पूर्व team member के पास copied credential रह जाना शामिल हैं। इन मामलों में रीबूट incidental है। Rotation का कारण suspected escape है।

Long-lived bearer credentials पर खास ध्यान दें, क्योंकि network की अनुमति वाले किसी भी स्थान से वे काम कर सकते हैं। अगर एजेंट को कभी उनका plaintext value मिल जाता है, तो gateway की वह साफ सीमा पहले ही टूट चुकी है जो रीबूट expiry को अर्थ देती है। मशीन रीस्टार्ट होने से पहले एजेंट उस value को store या transmit कर सकता है। बाद की session approval उसे वापस नहीं बुला सकती।

SSH में भी कुछ traps हैं। Private key local vault में सुरक्षित रह सकती है, फिर भी मौजूदा SSH connection remote channels को connection खत्म होने तक चलाती रह सकती है। SSH connection multiplexing local control socket भी छोड़ सकती है, जिसका इस्तेमाल बाद का client करता है। सामान्य स्थिति में रीबूट दोनों को साफ कर देना चाहिए, लेकिन अनुमान न लगाएं। टीम जिन actual client options और helpers का इस्तेमाल करती है, उन्हें जांचें।

व्यावहारिक policy ऐसी होनी चाहिए: encrypted source credentials रखें, रीबूट पर उन्हें lock करें, सभी grants और active transports खत्म करें, फिर gateway को दोबारा credential इस्तेमाल करने से पहले नए process की authorization लेने दें। Rotation triggers exposure और personnel changes पर आधारित हों, किसी मनमाने boot event पर नहीं।

यह policy incident response को भी ईमानदार रखती है। अगर ऑपरेटर कहता है, «हमने रीबूट किया, इसलिए access reset हो गया», तो पूछें कि credential कभी protected store से बाहर निकला था या नहीं और remote provider independent sessions रखता है या नहीं। रीबूट local runtime state reset करता है। Cloud provider पर token तब तक invalid नहीं होता, जब तक provider को revocation या rotation event न मिले।

## Device unlock, human presence और process approval अलग तथ्य हैं

सुरक्षित resume के लिए तीन सवालों के अलग जवाब चाहिए: क्या Mac protected credentials तक पहुंच सकता है, क्या जवाबदेह व्यक्ति मौजूद है और कौन सा process उनका इस्तेमाल करना चाहता है? एक ही signal से तीनों सवालों का जवाब देने वाला design उस signal को जरूरत से ज्यादा अर्थ देता है।

Device unlock local user environment तक पहुंच नियंत्रित करता है। इससे पता चल सकता है कि किसी ने Mac की login protection पार की है। Supported hardware पर vault Secure Enclave और Touch ID का इस्तेमाल करके secrets को locked स्थिति में unavailable रख सकता है। यह at-rest material की सुरक्षा करता है और स्पष्ट action boundary बनाता है, लेकिन इससे अगले agent framework process की कोई खास पहचान नहीं होती।

Human presence समय का एक क्षण है। Biometric confirmation या click किसी खास decision के लिए उसे स्थापित कर सकता है। अगली reboot तक future external actions को चुपचाप मंजूर करने देना उस क्षण का दायरा ऑपरेटर के इरादे से कहीं बड़ा कर देता है। जोखिम तब बढ़ता है जब coding agent घंटों चलता रहे, बदलती repository files पढ़े या pull requests और issue comments से instructions ले।

Process approval एक संकरा सवाल पूछता है: क्या मैं इस नए चल रहे program को इस run के दौरान gateway calls करने की अनुमति देता हूं? Approval screen को code-signing authority जैसे durable evidence से process की पहचान करनी चाहिए और operator को mutable process title समझने पर निर्भर नहीं करना चाहिए। `agent` जैसा label identity नहीं है। कोई भी यह label चुन सकता है।

क्रम महत्वपूर्ण है। पहले vault उपलब्ध होना चाहिए। फिर gateway process की पहचान कर सकता है। उसके बाद operator उस process को requested run के लिए मंजूर कर सकता है। असामान्य रूप से संवेदनशील credentials के लिए हर उपयोग पर फिर confirmation लें। इससे टीम के पास अलग काम करने वाले तीन controls रहते हैं, एक बड़ा «allow agent» button नहीं।

Mac account name को process identity का विकल्प न बनाएं। Shared local account कई terminal sessions, build tools, editors और agent hosts चला सकता है। अगर एक approval पूरे account पर लागू हो जाती है, तो malicious shell command या दूसरा agent वह authority इस्तेमाल कर सकता है जो किसी और process के लिए दी गई थी।

Approval decision को ऐसे scope सवालों का जवाब देने का दिखावा भी नहीं करना चाहिए जिनका वह जवाब नहीं देती। Process-level grant बताता है कि किसी खास run के दौरान gateway को कौन call कर सकता है। इसका अर्थ चुपचाप हर credential या हर action के लिए हमेशा की permission नहीं होना चाहिए। इसे credential selection और जरूरत पड़ने पर per-call confirmation के साथ जोड़ें। इससे high-impact credential को कम जोखिम वाली API call की सुविधा विरासत में नहीं मिलती।

इस समस्या को elaborate policy language से हल करने का मन होता है: time, source path, branch name, hostname, command patterns और prompts पर conditions लगाना। Dedicated security teams के लिए ऐसी systems काम कर सकती हैं, लेकिन सामान्य developers outcome का अनुमान न लगा पाएं तो नया खतरा पैदा होता है। Visible decisions का छोटा सेट रीबूट के बाद लागू करना और review में समझाना आसान है।

## Broad team permission के बजाय named run resume करें

टीमें interrupted work को सुरक्षित रूप से तब resume कर सकती हैं, जब work item durable और authorization ephemeral हो। Restarted agent को जारी रखने के लिए पर्याप्त context मिलना चाहिए, लेकिन नए process के रूप में उसे नया authority लेना चाहिए। Project-wide remembered approval गलत shortcut है, क्योंकि इससे असंबंधित काम पुराना operator decision inherit कर सकता है।

हर बड़े run को ऐसी durable reference दें जिसे लोग पहले से समझते हों। Development tasks के लिए repository path और branch पर्याप्त हो सकते हैं। Operational tasks के लिए ticket number, change request, environment name या incident identifier बेहतर हो सकता है। Reference permission नहीं देती। वह इंसान को restarted run की तुलना अपेक्षित काम से करने देती है।

एक उपयोगी resume card या terminal prompt में पांच बातें होनी चाहिए:

1. पिछला run identifier और उसके खत्म होने का कारण, जैसे `stopped_by_reboot`।
2. Work reference और वह repository revision या deployment artifact जिसे पुराने run ने इस्तेमाल किया था।
3. नए process की अगली external action, जिसमें destination और credential label शामिल हों।
4. मौजूदा process की identity evidence, केवल पुराने process की नहीं।
5. इस run को approve करने, reject करने या पिछला action record देखने का विकल्प।

पूरी action queue को review के बिना restore न करें। Mac बंद रहने के दौरान बाहरी दुनिया बदल सकती है। Pull request force-push हो सकती है, DNS record कहीं और point कर सकता है, deployment किसी दूसरे रास्ते से पूरी हो सकती है या maintenance window खत्म हो सकती है। एजेंट ने पहले कोई योजना बनाई थी, इससे बाद के side effects उचित नहीं हो जाते।

मान लें कोई agent HTTP API के जरिए servers के समूह को update कर रहा था। रीबूट से पहले उसने hosts A से D तक सफलतापूर्वक बदले और E से H के लिए calls तैयार कीं। Mac रीस्टार्ट हो जाता है। Launch पर agent अपनी पुरानी queue पाता है और जारी रखने की कोशिश करता है। लापरवाह implementation token फिर इस्तेमाल करके E से H को भेज देती है। सुरक्षित implementation interruption record पढ़ती है, नया run बनाती है, authorization मांगती है, current state fetch करती है और बाकी intended calls दिखाती है। उसे पता चल सकता है कि किसी दूसरे operator ने F और G पहले ही बदल दिए हैं। Fresh authorization ने व्यक्ति को यह पकड़ने का मौका दिया।

Retry behavior की स्पष्ट सीमा होनी चाहिए। अगर vault locked होने या process के पास approval न होने के कारण gateway call रोकता है, तो client को रुककर blocked action बतानी चाहिए। उसे loop में नहीं घूमना चाहिए, repeated prompts नहीं खोलने चाहिए, direct network access पर fallback नहीं करना चाहिए और environment variable से credential नहीं लेना चाहिए। Transient network failure के बाद retry तभी उचित है, जब call के पास अब भी valid authorization हो।

इस approach के लिए एजेंट को अपना काम भूलना जरूरी नहीं। Plan, command output, repository diff और interruption समझाने वाला सामान्य भाषा का note सुरक्षित रखें। इन artifacts को नए decision के लिए evidence मानें। Design meeting में यह अंतर छोटा लगता है और incident के समय बड़ा बन जाता है: saved plan intent समझाती है, जबकि inherited grant बिना नए जवाबदेह निर्णय के action करती है।

Sensitive operations के लिए restarted agent से अगली action प्रस्तावित करने से पहले current state दोबारा पढ़ने को कहें। यह destructive API calls और ऐसे SSH commands के लिए खास उपयोगी है जिनका असर मौजूदा host state पर निर्भर करता है। यह अतिरिक्त read permission नहीं है। यह जांच है कि पुरानी योजना अब भी दुनिया का सही वर्णन करती है या नहीं।

## HTTP और SSH के लिए स्पष्ट restart rules जरूरी हैं

HTTP APIs और SSH दोनों को रीबूट के बाद नए agent authorization की जरूरत होती है, लेकिन उनका hidden state इतना अलग है कि केवल vague «session reset» कहने से failures छूट जाएंगे। हर channel के लिए reset behavior लिखें और उन paths की जांच करें जिनका एजेंट वास्तव में इस्तेमाल करते हैं।

HTTP में credential को remote service द्वारा बनाए गए access token या cookie से अलग रखें। Gateway credential को local रूप से encrypted रख सकता है और approval के बाद ही request में inject कर सकता है। एजेंट को response मिलना चाहिए, bearer credential नहीं। रीबूट के बाद local cached access token, retry के लिए रखे request headers, automation में इस्तेमाल होने वाले browser-style cookie jars और open connection state को हटाएं।

अगर client बाद में valid refresh token या cookie पेश करे, तो provider रीबूट के बाद remote session बचाए रख सकता है। इसलिए एजेंट के पास ये artifacts नहीं होने चाहिए। इनके होने पर वह provider को सीधे call करके local restart rules bypass कर सकता है। Credential injection और token refresh को boundary के action side पर रखें, जहां नया authorized process उन्हें invoke करे।

SSH के लिए client connections समाप्त करें और multiplexing की जांच करें। OpenSSH `ControlMaster` और `ControlPath` के जरिए master connection reuse कर सकता है। यह interactive users के लिए उपयोगी है, लेकिन इससे यह अस्पष्ट हो सकता है कि remote session का मालिक कौन सा invocation है। Agent gateway को stateless execution path या ऐसा lifecycle इस्तेमाल करना चाहिए जो agent run खत्म होते ही हर helper को साफ तरीके से बंद कर दे। Local UI बंद होने से remote command रुक गई, ऐसा कभी न मानें।

दोनों channels के लिए यह reproducible reboot drill इस्तेमाल करें:

1. Agent run शुरू करें और non-production target पर harmless HTTP request या SSH command को मंजूर करें।
2. Run identifier, process identity, intended request और आखिरी पूरी हुई action का समय दर्ज करें।
3. Agent की पहले से तय दूसरी action से पहले Mac रीस्टार्ट करें।
4. Task files बदले बिना agent host फिर शुरू करें और उससे दूसरी action करने को कहें।
5. पुष्टि करें कि vault उपलब्ध होने और नए process को approval मिलने तक पहला प्रयास अस्वीकृत रहता है। फिर record देखकर सुनिश्चित करें कि दूसरी action अलग run identifier से जुड़ी है।

ऐसे gateway के लिए जिसमें command-line audit verifier हो, drill से पहले और बाद में verifier चलाएं:

```
sp audit verify
```

Command को यह बताना चाहिए कि encrypted audit chain verify होती है या नहीं, और इसके लिए vault unlock करना जरूरी नहीं होना चाहिए। Human-facing command के बनाए हुए success text को parse करने वाली automation न लिखें। Documented exit status जांचें और command output को drill record के साथ रखें। Sallyport write-blind, hash-chained encrypted audit log से session और individual-call journals दोनों project करता है, इसलिए verifier रीबूट के बाद operators को offline integrity check देता है।

Drill में bad path की भी जांच करें। पुराने environment variable, cached HTTP client profile, SSH control socket और दूसरे local agent process को आजमाएं। अगर इनमें से कोई नई authorization के बिना destination तक पहुंचता है, तो reboot boundary केवल दिखावटी है। Operators को एक और reminder देने के बजाय bypass ठीक करें।

## Audit records में पुराने और नए दोनों runs स्पष्ट होने चाहिए

रीबूट के बाद audit trail को investigator को यह बताना चाहिए कि एक run कहां रुका और दूसरा कहां शुरू हुआ। भले ही वही user, repository और agent framework उसी task को जारी रखें, फिर भी यह separation स्पष्ट दिखना चाहिए। अगर record इन घटनाओं को एक लंबे session में मिला देता है, तो वह यह नहीं बता सकता कि post-reboot action को किसने authorize किया।

पुराने run की अंतिम स्थिति स्पष्ट रूप से रखें। उपयोगी values में normal exit, vault lock के कारण denied, approval pending के कारण denied, host shutdown, network failure और operator revocation शामिल हैं। नए process के शुरू होते समय इस state को overwrite न करें। Restart record को पिछले run की ओर point करना चाहिए, उसमें मिलना नहीं चाहिए।

नए run के लिए authorization के समय प्रस्तुत process identity evidence, approval time और पहली external call दर्ज करें। पहली call महत्वपूर्ण है, क्योंकि approval का मतलब हमेशा use नहीं होता। Operator किसी run को मंजूर कर सकता है और वह action किए बिना बंद हो सकता है। Approval और execution को अलग रखने से review में यह गलत दावा नहीं होगा कि action हुआ था, जबकि operator ने केवल संभावना को मंजूरी दी थी।

Individual call records में secret सुरक्षित रखे बिना action दोबारा समझने के लिए पर्याप्त context होना चाहिए। HTTP के लिए destination, method, credential label, result class और request metadata का redacted रूप रखें। SSH के लिए destination, account label, command या उसका approved digest, exit status और result metadata दर्ज करें। Command output का retention उसके sensitivity पर निर्भर हो सकता है, लेकिन action होने का तथ्य न हटाएं।

Hash chaining बाद की छेड़छाड़ का पता लगाना आसान बनाती है, लेकिन यह tampering को असंभव नहीं मानती। इसका लाभ यह है कि हर record पिछले records के प्रति commitment रखता है और offline verification टूटा sequence दिखा सकती है। इससे यह साबित नहीं होता कि approved action समझदारी भरी थी और न ही यह उस व्यक्ति को रोकता है जिसके पास action जारी करने का अधिकार है। टीम को अब भी review और अनुशासित approval boundaries चाहिए।

Audit verifier को सामान्य agent path से बाहर रखें। जो agent अपना evidence rewrite या bless कर सकता है, वह circular trust claim बनाता है। Operators को vault locked रहने पर भी independently verification चलाने में सक्षम होना चाहिए। Audit data की copy में record बदलने पर क्या होता है, यह भी पहले जांचें, ताकि जरूरत पड़ने से पहले expected failure behavior पता हो।

Instant revocation के लिए भी scope का record जरूरी है। अगर operator रीबूट के बाद session revoke करता है, तो journal में दिखना चाहिए कि किस run ने authority खोई और उसके बाद कौन सी calls denied हुईं। «Agent access disabled» जैसी global statement से बचें, जब तक वास्तव में यही न हुआ हो। Precise records से टीम को यह अनुमान नहीं लगाना पड़ता कि किसी दूसरे process के पास approval अब भी था या नहीं।

## Automation से पहले expiration rules तय करें

एक सुरक्षित reboot policy इतनी छोटी होनी चाहिए कि हर developer उसे सही तरह बता सके: restart protected material को lock करता है, हर agent process grant खत्म करता है और evidence के साथ non-executable task context सुरक्षित रखता है। नए शुरू हुए process को नई review की गई authorization मिलती है। Credentials तभी rotate होते हैं, जब exposure या lifecycle rules इसकी मांग करें।

इस policy को operational terms में लिखें और हर exception का owner तय करें। अगर टीम कहती है कि reboot के दौरान uninterrupted automation जरूरी है, तो पूछें कि कौन सी action जारी रहेगी, किस account की ownership होगी, उसकी monitoring कैसे होगी और human approval boundary स्वीकार्य क्यों नहीं है। यह interactive coding agent के बजाय service account workload हो सकता है। Agent session को चुपचाप server credential बनाने के बजाय उसके लिए अलग design दें।

Unexpected reboot के बाद पहले workday के लिए predictable response तय करें। Operator audit integrity verify करे, पुराने run की आखिरी पूरी हुई call जांचे, जरूरत होने पर protected material unlock करे, नया agent process launch करे, resumed task review करे और केवल वही काम approve करे जो मौजूदा स्थिति से अब भी संबंधित हो। यह उस action को पलटने की तुलना में छोटी रुकावट है जो ऐसी approval के तहत हुई हो जिसके बचे रहने का किसी को पता ही नहीं था।

यह दावा न करें कि restart logic अपने आप autonomous work को सुरक्षित बना सकती है। यह केवल साफ decision point बना सकती है। उस decision की गुणवत्ता अब भी स्पष्ट process identity, सीमित credential use, समझने योग्य action descriptions और ऐसे records पर निर्भर करती है जिन्हें कोई दूसरा व्यक्ति बाद में देख सके।

जब अगला रीबूट वास्तविक task को रोक दे, तो «continue automatically» switch जोड़ने की इच्छा रोकें। Plan बचाएं। Evidence बचाएं। नए process से authority खर्च करने से पहले फिर पूछने को कहें।