Nested MCP requests: हर external action को सुरक्षित तरीके से trace करें

कोई agent ऐसा tool चला सकता है जो दूसरे tool को चलाए, जो किसी helper से environment resolve करने को कहे और अंत में HTTP request भेजे या SSH command चलाए। अगर आपके records पहली tool के नाम पर रुक जाते हैं, तो आपके पास सिर्फ इरादे की कहानी है। प्रक्रिया के बाहर वास्तव में क्या हुआ, उसका पूरा हिसाब आपके पास नहीं है।

Nested MCP requests के लिए ऐसी tracing चाहिए जो causal chain को हर credential वाले external action तक पूरा follow करे। इसका मतलब है कि agent transcript और सामान्य request log से आगे की जानकारी रिकॉर्ड करनी होगी। आपको ऐसा graph चाहिए जो बता सके: इस outbound call को किस run ने शुरू किया, call किस परिणाम पर पहुँची, इसे किसने approve किया और क्या यह वास्तव में execute हुई?

मैंने टीमों को एक साफ-सुथरे tool trace को अपने controls के काम करने का प्रमाण मानते देखा है। फिर कोई incident पूछता है कि production resource बदलने वाली call कौन-सी थी, और trace में सिर्फ release_service लिखा मिलता है। Friendly names operators के लिए उपयोगी हैं। ऑडिट सबूत में concrete operation चाहिए।

External action ही असली रिकॉर्ड है

Nested chain की आखिरी call अक्सर सबसे बड़ा असर डालती है, इसलिए उसका अपना स्थायी record होना चाहिए, भले ही उससे पहले की हर call का span मौजूद हो। Branch name जाँचने वाला tool शायद harmless हो। लेकिन बाद में उसी result का उपयोग करके deployment endpoint को call करने वाला helper अलग घटना है।

इन तीन चीज़ों को अलग रखें, जिन्हें टीमें अक्सर एक ही मान लेती हैं:

• Tool invocation, arguments के साथ किसी named capability को चलाने का request है।
• Trace span, काम की एक इकाई और causal graph में उसकी जगह बताता है।
• External action, trust boundary के बाहर जाने वाला concrete operation है, जैसे injected credentials के साथ HTTP request या remote host पर SSH command।

इसे गलत समझने पर दो उलटे नुकसान होते हैं। कुछ टीमें हर internal function call के लिए audit record बना देती हैं। उनका journal शोर से भर जाता है और कोई यह नहीं पहचान पाता कि वास्तव में कुछ बदलने वाली calls कौन-सी थीं। दूसरी टीमें सिर्फ अंतिम success line log करती हैं। तब वह chain खो जाती है जो बताती है कि किस agent decision, lookup और approval के कारण call हुई।

External action को स्थायी action_id दें। उसे शुरू करने वाले span से जोड़ें, लेकिन span ID को उसकी पहचान के रूप में इस्तेमाल न करें। एक span में local preparation, HTTP attempt, redirect और response parsing, सब शामिल हो सकते हैं। ये उपयोगी विवरण हैं। Action record implementation बदलने के बाद भी समझने योग्य रहना चाहिए।

Action record में resolution के बाद का destination बताना ज़रूरी है। सिर्फ environment=production या target=customer-api रिकॉर्ड करना काफी नहीं है। Resolved host, port, protocol, request method या SSH command और executor द्वारा चुना गया credential reference भी रखें। Secret references रखें, secret values कभी नहीं।

यह फर्क success का आकलन करने का तरीका भी बदलता है। Wrapper tool ok लौटा सकता है क्योंकि उसने काम queue कर दिया। Lower layer connection खुलने से पहले fail हो सकती है। Wrapper span का outcome और external action का outcome अलग-अलग रिकॉर्ड करें। ये दोनों तथ्य अलग हो सकते हैं और फिर भी दोनों records सही हो सकते हैं।

MCP आपका पूरा call graph नहीं देता

MCP clients और servers को tools खोजने और call करने का protocol देता है। यह हर implementation को internal call graph दिखाने के लिए बाध्य नहीं करता। कोई host कई servers को orchestrate कर सकता है। कोई server local helpers चला सकता है। कोई tool ऐसा job शुरू कर सकता है जो response के बाद भी चलता रहे। आपके audit design को इन सभी रूपों के लिए स्पष्ट व्यवस्था रखनी होगी।

