क्या locked vault request handling कभी call को replay करती है?

लॉक किया हुआ वॉल्ट समय में एक स्पष्ट सीमा बनाता है। उस सीमा के हटने से पहले action gateway तक पहुंचने वाली request को उसी समय असफल होना चाहिए। उसे queue में नहीं बैठना चाहिए, reconnect के बाद बची नहीं रहनी चाहिए और बाद में किसी के वॉल्ट को authenticate करने पर दोबारा चलने योग्य नहीं बनना चाहिए।

यह बात तब तक साफ लगती है, जब तक आप किसी वास्तविक agent stack का टेस्ट नहीं करते। एजेंट दोबारा कोशिश करते हैं। MCP clients reconnect करते हैं। HTTP libraries response खो जाने पर request फिर भेज देती हैं। Workers jobs संभालकर रखते हैं। UI denial दिखा सकता है, जबकि कोई दूसरा component call को बाद में चलाने के लिए पर्याप्त state पहले ही बचा चुका हो। अगर आप केवल approval card या agent transcript देखते हैं, तो खतरनाक हिस्सा छूट सकता है।

यहां बताया गया टेस्ट एक सीमित सवाल का जवाब देता है: क्या gateway ने वॉल्ट लॉक रहते मिली calls को हटा दिया, या unlock करने पर उनमें से कोई पुरानी call चल गई? इसमें नियंत्रित HTTP receiver, दो अलग request IDs और gateway के दोनों तरफ से मिलने वाले सबूत इस्तेमाल होते हैं। किसी ऐसे endpoint पर autonomous agent को भरोसा करने से पहले यह टेस्ट करें, जो पैसे, infrastructure, source code या customer data में बदलाव कर सकता है।

वॉल्ट लॉक को action रोकना चाहिए, टालना नहीं

अपेक्षित नियम सरल है: वॉल्ट लॉक होने पर gateway हर उस action को deny करता है जिसे वॉल्ट की जरूरत है। Unlock करने से बाद में आने वाली call का जवाब बदलता है। पहले आ चुकी call का जवाब नहीं बदलता।

यह फर्क महत्वपूर्ण है, क्योंकि request का एक life cycle होता है। कोई process stdin में bytes लिखता है। MCP shim JSON-RPC को parse करता है। Gateway configured action पहचानता है, पूछता है कि क्या वह secret इस्तेमाल कर सकता है, अनुमति मिलने पर credentials डालता है, outbound connection खोलता है और result लौटाता है। इस रास्ते में कई जगह bug request को संभालकर रख सकता है।

सुरक्षित design में उस invocation के लिए locked decision अंतिम होता है। Gateway denial दर्ज कर सकता है, लेकिन उसे ऐसा executable closure, serialized request body, outbound job या retry token नहीं रखना चाहिए, जो बाद में खुले हुए वॉल्ट के तहत चल सके।

लोग अक्सर दो अलग व्यवहारों को एक समझ लेते हैं:

• Fresh retry वह नई call है जिसे agent error या state change देखने के बाद भेजता है।
• Replay वह original call है, जिसे access deny होने के दौरान gateway या उसके किसी helper ने संभालकर रखा और बाद में चला दिया।

Fresh retry वैध हो सकती है, हालांकि उसे भी सामान्य authorization की जरूरत होगी। Replay बिना नए decision के security boundary पार करता है। अगर आप दोनों को मिला देते हैं, तो unlock करने के बाद destination तक पहुंची एक request देखकर टेस्ट को गलत तरीके से पास मान सकते हैं और यह समझ सकते हैं कि वह जानबूझकर की गई retry थी।

Model Context Protocol इस design समस्या का समाधान अपने आप नहीं करता। इसका stdio transport client द्वारा शुरू किए गए server process और client के बीच newline-delimited JSON-RPC messages इस्तेमाल करता है। id वाली JSON-RPC requests को संबंधित response मिलता है, जबकि notifications का कोई response नहीं होता। ये protocol rules correlation के लिए उपयोगी हैं, लेकिन यह तय नहीं करते कि gateway denied action को बाद में चलाने के लिए बचाकर रख सकता है या नहीं। यह फैसला gateway को स्पष्ट रूप से करना होगा।

Arrival time outbound HTTP call से पहले का समय है

Request उस समय पहुंचती है जब gateway के पास यह तय करने के लिए पर्याप्त जानकारी होती है कि उसे action करना है या नहीं, न कि उस समय जब destination server traffic देखता है। उस बिंदु पर वॉल्ट लॉक हो, तो credential injection से पहले और ऐसे किसी component को काम सौंपने से पहले denial हो जाना चाहिए जो इस decision के बाद भी जीवित रह सकता है।

