API क्लाइंट क्रेडेंशियल वॉल्ट है: इसका ऑडिट कीजिए

एक डेवलपर अपने Mac पर HTTP क्लाइंट खोलता है। बस इतना ही। कोई क्लिक नहीं, कोई कन्फर्मेशन डायलॉग नहीं, “enable AI features” वाला कोई चेकबॉक्स नहीं। अगले दिन उसका कोडिंग एजेंट एक ऐसे रिमोट MCP सर्वर से ऑथेंटिकेट नहीं कर पा रहा, जिसे उसने कभी कॉन्फ़िगर ही नहीं किया था। API का काम ऐसे skills के ज़रिए रूट हो रहा है जो उसने कभी इंस्टॉल नहीं किए, और एक ऐसा क्रिप्टोग्राफ़िकली ट्रस्टेड स्टार्टअप हुक चल रहा है जिसे उसने कभी approve नहीं किया। यह कोई काल्पनिक बात नहीं है। एक हालिया, बहुत बारीकी से दर्ज किए गए बग रिपोर्ट के सबूत दिखाते हैं कि Postman का डेस्कटॉप ऐप यही कर रहा था: Codex और Claude Code में अपने-आप प्लगइन इंस्टॉल करना, ग्लोबल एजेंट कॉन्फ़िग में लिखना, और अपने ही session hook को trusted मार्क करने की कोशिश करना। अगर आप API क्लाइंट सिक्योरिटी की परवाह करते हैं, तो यही वह घटना है जो आपके मशीन पर मौजूद हर डेस्कटॉप डेव टूल के साथ व्यवहार का तरीका बदल देनी चाहिए।

Postman डेस्कटॉप ऐप ने असल में क्या किया

ज़्यादा गुस्से को किनारे रखकर फ़ोरेंसिक सबूतों को देखिए, क्योंकि रिपोर्ट लिखने वाले ने वह काम किया है जो हममें से ज़्यादातर लोग नहीं करते। Postman की अपनी लॉग फ़ाइल में auto-existing-upgrade इवेंट दर्ज है: पहले से साइन-इन किए हुए डेस्कटॉप इंस्टॉलेशन पर एक स्क्रिप्ट चली और उसने claude-code:installed,codex:installed रिपोर्ट किया। कोई प्रॉम्प्ट नहीं आया। यूज़र के ग्लोबल Codex कॉन्फ़िगरेशन में एक नया marketplace जुड़ गया, जो Postman के git repo की ओर इशारा करता है, साथ में एक enabled प्लगइन और hook trust रिकॉर्ड। Claude Code की सेटिंग्स में भी एक enabled प्लगइन और इंस्टॉल रिकॉर्ड जुड़े, जिनके टाइमस्टैम्प उसी समय-सीमा से मेल खाते हैं। ~/.local/bin में एक Postman CLI बाइनरी प्रकट हुई। और एक रिमोट MCP कनेक्शन Postman के सर्वरों की ओर मोड़ दिया गया, जो फिर ऑथेंटिकेशन में फ़ेल होकर लगातार एरर भेजने लगा। यूज़र को बस इसी वजह से इन सब बातों का पता चला।

दो बातें दो बार पढ़ने लायक हैं। पहली, इंस्टॉल हुआ session-start hook एजेंट को निर्देश देता है कि किसी भी गैर-सामान्य API इंजीनियरिंग काम से पहले (डिज़ाइन, टेस्टिंग, mocking, डॉक्यूमेंटेशन या deploy) उसे Postman का skill लोड करना चाहिए। यह माँगे जाने पर होने वाला इंटीग्रेशन नहीं है; यह एक ऐप का दूसरे वेंडर के ऐप के डिफ़ॉल्ट व्यवहार को फिर से लिख देना है। दूसरी, इंस्टॉलर के सोर्स कोड में ऐसा कोड है जो hook का hash लाकर उसे एजेंट की trusted-hook स्थिति में upsert करता है। Trust मैकेनिज़्म इसलिए बना है ताकि यूज़र hooks को approve करे। इंस्टॉलर का खुद अपने hook को approve करना वैसा ही है जैसे आप खुद अपनी ही permission slip पर साइन कर दें।

