MCP सुरक्षा-सीमाएँ: AI एजेंट्स के लिए सुरक्षित अनुमतियाँ

MCP टोकन असल में आपके अकाउंट का पासवर्ड है जिसके साथ API जुड़ा है। इसे किसी एजेंट को दे दें, और आपके पास एक ऐसा यूज़र होगा जो कभी थकता नहीं, जिस पेज पर भेजें उसे पढ़ लेता है, और उसके कॉन्टेक्स्ट में आख़िरी निर्देश जो कहे, बिल्कुल वही करता है। ज़्यादातर समय यही चाहिए होता है। यह पेज बाक़ी समय के बारे में है।

नीचे की हर बात पेज के ऊपर लिखी तारीख़ पर लाइव सर्वर से जाँची गई है: टूल सूची https://mcp.eqvps.com/mcp पर tools/list से आई है, सीमाएँ सीधे API से। अगर आप नए हैं, तो पहले MCP क्लाइंट जोड़ना और API टोकन पढ़ें, फिर लौटें।

ख़तरे का मॉडल: असल में क्या गड़बड़ होता है

तीन चीज़ें, उसी क्रम में जिसमें हम इन्हें देखते हैं:

1. एजेंट ग़लत समझ लेता है। "टेस्ट मशीन साफ़ कर दो" किसी और सर्वर के री-इंस्टॉल में बदल जाता है। कोई बुरी नीयत नहीं, बस मॉडल ने निर्देश की ख़ाली जगह ख़ुद भर दी।
2. Prompt injection. एजेंट कोई ऐसा टेक्स्ट पढ़ता है जो आपने नहीं लिखा (README, सपोर्ट का जवाब, स्क्रैप किया गया पेज) और वह टेक्स्ट उसे कुछ करने को कहता है। अगर एजेंट के पास पूरे अधिकारों वाला टोकन है, तो घुसाए गए निर्देश के पास भी वही अधिकार हैं।
3. टोकन लीक हो जाता है। वह shell हिस्ट्री, पब्लिक repo, शेयर किए गए MCP कॉन्फ़िग या किसी लॉग लाइन में पहुँच जाता है।

MCP सर्वर जाँचता है कि टोकन वैध है और सर्वर उसी अकाउंट का है (या उसे डेलिगेट किया गया है)। आपका असली इरादा क्या था, यह उसे नहीं पता। नीचे की हर सुरक्षा-सीमा एक ही सवाल का जवाब देती है: अगर निर्देश ग़लत हो, तो नुक़सान कितना बड़ा हो सकता है?

सभी MCP टूल, जोखिम स्तर के हिसाब से

ग्राहक टोकन को 45 टूल दिखते हैं (MCP सर्वर 1.6.0)। रीसेलर टोकन (rk_…) को 30 रीसेलर टूल्स का अलग सेट दिखता है और इनमें से एक भी नहीं, इसलिए endpoint पर कुल 75 टूल हैं। आपका क्लाइंट tools/list से सिर्फ़ अपना सेट पाता है।

यह पेज टूल को जोखिम के हिसाब से बाँटता है। हर टूल के पैरामीटर और कॉल के उदाहरण पैरामीटर रेफ़रेंस में हैं; 30 रीसेलर टूल समेत सभी टूल एक-एक पंक्ति में पूरी सूची में हैं।

हम अभी MCP टूल एनोटेशन (readOnlyHint, destructiveHint) नहीं भेजते, इसलिए आपका क्लाइंट इन्हें ख़ुद नहीं छाँट सकता। नीचे दिए स्तरों के हिसाब से अनुमोदन हाथ से सेट करें।

स्तर 0 — सार्वजनिक, टोकन नहीं चाहिए (5)

स्तर 1 — अकाउंट पढ़ना, कोई साइड इफ़ेक्ट नहीं (15)

स्तर 2 — स्थिति बदलते हैं, कुछ ख़र्च नहीं करते (17)

