क्या agent session resume होने पर पुरानी approval बनी रहनी चाहिए?

फिर से शुरू की गई एजेंट बातचीत को केवल इसलिए अधिकार नहीं मिलना चाहिए कि उसका टेक्स्ट सुरक्षित रह गया है। मॉडल के पास वही योजना, वही tool history और वही आत्मविश्वासी लहजा हो सकता है। इनमें से कोई भी बात यह नहीं बताती कि access मांगने वाली प्रक्रिया वही है जिसे आपने अनुमति दी थी या नहीं, credential vault उपलब्ध है या नहीं, या gateway के पास अब भी अनुमति का भरोसेमंद रिकॉर्ड है या नहीं।

Resume को continuity claim मानें, ऐसा अधिकार नहीं जिसे client खुद घोषित कर सके। अगर process identity, vault state या gateway state बदली है, तो पुराना निर्णय समाप्त हो गया। अगली protected action से पहले फिर पूछें।

वास्तविक काम में restart कैसे होते हैं, यह देखने तक यह नियम बहुत सख्त लगता है। Coding agent खुद को अपडेट करता है। Crash के बाद editor अपने helper को फिर शुरू करता है। उपयोगकर्ता अटकी हुई प्रक्रिया बंद करके नई प्रक्रिया शुरू करता है। Vault lock होने के दौरान laptop sleep में चला जाता है। Upgrade के बाद menu-bar app दोबारा शुरू होता है। बातचीत अक्सर इतनी आसानी से reconnect हो जाती है कि उपयोगकर्ता को एक ही uninterrupted thread दिखाई देती है। जो security code इस thread को authority मानता है, वह अलग-अलग executions को चुपचाप एक ही approval में जोड़ देता है।

फिर से शुरू हुई बातचीत अपने साथ authority नहीं लाती

बातचीत context का प्रमाण है, जबकि authorization वर्तमान actor द्वारा वर्तमान action की कोशिश के बारे में लिया गया निर्णय है। दोनों को अलग रहना चाहिए।

Agent systems अक्सर लंबे समय तक रहने वाला conversation identifier, transcript और शायद tool-call history रखते हैं। Disconnect के बाद काम बहाल करने के लिए ये उपयोगी हैं। इनसे एजेंट को पता चलता है कि वह क्या करना चाहता था, उसने कौन-सी files बदलीं और कौन-सी API request बीच में विफल हुई। लेकिन ये उस operating-system process की पहचान नहीं करते जो इस समय tools से जुड़ा है।

एक सामान्य क्रम देखें। एजेंट deployment request तैयार करता है और session approval पाता है। Request भेजे जाने से पहले gateway restart हो जाता है। Agent client फिर जुड़ता है, पुराना transcript लोड करता है और कहता है कि वह वही run जारी रख रहा है। अगर gateway यह बात मानकर पुरानी अनुमति बहाल कर देता है, तो अनुमति अब ऐसी प्रक्रिया पर लागू है जिसकी gateway ने restart के बाद जांच नहीं की।

नई प्रक्रिया harmless हो सकती है। वह नया installed build, किसी दूसरी directory से चला wrapper executable या cached resume token पाने वाला दूसरा tool client भी हो सकता है। बातचीत पढ़कर इन स्थितियों में अंतर नहीं किया जा सकता।

इसीलिए «उपयोगकर्ता ने इस task को पहले ही approve कर दिया है» गलत जांच है। उपयोगकर्ता तय शर्तों के तहत पहचाने गए agent run को अनुमति देता है। जब वे शर्तें सही नहीं रहतीं या साबित नहीं की जा सकतीं, अनुमति समाप्त हो जाती है।

Model Context Protocol इस अंतर को समझना आसान बनाता है। इसके transport documentation के अनुसार stdio में client server को subprocess के रूप में शुरू करता है और standard input तथा output पर JSON-RPC messages भेजता है। यह live process relationship है, transcript में रखा स्थायी grant नहीं। MCP changelog ने नए Streamable HTTP काम में protocol-level sessions भी हटा दिए हैं और stateful servers को स्पष्ट, server-minted handles की ओर निर्देशित किया है। इससे authorization अपने-आप हल नहीं होता, लेकिन यह दिखावा नहीं होता कि transport session identifier identity credential है।

Design में इन शब्दों को स्पष्ट रखें:

• Conversation एक application record है जो processes से अधिक समय तक रह सकता है।
• Process एक operating-system instance है जिसका lifetime सीमित होता है।
• Session approval उस lifetime के दौरान किसी पहचानी गई प्रक्रिया को दिया गया grant है।
• Credential use ऐसी कार्रवाई है जिसे मौजूदा vault और gateway conditions पूरी करनी होंगी।

Happy-path demo में ये चारों चीजें साथ चलती दिखाई देती हैं, इसलिए teams अक्सर इनके अर्थ मिला देती हैं। Production restarts इन्हें अलग कर देते हैं।

Process identity के कई हिस्से होते हैं

केवल process identifier किसी स्थायी approval binding के लिए कमजोर है, क्योंकि process समाप्त होने के बाद operating system वही identifier फिर इस्तेमाल कर सकता है। केवल process path भी पर्याप्त नहीं है, क्योंकि उस path की file बदल सकती है। केवल code signature भी पर्याप्त नहीं है, क्योंकि एक ही signed program कई जगह एक साथ चल सकता है।

Approval के समय इकट्ठे किए गए कई facts से वह identity बनाएं और bind करें जिसे आप दिखाते हैं। macOS पर शुरुआत running process, उसकी executable identity और code-signing authority से करें। Apple designated requirements को ऐसे code requirement के रूप में बताता है जो signed code की पहचान करता है। जब app ने कोई explicit requirement न दी हो, तो यह अक्सर signing authority और embedded identifier से बनती है। इससे उपयोगकर्ता को raw PID से बेहतर जानकारी मिलती है।

फिर भी signing authority को जादुई उत्तर न मानें। समान designated requirement वाली दो अलग प्रक्रियाएं फिर भी दो अलग प्रक्रियाएं हैं। Signed agent unsigned helper शुरू कर सकता है। Locally built development binary पर ad hoc signature हो सकती है। Approval के बाद approved process पर नियंत्रण पाने वाला attacker सुरक्षित नहीं हो जाता, भले ही मूल signature सही दिखी हो।

Process binding में ऐसे facts इस्तेमाल करें जो साथ मिलकर अर्थपूर्ण हों:

approval_subject = {
  process_id: 48192,
  process_start_time: "2026-07-22T14:18:03Z",
  executable_file_id: "volume:.../inode:...",
  executable_hash: "sha256:...",
  signing_requirement: "anchor ... and identifier ...",
  parent_process_id: 48001,
  launch_nonce: "random-128-bit-value"
}

सटीक fields platform के अनुसार बदलेंगे। नियम नहीं बदलता: gateway के पास इतना evidence होना चाहिए कि पुराना subject समाप्त हो जाने पर वह पुरानी अनुमति अस्वीकार कर सके। Launch nonce महत्वपूर्ण है क्योंकि process की जांच के बाद इसे gateway बनाता है। Client इसे local cache से सुरक्षित रूप से restore करके continuity का दावा नहीं कर सकता।

हर field उपयोगकर्ता को दिखाने की जरूरत नहीं है। वास्तव में ऐसा करने से approval card अक्सर खराब हो जाता है। Signing authority, executable name और action channel का स्पष्ट विवरण दिखाएं। पूरी binding को बाद की जांच के लिए journal में रखें।

एक कठिन सीमा साफ-साफ समझ लें। अगर gateway उस process को देख या attest नहीं कर सकता जो request कर रहा है, तो वह process-specific approval नहीं दे सकता। वह किसी दूसरे भरोसेमंद subject से जुड़ी छोटी अनुमति दे सकता है, लेकिन यह दावा नहीं करना चाहिए कि उसने process verify किया है। Client द्वारा दिया गया process name «identity» कहलाने लगे, तो कमजोर designs को आधिकारिक लगने वाले labels मिल जाते हैं।

Process restart session approval समाप्त कर देता है

Process बंद होते ही session approval समाप्त हो जानी चाहिए, भले ही replacement process का code, arguments और conversation history बिल्कुल समान हों।

यह नियम उन मामलों को पकड़ता है जो नुकसान होने तक मामूली लगते हैं। मान लें agent editor extension के अंदर चलता है। Extension crash हो जाता है, supervisor replacement शुरू करता है और replacement पुराना task state फिर लोड कर लेता है। नई प्रक्रिया का project directory और user account वही हो सकता है। फिर भी उसे crash हुई प्रक्रिया को दी गई authority नहीं मिली है।

