Crash report के संवेदनशील डेटा को agent context leaks से बचाएं

Crash reporting किसी agent-enabled application में अनजाने में डेटा एक्सपोर्ट का सबसे बड़ा रास्ता बन सकती है। टीमें production credentials को सुरक्षित कर देती हैं, फिर exception SDK को breadcrumbs, HTTP context, process details और कॉपी किए गए tool input इकट्ठा करने देती हैं, और अंत में पूरा bundle किसी vendor account में भेज देती हैं। क्रैश local था। सबूत local नहीं रहा।

इसका समाधान crash report को छोड़ देना नहीं है। जब agent integration इस तरह fail हो कि सामान्य logs से वजह समझ न आए, तब ये reports जरूरी होती हैं। असली काम यह तय करना है कि कौन सी debugging जानकारी मशीन से बाहर जा सकती है, raw request material को डिफॉल्ट रूप से इकट्ठा होने से रोकना है और साबित करना है कि collector इन सीमाओं का पालन करता है। मैंने incident reviews को इस वजह से भटकते देखा है कि stack trace में कुछ खतरनाक नहीं था, लेकिन एक "useful" context field में पूरी failing request मौजूद थी।

Crash report केवल stack trace नहीं, evidence package है

Crash report अक्सर कई layers से मिलकर बनती है। Operating system native diagnostic report बना सकता है। आपका application exception metadata जोड़ सकता है। Crash SDK device data, breadcrumbs, session history, logs, tracing fields और user-defined tags जोड़ सकता है। Agent framework ने अपने prompt, tool input, response या retry state को इनमें से किसी field में पहले ही serialize किया हो सकता है।

यह फर्क महत्वपूर्ण है, क्योंकि developers अक्सर दिखाई देने वाले stack trace की जांच करके report को साफ मान लेते हैं। संवेदनशील सामग्री आम तौर पर उसके साथ मौजूद किसी दूसरे field में होती है।

Report इन रास्तों से डेटा उजागर कर सकती है:

• exception messages, जिनमें URL, command या response body जोड़ दी गई हो
• request logs या tool-call events से बने breadcrumbs
• ऐसे custom fields, जिनमें पूरा request object डाल दिया गया हो
• command-line arguments, temporary-file paths और environment से निकली values
• attached files, screenshots, session replay या support feedback

Native report में मौजूद memory address आम तौर पर अपने-आप API key नहीं बताता। लेकिन panic message में कॉपी की गई string ऐसा कर सकती है। इन दोनों स्थितियों को एक जैसा न मानें। Native diagnostics के लिए access controls चाहिए, जबकि application telemetry में सोच-समझकर data minimization करना जरूरी है।

Apple के diagnostic reports संबंधी documentation के अनुसार, ये application problems की जांच के लिए इस्तेमाल होने वाले records हैं, जिनमें process और thread की जानकारी हो सकती है। यह जानकारी उपयोगी है और आम तौर पर application monitoring event से सीमित होती है। लेकिन जब SDK आपकी अपनी runtime context से उस report को समृद्ध करता है, तो data boundary बदल जाती है। ऐसे enriched event को application data मानें, जो किसी दूसरे system में भेजा जा रहा है।

Agent failure बहुत समृद्ध diagnostic context बनाते हैं

एक सामान्य request handler route और status code के साथ fail हो सकता है। Agent action में user instruction, repository paths, command output, remote API के arguments, SSH destination और उस failure तक पहुंचाने वाले पिछले tool results शामिल हो सकते हैं। यह context bug को दोबारा बनाने में मदद करता है। लापरवाही से collection करने पर यही context बड़ा जोखिम बन जाता है।

जोखिम वाला रास्ता आम तौर पर एक जैसा होता है। Developer हर tool invocation को एक सुविधा देने वाले logger में लपेट देता है। Logger पूरा argument object emit करता है। Observability SDK log records को breadcrumbs में बदल देता है। Network timeout के कारण exception आती है। अब report में tool input मौजूद है, जिसमें header या चिपकाया गया token भी हो सकता है, और vendor उसे प्राप्त कर लेता है।

यही समस्या इस तरह के code में भी होती है:

try {
  await runTool(toolName, input);
} catch (error) {
  throw new Error(`Tool failed: ${toolName} input=${JSON.stringify(input)} error=${error.message}`);
}

Local test के दौरान यह message उपयोगी लगता है। Production में यह ऐसा data field बनाता है जिसकी कोई सीमा नहीं है और जिसे हर error collector, log sink और alert integration कॉपी कर सकती है। इसकी जगह stable identifiers और allowlisted summary का इस्तेमाल करें:

try {
  await runTool(toolName, input);
} catch (error) {
  throw new Error(`Tool failed: name=${toolName} request_id=${requestId} input_shape=${inputShape}`);
}

inputShape का अर्थ approved field names और sizes की सूची हो सकती है, field values कभी नहीं। अगर आप यह नहीं बता सकते कि कोई field error event में क्यों होना चाहिए, तो उसे छोड़ दें। Reproduction की शुरुआत ऐसे correlation ID से होनी चाहिए जो protected local record की ओर संकेत करे, न कि hosted dashboard में चिपकाई गई पूरी request से।

Raw request capture अच्छा default नहीं है

Raw request capture लोकप्रिय है, क्योंकि इससे पहली debugging session तेज हो जाती है। लेकिन agent actions संभालने वाली services के लिए यह default गलत है। Authorization headers, cookies, signed URLs, query parameters, request bodies और custom headers में अक्सर ऐसी सामग्री होती है जिसका crash system में कोई काम नहीं है।

एक सुरक्षित event में incident को group, triage और route करने के लिए पर्याप्त जानकारी होती है:

{
  "request_id": "rq_8c2f1a",
  "channel": "http",
  "method": "POST",
  "route": "/v1/issues/{issue_id}/comments",
  "status_class": "5xx",
  "duration_ms": 8120,
  "attempt": 2,
  "error_kind": "upstream_timeout"
}

Route में template है, वास्तविक path नहीं। Event बताता है कि request दोबारा भेजी गई, लेकिन यह नहीं बताता कि उसने क्या भेजा। Opaque ID से authorized responder जरूरत पड़ने पर local source record देख सकता है।

Secrets को hash करके redacted न मानें। Deterministic hash अब भी repeated bearer token की पहचान कर सकता है और जब original value की संभावित range छोटी हो, तब उस पर अनुमान लगाया जा सकता है। संवेदनशील values को constant marker से बदलें या उन्हें हटा दें। अगर आपको केवल यह जानना है कि credential मौजूद था या नहीं, तो auth_present: true रिकॉर्ड करें, उसका type, length, prefix या fingerprint नहीं।

URL handling की भी समीक्षा करें। कई libraries full URL अपने-आप रिकॉर्ड करती हैं। /callback?code=... जैसा route या signed download URL ऐसे field के जरिए लीक हो सकता है जिसे developer ने खुद कभी नहीं जोड़ा। Event SDK तक पहुंचने से पहले query strings हटा दें। बाद के processor से यह उम्मीद न रखें कि वह हर variation पहचान लेगा।

Redaction storage और export से पहले चलनी चाहिए

Scrubber backstop है, सब कुछ collect करने की अनुमति नहीं। SDK hooks अलग-अलग तरह से काम करते हैं। कुछ final event को process करते हैं, कुछ केवल चुने हुए fields को और कुछ native crash attachments या अलग integration से बने breadcrumbs को छूते तक नहीं। Authorization को redact करने वाला rule authorization, x-api-token, URL parameter या exception में embedded JSON string को छोड़ सकता है।

Boundary को कई layers में बनाएं। पहले वह automatic capture बंद करें जिसकी जरूरत नहीं है। फिर allowlisted fields से event बनाएं। इसके बाद बची हुई सभी strings पर defensive scrubber चलाएं। अंत में collector को मिला serialized data जांचें।

यह pseudocode उस क्रम को दिखाता है जो सबसे बड़ी समस्याओं को रोकता है:

request arrives
  -> derive route template and request ID
  -> retain protected local diagnostic record if policy permits
  -> create minimal crash context from allowlisted fields
  -> scrub all residual strings
  -> send minimized event