यहीं tests अक्सर लापरवाही से किए जाते हैं। कोई वॉल्ट लॉक करता है, agent को API call करने को कहता है, error का इंतजार करता है, फिर unlock करके देखता है कि तुरंत कोई request तो नहीं आई। इस टेस्ट में delayed retries, blocked workers, connection pools और client retry timers छूट जाते हैं। यह संभावना भी छूट जाती है कि UI ने error दिखाने से पहले call destination तक पहुंच गई हो।

तीन timestamps अलग-अलग जगहों से दर्ज करें:

1. T_lock: वॉल्ट के locked होने की पुष्टि का समय।
2. T_attempt: agent द्वारा पुरानी request ID submit करने का समय।
3. T_unlock: वॉल्ट दोबारा खोलने का समय।

इसके बाद T_unlock के बाद भी receiver को देखते रहें। प्रतीक्षा client, gateway और किसी भी intermediary में configured हर retry और timeout से अधिक होनी चाहिए। अगर आपको ये values मालूम नहीं हैं, तो भरोसा दिलाने वाली छोटी delay न चुनें। पहले उन्हें पता करें या ऐसा receiver इस्तेमाल करें जो delayed delivery दिखाने के लिए पर्याप्त समय तक उपलब्ध रहे।

एक उपयोगी acceptance statement, «locked request failed» से ज्यादा सटीक होगा:

Request ID locked-... के लिए controlled receiver T_unlock से पहले और बाद में zero executions दर्ज करता है। T_unlock के बाद भेजी गई fresh-... request ID के लिए receiver ठीक एक execution दर्ज करता है।

यह statement failure के दोनों पहलू पकड़ता है। यह बाद में चलने वाली पुरानी call का पता लगाता है और साबित करता है कि receiver या action configuration के खराब होने से टेस्ट विफल नहीं हुआ।

दोनों calls के लिए एक ही payload इस्तेमाल न करें। अगर दोनों में deploy=true लिखा होगा, तो आप पहचान नहीं पाएंगे कि कौन-सी call पहुंची। Request ID को URL path, harmless JSON field और header में रखें, अगर आपका configured action इसकी अनुमति देता हो। यहां redundancy उपयोगी है, क्योंकि इससे accidental rewriting या caching सामने आती है।

Replay defects queue और retries में छिपे रहते हैं

सबसे खतरनाक replay defects नाटकीय नहीं होते। वे अक्सर उस सामान्य reliability code से आते हैं, जिसे लिखने वाले ने मान लिया कि authorization failure भी transient network failure जैसा व्यवहार करता है।

एक सामान्य खराब sequence देखें। वॉल्ट लॉक रहते agent MCP tool call भेजता है। Shim message स्वीकार करता है और internal work item बनाता है। Vault check locked error लौटाता है, लेकिन worker उसे retryable मानता है, क्योंकि destination तक पहुंचा ही नहीं गया था। Caller disconnect हो जाता है या session खत्म हो जाता है। बाद में user वॉल्ट unlock करता है। Worker जागता है, usable credential पाता है और original HTTP request भेज देता है।

इस पूरे sequence में UI सही दिखाई दे सकता है। Original agent को error मिला। User ने vault locked देखा। Destination को valid credential unlock के बाद ही मिला। फिर भी gateway ने action को उस boundary के पार पहुंचा दिया, जहां उसे समाप्त हो जाना चाहिए था।

इन patterns को तलाशें:

• Generic retry wrapper malformed input को छोड़कर हर error पकड़ लेता है।
• Persistent job queue vault decision से पहले intent store कर लेती है।
• Future या promise unlock का इंतजार करती है, terminal error लौटाने के बजाय।
• Reconnect path client process बंद होने के बाद in-memory request फिर भेज देता है।
• Background helper retry state को vault gate से अलग संभालता है।

«हर failed network operation पर retry करें» वाली आम सलाह इस boundary पर गलत है। यह सलाह लोकप्रिय है, क्योंकि network transport failures आम हैं और retries delivery बेहतर कर सकती हैं। Locked vault transport failure नहीं है। यह authority इस्तेमाल करने से साफ इनकार है। उस invocation के लिए इसे terminal मानें।

