MCP agents को environment variables से हटाएं: credentials migrate करें
MCP agents को environment variables से हटाने के लिए tools map करें, credentials को vault में रखें, secret boundaries test करें और पुराने tokens को सुरक्षित रूप से rotate करें।
MCP server के environment में credentials रखना एक ऐसा shortcut है जो agent के commands चलाने, files देखने, failures troubleshoot करने या helper processes शुरू करने में सक्षम होते ही खतरनाक बन जाता है। समस्या यह नहीं है कि हर agent जानबूझकर token दिखाएगा। समस्या यह है कि आपने किसी process को, जिसे explore और act करने के लिए बनाया गया है, एक reusable secret दे दिया और फिर उससे ऐसा व्यवहार करने को कहा जैसे वह उसे देख ही नहीं सकता।
Authority को agent process से बाहर ले जाएं। Agent को किसी तय HTTP या SSH action का request करने दें और credential रखने वाले local component को उसे execute करने दें। बदलाव छोटा लगता है, लेकिन इससे आपको यह पहचानना पड़ता है कि हर tool वास्तव में क्या करता है, उसे किस identity की जरूरत है और आप कैसे साबित करेंगे कि token नई path में चुपके से नहीं पहुंचा।
मैंने migrations को इसलिए विफल होते देखा है क्योंकि किसी ने एक config file से API_TOKEN हटा दिया, लेकिन उसे shell profile, task runner या copied project template में छोड़ दिया। API call चलती रही, सब निश्चिंत हो गए और agent के पास पुराना credential अब भी था। साफ migration में discovery, replacement और proof को अलग-अलग काम माना जाता है।
Environment variables agent को tool की जरूरत से ज्यादा authority देते हैं
Environment variable किसी एक request का हिस्सा नहीं होता। वह process का हिस्सा होता है और अक्सर उस process से शुरू होने वाली हर चीज का भी। अगर कोई MCP client SERVICE_TOKEN को environment में रखकर server शुरू करता है, तो server उसे पढ़ सकता है। जब तक कोई उसे सावधानी से न हटाए, inherited child processes भी पढ़ सकते हैं। Debug commands, crash reports, test fixtures और गलती से हुआ env output स्थानीय सुविधा को लंबे समय तक रहने वाले leak में बदल सकते हैं।
यह उस स्थिति से अलग है जिसमें tool को authenticated result मिलता है। Result में repository list, deployment status या error response हो सकता है। Agent को अपना काम आगे बढ़ाने के लिए इनकी जरूरत है। Request को संभव बनाने वाले bearer token की उसे जरूरत नहीं है।
दोनों designs से एक जैसी successful request मिल सकती है, इसलिए फर्क धुंधला पड़ जाता है। फिर भी वे समान नहीं हैं:
- Credential possession का अर्थ है कि agent intended tool call के बाहर secret का इस्तेमाल, copy, बदलाव या exfiltration कर सकता है।
- Action authority का अर्थ है कि agent defined controls के तहत request करने के लिए trusted local executor से कह सकता है।
- Result access का अर्थ है कि agent को अगला action तय करने के लिए जरूरी response दिखता है।
यह फर्क समझ में न आने पर एक आम गलत सलाह मिलती है: tokens को secret manager में रखें और startup पर उन्हें agent के environment में डाल दें। इससे at-rest storage बेहतर हो सकती है, लेकिन runtime boundary नहीं बदलती। Agent को token अब भी मिल रहा है।
MCP specification clients, servers और tools के लिए protocol बताती है। वह environment variables को credential boundary नहीं मानती। उन्हें local configuration के transport की तरह तभी इस्तेमाल करें, जब उन्हें पाने वाला process underlying secret के लिए पहले से trusted हो। Autonomous coding agents अक्सर इस कसौटी पर खरे नहीं उतरते।
Configuration बदलने से पहले tool inventory बनाएं
एक लिखित inventory से शुरुआत करें। JSON files edit करने से शुरुआत न करें, क्योंकि configuration files शायद ही पूरी कहानी बताती हैं। कोई tool एक variable सीधे पढ़ सकता है, किसी wrapper को चला सकता है जो दूसरा variable पढ़ता है, या ऐसे command-line client पर निर्भर हो सकता है जो home-directory file से credentials लोड करता है।
हर MCP tool के लिए tool name, command, target, authentication method, credential owner, permission scope और testing के लिए harmless request दर्ज करें। यह भी लिखें कि secret अभी process में कहां प्रवेश करता है: client config, shell startup file, .env file, CI export, password manager command या helper script।
एक संक्षिप्त inventory ऐसी दिख सकती है:
| Tool | Action target | Current secret path | Replacement boundary | Test |
|---|---|---|---|---|
| issue search | issue API | client config में ISSUES_TOKEN | local HTTP action | एक ज्ञात project की सूची बनाएं |
| deploy status | deployment API | .env.local | local HTTP action | service status पढ़ें |
| host diagnostics | SSH host alias | private key file path | local SSH action | uname चलाएं |
| package publish | registry API | shell export | local HTTP action | package metadata पढ़ें |
prod-token या default-key जैसे अस्पष्ट नामों में broad permissions न छिपाएं। Credential record का ऐसा नाम रखें जिससे operator को पता चले कि वह क्या कर सकता है और कहां जाता है। deploy-api-production-read कम सुंदर है, लेकिन जल्दबाजी में होने वाले review में कहीं अधिक सुरक्षित है।
Inventory यह भी दिखाती है कि कोई credential होना भी चाहिए या नहीं। मैंने ऐसे tools से जुड़े write-capable tokens पाए हैं जो केवल project metadata पढ़ते थे, क्योंकि किसी ने development setup copy कर दिया था। Migration सीमित scope वाले credentials जारी करने का सही समय है। यह हर पुरानी privilege को बस बेहतर container में रखने का कारण नहीं है।
Secret injection हटाएं, उसे छिपाएं नहीं
Migrated configuration को secret agent या उसके MCP server तक पहुंचाना बंद करना होगा। Literal token को ${SERVICE_TOKEN}, $(secret-tool lookup ...) या unprotected file के path से बदलना इस कसौटी पर खरा नहीं उतरता। आपने authority नहीं, केवल लिखने का तरीका बदला है।
पहले वर्तमान references खोजें। Project directory में यह कई स्पष्ट मामलों को पकड़ लेता है:
rg -n --hidden --glob '! .git' 'API[_-]?KEY|API[_-]?TOKEN|SECRET|PASSWORD|PRIVATE[_-]?KEY|Authorization: Bearer' .
Expected output का रूप file:line:matching text entries की सूची जैसा होता है। अगर उसमें live values हों, तो output को issue में paste न करें। इसका इस्तेमाल remediation list बनाने के लिए करें, फिर सामान्य user-level locations, जैसे shell profiles और MCP client settings, को अलग से खोजें।
अब पुराने agent process को दिखने वाले environment की तुलना नए process को दिखने वाले environment से करें। Controlled test shell में values दिखाए बिना names की सूची बनाएं:
env | cut -d= -f1 | sort | rg 'TOKEN|KEY|SECRET|PASSWORD'
जिस process से agent शुरू होता है, उसमें पुराने names नहीं होने चाहिए। अगर वहां SERVICE_TOKEN दिखता है, तो नई gateway path काम करने पर भी migration अधूरी है।
उस आधे-अधूरे design से बचें जिसमें MCP server के पास token हो, लेकिन primary agent के पास न हो। इससे एक exposure path कम होता है, फिर भी server के पास credential का unrestricted possession रहता है। अगर server arbitrary commands चला सकता है, plugins load कर सकता है या logs लिख सकता है, तो आपने समस्या को ऐसे process में पहुंचाया है जिसकी अक्सर कम जांच होती है।
Target selection के लिए nonsecret configuration इस्तेमाल करें। Base URL, host alias, account identifier और credential label config में रखे जा सकते हैं, बशर्ते वे access न देते हों। Authenticated material को ऐसे local vault में रखें जिसे agent data की तरह query न कर सके।
नई path को requests, credentials और results के रूप में model करें
नई flow में स्पष्ट boundary होनी चाहिए: agent action का नाम और सामान्य request data देता है, local executor credential चुनकर जोड़ता है और response लौटाता है। Agent को ऐसा placeholder भी कभी नहीं मिलना चाहिए जिसे वह secret में resolve कर सके।
HTTP tool के लिए public request shape को private authentication step से अलग रखें। Agent यह request करने को कह सकता है:
GET https://api.example.internal/projects/atlas/issues?state=open
Local executor सही bearer, basic या custom-header credential जोड़ता है और response body तथा status लौटाता है। अगर agent unapproved host, method या account मांगे, तो executor को यह अनुमान लगाने के बजाय request अस्वीकार करनी चाहिए कि कौन-सा credential ठीक रहेगा।
SSH में request में host और command होते हैं, जबकि private key स्थानीय रहती है। यह महत्वपूर्ण है, क्योंकि SSH tooling अक्सर paths, agent forwarding, config includes और inherited SSH_AUTH_SOCK के जरिए authority पहुंचा देती है। Tool configuration में private key path रखना सुरक्षित replacement नहीं है। Agent अक्सर file पढ़, copy या उसका इस्तेमाल करने वाले command में बदलाव कर सकता है।
Sallyport अपने bundled sp mcp stdio shim के जरिए यही shape इस्तेमाल करता है: agents MCP calls करते हैं, जबकि app API keys या SSH keys agent को दिए बिना HTTP API calls और SSH commands चलाता है। यह boundary तभी उपयोगी है, जब आप पुरानी environment injection भी हटा दें।
Local executor को one all-powerful credential वाला general-purpose proxy न बनाएं। Agent के request में configured destination और credential की पहचान होनी चाहिए, arbitrary URL और token choice नहीं। वरना prompt-injected agent legitimate credential को ऐसी जगह का request signer बना सकता है जिसका आपने कभी इरादा नहीं किया था।
ऐसे approval points चुनें जिन्हें लोग सचमुच समझ सकें
Human approval तब काम करता है जब व्यक्ति समझ सके कि वह किस चीज को approve कर रहा है। Long-running agent बार-बार लगभग समान prompts दिखाता रहे और व्यक्ति सब पर click करता जाए, तो approval विफल हो जाता है। यह पहले से अनुमानित design fault है, operator की vigilance की कमी नहीं।
जब आपको यह तय करना हो कि किसी run के दौरान कोई specific agent process configured actions इस्तेमाल कर सकता है, तो session-level approval लें। Approval में process की ऐसी पहचान होनी चाहिए जिससे वास्तविक client और imitation में फर्क किया जा सके। केवल process name कमजोर प्रमाण है, क्योंकि कोई भी program परिचित नाम चुन सकता है।
Per-call approval उन credentials के लिए रखें जिनके परिणामों पर हर बार नया human judgment जरूरी है। Production write access, destructive host command और payment-adjacent API इस friction के योग्य हैं। Read-only issue lookup आम तौर पर नहीं। अगर हर tool call पर decision मांगेंगे, तो operators decision पढ़ना बंद कर देंगे।
Locked vault को requests अस्वीकार करनी चाहिए, भले ही पहले approved agent अभी चल रहा हो। Vault gate का उद्देश्य यही है। Unattended process को केवल इसलिए authority नहीं मिलनी चाहिए कि दोपहर में उसके पास वह authority थी।
Sallyport में policy language के बजाय तीन fixed controls हैं: vault gate, हर नए agent process के लिए authorization और optional per-key approval। यह fixed model जानबूझकर rules engine से संकरा है, इसलिए थके हुए operator के लिए गलत लिखने को कम clever rules होते हैं।
Success और secrecy को अलग-अलग claims की तरह test करें
Green tool response केवल यह साबित करता है कि किसी चीज ने request authenticate की। यह साबित नहीं करता कि agent credential हासिल नहीं कर सका। Migration test दोनों claims को जांचे, और शुरुआत low-risk action से करें।
हर tool के लिए यह sequence अपनाएं:
- Local vault लॉक करें और tool चलाएं। Call को environment token पर fallback किए बिना विफल होना चाहिए।
- Vault unlock करें, fresh agent process शुरू करें और यदि setup में जरूरी हो तो उसे approve करें। Inventory में दर्ज harmless request चलाएं।
- Action journal या server-side audit record में exact destination, account, method और result status देखें। सुनिश्चित करें कि action दर्ज हो, secret नहीं।
- Agent की allowed execution path से उसके environment में पुराने variable name और workspace में token prefix खोजें। Token दोनों जगह नहीं होना चाहिए।
- Agent process restart करें और request दोहराएं। इससे पता चलेगा कि कहीं आप पुराने shell की inherited state पर निर्भर तो नहीं थे।
पहला step एक सूक्ष्म लेकिन गंभीर गलती पकड़ता है। Teams कभी-कभी vault path configure करके पुराने variable को fallback के रूप में छोड़ देती हैं। Vault लॉक होने पर भी tool सफल हो जाता है। यह तब तक reliable लगता है, जब तक वही fallback CI worker, copied repository या agent transcript में दिखाई न दे।
मुख्य proof के रूप में agent से उसके सभी environment variables print करने को न कहें। यह test खुद disclosure route बनाता है और पुराने token को conversation history में डाल सकता है। Names को controlled shell से जांचें और inheritance behavior validate करना हो तो dry runs में जानबूझकर रखा गया nonsecret marker variable इस्तेमाल करें।
SSH के लिए ऐसा command चलाएं जो harmless system identity information लौटाए, state बदलने वाला command नहीं। Result की पुष्टि करें, फिर देखें कि agent configuration में host reference है, private key material नहीं। SSH configuration में ForwardAgent yes भी जांचें। Agent forwarding remote host को local identities इस्तेमाल करने का रास्ता दे सकता है, जो private key file expose होने से अलग जोखिम है।
Audit records से disputed action को दोबारा समझा जा सके
Action log तब उपयोगी है जब वह सोमवार सुबह के कठिन सवाल का जवाब दे सके: यह request किस agent run ने, किस configured credential के जरिए की और क्या किसी human ने उसे approve किया था? tool succeeded जैसी अस्पष्ट line किसी बात को साफ नहीं करेगी।
Agent runs के लिए session record और individual actions के लिए call record रखें। Session record बताता है कि process कब शुरू हुआ, आपने किस identity को approve किया और उसे कब revoke किया। Call record बताता है कि उस session के तहत क्या हुआ। अगर आपको कई runs में से एक की जांच करनी है, तो दोनों को एक flat event stream में न मिलाएं।
Tamper evidence जरूरी है, क्योंकि local command execution वाला agent किसी undesirable action के बाद अपने निशान मिटाने की कोशिश कर सकता है। Hash-chained log बदला या हटाया गया history पहचानने का तरीका देता है, लेकिन verification agent के cooperative होने पर निर्भर नहीं होनी चाहिए।
Sallyport दोनों journals को encrypted, write-blind, hash-chained audit log से project करता है और ciphertext पर offline chain verification के लिए यह command देता है:
sp audit verify
Successful result में verification के सफलतापूर्वक पूरा होने की जानकारी होनी चाहिए। Failure आए तो break समझने तक journal को संदिग्ध मानें। Verification यह नहीं बताता कि action समझदारी भरा था या नहीं। यह बताता है कि record की continuity अभी बनी हुई है या नहीं।
Audit data को model prompts और सामान्य chat transcripts से बाहर रखें। Credential कभी दर्ज न होने पर भी record में sensitive request context या response metadata हो सकता है। Investigation access casual browsing के लिए back door नहीं बनना चाहिए।
Rotation वह cleanup है जो साबित करता है कि migration सच में किया गया
हर नई path के tests पास होने के बाद पुराने credential को rotate करें। यह सोचकर valid न छोड़ें कि «शायद rollback के लिए जरूरत पड़े»। इससे वह समय बढ़ता है जिसमें भूले हुए configs अब भी authenticate कर सकते हैं। Rollback को अलग से controlled replacement पर आधारित करें, ऐसे secret पर नहीं जिसे आपने स्थानीय environments में पहले ही फैला दिया है।
Rotation का क्रम महत्वपूर्ण है। नया scoped credential बनाएं, उसे locally store करें, नई path validate करें, पुरानी secret injection हटाएं और फिर पुराना credential revoke करें। अगर पुराना token source control, chat message, support ticket या build output में दिखाई दे सकता है, तो उसे पहले revoke करें और safe access बहाल करते समय आने वाले outage को स्वीकार करें।
Revocation के बाद discovery search दोहराएं। आपको stale references ढूंढने हैं, live secret values नहीं। Sample files, onboarding documents, shell profiles, task scripts और test instructions से dead variable names हटाएं। Future developers examples को आश्चर्यजनक निष्ठा से copy करते हैं।
अंत में operational notes में एक जानबूझकर रखा गया failure test छोड़ें: vault लॉक करें और harmless tool call चलाएं। अगर call सफल हो जाती है, तो किसी ने bypass फिर से जोड़ दिया है। यह अकेली जांच किसी polished architecture diagram से ज्यादा खराब migrations पकड़ती है।
Broad credentials को tool design flaw मानें
Token को vault में ले जाने से broad token agent के लिए उचित नहीं हो जाता। इससे केवल यह बदलता है कि token किसके पास है। Project issues query करने वाले tool के पास projects delete करने, billing बदलने या production code deploy करने की permission चुपचाप नहीं होनी चाहिए।
Tools को वास्तविक काम और उसके परिणामों के अनुसार बांटें। Read-only discovery actions सीमित credential और सामान्य approval इस्तेमाल कर सकते हैं। State-changing actions को tighter scopes, स्पष्ट targets और कभी-कभी per-call consent चाहिए। इससे agent की निगरानी भी आसान होती है, क्योंकि उसके उपलब्ध verbs दिए गए task से मेल खाते हैं।
Tool simplicity के नाम पर universal admin credential से सावधान रहें। यह setup आज configuration work कम करता है। कल incident response को कठिन बना देता है, क्योंकि आप नहीं बता पाते कि किन requests को उस power की जरूरत थी और किन्होंने उसे केवल inherit किया था।
Migration तब सफल है जब agent अपना intended work पूरा कर सके, locked vault उसे रोक दे, नए process को configured authority के लिए approval लेना पड़े और कोई पुराना token उसके environment में न बचा हो। इनमें से किसी claim का test नहीं है, तो आपके पास credential boundary नहीं, केवल working demo है।
सामान्य प्रश्न
MCP agents के लिए environment variables असुरक्षित क्यों हैं?
Environment variables स्थानीय script के लिए सुविधाजनक होते हैं, लेकिन वे secret को agent process के environment में डाल देते हैं। एजेंट अक्सर उस environment को सीधे पढ़ सकता है, child process के जरिए उसे inherit कर सकता है या diagnostic output में दिखा सकता है। Local action gateway credential को उस process से बाहर रखता है और authenticated request खुद करता है।
क्या मैं environment variables इस्तेमाल करने वाली MCP configuration file सुरक्षित रूप से साझा कर सकता हूं?
कॉपी किए गए MCP configuration में आम तौर पर command, arguments और environment values साथ चले जाते हैं। ऐसी copied file को संभावित credential leak मानें, जब तक आप secret values हटा न दें और साझा किए गए किसी भी token को revoke या rotate न कर दें। Secret scanner copies ढूंढने में मदद कर सकता है, लेकिन यह साबित नहीं कर सकता कि कोई copy मौजूद नहीं है।
MCP tool migrate करने से पहले API tokens rotate करने चाहिए या बाद में?
किसी token को केवल इसलिए rotate न करें कि आप ऐसा कर सकते हैं। पहले replacement path को काम करने लायक बनाएं, फिर सबसे कम जोखिम वाले request से उसे verify करें और उसके बाद token rotate करें। अपवाद वह token है जो repository, ticket, chat या public build log में पहले ही उजागर हो चुका है। उसे तुरंत revoke करें और बाद में workflow ठीक करें।
क्या MCP config file में secret reference रखा जा सकता है?
Config file यह बता सकती है कि tool कौन-सा endpoint या account profile इस्तेमाल करता है, लेकिन उसमें bearer tokens, passwords, private keys या ऐसे shell expansions नहीं होने चाहिए जो secrets में बदल जाएं। Locally stored credential का reference तभी स्वीकार्य है, जब agent उस reference के जरिए credential पढ़ न सके।
मैं कैसे जांचूं कि agent migrated token नहीं देख सकता?
विश्वसनीय test दो बातें अलग-अलग साबित करता है: requested action सफल होता है और agent process token हासिल नहीं कर सकता। Gateway का action record देखें, फिर agent environment और working directory में पुराने variable name और token prefix को खोजें। केवल successful API call बहुत कम साबित करती है।
क्या मैं SSH keys को भी AI agent के environment से बाहर ले जा सकता हूं?
SSH को भी HTTP credentials जैसी ही boundary चाहिए। Agent को named SSH action मांगना चाहिए, जबकि local helper private key का इस्तेमाल करे और key file या उसकी contents agent को न दे। समस्या का हल agent configuration में unencrypted private key path डालना नहीं है।
MCP credential के लिए हर call पर approval कब जरूरी होना चाहिए?
Per-session approval यह तय करता है कि एक run के दौरान कौन-सा agent process calls कर सकता है। Per-call approval उन credentials या actions के लिए है जिन पर हर बार मानवीय निर्णय जरूरी है, जैसे production deployment access या payment-related API। हर harmless read के लिए approval मांगने पर लोग बिना पढ़े approve करने लगते हैं।
Agent run के दौरान local vault लॉक होने पर क्या होता है?
अगर vault लॉक है और locked state में actions अस्वीकार करता है, तो agent काम नहीं कर पाएगा। यह व्यवहार जानबूझकर है: केवल agent के चलते रहने से उसे access नहीं मिलना चाहिए। लंबे jobs को review योग्य phases में बांटें, lock boundary को हराने की कोशिश न करें।
MCP credential migration के लिए सबसे सुरक्षित rollback plan क्या है?
सबसे सुरक्षित rollback नई tool entry को disable करना है, secret environment variable वापस लाना नहीं। पुराने credential को migration window के दौरान थोड़े समय के लिए administrator के पास रखें और नई path के tests पास होने के बाद उसे revoke कर दें। यदि पुरानी path वापस लानी ही पड़े, तो संदेहास्पद exposed token के बजाय नया, सीमित scope वाला token इस्तेमाल करें।
क्या audit logs autonomous agent credentials को सुरक्षित बनाते हैं?
Audit log यह पता लगाने में मदद करता है कि किस agent session ने कौन-सा action कब चलाया और request approve या deny हुई थी या नहीं। इससे broad credential अपने आप सुरक्षित नहीं बनता। आपको फिर भी सीमित scopes, सही target selection और ऐसी boundary चाहिए जो agent को credential पढ़ने से रोके।