Model Context Protocol specification में tools/call को client से server तक named tool और arguments वाला request बताया गया है। यह interface contract है, tracing contract नहीं। Protocol किसी local function call को observable child event में नहीं बदलता और न ही ऐसा universal parent field तय करता है, जिसे हर intermediary को आगे भेजना ही हो।

यह बात तब महत्वपूर्ण हो जाती है जब कोई टीम कहती है कि किसी tool ने «दूसरे MCP tool को call किया»। कभी इसका मतलब सचमुच दूसरी protocol call होता है। कभी एक server ने समान नाम वाले library function को चलाया होता है। कभी agent host ने result लिया, उस पर reasoning की और नई call की। Graph एक जैसा दिख सकता है, लेकिन trust boundaries अलग होती हैं।

अपने records में edge types को अलग रखें:

• protocol_call MCP client request को server tool invocation से जोड़ता है।
• local_call एक ही trusted process के अंदर के code को जोड़ता है।
• delegated_job request को उस काम से जोड़ता है जिसे कोई दूसरा worker बाद में करता है।
• external_action span को HTTP या SSH operation से जोड़ता है।

Edge type का अनुमान tool name से न लगाएँ। Handoff के समय उसे रिकॉर्ड करें। उसी क्षण आपको पता होता है कि identity, credentials और cancellation rules दूसरे process तक पहुँचे या नहीं।

Delayed job पर खास ध्यान दें। अगर कोई tool task queue करके लौटता है, तो originating trace ID और root run ID को job payload के साथ रखें। बाद में worker चलने पर उस worker execution के लिए नया span बनाएँ और उसे original action plan से जोड़ें। यह दिखावा न करें कि worker original request के अंदर ही रहा। उसके execution का समय, identity और authorization state बदल चुके हो सकते हैं।

हर trust boundary पर identifiers बनाएँ

Trace तभी मददगार है जब हर participant अपने काम को उसी causal chain से जोड़ सके और forged history को तथ्य न मान ले। जब request आपके नियंत्रण वाले component में आए, तब अपने identifiers बनाएँ। Upstream context को untrusted diagnostic input की तरह रखें, जब तक वह authenticated peer से न आया हो।

W3C Trace Context recommendation traceparent header को version, 32 hexadecimal character trace ID, 16 hexadecimal character parent ID और flags के साथ परिभाषित करती है। OpenTelemetry इस format का व्यापक उपयोग करता है। जहाँ HTTP या कोई दूसरा transport headers ले जा सकता है, वहाँ इसका उपयोग करें, क्योंकि मौजूदा tracing tools इसे समझते हैं। लेकिन compatibility को audit model न समझें।

MCP over stdio में शायद कोई HTTP header हो ही नहीं। Equivalent context को application envelope में रखें या call dispatch करने वाले process में context बनाए रखें। Mechanism से ज़्यादा दो बातें महत्वपूर्ण हैं: हर child operation को अपना immediate parent पता होना चाहिए और receiving component को रिकॉर्ड करना चाहिए कि context किसने दिया।

एक न्यूनतम event shape ऐसी हो सकती है:

{
  "event_id": "evt_01J8...",
  "time": "2025-03-08T14:32:11.214Z",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7",
  "parent_span_id": "b7ad6b7169203331",
  "root_run_id": "run_8d43",
  "edge_type": "external_action",
  "actor": {
    "kind": "agent_process",
    "identity": "signed-process-identity"
  },
  "action": {
    "action_id": "act_5f17",
    "channel": "http",
    "method": "POST",
    "host": "deploy.internal.example",
    "path_template": "/v1/releases/{name}",
    "credential_ref": "ops-deploy"
  },
  "outcome": {
    "state": "sent",
    "http_status": 202
  }
}

ऊपर का timestamp केवल example shape है, recommended retention format नहीं। असली system में वही clock format इस्तेमाल करें जिसे आपका log verifier लगातार parse कर सके। जब raw endpoints और arguments में tenant names, repository paths या personal data हो, तो उन्हें broad telemetry exports में न रखें। Template और अलग से सुरक्षित forensic record अक्सर dashboard में संवेदनशील सामग्री की नकल किए बिना operators को पर्याप्त context दे देते हैं।