यह cancellation पर भी लागू होता है। Client disconnect का मतलब यह जरूरी नहीं कि HTTP या SSE request cancel हो गई है। MCP transport specification कहती है कि disconnection किसी भी समय हो सकता है और इसे अपने आप cancellation नहीं समझना चाहिए। Client cancellation चाहता हो, तो explicit cancellation notification भेजनी चाहिए। Long-running work के लिए यह व्यवहार सही है, लेकिन इससे local gateway state की अहमियत बढ़ जाती है: denied call केवल इसलिए runnable नहीं रहनी चाहिए कि transport state अस्पष्ट हो गई है।

ऐसा receiver बनाएं जिससे हर execution दिखाई दे

Controlled receiver agent chat transcript से बेहतर सबूत देता है। इससे पता चलता है कि outbound call वास्तव में पहुंची या नहीं, उसमें कौन-सी ID थी और वह कब पहुंची। इसे production से अलग रखें और इसका एकमात्र side effect append-only local log होना चाहिए।

यह छोटा Python receiver ऐसी machine और port पर चलाएं, जहां आपका gateway पहुंच सके। यह POST requests स्वीकार करता है, हर arrival के लिए एक JSON line लिखता है और harmless success response लौटाता है। यह authorization header से केवल छोटा marker दर्ज करता है, credential खुद नहीं।

# receiver.py
from http.server import BaseHTTPRequestHandler, HTTPServer
from datetime import datetime, timezone
import hashlib
import json

LOG = "receiver-events.jsonl"

class Receiver(BaseHTTPRequestHandler):
    def do_POST(self):
        length = int(self.headers.get("Content-Length", "0"))
        body = self.rfile.read(length).decode("utf-8", errors="replace")
        auth = self.headers.get("Authorization", "")
        auth_marker = hashlib.sha256(auth.encode()).hexdigest()[:12] if auth else None
        event = {
            "received_at": datetime.now(timezone.utc).isoformat(),
            "method": self.command,
            "path": self.path,
            "request_id": self.headers.get("X-Replay-Test-Id"),
            "auth_marker": auth_marker,
            "body": body,
        }
        with open(LOG, "a", encoding="utf-8") as log:
            log.write(json.dumps(event) + "\n")
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        self.wfile.write(b'{"received":true}')

    def log_message(self, format, *args):
        return

HTTPServer(("127.0.0.1", 8787), Receiver).serve_forever()

इसे इस command से शुरू करें:

python3 receiver.py

Output file का रूप कुछ ऐसा होगा:

{"received_at":"2026-07-22T16:42:12.103841+00:00","method":"POST","path":"/replay-test/fresh-8f1c","request_id":"fresh-8f1c","auth_marker":"a4d7e02c1b9f","body":"{\"kind\":\"fresh\"}"}

Request body में live secret न रखें। Test action को वॉल्ट में रखे अलग, कम-अधिकार वाले test credential के साथ configure करें और gateway को सामान्य HTTP channel के जरिए उसे डालने दें। Receiver का header fingerprint केवल यह साबित करता है कि कोई authorization value पहुंची थी। यह value ऐसी file में नहीं लिखी जाती जो test के बाद भी बची रह सकती है।

Locked test से पहले वॉल्ट खुला रहते एक सामान्य request भेजें। पुष्टि करें कि receiver उसे log करता है और configured endpoint path सही है। फिर receiver-events.jsonl हटाएं या कहीं अलग रख दें। खाली log से शुरुआत करने पर पहले की setup request result में शामिल नहीं होगी।

Test को जानबूझकर अलग दो calls के रूप में चलाएं

Test में एक पुरानी ID चाहिए, जिसे locked state में आजमाया जाए, और एक fresh ID चाहिए, जो unlock के बाद ही बनाई जाए। Random जैसी labels इस्तेमाल करें, लेकिन run से पहले उन्हें लिख लें। इंसानों के लिए स्पष्ट labels से audit comparison आसान होता है।

उदाहरण:

old request ID:   locked-3d4a
fresh request ID: fresh-91ce

Configured HTTP action को इस जानकारी के साथ call करने वाला agent instruction या MCP client request तैयार करें:

{
  "path": "/replay-test/locked-3d4a",
  "headers": {
    "X-Replay-Test-Id": "locked-3d4a"
  },
  "body": {
    "kind": "locked-period-attempt",
    "request_id": "locked-3d4a"
  }
}

सटीक tool name और argument shape आपके configured action interface पर निर्भर करते हैं। Receiver को सीधे shell command से call करके passing test का दिखावा न करें। Request उसी agent, MCP shim, gateway, vault और HTTP action path से गुजरनी चाहिए, जिस पर आप भरोसा करना चाहते हैं।

अब sequence को बिना improvisation के चलाएं:

1. पुष्टि करें कि receiver log खाली है और वॉल्ट लॉक है।
2. नया agent process शुरू करें, फिर locked-3d4a call submit करें।
3. Agent-side error और समय दर्ज करें। Request दोबारा न भेजें।
4. Agent process को थोड़ी observation period तक चालू रहने दें, फिर बंद करें। इससे तुरंत होने वाले और process से जुड़े retry behavior दोनों पकड़ में आते हैं।
5. वॉल्ट खोलें और पूरी observation period तक प्रतीक्षा करें। Receiver log बार-बार देखें। locked-3d4a कभी दिखाई नहीं देनी चाहिए।
6. इस प्रतीक्षा के बाद ही नया agent process शुरू करें और fresh-91ce submit करें। Receiver को यह ID एक बार दर्ज करनी चाहिए।

पुरानी और fresh calls को अलग-अलग agent processes में रखें। वरना session-level approval या internal client cache result को अस्पष्ट कर सकता है। आप यह जांच रहे हैं कि पुराना action lock boundary पार कर सकता है या नहीं, न कि यह कि एक ही process authorization state याद रखता है या नहीं।

अगर agent द्वारा नई call भेजे बिना unlock के बाद locked call के लिए approval prompt दिखाई दे, तो रुक जाएं। यह retained intent का सबूत है। अगर receiver को unlock के बाद किसी भी समय locked-3d4a मिले, तो इसे failed security test मानें, भले ही server ने data बदले बिना 200 लौटाया हो।

दोनों journals देखें, लेकिन logs को receiver का विकल्प न बनाएं

Gateway journal से यह समझने में मदद मिलती है कि gateway के अनुसार क्या हुआ। Receiver साबित करता है कि gateway के बाहर वास्तव में क्या हुआ। दोनों जरूरी हैं, क्योंकि अकेला कोई भी source झूठा भरोसा पैदा कर सकता है।

Sallyport agent runs के लिए Sessions journal और individual calls के लिए Activity journal रखता है। दोनों एक encrypted, hash-chained audit log से project होते हैं। इसका offline verifier sp audit verify के जरिए उपलब्ध है और chain validate करने के लिए vault key की जरूरत नहीं होती। Test के बाद यह command चलाएं और result को receiver log तथा agent transcript के साथ सुरक्षित रखें।

Records की मदद से ठोस सवालों के जवाब दें:

• क्या पुरानी call ने activity entry बनाई और क्या उसका outcome denied दिखता है?
• Session में कौन-सा agent process और code-signing authority दर्ज है?
• क्या पुरानी request ID, endpoint path या matching time window वाली कोई बाद की activity है?
• क्या unlock के बाद वाली fresh call के लिए नया session शुरू हुआ?
• क्या आपके जुटाए records के लिए audit verification सफल है?

«Denied» लिखी log entry को इस बात का प्रमाण न मानें कि request machine से बाहर नहीं गई। Log gateway के अपने decision का रिकॉर्ड है। Controlled receiver स्वतंत्र जांच देता है। इसके उलट, entry न मिलना भी यह दिखा सकता है कि search terms गलत थे, timestamps में अंतर था या test intended action के जरिए चला ही नहीं। इसी वजह से सफल fresh request जरूरी है।

Repeatable team test के लिए एक test run ID के तहत चार artifacts रखें: agent transcript, receiver JSONL file, calls की पहचान करने वाला journal export या screenshots, और sp audit verify का result। इनमें secret values न रखें।

Notifications, batches और reconnects के लिए अलग cases चाहिए

एक passing request test agent client द्वारा भेजे जा सकने वाले हर message form को cover नहीं करता। ID वाली requests का test सबसे आसान है, क्योंकि JSON-RPC response में वही ID लौटाने की मांग करता है। Notifications की कोई ID नहीं होती और उन्हें response नहीं मिलता, इसलिए gateway ने उन्हें reject किया या नहीं, इसका सामान्य proof नहीं रहता। JSON-RPC साफ कहता है कि server को notifications का reply नहीं देना चाहिए।

Notification-capable path के लिए outbound payload में receiver-side marker रखें, जैसे notification-77b2। वॉल्ट लॉक करें, notification एक बार emit कराएं, unlock करें और पुष्टि करें कि marker कभी नहीं पहुंचा। Client UI की खामोशी को safety का प्रमाण न मानें, क्योंकि protocol के अनुसार silence अपेक्षित है।

