क्या locked vault की pending requests को बिल्कुल इंतजार करना चाहिए?

Locked vault तक पहुंचने वाली agent request को उसी समय fail हो जाना चाहिए। उसे ऐसा dormant command नहीं बनना चाहिए जो कोई व्यक्ति एक घंटे बाद vault unlock करे और फिर अचानक चल पड़े।

यह नियम सख्त लगता है, जब तक आप यह न देखें कि unlock वास्तव में क्या साबित करता है। इससे सिर्फ यह साबित होता है कि किसी व्यक्ति ने इस समय secret store तक access authorize किया है। इससे यह साबित नहीं होता कि पुराने agent process के पास अब भी वही task है, deployment अभी भी वांछित है, pull request बदली नहीं है, या पुराना HTTP body और SSH command अब भी सही हैं।

यह उन फैसलों में से है जिन्हें सुविधा के रूप में पेश किया जाता है। कोई blocked run देखकर व्यक्ति queue का सुझाव देता है: request रोककर रखें, notification दिखाएं और Touch ID के बाद काम छोड़ दें। Request पहले से बनी हुई है, इसलिए queue मददगार लगती है। इसी वजह से वह खतरनाक भी है। बनी हुई request plan से आगे बढ़कर authority की प्रतीक्षा करती action बन चुकी है।

सुरक्षित नियम सरल है: vault locked हो तो actions deny करें और उनका dispatch योग्य रूप discard कर दें। Unlock के बाद agent अपनी current state देख सकता है और नई request submit कर सकता है। उस दूसरी request को current context के आधार पर session authorization या per-call approval मिल सकती है।

Locked vault को action तुरंत reject करना चाहिए

Vault lock access boundary है, अस्थायी network outage नहीं। इसे outage की तरह देखने से automatic retry को बढ़ावा मिलता है, जबकि पुराने agent intent के आसपास आपको automatic retry बिल्कुल नहीं चाहिए।

जब agent API call या SSH connection मांगता है, gateway के पास यह तय करने के लिए पर्याप्त जानकारी होती है कि request आगे बढ़ सकती है या नहीं। Vault locked हो तो उसे body inspect करने, host resolve करने, connection शुरू करने या user का इंतजार करने की जरूरत नहीं है। बाहरी system को छुए बिना उसे denial लौटानी चाहिए।

Result में agent को यह समझ आना चाहिए कि क्या हुआ, लेकिन उसे blind replay के लिए प्रेरित नहीं करना चाहिए। उपयोगी रूप इस तरह दिख सकता है:

{
  "ok": false,
  "error": {
    "code": "VAULT_LOCKED",
    "message": "The credential vault is locked. This action was not queued or sent.",
    "request_id": "req_7d4c1f",
    "retryable": false
  }
}

retryable: false पहली नजर में उलटा लग सकता है। Agent बाद में नई request बना सकता है, लेकिन failed request को retry करना सुरक्षित नहीं है। यह फर्क client बनाने वालों को generic backoff loop बनाने से रोकता है, जो unlock होते ही पुराना काम बिना समीक्षा के चला दे।

इसे 503 Service Unavailable, timeout या generic transport error से न बदलें। ऐसी responses अच्छे इरादे वाला client उसी action को दोहराने के लिए कहती हैं। Gateway को semantic result देना चाहिए: «Human-controlled security condition ने इस call को रोका है और यह exact call अब समाप्त हो चुकी है।»

यह नियम reads और writes दोनों पर लागू होता है। Teams अक्सर writes को लेकर सावधान रहती हैं, क्योंकि stale write कुछ delete या deploy कर सकती है। Stale read भी customer information दिखा सकती है, production configuration उजागर कर सकती है या agent को ऐसा अगला निर्णय लेने पर मजबूर कर सकती है जो user अब नहीं चाहता।

Unlock करने से पुराना intent approve नहीं होता

Unlock event और action approval अलग सवालों के जवाब हैं। Unlock पूछता है कि vault अपने secrets का इस्तेमाल कर सकता है या नहीं। Action approval पूछता है कि यह process मौजूदा task के तहत इस खास तरह की external call कर सकता है या नहीं।