Receiving service को केवल इसलिए parent_span_id पर भरोसा नहीं करना चाहिए कि वह agent ने भेजा है। नया local span बनाएँ, received value रिकॉर्ड करें और upstream_context_source=authenticated_mcp_client या upstream_context_source=unverified_input जैसा field जोड़ें। यह छोटा-सा फर्क किसी malicious caller को बाद में अपने action को किसी harmless run से जोड़ने से रोकता है।

केवल tool arguments नहीं, resolution भी रिकॉर्ड करें

Agent जिस action के लिए कहता है और executor जो action करता है, उनमें templates, defaults, aliases, redirects, environment lookup और credential selection के बाद अंतर आ सकता है। Records में दोनों पक्ष रखें, क्योंकि unsafe design अक्सर इसी अंतर में छिपा होता है।

मान लें agent यह call करता है:

{
  "tool": "publish_release",
  "arguments": {
    "environment": "prod",
    "release": "2025.03.08-rc2"
  }
}

Tool prod को base URL में बदल सकता है, credential चुन सकता है, release string को request path में बदल सकता है और headers जोड़ सकता है। Initial call destination का प्रमाण नहीं है। पूरी chain में यह बदलाव साफ दिखना चाहिए:

1. Agent run run_8d43 में publish_release चलाता है।
2. Tool prod को किसी खास allowed endpoint पर resolve करता है और credential reference ops-deploy चुनता है।
3. Executor request भेजने से ठीक पहले act_5f17 रिकॉर्ड करता है।
4. Executor response या transport error को उस action से जोड़कर रिकॉर्ड करता है।
5. Wrapper ऐसा result लौटाता है जिसमें act_5f17 का उल्लेख होता है, लेकिन credentials उजागर नहीं होते।

इस sequence से investigator agent के request से network operation तक पहुँच सकता है। इससे approver को भी request भेजे जाने से पहले जाँचने के लिए कोई concrete चीज़ मिलती है।

Good modeling के बदले complete authorization headers, cookies, private commands या मनमाने request bodies log न करें। दबाव में लोग ऐसा इसलिए करते हैं क्योंकि raw dump उस दिन की debugging समस्या हल कर देता है। लेकिन अगले दिन credential leak का खतरा पैदा होता है। इसके बजाय credential reference, header name, body digest, चुने हुए nonsecret fields और साफ redaction status रिकॉर्ड करें।

SSH में भी यही सावधानी चाहिए। ssh deploy लिखने वाला record बहुत अस्पष्ट है, अगर helper बाद में host alias expand करे, identity चुने और remote command बनाए। Resolved host और port, account name, identity reference, command template या command digest और exit status log करें। Command में sensitive data हो तो protected forensic copy तभी रखें, जब उसके लिए स्पष्ट कारण और retention rule हो।

Retry एक और attempt है, footnote नहीं

Retries और fan-out एक सरल tree को graph में बदल देते हैं। अगर उन्हें final success field वाले एक ही span में ठूँस देंगे, तो duplicate side effects और partial failure समझाने वाली जानकारी मिट जाएगी।

जब operation retry हो सकता हो, तो तीन IDs रखें: पूरे run के लिए trace ID, intended logical operation के लिए action ID और हर actual send के लिए attempt ID। हर attempt का अपना span हो। Action record में हर attempt का reference रखें।

मान लें tool release request भेजता है, remote service के उसे स्वीकार करने के बाद timeout हो जाता है और tool फिर कोशिश करता है। अगर remote endpoint में idempotency handling नहीं है, तो दूसरी request वही release दो बार बना सकती है। अंतिम 200 से बहुत कम जानकारी मिलती है। Log में दिखना चाहिए कि attempt one network तक पहुँचा, client पर locally timeout हुआ और attempt two को response मिला।

जहाँ destination idempotency token का समर्थन करता हो, वहाँ उसका उपयोग करें। उसे transient span ID से नहीं, logical action ID से derive करें। इससे executor restart होने या tracing library के नए spans बनाने पर भी remote service duplicate पहचान सकती है।

trace_id=4bf92f... action_id=act_5f17 attempt=1 state=timeout bytes_sent=418
trace_id=4bf92f... action_id=act_5f17 attempt=2 state=completed http_status=200

bytes_sent से पता लगाने में मदद मिलती है कि connection request भेजे जाने से पहले fail हुआ या client द्वारा data लिखे जाने के बाद timeout हुआ। लेकिन इससे यह साबित नहीं होता कि remote service ने क्या commit किया। इस uncertainty को record में साफ लिखें। पहले attempt को ऐसे failed न कहें जिससे लगे कि remote side ने कुछ किया ही नहीं।

