क्या MCP server rebuild करने से agent session reset हो जाता है?

Local MCP server का rebuild एक ही घटना नहीं होता। इससे agent को दिखने वाला tool catalog बदल सकता है, calls संभालने वाला code बदल सकता है या किसी इंसान द्वारा मंज़ूर किया गया authority scope बदल सकता है। इन सभी बदलावों को एक सामान्य «refresh» मानने पर दो गंभीर समस्याएँ आती हैं: agent पुराने schemas के साथ tools call करता है, या नया code पुराने code को दी गई permission ले लेता है।

व्यावहारिक नियम सीधा है: advertised contract बदलने पर metadata refresh करें, चल सकने वाले code में बदलाव होने पर executable identity बदलें और मंज़ूर authority बदलने पर authorization reset करें। Rebuild के बाद ये तीनों काम अक्सर साथ होते हैं, लेकिन इनके अर्थ अलग हैं। इन्हें अलग रखने वाला host बिना trust को चुपचाप बढ़ाए लंबे agent task को जारी रख सकता है।

Rebuild के तीन अलग प्रभाव होते हैं

Rebuild metadata, executable identity और authorization state को अलग-अलग बदल सकता है। अपने architecture में हर चीज़ को स्पष्ट रखें, क्योंकि tool list refresh यह साबित नहीं करता कि executable वही रहा और approval dialog agent को यह नहीं बता सकता कि उसका cached schema पुराना हो चुका है।

Tool metadata वह विवरण है जो tools/list के माध्यम से सामने आता है: tool names, descriptions, input schemas, उपलब्ध होने पर output schemas और annotations। Agent और host इसी से तय करते हैं कि call उपलब्ध है या नहीं और उसे कैसे बनाया जाए।

Executable identity अलग सवाल का जवाब देती है: अभी यह call किस code को मिलेगी? Local server के लिए इसमें compiled binary, interpreted entry file, lockfile, runtime version, container image digest या supervisor configuration शामिल हो सकते हैं। payments-dev जैसा display name identity नहीं है। /Users/dev/work/payments/dist/server.js जैसा path भी identity नहीं है।

Authorization state दर्ज करती है कि किसने किसके लिए क्या मंज़ूर किया। कोई इंसान agent process को एक run के लिए मंज़ूरी दे सकता है, हर tool call को अलग-अलग मंज़ूर कर सकता है या server connection को मंज़ूर कर सकता है। हर model का scope स्पष्ट होना चाहिए। अगर मंज़ूर subject बदल जाए, तो केवल tool name वही रहने के कारण approval को अपने-आप आगे नहीं बढ़ना चाहिए।

Teams इन सीमाओं को इसलिए मिला देते हैं क्योंकि development loop अक्सर एक ही action जैसा दिखता है:

1. Handler edit करें।
2. Build या save करें।
3. Local server restart करें।
4. Agent session जारी रखें।

यह loop एक से अधिक चीज़ें बदलता है। Handler अपना नाम या schema बदले बिना side effect जोड़ सकता है। Schema में environment field जुड़ सकती है, जबकि executable bytes अभी न बदले हों। Supervisor child process बदल सकता है, जबकि parent खुला stdio connection बनाए रखे। अगर आप इन सबको «hot reload» कहते हैं, तो host को क्या invalidate करना चाहिए, इसके लिए कोई भरोसेमंद नियम नहीं बचता।

Code और operational discussions में तीन शब्द इस्तेमाल करें: catalog revision, execution epoch और approval scope। Catalog revision बताता है कि tools अपने बारे में क्या दावा करते हैं। Execution epoch उस code की पहचान करता है जो इस समय action कर सकता है। Approval scope grant के exact subject और duration को बताता है। नाम बहुत महत्वपूर्ण नहीं हैं। Concepts को अलग रखना महत्वपूर्ण है।

Advertised contract बदलने पर metadata refresh करें

जब rebuild ऐसी कोई चीज़ बदलता है जिसे client call चुनने, जोड़ने, दिखाने या सीमित करने के लिए इस्तेमाल कर सकता है, तब tool metadata refresh करें। इसमें tool जोड़ना या हटाना तो शामिल है ही, लेकिन मौजूदा tool में बदलाव अधिक कठिन मामलों में आते हैं।