इन दोनों फैसलों को मिलाने से authorization bug पैदा होता है। मान लें agent service restart करने के लिए SSH command तैयार करता है। Developer laptop बंद करता है, vault lock हो जाता है और agent call भेजने की कोशिश करता है। चालीस मिनट बाद developer लौटकर किसी दूसरे issue को देखने के लिए Mac unlock करता है, और gateway में बची पुरानी command चलकर restart हो जाता है। उस क्षण developer ने restart approve नहीं किया था। उसने अपने लिए vault access approve किया था।

यही समस्या कुछ शांत रूपों में भी दिखती है:

• Agent ने pull request comment तैयार किया, लेकिन reviewer issue पहले ही ठीक कर चुका है।
• Agent ने branch name के आधार पर cloud API call तैयार की, लेकिन branch अब उसी commit की ओर नहीं जा रही।
• Agent ने support-system lookup तैयार किया, लेकिन customer request समाप्त हो चुकी है।
• Agent ने package publication तैयार की, लेकिन access locked रहने के दौरान test failure आ गया।

लोकप्रिय तर्क है कि lock से पहले request authorize हो चुकी थी। कभी-कभी यह सही हो सकता है, फिर भी deferred dispatch उचित नहीं बनता। Process मौजूद रहने तक authorization session के लिए बनी रह सकती है। केवल इसलिए intent जीवित नहीं रहता कि byte sequence queue में पड़ी है।

Gateway को साफ अलगाव रखना चाहिए:

1. Vault lock तय करता है कि secret-backed action शुरू हो सकती है या नहीं।
2. Session authorization तय करता है कि मौजूदा run के लिए यह agent process पहचाना गया है या नहीं।
3. Per-call approval तय करता है कि individual confirmation वाला credential अभी इस्तेमाल हो सकता है या नहीं।

पहले फैसले का उत्तर no हो तो रुक जाएं। बाद के फैसलों का मूल्यांकन न करें और उत्तर बदलने पर भेजने के लिए तैयार request बचाकर न रखें।

Notification request queue नहीं है

आप किसी व्यक्ति को बता सकते हैं कि काम blocked है, बिना ऐसा executable काम बचाए जो बाद में चल सके। ये अलग designs हैं, लेकिन दोनों को «pending requests» कहने से teams उन्हें मिला देती हैं।

Notification non-actionable fact है। वह बता सकती है कि किसी process ने किसी समय named credential reference को किसी destination class के साथ इस्तेमाल करने की कोशिश की। इससे व्यक्ति तय कर सकता है कि vault unlock करके task पर लौटना है या नहीं। इससे headers, request body, SSH command या approval token दोबारा नहीं बनाए जा सकते।

Request queue बाद में dispatch करने के लिए पर्याप्त material बचाकर रखती है। इसमें HTTP method, URL, body, command arguments, credential selection, authorization decision या signed replay token हो सकता है। यह material बचाते ही आपने delayed execution बना दी।

Implementation में यह फर्क महत्वपूर्ण है। Blocked-work notice के रूप में यह स्वीकार्य है:

{
  "event": "action_denied",
  "reason": "vault_locked",
  "session_id": "ses_31b8",
  "channel": "ssh",
  "credential_label": "production-deploy",
  "destination": "deploy host",
  "occurred_at": "2026-07-22T21:14:05Z"
}

यदि system बाद में event से पूरी command, destination address, private request body या credential-use authorization निकाल सकता है, तो यह स्वीकार्य नहीं है। Record investigation में मदद करे, replay में नहीं।

Hashes के साथ भी सावधान रहें। Digest correlation के लिए अक्सर सुरक्षित होता है, लेकिन तभी जब gateway उससे retained payload हासिल न कर सके। Digest और छिपा हुआ blob मिलकर भी queue ही हैं। Append-only audit record में मौजूद digest अलग बात है।

Product teams के लिए pending requests की list dashboard को responsive दिखाती है। जब तक हर entry unlock के बाद agent से fresh call resubmit न करवाए, इस आकर्षण से बचें। «Run all after unlock» वाली screen security prompt को delayed job scheduler बना देती है।

Agent को ऐसी state machine दें जिसे वह गलत न समझ सके