Original request object को "before send" callback में न भेजें। Library के उस object को inspect करने के बाद plugins उसे breadcrumbs या spans में बदल चुके हो सकते हैं। Telemetry code को ऐसा छोटा object दें जिसमें शुरू से sensitive fields हो ही न सकें।

Sentry data scrubbing और event processors का documentation देता है, जबकि Firebase Crashlytics custom keys और log collection का। इन settings को collection controls समझें, कोई सामान्य privacy guarantee नहीं। दोनों मामलों में custom context और logs वे जगहें हैं जहां application teams अक्सर अपनी default protections को खुद निष्प्रभावी कर देती हैं।

Integrations बदलने पर SDK defaults भी बदलते हैं

Crash SDK upgrade के साथ tracing, console capture, breadcrumbs, session replay, performance instrumentation या ऐसा framework integration जुड़ सकता है जो request state का अधिक हिस्सा देखता हो। जब app में केवल stack traces थे, तब की गई security review नए data path को cover नहीं करती।

हर runtime के लिए छोटा collection inventory रखें। Native crash collector, exception SDK, logging bridge, tracing package, feedback widget और support bundle mechanism दर्ज करें। हर component के लिए चार साधारण सवालों के जवाब दें: collection किससे शुरू होती है, वह अपने-आप कौन से fields collect करता है, upload से पहले data कहां store होता है और upload के बाद उसे कौन पढ़ सकता है।

Side channels को न भूलें। Developers अक्सर crash product में request bodies बंद कर देते हैं, लेकिन वही exception log aggregator को भेज देते हैं। Alerting rules exception text को chat notifications में कॉपी कर सकती हैं। Support button local log archive attach कर सकता है। Incident path के लिए एक data map चाहिए, हर vendor के लिए अलग आशावादी कहानी नहीं।

macOS पर app-level reporting और operating-system diagnostics दोनों की जांच करें। Apple crash reports local रह सकती हैं या system reporting choices के जरिए साझा की जा सकती हैं, जबकि third-party SDK अपनी configuration और network path का पालन करते हैं। Desktop app को यह फर्क उसे चलाने वाले लोगों के लिए स्पष्ट करना चाहिए। "Crash reports disabled हैं" कहना बेअर्थ है, अगर कोई अलग error-monitoring client अब भी enriched events upload कर रहा हो।

Credentials को agent process से बाहर रखें

Redaction उस समय exposure कम करती है जब code secret को संभाल चुका होता है। इससे मजबूत तरीका यह है कि agent process के पास secret हो ही नहीं। तब agent crash, copied environment और accidental debug dump में capture करने के लिए कम sensitive material उपलब्ध होगा।

इसका मतलब यह नहीं कि crash report harmless हो जाती है। Agent के पास अब भी private source, prompts या tool arguments हो सकते हैं। लेकिन जिस process को bearer token मिला ही नहीं, उससे वह token लीक नहीं हो सकता।

Sallyport HTTP APIs और SSH actions के लिए यही boundary अपनाता है: app credentials को अपने encrypted vault में रखता है, action चलाता है और credential material agent को दिए बिना result वापस agent को देता है। इससे crash telemetry की एक आम failure mode हट जाती है, लेकिन agent द्वारा संभाले जाने वाले request data और result text को फिर भी कम करना होगा।

Command arguments में भी secrets रखने से बचें। Process arguments diagnostic tools में developers की अपेक्षा से अधिक बार दिखाई देते हैं, और shell history या process inspection crash reporting से अलग भी उन्हें उजागर कर सकते हैं। Secret material को protected broker या सावधानी से managed local mechanism से पास करें, --token=... जैसे दिखाई देने वाले argument से नहीं।

Local retention के लिए भी retention rule चाहिए

कठिन failures के लिए पूरी reports को machine पर रखना उचित हो सकता है, खासकर controlled development के दौरान। यह अपने-आप सुरक्षित नहीं होता। Local spool incident के बाद भी पड़ा रह सकता है, support archive में कॉपी हो सकता है या shared user profile में रखा हो सकता है, जहां कोई दूसरा process उसे पढ़ सके।