Agent fork होने पर भी यही बात लागू होती है। Parent process को approval मिल सकती है और वह shell commands चलाने या network calls करने के लिए helper शुरू कर सकता है। अगर अनुमति केवल parent पर लागू है, तो helper को controlled delegation के तहत parent के जरिए काम करना होगा या अपनी approval लेनी होगी। Process tree में bearer token भेजना approval को ठीक उसी तरह portable बना देता है जिससे आप बचना चाहते हैं।

लंबी expiration देकर इसे ठीक न करें। ऐसी पांच मिनट की approval जिसे कोई replacement process resume कर सके, पांच मिनट की session approval नहीं है। वह friendly label वाली पांच मिनट की bearer credential है।

बेहतर नियम सरल है:

if current.process_id != approved.process_id:
    deny("approval belongs to a different process")

if current.process_start_time != approved.process_start_time:
    deny("process lifetime changed")

if current.launch_nonce != approved.launch_nonce:
    deny("gateway has not bound this run")

Gateway को यह जांच session approval के योग्य request पर निर्णय लेने से पहले करनी चाहिए। केवल agent reconnect होने पर जांच न करें। Multiplexed architecture में client के रहते प्रक्रिया बदल सकती है और stale approval object अपेक्षा से अधिक समय तक memory में रह सकता है।

उपयोगकर्ता कह सकता है कि replacement साफ तौर पर वही agent है। आमतौर पर यह smoother approval card की मांग है, boundary मिटाने का कारण नहीं। समझाएं कि agent restart हुआ है और नया signer दिखाएं। अनजाने production call की जांच करने से एक बार सोच-समझकर click करना सस्ता है।

Vault state बदलने पर कार्रवाई का अधिकार खत्म हो जाता है

Vault state कोई background detail नहीं है। Vault lock होने पर availability पर निर्भर पुराना निर्णय credential वाली कार्रवाइयों की अनुमति देना बंद कर दे।

दो failures से बचना है। पहला स्पष्ट है: gateway vault lock होने के बाद decrypted credential इस्तेमाल करता रहे। दूसरा शांत तरीके से होता है: gateway locked अवस्था में credential वाली action queue कर दे और vault unlock होते ही उसे अपने-आप चला दे, क्योंकि पुरानी session approval अभी मौजूद है। इससे बाद में किया गया human unlock पहले के request की अनजानी approval बन जाता है।

Apple का Keychain documentation यह सीमा स्पष्ट करता है। Access control किसी app द्वारा item retrieve करने पर user presence मांग सकता है और Apple app के लिए उपयुक्त सबसे restrictive accessibility setting चुनने की सलाह देता है। Secure Enclave user-space software को underlying biometric data दिए बिना cryptographic operations को gate कर सकता है। ये mechanics उपयोगी हैं, लेकिन gateway semantics तय नहीं करते। Vault gate बंद होने पर पहले से approved agent runs के साथ क्या होगा, यह application को तय करना होगा।

सबसे सुरक्षित तरीका vault epoch रखना है। Vault lock, unlock, reset या protected session खोने पर इसे बढ़ाएं। हर approval record में epoch जोड़ें। Mismatch होने पर record credential वाली action को authorize नहीं कर सकता।

approved_vault_epoch = 17
current_vault_epoch = 18

if approved_vault_epoch != current_vault_epoch:
    require_new_session_approval()

इसका मतलब यह नहीं कि हर unlock परेशान करने वाली ceremony बने। अगर agent का कोई active session नहीं है, तो कुछ नहीं होगा। Unlock के बाद किसी request को credential चाहिए, तो gateway नया approval card दिखा सकता है और कारण बता सकता है: पिछली approval के बाद vault state बदल गई। जिन credentials के लिए हर use पर approval चाहिए, वहां per-call check भी रखें। Session approval और per-call approval अलग सवालों के जवाब हैं।

Session approval पूछती है कि यह पहचानी गई प्रक्रिया अपने वर्तमान run के दौरान इस channel का उपयोग कर सकती है या नहीं। Per-call approval पूछती है कि उपयोगकर्ता अभी इस exact use को चाहता है या नहीं। Session approval को per-call decision का विकल्प मानना उस credential को इस तरह चिन्हित करने का उद्देश्य ही खत्म कर देता है।

Gateway restart grant की memory मिटा देता है

Gateway restart होने पर in-memory session approvals अमान्य हो जानी चाहिए, क्योंकि restarted gateway यह साबित नहीं कर सकता कि पुराना approval record live world से जुड़ी अपनी पूरी और छेड़छाड़-रहित binding अब भी रखता है।