Gateway छोटा और स्पष्ट state model दिखाए तो agents बेहतर व्यवहार करते हैं। अस्पष्ट errors agents को अपनी recovery plans बनाने पर मजबूर करती हैं, और उनका plan wait, retry या कोई दूसरा credential path हो सकता है।

ऐसी state machine रखें जिसमें vault gate request deny करते ही उसका एक terminal result हो:

received
  |
  +-- vault locked --> denied_locked (terminal)
  |
  +-- vault unlocked --> session check
                           |
                           +-- not approved --> denied_session (terminal)
                           |
                           +-- approved --> per-call check
                                             |
                                             +-- approval declined --> denied_call (terminal)
                                             |
                                             +-- approved --> dispatched --> completed

Diagram मुख्य बात नहीं है। मुख्य बात यह है कि denied_locked से dispatched की ओर कोई arrow नहीं जाता। बाद की request received से शुरू हो सकती है, लेकिन पुरानी request कहीं से फिर प्रवेश नहीं कर सकती।

इस design से idempotency समझना भी आसान होता है। Vault locked होने पर call fail हो तो ऐसा idempotency token reserve न करें जैसे server ने action स्वीकार कर ली हो। Agent को बाद में नई request, नए request ID के साथ बनानी होगी। External API idempotency keys support करती हो तो नई request application-level key इस्तेमाल कर सकती है, जो intended business operation को दर्शाए। फिर भी gateway की denial से आधा-अधूरा action record नहीं बनना चाहिए।

Write operations के लिए destination support करे तो agent से अपना current precondition शामिल करवाएं। यह revision ID, entity version, expected branch head या ETag हो सकता है। Vault खुलने पर agent current context फिर पढ़े और उसी के अनुसार call बनाए। Stale request अच्छी precondition पास नहीं कर पाएगी, जबकि fresh request दिखाएगी कि agent ने दोबारा जांच की है।

Freshness का अनुमान केवल elapsed time से न लगाएं। तेजी से बदलते deployment में पांच सेकंड भी बहुत हो सकते हैं, जबकि static lookup में एक घंटा harmless हो सकता है। Freshness timer से नहीं, task state दोबारा पढ़कर action बनाने से आती है।

Approval को actual call से bind करें

Fresh post-unlock request को भी narrow approval model चाहिए। वरना deferred replay हटाकर आप ऐसी vague permission बना देंगे जिससे click के बाद agent action बदल सके।

Approval card उन चीजों से bind होना चाहिए जो action का security meaning बदलती हैं। HTTP के लिए आम तौर पर method, normalized destination, credential reference और request body का digest शामिल होते हैं। SSH के लिए host identity, account, command या command digest और credential reference शामिल होते हैं। Approval को agent process से bind करें और जल्दी expire कराएं।

«Allow agent access to production» जैसी card से बचें। इससे व्यक्ति category approve करता है, जबकि details agent के नियंत्रण में रहती हैं। कोई व्यक्ति process को एक endpoint पढ़ने देना चाहता हो सकता है, लेकिन उसी hostname पर administrative endpoint चलाने की अनुमति न देना चाहता हो।

Practical approval record ऐसा दिख सकता है:

{
  "approval_id": "apr_8c62",
  "session_id": "ses_31b8",
  "process_identity": "signed-authority-and-process-instance",
  "channel": "http",
  "credential_label": "billing-api",
  "method": "POST",
  "destination": "api.example.internal/v1/invoices",
  "payload_digest": "sha256:...",
  "expires_at": "2026-07-22T21:16:00Z",
  "used": false
}

Large payload का हर byte दिखाए बिना भी gateway इस बारे में ईमानदार रह सकता है कि वह क्या approve कर रहा है। लेकिन approval उन bytes से bind होना चाहिए जिन्हें वह भेजेगा। Digest के साथ छोटा human summary दिया जा सकता है, जबकि digest exact request को substitution से बचाता है।

Per-call credentials के लिए one-time approval records इस्तेमाल करें। Dispatch शुरू होने से पहले approval को used mark करें, response आने के बाद नहीं। Dispatch के बाद connection टूट जाए तो agent को destination देखकर तय करना पड़ सकता है कि action हुआ या नहीं। Approval दोबारा इस्तेमाल करने से duplicate writes आसान हो जाएंगी।

जिस गलत समय unlock होता है, वही failure case test करें