MCP Tools specification servers को यह बताने के लिए notifications/tools/list_changed देती है कि उनकी tool list बदल गई है। यह उपयोगी है, लेकिन जानबूझकर छोटा है: notification केवल बताता है कि list बदली है, यह नहीं बताता कि क्या बदला या client ने उसे पहले ही fetch किया है। इसे भेजने वाले server को उम्मीद रखनी चाहिए कि client फिर tools/list चलाएगा। Client को यह नहीं मानना चाहिए कि हर server या host तुरंत प्रतिक्रिया देगा, खासकर ऐसे client implementations में जो aggressive caching करते हैं।

इनमें से किसी field के बदलने पर refresh करें:

• Tool name जोड़ा, हटाया या बदला गया हो।
• Description इस तरह बदली हो कि intended use या side effects बदलते हों।
• Input schema बदला हो, जिसमें defaults, enum values, required fields, bounds और object shape शामिल हैं।
• Output schema बदला हो और agent अपने अगले निर्णय के लिए उस result का उपयोग करता हो।
• Annotation, title या presentation field इस तरह बदली हो कि host review प्रभावित हो।

आखिरी बिंदु में judgment चाहिए। MCP schema annotations को hints मानता है और specification clients को untrusted server से मिली annotations के आधार पर security decisions लेने से सावधान करती है। यह चेतावनी सही है। readOnlyHint host को call दिखाने में मदद कर सकता है, लेकिन write को read नहीं बना सकता। अगर local server readOnlyHint को true से false करता है, तो catalog refresh करें ताकि human view सही रहे। यह field तय न करने दें कि call को credentials मिलेंगे या नहीं।

Schema change को जितनी सावधानी चाहिए, कई teams उतनी नहीं बरततीं। मान लें tool का शुरुआती contract यह था:

{
  "name": "publish_preview",
  "inputSchema": {
    "type": "object",
    "required": ["branch"],
    "properties": {
      "branch": { "type": "string" }
    },
    "additionalProperties": false
  }
}

Developer rebuild करता है और यह optional field जोड़ता है:

"target": {
  "type": "string",
  "enum": ["preview", "production"],
  "default": "preview"
}

यह harmless लग सकता है। फिर भी agent ने पहला schema cache किया हो सकता है, host target के बिना approval card दिखा सकता है और implementation में ऐसी bug हो सकती है जो omitted value को production मानती हो। सही प्रतिक्रिया केवल extra field स्वीकार करना नहीं है। Catalog refresh करें, review surface में default को स्पष्ट दिखाएँ और running code के खिलाफ omitted argument test करें।

जब executable नहीं बदला हो और मौजूदा approval scope अब भी valid हो, तब metadata refresh पर्याप्त है। ऐसा तब हो सकता है जब server remote data से tools बनाता हो और वही code चलते हुए नई list प्रकाशित करे। Server process के बाहर host documentation ठीक करे, तब भी ऐसा हो सकता है। केवल description की typo सुधारने के लिए session restart न करें।

लेकिन metadata refresh को execution boundary का विकल्प न बनाएं। यह agent को बताता है कि server अपने बारे में क्या कहता है। यह नहीं बताता कि server वास्तव में क्या करेगा।

Executable बदलने पर नई identity चाहिए

जब नया code image, runtime configuration या dependency set calls संभाल सकता हो, तब server identity बदलें। इसमें restarted binary, reloaded JavaScript module, नया container image, बदला हुआ interpreter environment और ऐसा wrapper script शामिल है जो किसी दूसरे program को चलाता है।

सबसे आम गलती trust को command line से बाँधना है। Host कुछ ऐसा store करता है:

server = "inventory"
command = "node"
args = ["/work/inventory/server.js"]

फिर मान लेता है कि configuration बदलने तक server वही रहेगा। ऐसा नहीं है। Rebuild के बाद node process अलग server.js load कर सकता है। वह file अलग dependency tree resolve कर सकती है। File byte-for-byte एक जैसी रहे, तब भी native addon, environment variable या shell wrapper execution को किसी और जगह भेज सकता है।