स्तर 3 — पैसे ख़र्च करते हैं, डेटा मिटाते हैं या पहुँच देते हैं (8)

टूल सेट का बदलाव-लॉग

चल रहा संस्करण सार्वजनिक है: curl -s https://mcp.eqvps.com/healthz। जब यह बदलेगा, यह तालिका भी साथ बदलेगी।

बैलेंस ही ख़र्च की सीमा है

EQVPS प्रीपेड है। कोई सेव किया कार्ड नहीं, कोई क्रेडिट लाइन नहीं, बैलेंस माइनस में नहीं जाता: एजेंट ज़्यादा से ज़्यादा उतना ही ख़र्च कर सकता है जितना बैलेंस में है। तीन टूल पैसे ख़र्च करते हैं: order_vps, change_plan और create_sandbox। आपके मौजूदा सर्वरों का नवीनीकरण भी इसी बैलेंस से कटता है।

एजेंट पैसे की माँग बना सकता है, लेकिन भुगतान नहीं कर सकता। topup_balance और pay_invoice क्रिप्टो भुगतान का लिंक लौटाते हैं, और पीछे वॉलेट न हो तो लिंक कुछ नहीं करता। पैसे निकालने का कोई endpoint भी नहीं है: बैलेंस का पैसा आपके अकाउंट में सेवाएँ ख़रीद सकता है, बाहर नहीं जा सकता। तुरंत रद्द करने पर मिलने वाला रिफ़ंड भी बैलेंस में ही लौटता है।

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

न्यूनतम अधिकार: केवल पढ़ने वाला टोकन (अभी) नहीं है

सीधी बात: हर ग्राहक टोकन के पास वही अधिकार हैं जो डैशबोर्ड में अकाउंट के पास हैं। टोकन का नाम और अवधि सेट की जा सकती है, स्कोप नहीं।

आज सबसे संकरा विकल्प डेलिगेशन है। आप एजेंट को शून्य बैलेंस वाला उसका अपना अकाउंट देते हैं और उसे एक सर्वर डेलिगेट करते हैं:

delegate_service  { "service_id": "EQ-XXXX", "email": "agent@yourdomain.com", "expires_days": 30 }

यही REST से:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/services/EQ-XXXX/delegations" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"email":"agent@yourdomain.com","expires_days":30}'

निमंत्रण उसी ईमेल से लॉग-इन रहते हुए स्वीकार करना होता है (accept_delegation), और expires_days 1 से 365 तक हो सकता है। स्क्रीनशॉट के साथ क़दम-दर-क़दम: पहुँच डेलिगेट करना और डॉक्स में एक्सेस।

बाईं ओर की आख़िरी दो पंक्तियों पर ध्यान दें। डेलिगेट आपका पैसा ख़र्च नहीं कर सकता, लेकिन उस सर्वर को मिटा सकता है। जिस भी सर्वर को एजेंट री-इंस्टॉल कर सकता है, उस पर बैकअप चालू करें।

टोकन की साफ़-सफ़ाई

हर एजेंट का एक टोकन, नाम के साथ। इसे डैशबोर्ड → सेटिंग्स → एजेंट्स के लिए API टोकन में बनाएँ, या ऐसे:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/auth/tokens" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"backup-agent","expires_in_days":90}'

टोकन सिर्फ़ एक बार दिखता है। अवधि 1 से 1825 दिन, कुछ न बताएँ तो 365। एजेंट्स के लिए हम 90 चुनेंगे।

इसे ऐसी फ़ाइल में रखें जिसे सिर्फ़ आप पढ़ सकें, repo में नहीं, प्रॉम्प्ट में नहीं, और ऐसे shell वेरिएबल में नहीं जिसे आप इधर-उधर कॉपी करते हैं:

mkdir -p ~/.config/eqvps && chmod 700 ~/.config/eqvps
( umask 077; read -rsp 'EQVPS token: ' T; echo; printf 'EQVPS_TOKEN=%s\n' "$T" > ~/.config/eqvps/agent.env )
ls -l ~/.config/eqvps/agent.env   # अपेक्षित: -rw-------