कुछ teams approval tokens persist करके restart के बाद reload करती हैं। वजह समझ में आती है: उपयोगकर्ता ने एक बार click किया, agent अभी काम कर रहा है और restart से workflow नहीं टूटना चाहिए। लेकिन persistent token अक्सर reusable credential बन जाता है। Client reconnect के बाद उसे भेजता है, gateway उसे पहचान लेता है और बिना नई process inspection के पुराना grant वापस आ जाता है।

यह design recovery को भी अस्पष्ट बनाता है। क्या gateway action भेजने से पहले crash हुआ? क्या उसने action भेजा और response record करने से पहले crash हुआ? Retry के बाद remote service को request दो बार मिली? Authorization restore और request retry को एक operation बनाने से identity recovery और delivery recovery मिल जाते हैं। दोनों के लिए अलग controls चाहिए।

हर gateway lifetime के लिए boot identifier बनाएं, जो केवल उसकी current memory में रहे। इसे हर approval record में जोड़ें। Restart के बाद current boot identifier अलग होगा, इसलिए कोई पुराना session record match नहीं कर सकेगा।

approval = {
  gateway_boot_id: "b7f9...",
  process_binding: "...",
  vault_epoch: 17,
  approved_at: "2026-07-22T14:20:11Z"
}

if approval.gateway_boot_id != gateway.current_boot_id:
    require_new_session_approval()

Gateway यह audit event persist कर सकता है कि approval हुई थी। उसे उस event को active grant के रूप में reload नहीं करना चाहिए। Audit history बताती है कि क्या हुआ; वह live authority relationship दोबारा नहीं बनाती।

Sallyport इसी तरह vault को signed menu-bar app में रखता है और vault locked होने पर actions रोकता है। उसकी per-session authorization नई agent process से जुड़ी है और उपयोगकर्ता recorded run को तुरंत revoke कर सकता है। ये boundaries तभी उपयोगी हैं जब restart या lock पुराने run को चुपचाप नए decision से फिर न जोड़ सके।

Approval को ऐसे evidence से बांधें जिसे client replay न कर सके

Approval record में server-created और current evidence होना चाहिए। Client-provided resume token gateway को conversation खोजने या उपयोगी label दिखाने में मदद कर सकता है, लेकिन यह प्रमाण नहीं हो सकता कि authorization अब भी valid है।

व्यावहारिक न्यूनतम pattern में चार बदलने वाले values हैं:

1. Gateway launch के समय random boot identifier बनाता है।
2. Gateway नई connected process की पहचान करने के बाद random run nonce बनाता है।
3. Vault protected availability बदलने पर बदलने वाला epoch रखता है।
4. User द्वारा identified run को approve करने के बाद gateway approval identifier बनाता है।

फिर gateway हर action को अपने नियंत्रण वाले सभी values के आधार पर जांचता है। Client action मांग सकता है, लेकिन नए boot identifier या नए run nonce से मेल खाने वाली approval खुद नहीं बना सकता।

यहां एक छोटा state model है जिसे teams अपना सकती हैं। इसमें conversation reference को केवल display context के रूप में रखा गया है, authorization field के रूप में नहीं।

{
  "run": {
    "conversation_ref": "worktree-cleanup-42",
    "process": {
      "pid": 48192,
      "started_at": "2026-07-22T14:18:03Z",
      "signing_requirement": "recorded-at-approval",
      "launch_nonce": "gateway-generated"
    }
  },
  "approval": {
    "id": "gateway-generated",
    "gateway_boot_id": "gateway-generated",
    "vault_epoch": 17,
    "expires_when_process_exits": true
  }
}

ध्यान दें कि resume_authorized जैसा reusable flag और ऐसा expiration timestamp नहीं है जो dead process को live subject बना सके। अतिरिक्त सीमा के रूप में छोटा timeout रखा जा सकता है, लेकिन timeout identity नहीं है।

Agent reconnect होने पर उससे initialization और process registration दोहरवाएं। Gateway को फिर इनमें से कोई outcome लौटाना चाहिए:

REAUTH_REQUIRED process_changed
REAUTH_REQUIRED gateway_restarted
REAUTH_REQUIRED vault_state_changed
RETRY_SAFE previous_action_not_started
STATUS_UNKNOWN inspect_activity_journal

RETRY_SAFE और STATUS_UNKNOWN का अंतर महत्वपूर्ण है। Gateway तभी कह सकता है कि action शुरू नहीं हुई, जब उसके पास durable evidence हो कि वह शुरू नहीं हुई। अगर HTTP request network stack को सौंपने के बाद power चली गई, तो ईमानदार उत्तर unknown हो सकता है। Duplicate action से पहले agent को destination या journal की जांच करनी चाहिए।

