OWASP MCP गवर्नेंस और रिस्क: वह MCP सर्वर अंदर आने दें?

AI एजेंट तेज़ी से असली सिस्टम से जोड़े जा रहे हैं, और यह जोड़ने का काम करने वाला कनेक्टर है Model Context Protocol (MCP)। एक MCP server किसी एजेंट को आपकी wiki पढ़ने, pull request खोलने, Slack पर पोस्ट करने और production workflow ट्रिगर करने दे सकता है — अक्सर बिना किसी इंसान के हर कदम देखे। नया OWASP MCP Governance & Risk Project उसी एक सवाल का जवाब देने के लिए है जो किसी server को जोड़ने से पहले सबसे ज़्यादा मायने रखता है: क्या यह server हमारे environment में अनुमति पाने योग्य है, और किन controls के तहत?

किसी भी स्कोर से पहले चार गेट

इस framework का सबसे तेज़ विचार यह है कि कुछ चीज़ें negotiable नहीं हैं। किसी एक भी risk factor को तौलने से पहले चार गेट पास होने चाहिए, और इनमें से किसी एक का भी फेल होना अकेले ही approval रोक देता है। कुछ भी sign-off करने से पहले आप यही गेट-लॉजिक MCP सर्वर गवर्नेंस टूल से चला कर देख सकते हैं।

• कोई owner नहीं तो कोई approval नहीं। हर server का एक नामित, जवाबदेह owner हो, वरना वह ship नहीं होता।
• कोई logging नहीं तो production नहीं। production में हर action का audit trail अनिवार्य है।
• कोई scope परिभाषा नहीं तो access नहीं। वह क्या data पढ़ सकता है और क्या action ले सकता है, यह documented हो।
• कोई review नहीं तो enterprise deployment नहीं। approval एक बार की घटना नहीं — समय-समय पर risk-tier review तय होती है।

वर्गीकरण: Tier 0 से Tier 4 तक

हर MCP server का risk एक जैसा नहीं होता, इसलिए framework हर एक को पाँच tier में से किसी एक में रखता है, और ऊपर चढ़ते हुए मानक कड़ा होता जाता है: Tier 0 है public data, read-only; Tier 1 है internal, गैर-संवेदनशील read; Tier 2 है संवेदनशील read; Tier 3 है write-capable; और Tier 4 है privileged या critical। एक Tier 0 documentation-search server और एक Tier 4 server जो production में deploy कर सकता है — दोनों एक ही नियमों से चलते हैं, पर बहुत अलग thresholds पर। tier ही वह जगह है जहाँ "किन controls के तहत?" का जवाब मिलता है।

प्रमुख risk: tool chaining

MCP deployment जितने तरीकों से बिगड़ सकता है, उनमें framework tool chaining को प्रमुख risk बताता है: जो server दूसरे tool को invoke कर सके या downstream workflow ट्रिगर कर सके, वह एक अकेली approved action को ऐसी chain में बदल देता है जिसे user ने कभी नहीं देखा। इसके इर्द-गिर्द जाने-पहचाने खतरे हैं: authorization और access scope, credential exposure और data leakage, audit-trail में अंतराल, supply-chain भरोसा और shadow-IT deployment। आठ-factor वाला risk model ठीक इन्हीं को score करता है, इसलिए एक ही tier के दो server अलग-अलग residual risk पर पहुँच सकते हैं। अगर आप कोई model भी expose कर रहे हैं तो इसके साथ model रिस्क स्कैनर भी चलाएँ।

यह उसी से मेल खाता है जो आपके auditor पहले से अपेक्षित रखते हैं

यह कोई अलग-थलग standard नहीं है। framework OWASP MCP Top 10, OWASP LLM Top 10, NIST AI RMF, ISO/IEC 42001 और SOC 2 से align होता है, इसलिए यहाँ दर्ज एक governance निर्णय सीधे उसी compliance evidence में बैठ जाता है जो आप पहले से बनाते हैं। अंतिम लक्ष्य सरल है: approved रास्ते को shadow deployment से तेज़ बनाना, क्योंकि जो governance "खुद ही चला लो" से धीमी हो, उसका पालन नहीं होता, उसे bypass किया जाता है।