फिर एजेंट की सर्विस में EnvironmentFile= (systemd) या set -a; . ~/.config/eqvps/agent.env; set +a से लोड करें।

अवधि ख़त्म होने से पहले बदलें। refresh_token टूल या POST /auth/tokens/{id}/refresh उसी नाम का नया टोकन जारी करता है और पुराने को तुरंत रद्द कर देता है। अगर टोकन MCP क्लाइंट के कॉन्फ़िग में सीधे लिखा है, तो तुरंत अपडेट करें, वरना अगला सेशन 401 पाएगा।

कौन क्या इस्तेमाल कर रहा है, जाँचें: GET /auth/tokens हर टोकन को नाम, एक्सपायरी और last_used_at के साथ दिखाता है। कोई अनजाना टोकन, या एजेंट बंद करने के बाद इस्तेमाल हुआ टोकन, आपके लिए चेतावनी है।

अगर टोकन लीक हो जाए

इसी क्रम में:

1. रद्द करें। डैशबोर्ड → सेटिंग्स → एजेंट्स के लिए API टोकन → रद्द करें, या curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>। अगले अनुरोध से यह काम करना बंद कर देता है।
2. नए टोकन ढूँढें जो आपने नहीं बनाए, और उन्हें भी रद्द करें।
3. देखें क्या-क्या प्रभावित हो सकता है: हर सर्वर का सेवा इतिहास, इनवॉइस और बैलेंस, और list_delegations में ऐसी पहुँच जो आपने नहीं दी।
4. root पासवर्ड बदलें हर उस सर्वर पर जिसे वह टोकन देख सकता था। reveal: true के साथ get_vps_status root पासवर्ड दे देता है, इसलिए लीक हुआ टोकन मतलब लीक हुआ root पासवर्ड। साथ ही ~/.ssh/authorized_keys भी जाँच लें।
5. पासवर्ड वाला दरवाज़ा बंद करें। अगर आपके अकाउंट पर कभी पासवर्ड नहीं था, तो टोकन रखने वाले ने set_password से एक सेट किया हो सकता है। ईमेल कोड से लॉग-इन करें और पासवर्ड बदलें।

पाँचवें क़दम की रोकथाम मुफ़्त है: अभी ख़ुद अकाउंट पासवर्ड सेट कर दें, और set_password आपके बाद आने वाले हर किसी को 409 लौटाएगा।

मानव अनुमोदन

सर्वर क्या लागू करता है:

• reinstall_vps, reset_password और type: immediate वाला cancel_service, confirm में सटीक hostname माँगते हैं (री-इंस्टॉल और रीसेट के लिए DELETE भी चलता है)।
• change_plan के लिए confirm: true चाहिए।
• डिफ़ॉल्ट रद्दीकरण end_of_period है: सर्वर चुकाई गई अवधि के अंत तक चलता है, और undo_cancel उसे वापस ले सकता है।
• हर अकाउंट की दर-सीमाएँ: री-इंस्टॉल 4/मिनट, पासवर्ड रीसेट 6/मिनट, पावर 20/मिनट, ऑर्डर 20/मिनट। इतना कि लूप में फँसा एजेंट एक ही काम पचास बार न कर दे, लेकिन एक ग़लत कॉल को रोकने के लिए काफ़ी नहीं।

साफ़ समझ लें कि confirm क्या है। यह एजेंट को "वहाँ साफ़ कर दो" जैसे निर्देश पर कुछ करने से रोकता है। यह हमलावर को नहीं रोकता, क्योंकि hostname सिर्फ़ एक get_vps_status कॉल दूर है। असली अनुमोदन आपके MCP क्लाइंट में होता है। ज़्यादातर क्लाइंट हर टूल कॉल से पहले पूछ सकते हैं: स्तर 0 और 1 को खुला छोड़ें, स्तर 3 को हमेशा पूछने दें। जिन क्लाइंट में हर टूल की अलग अनुमति होती है, जैसे Claude Code की settings.json (सर्वर eqvps नाम से दर्ज):