सबसे उपयोगी test यह नहीं है कि «locked रहते call fail होती है या नहीं?» असली सवाल है, «user unlock करने से पहले दुनिया बदल जाए तो क्या होता है?»

एक harmless test service बनाएं जिसमें एक endpoint deployment target record करे और दूसरा currently permitted target बदल दे। फिर यह sequence चलाएं:

1. Agent task शुरू करें, जो {\"revision\":\"a1b2c3\"} के साथ POST /deploy भेजने वाला है।
2. Agent के call भेजने से पहले vault lock करें।
3. Confirm करें कि gateway VAULT_LOCKED लौटाता है और test service को कुछ नहीं मिलता।
4. Vault locked रहते permitted revision को d4e5f6 में बदलें।
5. किसी असंबंधित कारण से vault unlock करें।
6. Agent को छुए बिना प्रतीक्षा करें।

सही result नीरस होना चाहिए: test service को अब भी कुछ नहीं मिलना चाहिए। यदि उसे a1b2c3 का deployment मिलता है, तो gateway में deferred execution path है।

अब agent को बताएं कि call deny हुई, उसे permitted revision फिर पढ़ने दें और नई request submit करवाएं। Expected request अब d4e5f6 होगी और gateway लागू session या per-call authorization मांग सकता है। इससे साबित होता है कि recovery path current context बचाता है, locked समय को invisible pause button नहीं मानता।

यही test SSH के लिए भी करें। ऐसी command इस्तेमाल करें जो intended revision वाला harmless marker लिखे। केवल connection establishment test न करें। Unsafe implementation अक्सर key चुनने के बाद command रोककर रखती है और vault उपलब्ध होते ही भेज देती है। आपको प्रमाण चाहिए कि command text खुद lock boundary पर समाप्त हो जाता है।

Clients को denial छिपाने न दें

Gateway सही निर्णय ले सकता है, फिर भी clients हर error को «try again later» बना दें तो परिणाम खराब होगा। Protocol में agent frameworks और wrapper scripts को locked vault को जानबूझकर handle करने लायक structure चाहिए।

Response contract में agents को तीन बातें मिलनी चाहिए। पहली, action gateway से बाहर नहीं गई। दूसरी, gateway ने request discard कर दी। तीसरी, agent को वही request अपने-आप retry नहीं करनी चाहिए।

Agent का recovery loop कुछ ऐसा होना चाहिए:

if result.error.code == "VAULT_LOCKED":
    record_blocked_task()
    ask the user to unlock when appropriate
    stop this action

if user later resumes the task:
    reread relevant state
    decide whether the action is still needed
    create a new request

decide whether the action is still needed वाली line महत्वपूर्ण है। इसे retry request से नहीं बदलना चाहिए। Agent को नई user instructions मिल सकती हैं, files edit हो सकती हैं, branch बदल सकती है या test fail हो सकता है। अब उसे अलग action की जरूरत हो सकती है, या किसी action की नहीं।

Unattended runs में denial orchestrator को लौटाएं और run को blocked state में समाप्त होने दें। Gateway को किसी के unlock करने तक wait न करवाएं। Waiting agent process memory रखता है, sensitive हो सकने वाला context बचाए रखता है और eventual unlock को continue करने की permission मानने का दबाव बनाता है। Clean stop human को resume करने से पहले task review करने का मौका देता है।

Interface में notification दिखाएं तो wording सटीक रखें: «Vault locked होने के कारण agent action deny की गई।» «continue» या «approve pending» जैसे buttons से बचें। Button vault खोल सकता है या session details दिखा सकता है, लेकिन पुरानी action नहीं चला सकता।

Logs से साबित होना चाहिए कि कुछ भेजा नहीं गया

Denial का audit record होना चाहिए, क्योंकि operators अंततः पूछेंगे: agent ने केवल action का प्रयास किया था या वास्तव में बाहरी system से संपर्क भी किया था?

Attempted channel, agent run की identity, credential reference, normalized destination, outcome और timestamps record करें। Dispatch state स्पष्ट रखें। Operators को denied_before_dispatch, dispatch_started, remote_rejected और completed में फर्क exception strings का अनुमान लगाए बिना समझ आना चाहिए।

Secrets, raw authorization headers, private key material या full bodies को default रूप से log न करें। Sensitive request bodies के लिए digest और छोटी approved summary record करें, यदि वह content leak किए बिना बनाई जा सकती हो। उद्देश्य यह बताना है कि क्या हुआ, न कि protected data की दूसरी copy बनाना।

Audit query इस तरह की incident report का उत्तर दे सके:

21:14:05  session ses_31b8 attempted SSH action using production-deploy
21:14:05  vault gate denied action before dispatch
21:15:41  vault unlocked by local user action
21:16:09  no action dispatched from ses_31b8

अंतिम line dispatch records की अनुपस्थिति से निकाली जा सकती है, लेकिन explicit terminal states investigation तेज करती हैं और ambiguity घटाती हैं। Hash-chained journal इस्तेमाल करते हों तो incident review के दौरान भी chain verify करें, केवल routine checks के दौरान नहीं। Tamper evidence का लाभ तभी है जब record महत्वपूर्ण होने पर कोई उसका इस्तेमाल करे।

Sallyport का Sessions journal और Activity journal में विभाजन इस समस्या के लिए उपयोगी है। Locked-vault denial run की history और action-level trail दोनों से जुड़ी होती है। इसका offline sp audit verify check vault खोले बिना उस history की integrity test करने देता है।

Convenience queues दूसरा authorization system बनाती हैं

Gateway requests को बाद में release करने के लिए store करने लगे तो rules जमा होने लगते हैं: requests कितनी देर जीवित रहेंगी, कौन release कर सकता है, original process मौजूद रहना जरूरी है या नहीं, content बदल सकता है या नहीं, reboot के बाद क्या होगा, और एक unlock एक request छोड़ेगा या सभी।

ये rules छिपा हुआ policy engine हैं। Users को इन्हें समझाना मुश्किल होता है, क्योंकि हर exception unlock के अर्थ को बदल देती है। छोटी queue timeout इस समस्या को हल नहीं करती। Original process को जीवित रखना भी समाधान नहीं है, क्योंकि process compromised हो सकता है या stale context पर काम कर सकता है।

Design छोटा रखें। Vault locked हो तो gate सभी actions deny करे। New process session को approval की जरूरत हो सकती है। Per-call approval वाले credential के लिए हर बार explicit confirmation हो। बाकी convenience agent side पर task recovery के रूप में रखें, जहां agent को अपना plan फिर बनाना पड़े और human देख सके कि क्या बदला।

इससे users को भरोसेमंद mental model मिलता है: Unlock करने से नई actions पर विचार करने की क्षमता लौटती है। इससे वे actions release नहीं होतीं जिन्हें वे भूल चुके थे। इस model के साथ लोग सही निर्णय ले सकते हैं। जब lock screen छिपी work queue भी बन जाती है, तो स्थिति कठिन हो जाती है।

Safe path को unsafe path से आसान बनाएं

Teams queues इसलिए बनाती हैं क्योंकि hard failure normal development में बाधा जैसा लगता है। Executable requests बचाकर रखे बिना friction दूर करें।

Agent process के lifetime तक session authorization रखें, ताकि developer को हर सामान्य call approve न करनी पड़े। Production administration या external publication जैसे credentials के लिए per-call confirmation रखें, जिन्हें सचमुच deliberate friction चाहिए। ऐसा स्पष्ट denial लौटाएं जिसे agent plain language में blocked work के रूप में बता सके। User को unlock करने, agent session देखने और task को सोच-समझकर resume करने का रास्ता दें।

Agent instructions भी स्पष्ट बनाएं। Agents को बताएं कि credentials उनके context से बाहर रहते हैं, locked-vault result attempted action समाप्त करता है और बाद की action current state जांचने के बाद फिर बनानी होगी। Agent prompt इस नियम को enforce नहीं कर सकता, लेकिन बेकार retries घटाता है और protocol को समझना आसान बनाता है।

इस design की परीक्षा सरल है। यदि कोई व्यक्ति distracted, tired या किसी असंबंधित काम में व्यस्त रहते vault unlock करे, तो कोई पुरानी agent action नहीं चलनी चाहिए। यदि यह दावा सही नहीं है, तो queue को incident report बनने से पहले हटा दें।