इसे बेहतर बनाने के लिए perfect universal fingerprint की ज़रूरत नहीं है। Stated scope वाली identity और conservative invalidation rule चाहिए। Local development server के लिए launch time पर execution record बनाएं:

{
  "serverLabel": "inventory-local",
  "launchCommand": ["node", "/work/inventory/dist/server.js"],
  "entryDigest": "sha256:9e4c...71af",
  "lockfileDigest": "sha256:344b...0d19",
  "runtime": "node 22.14.0",
  "workingDirectory": "/work/inventory",
  "epoch": "01JQ7R4S4S0QJ7GZP1S2",
  "processId": 48192
}

Digests path को identity बनने से रोकते हैं। Runtime और working directory बताते हैं कि host ने entry point कैसे resolve किया। Epoch हर restart को अलग handle देता है, भले rebuilt artifact से वही digest निकले। Process ID operator को जाँच में मदद करता है, लेकिन identity नहीं है क्योंकि operating systems उसे दोबारा इस्तेमाल कर सकते हैं।

Compiled server के लिए build पूरा होने के बाद actual executable का hash लें। Script server के लिए कम से कम entry point और dependency lockfile का hash लें। अगर runtime उस lockfile के बाहर code load करता है, तो resolved package tree शामिल करें या packaged artifact चलाएँ। अगर shell script असली server चलाती है, तो script और child artifact दोनों का hash लें। Dispatcher को नज़रअंदाज़ करने वाली identity केवल यह साबित करती है कि गलत program नहीं बदला।

macOS पर local server शुरू करने से पहले developer यह repeatable record बना सकता है:

shasum -a 256 dist/server.js package-lock.json

आम output में हर line पर एक digest और एक path होता है:

9e4c1b2d8f3a6d...71af  dist/server.js
344bb81b6c09de...0d19  package-lock.json

Agent के काम पर लौटने के बाद digest न निकालें। इसे process launch पर capture करें, server epoch से जोड़ें और हर authorization decision के पास record करें। वरना audit trail केवल यह साबित कर पाएगा कि कोई file बाद में मौजूद थी।

Code बदलने वाला लेकिन वही tool catalog रखने वाला rebuild भी identity refresh माँगता है। मान लें get_invoice का name, schema, description और read-only annotation वही रहें। Rebuilt handler अब वही invoice लौटाने से पहले हर invoice number को बाहरी debugging endpoint पर भेजता है। Metadata नहीं बदला। Authority बदल गया।

इसका उलटा भी हो सकता है। Running server बदली हुई configuration के आधार पर अलग tenant-specific tools प्रकाशित कर सकता है, जबकि executable identity वही रहे। Metadata refresh करें, epoch बनाए रखें और देखें कि नया catalog approved scope से बाहर जाता है या नहीं।

Authorization को execution epoch के साथ बदलें

जब server execution epoch बदलता है, तब authorization invalidate करें, जब तक authorization स्पष्ट रूप से trusted publisher और defined update channel को cover न करती हो। Local rebuilt servers के लिए यह exception आम तौर पर जितना लाभ देता है उससे अधिक जटिलता लाता है।

Development को आसान रखने के लिए लोग rebuild के बाद approval जारी रखने की बात करते हैं। यह बात कुछ हद तक सही है: हर file save पर approval माँगने से control बेकार हो सकता है। समाधान approval को अमर बनाना नहीं है। उसे सही unit तक सीमित करें।

व्यावहारिक approval grant में ये fields बाँधी जा सकती हैं:

{
  "agentRun": "run_01JQ7R1",
  "serverLabel": "inventory-local",
  "executionEpoch": "01JQ7R4S4S0QJ7GZP1S2",
  "toolScope": ["inventory_lookup", "inventory_adjust"],
  "credentialScope": ["inventory-api-staging"],
  "issuedAt": "2026-07-22T14:31:08Z",
  "expiresWhen": "agent-run-ends"
}