Parallel work के लिए sibling spans बनाएँ, ऐसा shared mutable trace field नहीं जिसे workers एक-दूसरे पर लिख दें। अगर planning tool चार environment checks करता है, तो चार child spans और चार अलग results बनाएँ। अगर दो branches external actions तक पहुँचती हैं, तो दो action IDs जारी करें। Operator को एक branch को उसके sibling से भ्रमित किए बिना revoke या investigate कर पाना चाहिए।

Approval resolved operation से जुड़ा होना चाहिए

Human approval तभी उपयोगी है जब reviewer वह operation देख सके जो resolution के बाद वास्तव में होगा। deploy जैसे broad label को approve करने से व्यक्ति के पास निर्णय लेने के लिए लगभग कुछ नहीं होता, खासकर जब nested tools बाद में असली host और credential चुनते हों।

Approval input pending external action record से बनाएँ: channel, resolved destination, operation shape, credential reference, process identity और impact का संक्षिप्त विवरण। Approval decision में trace और action IDs रखें। Executor जब request भेजे, तो उसे साबित करना चाहिए कि उसने उसी approved action का उपयोग किया है, न कि केवल उसी agent run से जुड़ी कोई approval।

पूरी chain को सिर्फ इसलिए approve न करें कि उसका पहला tool harmless दिखा। Chain find_release से शुरू होकर host बदलने वाली SSH command पर खत्म हो सकती है। अगर design में बाद की resolution chain की क्षमता को बढ़ा सकती है, तो outbound boundary पर नया decision ज़रूरी करें।

इसका मतलब यह नहीं कि tool के अंदर होने वाले हर string concatenation के बारे में human से पूछना पड़े। निर्णय उस जगह होना चाहिए जहाँ कोई capability trusted execution path से बाहर जाती है। इससे लोगों को समझने योग्य prompt मिलता है और log में consent और effect के बीच स्थायी connection बनता है।

Sallyport अपने समर्थित HTTP और SSH channels के लिए यही तरीका अपनाता है: credentials अपने vault में रखता है, action खुद execute करता है और चुने गए credential के हर उपयोग के लिए approval ज़रूरी कर सकता है। उपयोगी integration point resulting external action है, agent का यह दावा नहीं कि उसके nested helper का इरादा क्या था।

Approval records में expiry और binding rules भी होने चाहिए। Decision को action ID, resolved target, credential reference और argument digest से bind करें। Prompt और execution के बीच इनमें से कुछ भी बदल जाए, तो decision discard करके फिर approval माँगें। Reusable approval token अगर agent process के साथ unrelated calls में चलता रहे, तो देर-सबेर वह ऐसी चीज़ authorize करेगा जिसे किसी ने पढ़ा ही नहीं।

Audit journal में order और verification चाहिए

Conventional application logs failure diagnose करने में मदद करते हैं, लेकिन सामान्य logs अक्सर यह नहीं बताते कि किसी ने असुविधाजनक line हटा दी या नहीं। Autonomous agents द्वारा किए गए actions के लिए event order सुरक्षित रखें और बाद में हुआ बदलाव स्पष्ट दिखना चाहिए।

Simple hash chain में हर event के canonical serialized bytes, पिछले event hash और नए event hash को रिकॉर्ड किया जाता है। Verifier पहले सुरक्षित रखे गए record से शुरू करके हर link को दोबारा बनाता है। अगर कोई attacker बीच में record बदलता, जोड़ता या हटाता है, तो प्रभावित जगह पर verification fail हो जाती है।

Canonical serialization बहुत महत्वपूर्ण है। अगर एक process JSON fields को sort करता है और दूसरा नहीं, तो समान records के hashes अलग होंगे। Field ordering, Unicode normalization, timestamp precision, absent-field handling और byte encoding तय करें। हर language में events लिखने वाले components के बीच इन rules की जाँच करें। ज़्यादातर टूटी हुई audit chains hash function में नहीं, यहीं fail होती हैं।

Verifier को ऐसे results देने चाहिए जिन पर operator कार्रवाई कर सके:

$ audit verify journal.events
records_checked: 1842
first_sequence: 91001
last_sequence: 92842
chain: valid
signature: valid

Damage मिलने पर उसे पहला गलत sequence और expected तथा observed predecessor hash बताना चाहिए। File को चुपचाप repair करने की कोशिश नहीं करनी चाहिए। Repair करने से यह सबूत नष्ट हो जाता है कि क्या गलत हुआ।