दो records अलग रखें। Grouping और alerting के लिए minimized remote event भेजें। जरूरत होने पर अधिक विस्तृत reproduction record को short retention period और स्पष्ट deletion path के साथ protected local location में रखें। Remote event को local record की opaque ID चाहिए, उसका content नहीं।

एक उपयोगी local record में exact build identifier, sanitized configuration fingerprint, timing और action attempt का reference शामिल हो सकता है। यह ऐसा खुला text file नहीं होना चाहिए जिसमें environment variables, request bodies और terminal output जोड़ दिए गए हों। Structured local storage से exports के लिए इस्तेमाल होने वाली allowlist और deletion rules वहीं भी लागू की जा सकती हैं।

Agent action gateways के लिए audit records पर खास ध्यान दें। वे यह साबित करने में मदद करते हैं कि agent ने क्या करने की कोशिश की, लेकिन इसका अर्थ यह नहीं कि raw credentials या पूरे prompts को हर diagnostic subsystem में दोहराया जाए। Sallyport की audit trail action records को agent से अलग रखती है और उसका sp audit verify command vault key के बिना offline encrypted hash chain की जांच करता है। Verification बताता है कि trail बदली है या नहीं; कौन सा diagnostic context कहीं और जाना चाहिए, यह data minimization तय करता है।

Planted secrets से collector की जांच करें

Configuration review स्पष्ट गलतियां पकड़ लेती है। Planted-data test उन गलतियों को पकड़ता है जो वास्तव में मायने रखती हैं। इसे launch से पहले, telemetry SDK upgrade के बाद और agent framework में कोई नया tool या logging integration जुड़ने पर चलाएं।

ऐसे unique marker strings इस्तेमाल करें जिन्हें वास्तविक credentials न समझा जा सके। अलग-अलग markers उन जगहों पर रखें जिन्हें टीमें अक्सर भूल जाती हैं: authorization header, query parameter, JSON body field, agent instruction, environment variable, command argument और tool result। Controlled exception trigger करें और फिर हर destination में खोजें।

Vendor event view, उपलब्ध raw event export, local crash spool, application logs, tracing events, alert payloads, support attachments और app तथा collector के बीच मौजूद किसी भी queue की जांच करें। Exact markers और URL encoding या escaped JSON जैसी सामान्य transformations खोजें। केवल web dashboard देखना ही वह वजह है जिसके कारण teams breadcrumb या attached log में मौजूद leak नहीं देख पातीं।

Expected result लिखकर रखें। उदाहरण के लिए report में route=/v1/files/{file_id} और request_id=rq_test_01 हो सकते हैं, लेकिन उसमें MARKER_HEADER_7, MARKER_PROMPT_7 या literal query string नहीं होनी चाहिए। Failed test को security defect मानें: जिस capture path से समस्या आई उसे बंद करें, regression test जोड़ें और serialized event की फिर से जांच करें।

छोटी review से अधिकांश accidental exports पकड़े जा सकते हैं

जब कोई error handling, observability, agent tool या support diagnostics बदलता है, तब crash telemetry की review करें। Reviewer को यह पूछना चाहिए कि नया code request-shaped object को serialize कर सकता है या नहीं, केवल यह नहीं कि उसने कोई नया secret field जोड़ा है या नहीं।

Review के दौरान यह छोटी checklist इस्तेमाल करें:

• Error messages में identifiers और categories हों, serialized inputs या outputs नहीं।
• Telemetry को allowlisted context मिले, raw request या agent state object कभी नहीं।
• URLs से query strings हटाई जाएं और headers breadcrumbs या custom fields में कभी न जाएं।
• Full local diagnostics के लिए protected storage, deletion rules और मौजूद रहने का स्पष्ट कारण हो।
• Planted-marker test हर configured export destination को cover करे।

असहज सच यह है कि अच्छी debugging habits ही अक्सर leak का कारण बनती हैं। Developers context इसलिए जोड़ते हैं क्योंकि पिछली incident में वह नहीं था। ऐसा context रखें जो failure को classify करता है, जरूरत होने पर fuller evidence को local control में सुरक्षित रखें और केवल इसलिए raw material export न करें कि crash SDK में उसके लिए कोई field मौजूद है।