यह grant reviewer को साफ़ बात बताता है: यह agent run इस exact server instance के माध्यम से इन tools का उपयोग इस named credential scope के साथ कर सकता है। Restarted server को नया epoch मिलता है। Host credential डालने से पहले पुराने grant को अस्वीकार करता है और call को authority चाहिए तो fresh approval माँगता है।

Grant को केवल tool names से न बाँधें। Tool names interface convention हैं। Rebuild inventory_adjust को «staging count बदलो» से «environment variable से चुने गए production endpoint को call करो» में बदल सकता है। Agent वही नाम call करता रहे, फिर भी host को देखना होगा कि उस नाम को संभालने वाला executable बदल गया है।

यही नियम agent-side wrapper पर भी लागू होता है। अगर agent ऐसा launcher इस्तेमाल करके local MCP server शुरू करता है जो खुद को rebuild या rewrite करता है, तो launcher identity record में शामिल होना चाहिए। Malicious या broken wrapper user-facing tool names वही रखते हुए calls को किसी दूसरे program की ओर भेज सकता है।

कुछ मामलों में code update के बाद approval बच सकती है, लेकिन इसके लिए local build से अधिक structure चाहिए। उदाहरण के लिए organization named publisher द्वारा signed artifacts को approve कर सकती है, deployment channel सीमित कर सकती है, verified version policy और fixed credential scope रख सकती है और permission changes के लिए अलग review process लागू कर सकती है। यह release management है। File watcher और unpinned development directory को ऐसी ही assurance देने वाला न मानें।

Per-call approval tradeoff बदलती है। अगर credential या tool को हर उपयोग पर confirmation चाहिए, तो rebuild को audit के लिए नई identity फिर भी बनानी होगी, लेकिन तत्काल action के लिए नया human decision मौजूद होगा। इससे schemas refresh करने की ज़रूरत खत्म नहीं होती। हाँ, इससे stale session approval से होने वाला नुकसान सीमित होता है।

Sallyport agent actions के लिए इससे जुड़ा तरीका अपनाता है: locked होने पर उसका vault gate actions रोकता है, per-session authorization नए connected agent process की पहचान करता है और individual credential settings हर उपयोग पर approval माँग सकती हैं। मुख्य design lesson यह है कि human decision का स्पष्ट subject और end point होना चाहिए, केवल यह अस्पष्ट भरोसा नहीं कि परिचित label अब भी सुरक्षित है।

Stdio एक pipe के पीछे process replacement छिपाता है

Stdio MCP connection rebuild behavior को खास तौर पर भ्रामक बनाता है, क्योंकि connection files का नहीं, processes का होता है। File rebuild करने से running child process में तब तक कुछ नहीं बदलता जब तक कोई उस process को replace या reload न करे।

साधारण स्थिति में MCP host child server शुरू करता है और उसके standard input तथा output pipes अपने पास रखता है। Child ने startup पर code load कर लिया। Developer फिर build चलाता है, लेकिन मौजूदा child memory में बना रहता है। Agent अब भी पुरानी implementation से बात कर रहा है, भले directory में नए artifacts आ गए हों।

इस मामले में protocol refresh की ज़रूरत नहीं है। Actual executable identity नहीं बदली। गलती यह बताना है कि rebuild लागू हो गया, जबकि हुआ नहीं। Development tooling को स्पष्ट status line दिखानी चाहिए:

build complete: dist/server.js changed
running server unchanged: pid=48192 epoch=01JQ7R4S4S0QJ7GZP1S2

कठिन स्थिति watcher वाली है। Parent stdio pipe संभालता है, files देखता है, worker को kill करता है और नया worker शुरू करता है। Parent pipe को खुला रखते हुए calls चुपचाप नए child तक पहुँचने लगती हैं। MCP client को connection बंद नहीं दिखता। Security reviewer के लिए existing session के नीचे executable identity बदल चुकी है।

इस बदलाव को अदृश्य न रहने दें। इनमें से कोई design चुनें:

1. Child restart होने पर MCP connection बंद करें, ताकि host नए instance से reconnect, initialize और authorize करे।
2. Outer connection बनाए रखें, लेकिन supervisor कोई नया call forward करने से पहले host को नया execution epoch प्रकाशित करे।
3. Development में in-process reload से बचें और host control में पूरे server process को restart करें।