Hash chains हर threat का समाधान नहीं हैं। अगर किसी के पास signing material और storage दोनों का नियंत्रण हो, तो वह पूरी तरह alternate history लिख सकता है। Writer के सामान्य control से बाहर रखे गए periodic signed checkpoints इस जोखिम को कम करते हैं। Events लिखने और पढ़ने के access paths भी अलग रखें। अपने protection के बारे में सटीक रहें, हर log को immutable न कहें।

Action event को execution point के पास रखें। बाद में batches पाने वाला background collector outbound call होने का एकमात्र प्रमाण खो सकता है। Executor को transmission से पहले planned record append करना चाहिए और outcome मिलते ही completion record लिखना चाहिए। अगर वह दोनों के बीच crash हो जाए, तो अधूरी जोड़ी बताती है कि action शायद बाहर निकल चुकी है।

Trace को उन failures के खिलाफ test करें जो लोग वास्तव में पैदा करते हैं

Trace design तभी भरोसेमंद है जब वह malformed context, lost workers, duplicate sends और operator revocation के बाद भी सही रहे। Happy-path demos उन्हीं edges को छिपाते हैं जो agent के unexpected behavior के समय सबसे महत्वपूर्ण होते हैं।

Disposable endpoint या host के खिलाफ छोटी test suite चलाएँ। हर test में केवल tool response नहीं, audit graph पर assertion लगाएँ:

• Forged parent ID वाली nested call भेजें और पुष्टि करें कि receiver उस context को unverified बताता है।
• Request bytes client से निकलने के बाद timeout कराएँ, फिर retry करें और पुष्टि करें कि दोनों attempts का action ID एक ही है।
• Work queue करें, worker restart करें और पुष्टि करें कि resumed span original run से जुड़ता है, बिना यह दिखाए कि वह लगातार चलता रहा।
• Planning के बाद लेकिन execution से पहले authorization revoke करें और पुष्टि करें कि कोई external action record sent तक नहीं पहुँचता।
• दो sibling calls parallel में चलाएँ और पुष्टि करें कि कोई branch दूसरे का parent span या result नहीं अपनाती।

तीसरा test logs में एक आम झूठ पकड़ता है। Systems अक्सर एक uninterrupted request दिखाते हैं, जबकि worker घंटों बाद अलग process identity के साथ restart हुआ होता है। इससे असल में action करने वाला कौन था, यह छिप जाता है। New span के facts के रूप में worker identity और start time रिकॉर्ड करें।

चौथा test एक और आम failure पकड़ता है। Tool final target resolve करने से पहले authorization ले लेता है और फिर resolved call के लिए उस stale decision का उपयोग करता है। Test में approval के बाद target या credential reference बदलें और executor से उसे reject करने की अपेक्षा रखें।

Trace viewer के screenshots पर निर्भर न रहें। Raw records export करें, उनकी chain verify करें और parent IDs, action IDs, destinations, authorization bindings और outcomes पर assertions लिखें। Viewer सुविधा है। Event stream सबूत है।

पहले boundary बनाएँ, फिर graph भरें

HTTP और SSH operations करने वाले code से शुरुआत करें। उससे explicit trace context स्वीकार करवाएँ, send से पहले action record बनवाएँ, उसके बाद outcome record बनाएँ और authorization resolved operation से bind न होने पर execution रोक दें।

जब वह boundary सही काम करने लगे, तब उसके ऊपर nested tool calls को instrument करें। आपको पता रहेगा कि हर parent को कौन-सी जानकारी नीचे भेजनी है, क्योंकि executor उसे माँगेगा। उलटी दिशा में काम करने पर अक्सर सुंदर trees बनते हैं, लेकिन उनके leaf nodes भरोसेमंद नहीं होते।

Tool names, planning notes और model reasoning को external action journal से अलग रखें। ये बातें किसी run के पीछे की वजह समझने में मदद कर सकती हैं। लेकिन ये उस record की जगह नहीं ले सकतीं जिसमें लिखा हो कि किस remote system को request मिली, किस credential reference के तहत मिली, किस approval के बाद मिली और उसका result क्या रहा। जब agent का जवाब विश्वसनीय लगे लेकिन remote system कुछ और कहे, तब आपको यही chain चाहिए होगी।