Action retry करना approval restore करने से अलग है

Reconnect protocol को पहले communication बहाल करनी चाहिए, दूसरे चरण में fresh authority स्थापित करनी चाहिए और तीसरे चरण में retry का निर्णय लेना चाहिए। इन चरणों को मिलाने से duplicate requests और inherited approvals पैदा होते हैं।

Connection खोने वाली protected action के लिए यह क्रम अपनाएं:

1. Agent reconnect करके नया gateway relationship initialize करता है।
2. Gateway current process की पहचान करता है और उसे current run record से मिलाता है।
3. Gateway अपना boot identifier और current vault epoch जांचता है।
4. Authority का कोई fact बदलने पर gateway credential use से पहले नई session approval मांगता है।
5. Gateway बताता है कि पिछली action शुरू नहीं हुई, पूरी हो गई या उसका status unknown है।

क्रम महत्वपूर्ण है। Current authorization स्थापित करने से पहले agent से original request दोबारा भेजने को न कहें। इससे reconnect करता client पुराने request को लेकर दबाव बना सकता है: «मुझे पहले ही approval मिल चुकी है, बस इसे पूरा कर दो।» उपयोगकर्ता अक्सर वही words देखकर इसे harmless continuation मान लेता है। Action को सामने रखने से पहले gateway को बदली हुई condition स्पष्ट करनी चाहिए।

HTTP APIs के लिए destination support करे तो idempotency key इस्तेमाल करें। Logical business action के लिए key बनाएं, भेजने से पहले उसे durably record करें और retry के लिए तभी reuse करें जब authorization दोबारा स्थापित हो चुकी हो। Idempotency key remote service को duplicate delivery पहचानने में मदद करती है। यह retry को authorize नहीं करती।

SSH retries में अधिक सावधानी चाहिए, क्योंकि connection टूटने से पहले remote command मशीन को आंशिक रूप से बदल सकती है। ऐसी operations पसंद करें जो explicit marker लिखें या फिर से बदलाव करने से पहले existing state पढ़ें। mkdir जैसी command को expected directory check से सुरक्षित बनाया जा सकता है। Credential rotate करने या service restart करने वाली command के लिए transport failure के बाद आमतौर पर status unknown बताना चाहिए, जब तक agent remote state न पढ़ ले।

इस uncertainty को optimistic language के पीछे न छिपाएं। Response खोने के बाद «deployment completed» कहने वाला agent झूठा confidence बना रहा है। Journal में लिखना चाहिए कि action का result observe नहीं हुआ और agent को जांच करनी चाहिए।

खराब failures सही boundary दिखाते हैं

सबसे उपयोगी test clean reconnect नहीं, बल्कि action के बीच restart और फिर जारी रखने की agent की कोशिश है।

मान लें agent को HTTP API के जरिए issue tracker update करने की session approval मिली है। वह request तैयार करता है, approval पाता है और gateway को call करता है। Gateway credential जोड़कर request भेजना शुरू करता है। उसी समय gateway app restart हो जाती है। Agent अपने पुराने conversation reference और cached local tool state के साथ reconnect करता है।

कमजोर design पुराना reference स्वीकार कर approval बहाल करता है और request retry करता है। Issue को दो comments मिल सकती हैं। इससे भी बुरा यह है कि approval अब cached state देने वाली मौजूदा process पर लागू हो सकती है।

सावधान design कम आकर्षक लेकिन सही परिणाम देता है। Restarted gateway नया boot identifier बनाता है। वह पुराना session grant अस्वीकार करता है। Current connected process के लिए approval मांगता है। Activity journal जांचता है। अगर journal completed request दर्ज करता है, तो result लौटाता है। अगर दर्ज है कि gateway से कोई request नहीं निकली, तो fresh approved retry की अनुमति देता है। अगर delivery boundary पार हो गई लेकिन result खो गया, तो unknown status देता है। Agent issue पढ़कर तय करता है कि दूसरा write जरूरी है या नहीं।

Resume token पर भरोसा करने से यह अधिक काम है। लेकिन यही traceable action system और duplicate changes छिपाने वाले system के बीच का अंतर है।

Resume behavior को safe कहने से पहले कम-से-कम ये cases test करें:

• Approval के बाद agent को बंद करें और वही conversation reference देने वाला replacement शुरू करें।
• Approved agent जीवित हो और दूसरी credential वाली call करने की कोशिश करे, तब gateway restart करें।
• Approved agent retry की प्रतीक्षा कर रहा हो, तब vault lock और unlock करें।
• समान signed agent processes शुरू करें और सुनिश्चित करें कि एक की approval दूसरे पर लागू न हो।
• Gateway external request शुरू करने के बाद network response drop करें और जांचें कि retry path delivery uncertainty बताता है।

ये tests एक आम गलती पकड़ते हैं: engineers केवल यह जांचते हैं कि legitimate client recover कर सकता है या नहीं। वे यह नहीं जांचते कि कोई दूसरा client recovery path उधार ले सकता है या नहीं।

Logs को बताना चाहिए कि authority क्यों समाप्त हुई

Audit log में authority changes को first-class events के रूप में दर्ज करें। Investigator को tool calls के बीच के gaps से अनुमान नहीं लगाना चाहिए।

Session approval के साथ इस्तेमाल किए गए process identity facts, gateway boot identifier, vault epoch और user-visible subject दर्ज करें। End event के साथ स्पष्ट कारण लिखें: process exited, process identity mismatch, gateway restarted, vault locked, manual revoke या approval expired। Denied action को missing action से अलग record करें। दोनों अलग facts हैं।

उपयोगी activity sequence ऐसा दिख सकता है:

14:20:11 session_approved run=R31 signer="Example Developer ID" boot=B8 vault=17
14:23:04 gateway_restarted previous_boot=B8 current_boot=C2
14:23:06 action_denied run=R31 reason=gateway_restarted
14:23:09 session_approved run=R32 signer="Example Developer ID" boot=C2 vault=17
14:23:12 http_action_started run=R32 request=Q44
14:23:13 http_action_result run=R32 request=Q44 status=201

उद्देश्य हर journal entry में secret values या पूरे request bodies दिखाना नहीं है। उद्देश्य causal chain बचाए रखना है: किसने पूछा, कौन-सी authority लागू हुई, कौन-सी state बदली और gateway ने action वास्तव में की या नहीं।

यहां tamper evidence भी महत्वपूर्ण है, क्योंकि approval history तभी उपयोगी है जब बाद में rewriting का पता लगाया जा सके। Sallyport अपने Sessions और Activity journals को write-blind encrypted, hash-chained audit log से बनाता है और sp audit verify vault key के बिना ciphertext पर offline chain verify कर सकता है। Reviewer actions को चलाने वाले secrets खोले बिना sequence की पुष्टि कर सकता है।

Audit log को prevention का भार न दें। पुरानी approval reuse हुई, यह बताने वाला perfect record खराब decision का evidence है, उसका समाधान नहीं। Live gateway को credential injection से पहले action रोकनी होगी, जब binding match न करे।

Reapproval इतनी स्पष्ट हो कि interruption उचित लगे

Meaningful state change के बाद reapproval जरूरी है, लेकिन अस्पष्ट prompt users को बिना सोचे click करना सिखाता है। Approval card में बताएं कि क्या बदला और अब कौन request कर रहा है।

«Session expired. Approve again?» जैसे generic message से बचें। इससे उपयोगकर्ता इसे timer समझता है। उसकी जगह continuity टूटने की condition दिखाएं: «Gateway restart हो गया है। इस run के लिए Git hosting API इस्तेमाल करने वाली नई connected process को approve करें।» Process identity बदली हो तो नया signing authority दिखाएं या बताएं कि program unsigned है। Vault lock हुआ हो तो कहें कि vault unlock करने से पहले वाली agent grant बहाल नहीं हुई।

यहीं तय करें कि किसी channel के लिए session approval बहुत broad तो नहीं है। अगर resumed agent production SSH change करना चाहता है, तो fresh session decision के बाद भी per-call approval सही विकल्प हो सकती है। Session के सभी checks पास होने से हर command समान रूप से सुरक्षित नहीं हो जाती।

Approval fatigue का समाधान approvals को transferable बनाना नहीं है। अनावश्यक changes कम करें, जहां संभव हो stable process identity दिखाएं और हर decision का scope समझने योग्य रखें। उपयोगकर्ता concrete request approve कर सकता है। वह इस promise को सुरक्षित रूप से approve नहीं कर सकता कि पुराने transcript वाली कोई भी future process action कर सके।

Implementation rule को sticky note पर लिखा जा सकता है: resume के दौरान context बचाएं, लेकिन live evidence से authority फिर बनाएं। Process, vault या gateway बदलने पर पुरानी approval पुराने run की होती है।