पहला design सबसे स्पष्ट है। दूसरा लंबे agent context को बचा सकता है, लेकिन supervisor और host के बीच भरोसेमंद boundary चाहिए। तीसरे में कुछ seconds लगते हैं और यह समझाने में लगने वाले हफ्ते बचाता है कि session approval ने अज्ञात code को कैसे cover किया।

Server की अपनी notification पर replacement की पुष्टि के लिए निर्भर न रहें। नया code झूठ बोल सकता है और compromised server के पास वही identity घोषित करने का कारण होगा। Process manager, host या credential gateway को launch देखना चाहिए और epoch बनाना चाहिए। अगर ये layers restart नहीं देख सकतीं, तो वे rebuild और stable server में सुरक्षित अंतर नहीं कर सकतीं।

Tool-list notifications संकेत हैं, handoff नहीं

notifications/tools/list_changed catalog fetch का संकेत देना चाहिए, लेकिन यह session restart नहीं करता, capabilities renegotiate नहीं करता और authorization decision साथ नहीं लाता। अपना control flow उसी बात पर आधारित करें जो notification वास्तव में कहता है।

MCP Lifecycle specification initialization को वह phase बताती है जहाँ client और server protocol version तथा capabilities पर सहमत होते हैं। उसके बाद normal operation शुरू होता है। tools.listChanged advertise करने वाला server कहता है कि वह client को tool list बदलने की सूचना दे सकता है। वह यह नहीं कहता कि server बिना परिणामों के session के बीच अपनी identity बदल सकता है और न ही host को notification को security attestation मानना पड़ता है।

Reload path बनाते समय यह अंतर महत्वपूर्ण है। कमजोर implementation ऐसा करती है:

watcher rebuilds server
server sends tools/list_changed
client fetches tools/list
agent continues

Demo में यह सफल है। लेकिन चार operational सवाल अनुत्तरित रहते हैं:

• क्या existing process ने rebuilt code load किया?
• क्या किसी अलग process ने connection संभाल लिया?
• क्या नए code के पास वही approved authority है?
• क्या host ने पुराने schema से तैयार किए गए call को discard किया?

बेहतर path अलग layers को अलग जिम्मेदारियाँ देती है। Build system artifacts report करता है। Supervisor process replacement report करता है। MCP server catalog changes report करता है। Host agent-visible metadata refresh करता है। Authorization layer execution epoch की तुलना grant से करती है। Audit log हर transition record करता है।

अगर host को list-change notification मिले और बाद में epoch change का पता चले, तो पहले epoch change process करें। Cached tool catalog को suspect mark करें, current catalog और authorization decision मिलने तक credentialed calls रोकें, फिर आगे बढ़ें। Agent अपनी conversation history रख सकता है। लेकिन वह यह नहीं मान सकता कि rebuild से पहले तैयार किया गया tool invocation अब भी valid है।

यही सावधानी capability changes पर भी लागू होती है। अगर rebuild resources, prompts, logging behavior या experimental extension जोड़ता है, तो पुराने initialized session ने शायद इन features को negotiate नहीं किया हो। Connection को बीच में mutate करने के बजाय reconnect करें। Long-lived sessions सुविधाजनक हैं, लेकिन रात के दो बजे कुछ गलत होने पर connection contract समझ में आना चाहिए।

Hot reload जोड़ने से पहले refresh contract लिखें

Refresh contract में यह स्पष्ट होना चाहिए कि rebuild का पता कौन लगाता है, इससे कौन-सी state बदलती है, कौन-सी calls रुकती हैं और audit log में कौन-सा evidence जाता है। अगर यह लिखा नहीं है, तो हर component locally reasonable decision लेगा और संयुक्त behavior unsafe हो सकता है।

एक छोटी state machine इस्तेमाल करें। Policy language या नियमों की भूलभुलैया की ज़रूरत नहीं है।

ready(epoch A, catalog 12, approval A)
  build artifact changes
ready(epoch A, catalog 12, approval A)
  worker restarts