{
  "permissions": {
    "ask": ["mcp__eqvps__order_vps", "mcp__eqvps__change_plan", "mcp__eqvps__create_sandbox", "mcp__eqvps__reset_password", "mcp__eqvps__delegate_service"],
    "deny": ["mcp__eqvps__reinstall_vps", "mcp__eqvps__cancel_service", "mcp__eqvps__kill_sandbox"]
  }
}

एजेंट के निर्देशों में भी एक पंक्ति जोड़ें। अपने आप में यह सुरक्षा उपाय नहीं है, लेकिन ग़लतफ़हमी के मामले घटाती है (इसे अंग्रेज़ी में ही रहने दें, मॉडल इसे वैसे ही समझते हैं):

Never call reinstall_vps, reset_password, cancel_service (type=immediate), change_plan,
order_vps, create_sandbox, kill_sandbox or delegate_service unless the human has typed
the target server's hostname in this conversation for that specific action.

अगर एजेंट लंबे समय वाला टोकन रखने के बजाय ईमेल कोड से लॉग-इन करता है, तो MCP से एजेंट लॉग-इन देखें।

ऑडिट: बाद में क्या दिखता है

• टोकन सूची (GET /auth/tokens, या सेटिंग्स → एजेंट्स के लिए API टोकन): नाम, बनने की तारीख़, एक्सपायरी, last_used_at। इसी वजह से टोकन का नाम एजेंट के हिसाब से रखना फ़ायदेमंद है।
• सेवा इतिहास (डैशबोर्ड, सर्वर पेज): पावर कार्रवाइयाँ, री-इंस्टॉल, पासवर्ड रीसेट, प्लान बदलाव, भुगतान, हर एक समय और करने वाले के साथ: आप, सहायता या स्वचालित। यह नहीं बताता कि कौन-सा टोकन या डेलिगेट था, सिर्फ़ इतना कि कार्रवाई आपकी तरफ़ से आई।
• इनवॉइस और बैलेंस: हर कटौती और रिफ़ंड।
• list_delegations: किसके पास किस चीज़ की पहुँच है, और कब तक।

सेवा इतिहास की यह कमी आज सर्वर-साइड ऑडिट की ईमानदार सीमा है। अगर आपको जानना है कि किस एजेंट ने क्या किया, तो एजेंट की तरफ़ हर टूल कॉल को उसके आर्ग्युमेंट्स (सीक्रेट छोड़कर) के साथ लॉग करें।

वह सेटअप जो हम चुनेंगे

एक प्रोडक्शन सर्वर संभालने वाले एजेंट के लिए:

1. एजेंट का अलग अकाउंट, बैलेंस शून्य, सर्वर expires_days: 90 के साथ डेलिगेट।
2. आपका मालिक वाला टोकन आपके पास रहे, किसी एजेंट कॉन्फ़िग में नहीं।
3. उस सर्वर पर बैकअप, क्योंकि डेलिगेट री-इंस्टॉल कर सकता है।
4. क्लाइंट में स्तर 3 के टूल "ask" या "deny" पर।
5. एजेंट का टोकन 600 अनुमति वाली फ़ाइल में, एक्सपायरी से पहले रिफ़्रेश।

जिस एजेंट को सर्वर ऑर्डर करने हों या सैंडबॉक्स चलाने हों, उसके लिए डेलिगेशन काफ़ी नहीं, क्योंकि उसे बैलेंस चाहिए। तब बैलेंस ही आपकी सीमा है: हर काम के हिसाब से टॉप-अप करें, टोकन को नाम दें, और हफ़्ते में एक बार last_used_at देखें। अगर केवल पढ़ने वाला टोकन आपके एजेंट चलाने का तरीक़ा बदल देगा, तो हमें सहायता पर बताएँ: आगे हम क्या बनाएँगे, यह ऐसी ही प्रतिक्रियाएँ तय करती हैं।