रिपोर्ट लिखने वाले ने सावधानी बरती थी। उन्होंने साफ़ लिखा है कि अकेला trust रिकॉर्ड यह साबित नहीं करता कि उसे किसने बनाया, और उन्होंने कोई डेटा चोरी होने का दावा नहीं किया। यह संयम रिपोर्ट को कम नहीं, ज़्यादा भरोसेमंद बनाता है। जो बात साबित होती है वह काफ़ी है: असंबंधित टूल्स में चुपचाप बदलाव, एजेंट के session startup में एक व्यापक व्यवहार-निर्देश का इंजेक्शन, और यूज़र की consent वाले कंट्रोल को बायपास करने की कोशिश। मैंने जितनी भी सिक्योरिटी रिव्यू किए हैं, उनमें यह संयोजन होने पर जाँच पूरी होने तक प्रोडक्ट को फ़्लीट से हटा दिया गया है।

आपका API क्लाइंट क्रेडेंशियल वॉल्ट क्यों है

यही वह हिस्सा है जिसे टीमें लगातार कम आँकती हैं। API क्लाइंट सिर्फ़ एक टेक्स्ट एडिटर जैसा नहीं है जिसमें send का बटन हो। आपके bearer tokens, session cookies, mTLS client certificates, OAuth client secrets और साइन किए गए request headers यहीं रहते हैं। डेटाबेस URLs और third-party keys वाले environment variables भी इसमें पेस्ट होते हैं। अगर आप {{api_secret}} जैसा टेम्पलेटिंग सिंटैक्स इस्तेमाल करते हैं, तो हर request पर resolved value ऐप से होकर गुज़रती है, और वेंडर के टेलीमेट्री डिज़ाइन के आधार पर शायद उनकी logging pipeline से भी। HIPAA compliance की जाँच कर रहे एक प्रैक्टिशनर ने बिल्कुल यही पाया: outbound logging ट्रैफ़िक में resolved secret values थीं, और वह endpoint ब्लॉक करने पर ऐप ख़राब व्यवहार करने लगा। मैं हर विवरण की स्वतंत्र पुष्टि नहीं कर सकता, लेकिन यह उस आर्किटेक्चर पैटर्न से मेल खाता है जो मैंने दूसरे “मददगार” डेस्कटॉप टूल्स में देखा है: पूरी तरह विस्तृत request logging को एक फ़ीचर बनाकर भेजना।

अब एजेंट वाला पहलू जोड़िए। जब कोई टूल आपके कोडिंग एजेंट में प्लगइन इंस्टॉल करता है और session hook रजिस्टर करता है, तो वह अपने निर्देश उस प्रोसेस के context में डाल देता है जो आपका codebase पढ़ सकता है, shell commands चला सकता है, और अपने credentials भी रख सकता है। अब ख़तरा सिर्फ़ “मेरे API collections लीक हो सकते हैं” तक सीमित नहीं है। अब मतलब है “मेरे एजेंट के environment में पहुँच योग्य हर secret एक ख़राब prompt या एक compromised skill की दूरी पर है, और वह गलत endpoint तक पहुँच सकती है।” हम पहले लिख चुके हैं कि बैकग्राउंड daemons इंस्टॉल करने वाले CLI टूल्स चुपचाप अपना attack surface कैसे बढ़ाते हैं; यह वही पैटर्न है, बस ज़्यादा चालाक payload के साथ। ps में दिखने वाला daemon तो लगभग शिष्ट लगता है, उस instruction hook के मुकाबले जो किसी दूसरे वेंडर के trust store में बैठा हो।

