लेखक: 
MCP Server Security Checklist 2026: Model Context Protocol से AI assistants business data और developer tools तक पहुँचते हैं। यह 15-point production checklist बताती है कि OAuth, tool permissions, prompt injection, token passthrough, URL validation, local sandboxing, logging और incident response को कैसे assess करें। यह guide security awareness और defensive implementation के लिए है, hacking steps के लिए नहीं। Official MCP July 2026 protocol revision और उसके security documents को reference रखा गया है।
MCP Server Security अब अलग SEO topic क्यों है?
Nexeons के पुराने article में Model Context Protocol का परिचय है। यह नया guide विशेष तौर पर production MCP security assessment को संबोधित करता है: authentication, OAuth audience validation, token passthrough, prompt injection, dangerous tool calls, logs और incident response। MCP किसी language model को बाहरी tools तथा resources से जोड़ सकता है, इसलिए integration की permission ही असल security boundary बन जाती है। Model का उत्तर सही होना आवश्यक है, लेकिन उससे भी महत्वपूर्ण है कि model या attacker किसी tool को unauthorized तरीके से न चला सके। Security controls server, client, API gateway और identity system पर लागू होते हैं; सिर्फ system prompt लिखना पर्याप्त नहीं है।
MCP 2026 specification को सही context में पढ़ें
Official MCP project ने July 2026 specification revision प्रकाशित की। इसमें authorization hardening, stateless core और extensibility से जुड़ी महत्वपूर्ण changes बताई गईं। इसका अर्थ यह नहीं कि हर deployed MCP server तुरंत latest revision पर चल रहा है। Organisation को पहले यह जानना चाहिए कि उसका chosen SDK, client और server किस protocol version को negotiate करते हैं तथा कौन-से authorization protections वास्तव में enabled हैं। पुराने setup का threat model नए setup जैसा नहीं हो सकता। Migration से पहले changelog, client compatibility, release notes और test environment की पुष्टि करें। Production upgrade में authentication flow या tool schema बदलने से unintended breakages आ सकती हैं।
Threat model: MCP client, server और tool तीनों अलग हैं
किसी typical deployment में user AI client को instruction देता है; client MCP server के published tools की discovery करता है; server अलग backend APIs, files या internal data source से बात कर सकता है। जोखिम हर trust boundary पर बनता है। User की legitimate request malicious document text से contaminate हो सकती है, server untrusted backend output model तक भेज सकता है, और unsafe tool implementation excessive privilege के साथ filesystem या admin APIs तक पहुँच सकता है। Security review में हर data flow को note करें: कौन request भेजता है, कौन identity verify करता है, कौन credentials रखता है, किस system में audit log है और कौन resulting side effect reverse कर सकता है।
Checklist 1: Remote MCP server पर authentication
Internet-accessible MCP endpoint का discovery या tool invocation बिना access control expose करना जोखिम बढ़ाता है। Remote users के लिए provider-supported authentication और scoped authorization की जरूरत का मूल्यांकन करें। केवल long random secret को URL query string में लगाना leakage या accidental sharing का कारण बन सकता है। Production transport पर HTTPS उपयोग करें और reverse proxy में appropriate routing rules रखें। हर request के लिए user या service principal का identity context स्थापित करें; anonymous read-only public tool भी rate limits तथा abuse monitoring से मुक्त नहीं है। Local development server को default public internet exposure से बचाएँ, और localhost binding को publicly hosted endpoint के बराबर न समझें।
Checklist 2: OAuth token audience validation
Official MCP authorization security considerations के अनुसार resource-bound tokens और सही audience validation critical हैं। MCP server को यह सुनिश्चित करना चाहिए कि आने वाला access token उसी intended resource के लिए जारी हुआ है। किसी अन्य API के लिए जारी token को सिर्फ valid-looking होने पर accept करना authorization boundary को कमजोर करता है। Issuer, signature, validity period, audience, client policy और granted scopes सत्यापित करें। Self-hosted deployments में OAuth provider की discovery metadata तथा JWKS refresh भी operational responsibility है। Client और server के बीच consent होने का मतलब backend में unrestricted authorization नहीं है; हर sensitive tool call पर resource ownership और scope check करें।
Checklist 3: Token passthrough रोकें
Token passthrough वह insecure shortcut है जिसमें MCP server client से मिले bearer token को बिना सही separation किसी downstream service को भेज देता है। इससे server की auditability और delegated trust model प्रभावित होती है। Official authorization guidance में ऐसे passthrough पर explicit restriction है। सही design में MCP server अपनी audience के लिए incoming credential verify करता है और downstream API को अलग, appropriately delegated credential से call करता है। Token को logs, error traces, model context या analytics events में serialize न करें। Production में testing के लिए deliberately गलत audience वाला token भेजकर confirm करें कि server request reject करता है; यह legitimate authorization test है, credential exploitation नहीं।
Checklist 4: Least privilege और step-up permissions
Calendar पढ़ने वाला assistant अपने-आप calendar delete करने की permission न पाए। Tool के लिए read, create, update और delete scopes अलग रखने से mistakes का damage सीमित होता है। Account-wide admin token का इस्तेमाल सभी users के behalf पर न करें। Folder, project, tenant और record-level authorisation भी आवश्यक हो सकती है; सिर्फ tool की visibility permission नहीं है। Sensitive action तभी enable करें जब specific request और business need उसे justify करे। Elevated permission की जरूरत पड़े तो explicit user consent, time-limited elevation और server-side revalidation लागू करें। Revoked access के बाद active sessions या cached credentials प्रभावी रूप से समाप्त होने चाहिए।
Checklist 5: Tool descriptions को untrusted surface मानें
MCP clients को tool names, descriptions, parameters और returned data दिखाई देते हैं। यदि attacker किसी untrusted server या compromised registry entry को control करता है, तो description के माध्यम से model को गलत route पर भेजने की कोशिश कर सकता है। इसलिए नए server जोड़ने से पहले publisher identity, repository, package version और requested scope review करें। High-trust tool की जगह near-identical name वाली unknown tool को allow न करें। Server-generated documentation में natural-language instructions को authorisation का substitute न समझें। AI model को दिखाया गया description एक hint है, executable policy नहीं; enforcement application और server layer पर होना चाहिए।
Checklist 6: Prompt injection को normal task से अलग करें
Prompt injection तब होती है जब document, webpage, support ticket या tool result में लिखा attacker-controlled text model को higher-priority instruction जैसा दिखाने की कोशिश करे। Example: employee किसी vendor invoice की summary माँगता है, लेकिन invoice text में hidden instruction होता है कि सारे invoices किसी external address पर भेज दो। Document का content task data है, trusted admin instruction नहीं। Model को यह distinction बताना एक defense है, पर निर्णायक सुरक्षा tool scopes, destination allowlists और approval gates से मिलेगी। Sensitive actions के लिए deterministic server-side validation जरूरी है ताकि malicious content से automatic data disclosure न हो।
Checklist 7: Write और destructive actions पर human confirmation
Read-only search और delete-all-records दोनों को एक जैसी automatic permissions देना खराब design है। Client में user को action summary दिखाएँ: कौन सा record बदलेगा, किन recipients को email जाएगी, कितने पैसे का payment होगा या कितनी files delete होंगी। Approval के बाद भी server पर authorization, ownership, input constraints और business rules validate होने चाहिए। Confirmation को केवल frontend popup न मानें जो आसानी से bypass किया जा सके। Financial transfer, mass email, production deploy या external data share जैसे काम के लिए precise payload review तथा recipient allowlist रखें। Bulk operations में action count और affected resource sample दिखाना विशेष रूप से उपयोगी है।
Checklist 8: Input schema validation और secure output handling
Tool input JSON Schema होना पर्याप्त नहीं; implementation को भी length, enum, datatype, ID ownership और expected format check करना चाहिए। File path, shell command, SQL text, URL या email address लेते समय अलग-अलग validators चाहिए। सिर्फ dangerous शब्द blacklist करने से validation complete नहीं होती। Backend API को parameterised queries और safe libraries से call करें। किसी webpage से fetch किए गए HTML को browser interface में बिना sanitization render करना XSS का कारण हो सकता है। Tool result में minimum आवश्यक fields लौटाएँ, internal stack traces और hidden secrets नहीं। Invalid request पर sanitized error code और safe user-facing explanation देना बेहतर है।
Checklist 9: SSRF और dangerous URL handling
कुछ MCP workflows remote URLs fetch करते हैं, image import करते हैं या OAuth metadata discover करते हैं। यदि attacker URL control कर सके, तो client या server को internal service या cloud metadata endpoint की ओर request भेजने का खतरा होता है। Network egress controls, permitted schemes, DNS resolution policy और redirect validation लागू करें। Localhost, private network addresses और sensitive metadata destinations को protection की जरूरत है, पर custom IP parsing पर अकेले निर्भर न रहें। Hostile URLs को shell commands से open करना भी जोखिमपूर्ण है; protocol documentation platform-provided safe URL opening approaches पर बल देता है। Legitimate internal integrations के लिए narrowly scoped exceptions और audit trail रखें।
Checklist 10: Local stdio server में sandboxing
Local MCP server अक्सर developer machine पर child process के रूप में चलता है। उसका effective privilege उसी operating-system account तथा mounted filesystem तक पहुँच से जुड़ा हो सकता है। Unknown package को main user session, SSH keys, browser profiles, cloud credentials और office documents तक unrestricted access न दें। Container, restricted OS user, filesystem allowlist और network policy के साथ isolation करें। Development laptop और production host के controls अलग होंगे। यदि server को केवल एक project folder पढ़ना है तो home directory mount देना जरूरी नहीं। Package install से पहले source provenance, dependency tree और update policy जाँचें।
Checklist 11: Secrets, API keys और environment variables
Credentials को prompt में paste करना, code repository में commit करना या tool output में भेजना avoid करें। Managed secrets storage, short-lived access, rotation procedure और per-service identities उपयोगी हैं। Logging pipeline में authorization header, refresh token, session cookie और connection string को mask करें। Incident के दौरान exposed key को revoke करने के लिए runbook तैयार रखें। Developers को sandbox और production credentials अलग दिए जाएँ। CI/CD में generated artefacts, screenshots या debugging outputs भी accidental secret leakage का स्रोत हो सकते हैं। Company-managed credentials से personal experimentation अलग करें। Credentials access की review को quarterly या project risk के अनुसार recurring प्रक्रिया बनाएँ।
Checklist 12: Data isolation, multi-tenant access और consent
यदि एक MCP server कई customers के data तक पहुँच देता है, तो tenant ID को केवल model के instruction या client-supplied parameter पर trust न करें। हर backend request में verified identity से resource ownership resolve करें। Search results, embeddings, cache और conversation memory में tenant boundaries जाँचें। Team members की roles बदलने पर old cached results तक access जारी नहीं रहना चाहिए। Sensitive documents के लिए retention policy, consent और deletion mechanism बनाएं। Data classification के आधार पर public, internal, confidential और restricted tools अलग करें। Customer data किसी third-party model या outside API में जाने से पहले contractual तथा privacy requirements verify हों।
Checklist 13: Rate limiting, timeouts और cost control
Tools के misuse का risk केवल data breach नहीं; paid API calls, background jobs, duplicate orders और infinite agent loops से cost बढ़ सकती है। Caller, organisation, tool name और backend resource के अनुसार quotas रखें। HTTP timeouts, concurrency limits और pagination caps enforce करें। Retry mechanism idempotency key के साथ डिजाइन करें; payment या ticket creation जैसी non-idempotent action को दो बार चलाना आर्थिक नुकसान करा सकता है। Tool failure पर agent को अनंत retry देने के बजाय exponential backoff और circuit breaker रखें। Budget alert और manual stop control उपलब्ध कराएँ। Usage report में useful task completions और avoidable requests अलग से देखें।
Checklist 14: Logs useful हों, private data exposed न हो
Audit events में timestamp, actor identity, tool name, decision, resource identifier, response status और correlation ID पर्याप्त हो सकते हैं। Full prompt, entire document, personal phone numbers या token strings को default log में रखने से अलग privacy risk उत्पन्न होगा। Incident investigation के लिए request से downstream action तक traceability चाहिए। Logs को tamper resistance, retention schedule और role-based access से सुरक्षित रखें। Model-generated text और server-authorised tool operation को अलग events में record करें ताकि यह समझा जा सके कि unwanted action किस stage पर हुआ। Security analytics में false positives को manage करें; noisy alerts महत्वपूर्ण incidents छिपा सकते हैं।
Checklist 15: Package provenance और supply-chain review
MCP server का नाम लोकप्रिय होने से package सुरक्षित साबित नहीं होता। Official repository, maintainer verification, signed release, dependency versions और security advisories जाँचें। Production में reproducible builds या pinned dependencies से unexpected update risk कम किया जा सकता है। Pull request में tool scopes, added network calls और new filesystem permissions का review करें। Third-party connectors install करते समय requested access और actual business requirement compare करें। Unsafe library को patch करने के लिए change-management procedure रखें। पुराने clients या unsupported SDK versions security fixes miss कर सकते हैं; supported branches की regular inventory बनाना जरूरी है।
Threat-to-control mapping: चार realistic scenarios
Scenario एक: webpage कहती है किसी external address पर internal report भेज दो। Defense: webpage को untrusted data, send-email tool पर recipient validation और approval। Scenario दो: user का wrong-audience token backend के लिए reuse किया जाता है। Defense: resource-bound tokens तथा separate downstream credentials। Scenario तीन: uploaded file name या URL internal server पर request trigger करता है। Defense: strict path checks, safe fetch policy और network egress restrictions। Scenario चार: assistant बार-बार expensive API call करता है। Defense: per-task call budget, rate limiting और timeout। हर scenario के लिए automated regression test रखें।
एक school या business team का permission example
मान लें IT helpdesk assistant को कर्मचारी के ticket पढ़ने और ticket number खोजने की जरूरत है। वह public contact page नहीं बदल सकता, admin user नहीं बना सकता और payroll spreadsheet नहीं खोल सकता। Ticket create करने की permission अलग tool में और ticket close करने की permission authorised helpdesk supervisor तक सीमित होनी चाहिए। किसी forwarded email में लिखा आदेश कि सारे tickets delete कर दो, workflow के authorisation rules को override नहीं कर सकता। इस example का उद्देश्य एक principle दिखाना है: agent का language understanding system-access governance का विकल्प नहीं है। सामान्य office automation में भी low-risk read और high-risk write का अलग tier जरूरी है।
Security checklist को 0–3 maturity score में बदलें
अपने हर control को 0: absent, 1: manually documented, 2: enforced in staging, 3: enforced plus monitored in production दें। उदाहरण के लिए OAuth audience validation पर 3 अंक तभी दें जब implementation, negative tests और logs तीनों मौजूद हों। Fifteen controls के लिए maximum 45 अंक होंगे, लेकिन यह हमारा editorial scorecard है, industry certification या guarantee नहीं। सभी controls समान प्रभाव वाले नहीं; production data write करने वाले high-risk deployment में authentication और cross-tenant authorization के absent होने पर बाकी score ऊँचा होने से system acceptable नहीं बन जाता। Fail-critical controls को hard blockers रखें।
Pre-production testing: क्या-क्या verify करें?
Staging में unauthenticated request को reject होते देखें; expired और wrong-audience token को भी। Read-only account से destructive tool trigger करने पर failure expected होना चाहिए। Cross-tenant record access negative test, malicious document text से prompt-injection scenario, disallowed outbound URL, malformed JSON inputs, duplicate request replay और unexpected backend timeout cover करें। Legitimate usage भी test करें ताकि controls से जरूरी workflows टूट न जाएँ। Test user accounts और sample data रखें; real customer records पर aggressive probing न करें। हर deployment में test results, policy exceptions और rollback procedure record करें।
Incident response: tool से गलत action हो गया तो?
Incident plan में सबसे पहले affected endpoint isolate करने, exposed credential revoke करने और tool permission temporarily disable करने का रास्ता होना चाहिए। Audit log से समय, user identity, requested action, downstream effects और recipients की scope पता करें। Data access हुआ हो तो privacy, contractual और applicable legal notification obligations का मूल्यांकन responsible team करे। यदि गलत external email चली गई हो, तो deletion claim अपने आप true न मानें। Corrective changes के बाद regression tests चलाएं और root cause note करें: prompt-injection boundary, authorisation bug, missing confirmation या dependency compromise। User communication transparent और evidence-based रखें।
Third-party MCP connection approve करने से पहले सवाल
Vendor से पूछें: server किस organisation ने बनाया, कौन maintenance करता है, data कहाँ process होती है, permission कितनी broad है, tokens कितनी जल्दी expire होते हैं, revoke कैसे करेंगे और incident reporting कौन संभालेगा? उसके बाद यह जाँचें कि official SDK या standard authorization implementation पर कितना reliance है और custom patches कहाँ हैं। Marketing sheet में लिखा secure-by-design पर्याप्त evidence नहीं। Product की SOC audit या certification होने का मतलब आपके custom deployment का configuration automatically सही नहीं है। Integration owner, security reviewer और data steward की responsibility पहले से define करें।
MCP security और traditional API security में अंतर
कई controls समान हैं—authentication, authorization, input validation, audit logging और network filtering। फर्क यह है कि AI agent untrusted natural-language content को tool selection के साथ combine कर सकता है। Backend API पहले भी object-level authorization verify करती थी; MCP जोड़ने के बाद भी वही rule अनिवार्य है। Additional attention tool descriptions, prompt injection, indirect instruction following, delegated credentials और high-impact actions के human approval पर देना होगा। अगर पुरानी API में excessive access था तो MCP उसे नया privilege नहीं बनाता, लेकिन misuse के रास्ते बढ़ सकते हैं। इसलिए AI security review को existing application security और IAM program से जोड़ें।
Frequently Asked Questions: क्या हर MCP Server में OAuth चाहिए?
हर environment का protocol transport और deployment model अलग हो सकता है। Internet-facing remote server की authentication जरूरत को गंभीरता से लें, और official specification की relevant authorization requirements follow करें। Local stdio process के लिए risk model अलग होगा; उसे sandbox और local permissions की जरूरत हो सकती है। किसी एक login mechanism को हर scenario का universal solution कहना गलत है। Application की identity architecture, enterprise policy और protocol compatibility के आधार पर auth design करें। OAuth configured होने पर भी per-tool और per-resource authorisation testing जरूरी है।
Frequently Asked Questions: क्या MCP prompt injection पूरी तरह रोक सकता है?
नहीं। Input में आया malicious instruction और model behavior का risk zero बताना ईमानदार नहीं होगा। Practical design attack-success probability और potential impact कम करता है: untrusted content की isolation, permissions separation, destination validation, confirmation gates, safe tool output और auditability साथ मिलकर defense-in-depth बनाते हैं। Model से केवल यह कह देना कि previous instructions ignore करो, मजबूत protection नहीं है। High-risk systems में sensitive actions को deterministic policy engine से enforce करें और evaluation dataset में new attack patterns जोड़ते रहें। Security testing को लगातार सुधारने वाली engineering process समझें।
Primary sources, checklist review और internal reading
इस guide के core technical claims के लिए Official MCP Security Best Practices, Authorization Security Considerations और July 2026 specification announcement पढ़ें। Implementation orientation के लिए Microsoft MCP security learning notes भी relevant हैं। Related Nexeons articles में MCP क्या है और Zero Trust Security शामिल हैं। Software versions और threat guidance बदल सकते हैं; production rollout से पहले canonical specification की fresh review करें।
इस विषय पर आगे क्या पढ़ें?
इस खबर से जुड़े विषयों को आसान भाषा में और गहराई से समझें।