identity-pending(epoch B, catalog unknown, approval A invalid)
  host fetches tools/list
catalog-ready(epoch B, catalog 13, approval A invalid)
  reviewer approves required scope
ready(epoch B, catalog 13, approval B)

महत्वपूर्ण transition identity-pending है। इस state में host केवल इसलिए credentialed call forward नहीं कर सकता कि agent ने उसे पहले से तैयार कर लिया था। अगर harmless की स्पष्ट परिभाषा है तो harmless discovery requests की अनुमति दी जा सकती है, लेकिन अनुमान न लगाएँ। अधिकांश local servers के लिए catalog और grant current होने तक सभी tool calls रोकना आसान है।

आपके contract में ये निर्णय सरल भाषा में होने चाहिए:

• Execution epoch बनाने वाला component।
• Executable identity में शामिल artifacts और runtime facts।
• वे metadata changes जिन पर tools/list फिर चलाना होगा।
• Epoch बदलने पर समाप्त होने वाले authorization scopes।
• Restart के दौरान in-flight call का behavior।

In-flight calls के लिए पक्का नियम रखें। अगर worker tool call प्राप्त करने के बाद response देने से पहले बंद हो जाए, तो epoch transition बताने वाली error लौटाएँ। नए process के खिलाफ write को अपने-आप retry न करें। Retry से payment दो बार हो सकती है, publish दो बार हो सकता है या arguments का अर्थ बदलने के बाद कोई change लागू हो सकता है।

Read-only calls के लिए automatic retry स्वीकार्य हो सकती है, अगर host साबित कर सके कि पहली कोशिश action boundary तक पहुँची ही नहीं। Local subprocesses और remote APIs के बीच यह साबित करना कठिन है। Timeout इसका प्रमाण नहीं है। Empty response भी प्रमाण नहीं है। पहले explicit failure से शुरू करें, फिर जहाँ idempotency साबित कर सकें वहीं safe retries जोड़ें।

Rebuild को authority changes की तरह test करें

Rebuild test को केवल «नया tool दिखाई देता है» से अधिक साबित करना चाहिए। उसे साबित करना चाहिए कि stale metadata dangerous call नहीं बना सकता, पुरानी authorization नए code तक नहीं पहुँच सकती और audit trail दोनों execution epochs में अंतर कर सकता है।

ऐसे local fixture में test चलाएँ जिसमें एक credentialed write tool और एक harmless read tool वाला server हो।

1. Server revision A शुरू करें। उसका execution record capture करें, tools/list fetch करें और एक agent run को write tool के लिए authorize करें।
2. Write tool को revision=A जैसे marker के साथ एक बार call करें। Confirm करें कि log epoch A और epoch A का approval grant दर्ज करता है।
3. Revision B rebuild करें। Tool name वही रखें, लेकिन required schema field जोड़ें या handler बदलकर revision=B लिखवाएँ।
4. सामान्य development में इस्तेमाल होने वाले mechanism से running worker replace करें।
5. Metadata refresh और approval से पहले पुरानी prepared call चलाने की कोशिश करें। Host को epoch बदलने के कारण उसे रोकना चाहिए।
6. नया catalog fetch करें, call को authority चाहिए तो नया approval लें और फिर call करें। Confirm करें कि log epoch B और नया grant दर्ज करता है।

Expected denial debugging के लिए पर्याप्त स्पष्ट होनी चाहिए:

{
  "error": "authorization_stale",
  "reason": "server execution epoch changed",
  "approvedEpoch": "01JQ7R4S4S0QJ7GZP1S2",
  "currentEpoch": "01JQ7R9KQ6K2Y8W4JH0M",
  "retry": "refresh tool metadata and request authorization"
}

इसे generic «tool unavailable» message के पीछे न छिपाएँ। Agent को पता होना चाहिए कि catalog refresh करना है, server restart का इंतज़ार करना है या इंसान से पूछना है। Operator को पता होना चाहिए कि watcher ने worker को अनपेक्षित रूप से बदला या नहीं।

वे failure tests भी जोड़ें जिन्हें developers अक्सर छोड़ देते हैं:

• Build सफल हो, लेकिन पुराना process चलता रहे।
• Process restart हो, लेकिन tool list वही रहे।
• Schema बदले, लेकिन client tools/list_changed को ignore करे।
• Write call response की प्रतीक्षा में हो और उसी समय restart हो।
• Server path वही रहे, लेकिन resolved dependency tree बदल जाए।

ये tests दिखाएँगे कि आपका design friendly server के सच बोलने पर निर्भर है या नहीं। ऐसा नहीं होना चाहिए। Local development code में accidental trust expansion सबसे अधिक होता है, क्योंकि developers लगातार rebuild करते हैं और assumptions अदृश्य हो जाती हैं।

Audit records को बताना चाहिए कि कौन-सा code चला

Audit record से यह पता चलना चाहिए कि call किस executable epoch ने संभाली, वरना rebuild से जुड़े incident को सुलझाया नहीं जा सकेगा। Tool name, arguments और timestamp उपयोगी हैं, लेकिन सबसे कठिन सवाल फिर भी बचा रहता है।

हर tool call पर execution epoch record करें। Host agent को tool information दिखाए समय catalog revision या metadata digest record करें। Approval decisions को उस subject के साथ record करें जिसे वे cover करते हैं। अगर call credential boundary पार करती है, तो secret record किए बिना credential scope name दर्ज करें।

एक compact event sequence ऐसा हो सकता है:

{"type":"server_started","epoch":"01JQ7R4...","entryDigest":"sha256:9e4c...71af"}
{"type":"approval_granted","run":"run_01JQ7R1","epoch":"01JQ7R4...","scope":"inventory-api-staging"}
{"type":"tool_called","run":"run_01JQ7R1","epoch":"01JQ7R4...","tool":"inventory_adjust"}
{"type":"server_replaced","oldEpoch":"01JQ7R4...","newEpoch":"01JQ7R9..."}
{"type":"authorization_denied","run":"run_01JQ7R1","epoch":"01JQ7R9...","reason":"stale_epoch"}

यह structure सामान्य debugging में भी मदद करता है। जब कोई बताए कि rebuild के बाद agent ने पुराना schema इस्तेमाल किया, तो आप देख सकते हैं कि host metadata refresh करना भूल गया, server restart ही नहीं हुआ या supervisor ने बिना घोषणा के code बदल दिया। ये अलग defects हैं और इन्हें एक ही bug category में नहीं रखना चाहिए।

Sallyport के Sessions journal और Activity journal agent-run records को individual action records से अलग रखने के अच्छे उदाहरण हैं, जबकि दोनों को एक encrypted, hash-chained audit log से project किया जाता है। यही separation यहाँ भी लागू होती है: एक record बताता है कि किसे run करने की मंज़ूरी थी और दूसरा बताता है कि कौन-सी call किस execution epoch के तहत हुई।

Audit system को server की self-reported identity पर निर्भर न बनाएं। Identity capture को process launch या credential dispatch के पास रखें। जहाँ environment support करे, वहाँ audit chain की स्वतंत्र जाँच करें। जो server session के दौरान code बदल सकता है, उसे इस बात का अकेला गवाह नहीं बनना चाहिए कि कौन-सा code चला।

Rebuild speed inherited trust का कारण नहीं है

Fast rebuild development सुविधा है। इससे नया code पहले review किए गए code में नहीं बदल जाता। अगर local MCP server credentials, files या remote systems तक पहुँच सकता है, तो rebuild को approved code और अगले action करने वाले code के बीच स्पष्ट boundary बनानी चाहिए।

सबसे पहले process replacement को दिखाई देने योग्य बनाएं। Launch पर epoch जोड़ें। Session authorization को उस epoch से बाँधें। Contract बदलने पर tool metadata refresh करें। फिर एक test जानबूझकर fail कराएँ: active agent session के दौरान server rebuild करें और confirm करें कि अगली credentialed call तब तक रुकती है जब तक host के पास current metadata और current grant न हो।

अगर test सही कारण से pass होता है, तो आपका agent rebuild के बाद काम जारी रख सकता है, बिना उस permission के जो किसी पुराने executable को दी गई थी।