अगर आप ख़तरे के मॉडल को ईमानदारी से देखें, तो नतीजा असहज है: डेस्कटॉप API क्लाइंट secrets, नेटवर्क एक्सेस, और तेज़ी से बढ़ते agent control planes के संगम पर बैठा है। इसे उतनी ही जाँच मिलनी चाहिए जितनी आप password manager या CI runner को देते हैं। लगभग कोई इसे वह जाँच नहीं देता। यही वह कमी है जिसका इस घटना ने फ़ायदा उठाया, और इसीलिए जवाब सिर्फ़ भावनात्मक नहीं, प्रक्रियागत होना चाहिए।

वेंडर के opt-outs और सेटिंग टॉगल क्यों फ़ेल होते हैं

ऐसी घटना के बाद पहली प्रतिक्रिया अक्सर ऐप की प्राथमिकताओं में telemetry टॉगल ढूँढने, उसे बंद करने और आगे बढ़ जाने की होती है। मैंने पूरी टीमों को यही करते और इसे remediation कहते देखा है। यह तीन कारणों से दिखावा है।

• Consent को version के हिसाब से सीमित किया जा सकता है। Postman का इंस्टॉल एक पहले से साइन-इन किए हुए अकाउंट पर feature flag से शुरू हुआ था। आज मौजूद टॉगल यह नहीं बताता कि कल कौन से flags आएँगे, और auto-updaters की वजह से “कल” बिना पूछे आ जाता है।
• टॉगल वही नियंत्रित करते हैं जो दस्तावेज़ित है, वह नहीं जो संभव है। किसी प्राइवेसी सेटिंग का नियंत्रण सिर्फ़ उन code paths पर होता है जिन्हें वेंडर ने दिखाने के लिए चुना है। प्लगइन इंस्टॉलर कोई दस्तावेज़ित प्राथमिकता नहीं थी, बल्कि एक scripted upgrade path था। जो स्विच आपको दिखता ही नहीं, उससे आप opt out नहीं कर सकते।
• ट्रस्ट के फ़ैसले ऐप के बाहर होते हैं। Hook को approve करने की कोशिश Codex की कॉन्फ़िगरेशन के अंदर हुई, Postman के अंदर नहीं। सोर्स ऐप का सबसे अच्छा व्यवहार करने वाला सेटिंग पैनल भी इसे सामने नहीं ला पाता।

गहरी समस्या संरचनात्मक है: opt-outs सतर्कता का बोझ उस पक्ष पर डालते हैं जिसके पास सबसे कम जानकारी है। वेंडर जानता है कि उसका updater क्या कर सकता है; आप नहीं जानते। वेंडर जानता है कि ऐप किन endpoints पर “घर फ़ोन” करता है; आप अंदाज़ा लगा रहे होते हैं। ऐसा कोई भी कंट्रोल जिसमें कम जानकारी वाले पक्ष को लगातार ज़्यादा जानकारी वाले पक्ष से आगे निकलने की रिसर्च करनी पड़े, अंततः फ़ेल होगा। यही कारण है कि IDE प्लगइन marketplaces की ट्रस्ट समस्याएँ लोगों को बार-बार परेशान करती हैं: जिस सिक्योरिटी बाउंड्री को आप सँभाल रहे हैं, असल में उसे पार ही नहीं किया जा रहा होता।

वेंडर पर भरोसा बेकार नहीं है, बस वह कंट्रोल नहीं हो सकता। यह तय करने में एक कारक है कि क्या इंस्टॉल करना है, इंस्टॉल किए गए सॉफ़्टवेयर को ईमानदार रखने का तरीका नहीं। एक बार यह बात समझ आ जाए, तो ऑडिट की रणनीति अपने-आप बन जाती है: व्यवहार को बाहर से, लगातार, ऐसे टूल्स से जाँचिए जिन्हें वेंडर नियंत्रित नहीं करता।