अगर आपका client या shim batch स्वीकार करता है, तो batch input का अलग test करें। Batch में दो harmless calls रखें: एक locked state में और एक unlock के बाद अलग batch में भेजी जाए। पुरानी और नई calls को एक ही batch में न रखें, क्योंकि state बदलने से पहले batch के कुछ हिस्से को process करने वाला gateway ऐसा result दे सकता है जिसकी व्याख्या मुश्किल हो।

Reconnect tests में एक बार में केवल एक चीज बदलें। अलग-अलग runs में ये cases आजमाएं:

• Unlock तक agent process चालू रखें।
• Unlock से पहले agent process बंद कर दें।
• Unlock से पहले केवल MCP client या shim restart करें।
• Locked error के बाद network path disconnect करें और unlock के बाद reconnect करें।

अपेक्षा वही रहती है। पुरानी receiver ID कभी दिखाई नहीं देनी चाहिए। अगर पुरानी ID केवल reconnect के बाद दिखाई दे, तो आपको vault UI से नहीं बल्कि transport recovery से जुड़ा replay path मिला है।

Per-session approval retained action को सुरक्षित नहीं बना सकता

Per-session authorization और per-call approval यह तय करते हैं कि current action आगे बढ़ सकती है या नहीं। वे उस action को संभालकर रखना सुरक्षित नहीं बना सकते, जिसे वॉल्ट लॉक होने पर reject किया गया था।

यह ordering महत्वपूर्ण है। Vault gate absolute है: लॉक रहते हर action deny होती है। वॉल्ट खुलने के बाद ही gateway session authorization के पीछे मौजूद process पर विचार कर सकता है या configured credential के लिए per-call approval मांग सकता है। इस mental model को उलटने पर teams पूछने लगती हैं कि क्या पहले दिखा approval card delayed action को authorize कर सकता है। ऐसा नहीं होना चाहिए, क्योंकि locked call runnable work के रूप में बचनी ही नहीं चाहिए।

Boundaries को अलग-अलग test करें। पहले साबित करें कि locked-period call unlock के बाद कभी execute नहीं होती। फिर, वॉल्ट खुला रखकर test करें कि नया agent process अपेक्षित session authorization behavior दिखाता है। अंत में, अगर किसी credential पर per-call approval flag है, तो जांचें कि हर fresh use पर फिर से पूछा जाता है। इन तीनों को एक लंबे run में मिलाने से failure का कारण तय करना कठिन हो जाता है।

Process identity का एक सूक्ष्म मुद्दा भी है। Session approval किसी खास agent process run से जुड़ा होता है, «उसी assistant» के विचार से नहीं। जब आप process restart करें, तो उसे नया मानें, जब तक gateway अपने rules के अनुसार उसे पहचानकर authorize न कर दे। पुराने connection वाले process को दोबारा इस्तेमाल करके test script को यह बात छिपाने न दें।

Result को release gate बनाएं

जब भी gateway dispatch, vault lifecycle code, MCP shim, retry behavior, HTTP client configuration या SSH actions करने वाले helper में बदलाव करें, यह test चलाएं। Replay defect अक्सर reliability change के दौरान आता है, क्योंकि review में code harmless दिखता है: queue, reconnect handler या एक broad catch clause।

इनमें से कोई statement गलत हो, तो release fail होनी चाहिए:

• Locked state में submit की गई हर ID के लिए controlled receiver में zero entries हों, वॉल्ट खुलने के बाद भी।
• Fresh post-unlock ID उसी configured action के जरिए receiver तक एक बार पहुंचे।
• Restart किया हुआ client या agent पुरानी ID को दिखाई न दे सके।
• Journals अपेक्षित denied और allowed events को बिना unexplained duplicates के पहचानें।
• सुरक्षित रखे गए evidence के लिए audit chain verify हो।

जहां संभव हो, negative case को automated integration test में लिखें। Test harness को वॉल्ट लॉक करना चाहिए, पुरानी call भेजनी चाहिए, वॉल्ट खोलना चाहिए, bounded retry window तक इंतजार करना चाहिए और assert करना चाहिए कि receiver में पुरानी ID नहीं है। फिर fresh call भेजकर एक arrival assert करें। Receiver को local और disposable रखें, ताकि test की authority केवल अपनी log file तक सीमित रहे।

खराब नतीजे को आसानी से कहा जा सकता है: कोई व्यक्ति अगली कार्रवाई को authorize करने के लिए वॉल्ट खोलता है और उसके बजाय पहले की कार्रवाई चल जाती है। ऐसे gateway को स्वीकार न करें जो केवल सही locked error दिखाता हो। बाहर मौजूद observer के जरिए उससे साबित कराएं कि उसने पुरानी request भुला दी है।