एक-बार की सिक्योरिटी ऑडिट भी फ़ेल होती हैं

दूसरी असफल कोशिश ज़्यादा सम्मानजनक दिखती है: किसी एक समय-बिंदु पर ऑडिट। सिक्योरिटी टीम टूल की समीक्षा करती है, उसकी network calls जाँचती है, privacy policy पढ़ती है, मंज़ूरी देती है और रिपोर्ट फ़ाइल कर देती है। काम पूरा। जब तक auto-updater न चले। आज डेस्कटॉप डेव टूल्स साप्ताहिक या रोज़ाना रिलीज़ होते हैं, और feature flags की वजह से एक ही version नंबर वाले दो यूज़र काफ़ी अलग कोड चला सकते हैं। इस घटना का व्यवहार server-side flag और “मौजूदा यूज़र” की शर्त के पीछे छिपा था। मतलब आपकी सिक्योरिटी टीम का clean-room इंस्टॉल बेदाग दिख सकता है, जबकि आपके पुराने यूज़र्स को प्लगइन मिल रहा होता है।

मैं खुद इसी कमी से जल चुका हूँ। कुछ साल पहले मैंने एक sync क्लाइंट को विस्तृत समीक्षा के बाद मंज़ूरी दी थी: traffic capture साफ़ था, permissions ठीक थे, कोई persistence mechanism नहीं था। छह महीने बाद एक अपडेट ने LaunchAgent और एक socket listener जोड़ दिया। यह बात हमें सिर्फ़ इसलिए पता चली क्योंकि एक अस्थिर VPN वाले लैपटॉप के firewall log में अजीब connection retries लगातार दिख रहे थे। किसी ने भी कुछ दोबारा रिव्यू नहीं किया था, क्योंकि किसी की प्रक्रिया ने ऐसा करने को कहा ही नहीं था। मंज़ूरी एक snapshot थी; सॉफ़्टवेयर एक फ़िल्म था।

तो दोनों सस्ते उपाय फ़ेल होते हैं: वेंडर की सेटिंग्स पर भरोसा इसलिए फ़ेल होता है क्योंकि दिलचस्प व्यवहार सेटिंग्स में होता ही नहीं, और एक-बार के ऑडिट इसलिए फ़ेल होते हैं क्योंकि दिलचस्प व्यवहार ऑडिट के बाद आता है। जो काम करता है वह है अपनी मशीन की स्थिति को सच्चाई का स्रोत मानना और उसके बदलने पर नज़र रखना। यह procurement रिव्यू जितना आकर्षक नहीं है, लेकिन यह इरादों की नहीं, वास्तविकता की पकड़ करता है।

डेस्कटॉप डेवलपर टूल्स का असली ऑडिट कैसे करें

काम करने वाले तरीके के तीन हिस्से हैं: ज़रूरी स्थिति का snapshot लें, wire पर नज़र रखें, और जो पूरी तरह जाँचा नहीं जा सकता उसे कंटेन करें। इनमें से किसी के लिए भी एंटरप्राइज़ टूलिंग की ज़रूरत नहीं। ज़रूरत है अनुशासन और लगभग एक घंटे के सेटअप की।

Config snapshots से चुपचाप प्लगइन इंस्टॉल पकड़ें

आपकी मशीन पर हर coding agent और डेव टूल के पास कुछ फ़ाइलें होती हैं जो उसका व्यवहार तय करती हैं: ~/.codex/config.toml, ~/.claude/settings.json और plugins डायरेक्टरी, MCP configs, shell rc फ़ाइलें, ~/Library/LaunchAgents, ~/.local/bin। ये फ़ाइलें ही consent की सीमा हैं। जो भी इन्हें बिना पूछे बदलता है, वही वह चीज़ है जिसे आप पकड़ना चाहते हैं। इसलिए इनका रोज़ hash लीजिए और diff कीजिए:

#!/usr/bin/env bash
# snapshot-agent-configs.sh — hash every file your agents and shells read,
# then diff against yesterday. Run from cron or launchd.
set -euo pipefail
SNAP_DIR="$HOME/.config-audit"
mkdir -p "$SNAP_DIR"
TODAY="$SNAP_DIR/$(date +%F).txt"
find \
"$HOME/.codex" \
"$HOME/.claude" \
"$HOME/.config" \
"$HOME/.local/bin" \
"$HOME/Library/LaunchAgents" \
-type f 2>/dev/null \
| sort \
| xargs shasum -a 256 > "$TODAY"
PREV=$(ls -t "$SNAP_DIR"/*.txt 2>/dev/null | sed -n '2p' || true)
if [ -n "${PREV:-}" ]; then
if ! diff -u "$PREV" "$TODAY" > "$SNAP_DIR/latest.diff"; then
echo "config drift detected — see $SNAP_DIR/latest.diff" \
| mail -s "agent config drift" you@example.com || \
cat "$SNAP_DIR/latest.diff"
fi
fi

यह तरीका कच्चा है और यह ठीक है। अगर यह रिपोर्ट लिखने वाले की मशीन पर चल रहा होता, तो अगली सुबह Codex config.toml का बदलाव, नए Claude plugin रिकॉर्ड और ~/.local/bin की CLI बाइनरी, तीनों एक ही diff में दिख जाते। Signal-to-noise अनुपात बहुत अच्छा है, क्योंकि ये डायरेक्टरी वैसे भी शांत रहती हैं। आपके अपने बदलाव ही वैध बदलाव होते हैं, और आपको पता होता है कि वे कब किए गए। इसके साथ उसी snapshot में launchctl list | grep -v com.apple का आउटपुट भी जोड़ दें, तो persistence mechanisms भी उसी दिन पकड़ में आ जाएँगे जिस दिन वे प्रकट होंगे।

सिर्फ़ फ़ाइलें नहीं, Network egress पर भी नज़र रखें

File integrity बताती है कि डिस्क पर क्या बदला; यह नहीं बताती कि इमारत से बाहर क्या गया। Egress के लिए आपको हर ऐप की अलग दृश्यता चाहिए। macOS पर Little Snitch या ओपन-सोर्स LuLu firewall दोनों प्रति-प्रोसेस नए outbound connections पर अलर्ट करते हैं। पहली बार जब Postman का updater या कोई नई CLI बाइनरी किसी अनजान होस्ट तक पहुँचेगी, तो आपको एक प्रॉम्प्ट मिलेगा, न कि हो चुका काम। Linux पर opensnitch यही काम करता है। अगर आप बस यह देखना चाहते हैं कि कोई बातूनी ऐप अभी क्या कर रहा है, तो यह मैन्युअल जाँच है:

# Every established outbound connection, grouped by process
sudo lsof -iTCP -sTCP:ESTABLISHED -P -n | awk '{print $1, $9}' | sort | uniq -c | sort -rn
# Watch one vendor's traffic live (find the process name first)
sudo tcpdump -i any -n host mcp.postman.com

इन दो चीज़ों पर ध्यान दीजिए: ऐसे destinations जिनका टूल के घोषित काम से कोई संबंध न हो, और ऐसे connections जो ऐप के निष्क्रिय होने पर भी बने रहें। HTTP क्लाइंट को तब शांत रहना चाहिए जब आप send पर क्लिक न कर रहे हों। Telemetry endpoints अपने-आप में दोषी नहीं होते, लेकिन जैसा पहले वाली HIPAA जाँच की कहानी दिखाती है, असली बात payload की है। अगर आपका क्लाइंट {{secrets}} को क्लाइंट-साइड पर resolve करता है और सर्वर-साइड पर पूरा request detail लॉग करता है, तो “anonymous usage data” वाकई anonymous नहीं है। यह जानने का एक ही तरीका है: capture करके पढ़ना, आदर्श रूप से ऐसे session में जहाँ आपने जानबूझकर एक canary token, यानी एक अनोखा नकली credential, environment variable में डाला हो और देखा हो कि वह कहीं ऐसी जगह तो नहीं जा रहा जहाँ उसे नहीं जाना चाहिए। Canary tokens “हमें लगता है कि शायद” को “हमें पता है कि हुआ” में बदल देते हैं।

जिस पर पूरा भरोसा नहीं, उसे कंटेन करें

आखिरी हिस्सा मानता है कि आप सब कुछ नहीं पकड़ पाएँगे। इसलिए ब्लास्ट रेडियस सीमित कीजिए। Credential-भारी टूल्स को एक अलग OS user account या हल्की VM में चलाइए, ताकि उनकी फ़ाइल-सिस्टम पहुँच sandbox की सीमा पर रुक जाए। macOS और Linux दोनों पर दूसरा user बनाना सस्ता है, और Linux पर firejail जैसे टूल प्रति-ऐप पूरे directory trees को रोक सकते हैं। असली production secrets को डेस्कटॉप टूल्स से पूरी तरह बाहर रखिए: short-lived tokens, scoped service accounts और ऐसी request signing का उपयोग कीजिए जो खुद एक्सपायर हो जाए। अगर कोई टूल काम करने के लिए लंबे समय वाला production credential माँगता है, तो यही माँग अपने-आप में एक finding है। हम पहले भी लिख चुके हैं कि जब चूक की कीमत बहुत ज़्यादा हो, तब containment monitoring से बेहतर है। एजेंट्स के लिए और उन्हें कॉन्फ़िगर करने वाले टूल्स के लिए, containment वह परत है जो उस दिन भी काम करती है जब आपकी monitoring में कोई blind spot होता है।

टूलिंग घटनाओं के लिए रोलबैक प्लेबुक

जब आप कुछ पकड़ लें, तो आपत्तिजनक ऐप को हटाना लगभग छह चरणों में पहला कदम है। Postman रिपोर्ट लिखने वाले की removal checklist सही आकार की है, और ज़रूरत पड़ने से पहले इसे अपनाना उपयोगी है:

1. पहले सबूत सुरक्षित करें। अनइंस्टॉल करने से पहले logs, configs और version नंबर किसी सुरक्षित जगह कॉपी करें। Postman की अपनी main.log यहाँ सबसे बड़ा सबूत थी, और uninstall scripts को उसे मिटाना बहुत पसंद है।
2. ऐप और उसके helpers हटाएँ। ऐप bundle के साथ वह सब भी जो उसने ~/.local/bin, Application Support और caches में डाला हो।
3. Agent configs साफ़ करें। हर agent host से marketplace entries, enabled-plugin stanzas, MCP server definitions और cached plugin directories हटाइए, सिर्फ़ सबसे स्पष्ट वाले host से नहीं।
4. Trust रिकॉर्ड रद्द करें। उन hooks के trusted_hash entries हटाइए जिन्हें आपने approve नहीं किया था। फिर उसी फ़ाइल के बाकी hooks भी जाँचिए, अगर एक चोरी से घुसाया गया था तो बाकी भी जाँचने लायक हैं।
5. Persistence जाँचें। LaunchAgents, LaunchDaemons, login items, cron entries और shell rc में जोड़े गए हिस्से।
6. जो उसके ज़रिए गुज़रा उसे रोटेट करें। टूल के environments या collections में रहने वाली हर credential को exposed मानिए। Rotation परेशान करती है; incident response इससे भी ज़्यादा परेशान करता है।
7. पक्का करें कि हटाना टिका रहे। कुछ हफ़्तों तक अपना snapshot script चलता रहने दीजिए। किसी दूसरे flag के साथ दोबारा इंस्टॉल होना एक ज्ञात पैटर्न है।

सूची में क्या नहीं है: टिकट फ़ाइल करना और इंतज़ार करना। यह भी कीजिए, सार्वजनिक, अच्छे सबूतों वाली रिपोर्टें ही बाकी लोगों को चीज़ों का पता चलने का तरीका हैं, लेकिन आपकी अपनी सफ़ाई वेंडर के roadmap पर निर्भर नहीं हो सकती।

डेवलपर टूल सिक्योरिटी पर बड़ा सबक

इस कहानी को सिर्फ़ एक कंपनी के सफ़र की कहानी बना देने का लालच रहता है: एक प्यारा हल्का टूल जिसने सैकड़ों मिलियन डॉलर जुटाए, बड़ी टीम भर्ती की, और अब logins, subscriptions और “सब कुछ AI” के साथ अरबों डॉलर के valuation को जायज़ ठहराना है। यह कहानी संतोषजनक है और ज़्यादातर सच भी है, पर इससे बाकी हम सब बहुत आसानी से बच निकलते हैं। वही प्रोत्साहन ढाँचा आज आपकी मशीन के आधे टूल्स के नीचे भी है। हर वेंडर जिसके पास AI की कहानी है, चाहता है कि उसका प्लगइन आपके एजेंट में हो, उसका MCP सर्वर आपकी config में हो, और उसका hook आपके session start में। कुछ पूछेंगे। सबूत बताते हैं कि कम से कम एक ने तय कर लिया कि पूछना वैकल्पिक है।

बाज़ार की प्रतिक्रिया पहले ही दिख रही है और वह सीख देने वाली है: Bruno, Kreya और Yaak जैसे offline-first, git-native API क्लाइंट्स इसी वजह से लोकप्रिय हो रहे हैं कि उनका trust model पढ़ने लायक है। फ़ाइलें आपके repo में हैं, requests आपकी मशीन से जाती हैं, और खाते की ज़रूरत नहीं। जब किसी टूल का storage format text फ़ाइलों का फ़ोल्डर हो, तो उसका ऑडिट git diff है। यह नॉस्टैल्जिया नहीं, सिक्योरिटी आर्किटेक्चर है। LiteLLM supply-chain घटना ने package-registry की तरफ़ से यही सबक दिया था: जिन artifacts का आप निरीक्षण और pin कर सकते हैं, सिर्फ़ उन्हीं का बचाव कर सकते हैं।

Feature flag में रहने वाली consent, consent नहीं है। अगर कोई टूल अपना version नंबर बदले बिना अपना व्यवहार बदल सकता है, तो उस टूल की आपकी मंज़ूरी का कोई अर्थ नहीं।

तो मेरी स्थिति यह है, जिसका मैं बचाव करूँगा: डेस्कटॉप डेव टूल्स को फ़ीचर के आधार पर आँकना बंद कीजिए, और reversibility के आधार पर आँकना शुरू कीजिए। क्या मैं देख सकता हूँ कि वह क्या-क्या लिखता है? क्या मैं उसकी config का diff ले सकता हूँ? क्या मैं उसे बिना अकाउंट, offline, और ऐसे firewall के पीछे चला सकता हूँ जो लॉग करता हो? क्या मैं उसे पूरी तरह हटा सकता हूँ, अपनी डायरेक्टरी के बाहर जो कुछ उसने छुआ उसे भी? जो टूल इन सवालों पर खरे उतरते हैं वे आम तौर पर उबाऊ होते हैं, और यही वह चीज़ है जो आपके credentials और नेटवर्क के बीच चाहिए। जो फ़ेल होते हैं, उनका autocomplete चाहे कितना भी बढ़िया हो, उन्हें sandbox में या मशीन से बाहर रखना चाहिए। आपका API क्लाइंट एक credential vault है। उसके साथ वैसा ही व्यवहार शुरू कीजिए, क्योंकि वेंडर पहले से ही ऐसा कर रहे हैं, बस उस तरह नहीं जैसी आप उम्मीद करते हैं।