Custom MCP tool review: hands-on security checklist

Custom MCP tools की समीक्षा उसी तरह होनी चाहिए जैसे आप ऐसे छोटे production integration की करते हैं जिसे आपके workstation, network और credentials तक access हो। Agent tool को MCP के ज़रिए call करता है, इससे उसकी authority कम नहीं होती। कई बार इससे गलत authority को बार-बार इस्तेमाल करना और आसान हो जाता है।

मैंने बार-बार एक ही गलती देखी है: developer tool का description पढ़ता है, deploy_preview या search_docs जैसा उपयोगी नाम देखता है और access दे देता है क्योंकि tool local लगता है। बाद में implementation model से मिली string को URL, shell argument या recursive file read में बदल देती है। उपयोगी tool security boundary कभी था ही नहीं। असली boundary implementation और credential path थे।

Model Context Protocol specification tools को ऐसे functions बताती है जिन्हें server client के लिए discover और call करने योग्य बनाता है। यह एक असुविधाजनक तथ्य भी साफ करती है: tool execution model-controlled होता है। Client human को approval loop में रख सकता है, लेकिन tool author को फिर भी मानकर चलना चाहिए कि arguments चौंकाने वाले, जरूरत से ज्यादा या गलत target की ओर निर्देशित हो सकते हैं। Agent को inventive होने का मौका देने से पहले tool की समीक्षा करें।

README से नहीं, authority map से शुरुआत करें

Custom MCP tool तभी स्वीकार्य है जब आप agent request से उसके प्रभाव तक पहुँचने वाला छोटा और स्पष्ट रास्ता बना सकें। पहले लिखें कि tool क्या पढ़ सकता है, data कहाँ भेज सकता है, क्या बदल सकता है और यह सब किस credential या operating-system identity से संभव होता है।

Implementation details पढ़ने से पहले यह करें। इससे code को परखने का एक standard मिलता है और अच्छा लगने वाला description आपका standard तय नहीं करता। get_build_status नाम का tool local config file पढ़ सकता है, hosted API call कर सकता है, cache लिख सकता है और command-line helper चला सकता है। हर action का failure mode अलग है।

ऐसा छोटा authority map इस्तेमाल करें:

Network row में «the internet» या credential row में «developer credentials» न लिखें। ऐसे labels का मतलब है कि review अभी शुरू ही नहीं हुई। Host, API route family, account या token और उसे revoke करने वाले व्यक्ति या system का नाम दें।

यह अभ्यास दो ऐसी चीजों को भी अलग करता है जिन्हें teams अक्सर मिला देती हैं: tool का advertised purpose और उसकी actual authority। create_issue नाम सीमित लगता है। लेकिन arbitrary base URL, arbitrary headers और arbitrary request body लेने वाला function generic HTTP client जितनी authority रखता है। Label नहीं, बाद वाली authority review करें।

Input schema को choices कम करनी चाहिए

MCP input schema को agent को उसी operation तक सीमित करना चाहिए जिसे आप अनुमति देना चाहते हैं। यह free-form command channel के चारों ओर लगाया गया decorative type definition नहीं होना चाहिए।

MCP specification tool input schemas के लिए JSON Schema इस्तेमाल करती है। इससे clients arguments दिखा सकते हैं और implementations उन्हें validate कर सकती हैं, लेकिन JSON Schema enforcement नहीं है, जब तक server काम शुरू करने से पहले invalid values reject न करे। Schema को पहला gate और server-side validation को दूसरा gate मानें।

Known build का status fetch करने वाले tool के लिए यह review योग्य schema है:

{
  "name": "get_build_status",
  "description": "Return the status for one build in the approved CI project.",
  "inputSchema": {
    "type": "object",
    "additionalProperties": false,
    "required": ["build_id"],
    "properties": {
      "build_id": {
        "type": "string",
        "pattern": "^[A-Z]{2,8}-[0-9]{1,10}$",
        "maxLength": 20
      },
      "include_logs": {
        "type": "boolean",
        "default": false
      }
    }
  }
}

यह agent के लिए कई choices तय करता है। वह host नहीं चुन सकता, headers नहीं जोड़ सकता और shell command पास नहीं कर सकता। additionalProperties false होने के कारण undeclared fields नहीं भेज सकता। Build identifier का format सीमित है, इसलिए downstream use कम खतरनाक और logs में आसान है।

अब इसकी तुलना उस shape से करें जो परेशानी पैदा करती है:

{
  "name": "request",
  "inputSchema": {
    "type": "object",
    "properties": {
      "url": {"type": "string"},
      "method": {"type": "string"},
      "headers": {"type": "object"},
      "body": {}
    }
  }
}

यह friendly handle वाला HTTP client है। अगर इसके पास bearer token है, तो यह उस token या agent-controlled prompt से मिले data को arbitrary endpoint पर भेज सकता है। Prototype बनाते समय यह design समय बचाता है, इसलिए लोग इसे रखते हैं। फिर भी production boundary के लिए यह खराब है, भले ही tool का नाम specific लगे।

Input handling को ऐसे values के साथ test करें जो केवल malformed दिखने के बजाय parsing बदलती हों। Duplicate identifier field, unexpected field, बड़ी string, Unicode lookalikes, newline और ऐसा syntactically valid value आज़माएँ जो intended business domain के बाहर जाता हो। अगर input path बनता है, तो relative identifier लें और उसे fixed directory के आधार पर resolve करें। अगर वह API filter बनता है, तो query strings जोड़ने के बजाय structured parameters इस्तेमाल करें।

Schema validate हो जाने के कारण किसी argument को shell को न सौंपें। Fixed executable path के साथ argument array इस्तेमाल करें। यह अधिक सुरक्षित है:

subprocess.run(
    ["/usr/local/bin/buildctl", "status", "--id", build_id],
    check=True,
    text=True,
    capture_output=True,
    env={"PATH": "/usr/bin:/bin"}
)

यह review failure है:

subprocess.run(f"buildctl status --id {build_id}", shell=True)

पहले form को भी validation, error handling और trustworthy executable की जरूरत है। लेकिन वह shell को model-controlled punctuation की दोबारा व्याख्या करने के लिए नहीं कहता।

हर outbound request का destination fixed होना चाहिए

Custom MCP tool के पास destinations का छोटा set होना चाहिए और connection खोलने से पहले उसका code बाकी हर destination को reject करे। Documentation में hostname allowlist लिखना बेकार है, अगर request code arbitrary URL स्वीकार करता हो।

Outbound traffic को दो स्तरों पर review करें। पहले source में HTTP libraries, WebSocket clients, DNS lookups, package installers, telemetry SDKs, webhook libraries और ऐसे helper processes खोजें जो कहीं और connect कर सकते हों। फिर वास्तविक run देखें। Static inspection intended paths दिखाती है। Runtime observation उस dependency को पकड़ती है जो home call करती है या वह configuration value जो target बदल देती है।

Safe client fixed pieces से URL बनाता है और केवल identifier को encode करता है:

from urllib.parse import quote

BASE = "https://ci.example.internal/api/builds/"
url = BASE + quote(build_id, safe="")
response = client.get(url, timeout=10, follow_redirects=False)

महत्वपूर्ण control quote नहीं, fixed origin है। अगर client redirects follow करता है, तो trusted origin untrusted host पर redirect कर सकता है। जब तक tool हर redirect destination को उसी allowlist से check न करे, redirects disable रखें।

यह internal services के लिए भी महत्वपूर्ण है। http://host/path स्वीकार करने वाले tool को local admin services या metadata endpoints तक पहुँचने के लिए बहकाया जा सकता है, जहाँ agent सीधे नहीं पहुँच सकता। Public hosts को block करना पर्याप्त नहीं है। Approved origins की positive list और literal IP addresses या private destinations को reject करने वाला rule चाहिए, जब तक tool को उनकी सचमुच जरूरत न हो।

Disposable test environment में traffic capture करें। macOS पर lsof मौजूदा network sockets की जल्दी से पहली झलक देता है:

lsof -nP -iTCP -sTCP:ESTABLISHED -c python

Output का shape process, उसके user, file descriptor और remote endpoint को दिखाता है:

COMMAND   PID  USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
python   8421  alex   12u  IPv4 0x...             0t0  TCP 10.0.0.8:51244->203.0.113.20:443 (ESTABLISHED)

python की जगह वास्तविक process name रखें और एक tool operation invoke करते समय इसे दोहराएँ। यह command complete traffic audit नहीं है। Short connections आपके देखने से पहले गायब हो सकती हैं। फिर भी यह अनपेक्षित long-lived connection या ऐसे helper को उजागर करने में अच्छी है जिसके बारे में आपको पता नहीं था।

Request payloads की भी उतनी ही सावधानी से समीक्षा करें। Tool सही approved API को call कर सकता है, लेकिन फिर भी पूरा repository diff, environment variable या agent transcript query parameter में डाल सकता है। Outbound fields को code में सीमित करें। Agent से मिले पूरे object को serialize करने के बजाय payload को उन named values से बनाएँ जिनकी operation को जरूरत है।

Process identity permission का हिस्सा है

अगर आपको पता ही नहीं कि कौन-सा executable request कर रहा है, तो आप tool use को जिम्मेदारी से approve नहीं कर सकते। केवल process name कमजोर प्रमाण है, क्योंकि कोई भी process जाना-पहचाना नाम चुन सकता है।

Complete launch command, executable path, version, working directory, parent process और user account दर्ज करें। अगर macOS code signing लागू है, तो signature authority भी देखें। codesign वह identity दिखा सकता है जिसे macOS देखता है:

codesign -dv --verbose=4 /absolute/path/to/mcp-server 2>&1 | grep -E 'Identifier|TeamIdentifier|Authority'

सामान्य output में ऐसे fields होते हैं:

Identifier=com.example.mcpserver
Authority=Developer ID Application: Example Developer
TeamIdentifier=ABCDE12345

ये fields evidence हैं, अपने-आप permission decision नहीं। Signed binary फिर भी इस काम के लिए गलत binary हो सकती है और unsigned internal script अपने-आप malicious नहीं होता। Review का सवाल है कि path, owner, source और identity उस tool से मेल खाते हैं या नहीं जिसे आप चलाना चाहते थे।

फिर invocation के दौरान process tree देखें:

ps -axo pid,ppid,user,command | grep -E 'mcp-server|sp-ssh|node|python'

आपको एक साधारण जवाब चाहिए: agent client MCP server launch करता है और server केवल वही helper processes शुरू करता है जिनकी आपको उम्मीद थी। जब server shell, package manager, mutable project directory के interpreter या session के बाद भी जीवित रहने वाले background process को launch करे, तो सावधान हो जाएँ।

Configuration file में यह सामान्य-सा failure दिख सकता है:

{
  "command": "npx",
  "args": ["-y", "some-mcp-package"]
}

Local cache और package resolution के आधार पर यह launch के समय code fetch या बदल सकता है। इससे कल के source की review उतनी भरोसेमंद नहीं रहती जितना teams मानती हैं। Executable या package version pin करें, controlled process से install करें और known local path launch करें। अगर tool को updates चाहिए, तो updates को explicit review event बनाएँ, agent शुरू करने का छिपा हुआ side effect नहीं।

Process identity में inherited environment भी शामिल है। Developer shell से launch किया गया server cloud tokens, source-control tokens, proxy settings और broad PATH inherit कर सकता है। Test runs में sanitized inventory print करें या minimal environment के साथ launch करें। Secret values log न करें। उन variable names को log करें जो behavior बदलते हैं और पुष्टि करें कि tool को ऐसे ambient credentials की जरूरत नहीं है जिनका इस्तेमाल उसके लिए intended नहीं था।

Logs को secrets दोहराए बिना actions दोबारा समझने योग्य होना चाहिए

एक उपयोगी audit record बताए कि tool किसने चलाया, किस process के तहत, किन sanitized arguments के साथ, किस destination के विरुद्ध और किस result के साथ। tool call succeeded जैसी line उस समय आपके किसी काम की नहीं होगी जब agent किसी अनपेक्षित जगह data भेज दे।

Operational logs को secret-bearing debug output से अलग रखें। Operators को investigation के लिए पर्याप्त detail चाहिए, लेकिन bearer tokens, authorization headers, private keys, raw agent transcripts या पूरी response bodies को text file में copy करने की जरूरत नहीं।

हर invocation के लिए इन जैसे fields लिखें:

{
  "time": "2025-03-08T14:22:11Z",
  "session_id": "run_7c2f",
  "process": "/opt/tools/build-mcp",
  "tool": "get_build_status",
  "argument_summary": {"build_id": "CI-4812", "include_logs": false},
  "destination": "ci.example.internal",
  "decision": "approved",
  "result": "success",
  "request_id": "c4e8..."
}

Example में argument summary जानबूझकर इस्तेमाल किया गया है। Summary में investigation में मदद करने वाले identifiers और bounded fields रखें, जबकि sensitive values को redact या hash करें। अगर operation सचमुच कोई document भेजती है, तो जहाँ correlation में मदद मिले वहाँ byte count और content digest log करें। केवल debugging आसान बनाने के लिए document को journal में न डालें।

OpenTelemetry logging model यहाँ उपयोगी है, भले ही आप OpenTelemetry अपनाएँ नहीं। यह event body को attributes से अलग करता है और filtering तथा correlation के लिए structured fields पर जोर देता है। यही विचार local स्तर पर लागू करें: destination, operation, outcome और process identity machine-readable बनाएँ। Prose log lines का ढेर तब बेकार हो जाता है जब आपको पता करना हो कि agent ने वही request दस बार भेजी या नहीं।

Error paths भी देखें। कई tools successful requests को redact करते हैं, लेकिन API error आने पर पूरा request object print कर देते हैं। 401, timeout, malformed JSON और failed DNS lookup force करें। हर emitted line पढ़ें। Credentials अक्सर debug output से बाहर निकलते हैं।

Sallyport agent runs के लिए Sessions journal और individual calls के लिए Activity journal रखता है। दोनों write-blind encrypted, hash-chained audit log से project किए जाते हैं। जब आपको tool author's logs से अलग local record चाहिए, यह design उपयोगी है, लेकिन इससे broad tool safe नहीं हो जाता। Tool को फिर भी narrow inputs और known destinations चाहिए।

Approval prompts broad authority की मरम्मत नहीं कर सकते

Human approval तभी उपयोगी brake है जब approve की जाने वाली चीज का scope समझ में आता हो। Unrecognized process किसी credential का उपयोग करना चाहता है, ऐसा card आपको एक महत्वपूर्ण बात बताता है। लेकिन यह नहीं बताता कि generic request tool पाँच seconds बाद model द्वारा चुने गए host पर repository file भेजेगा या नहीं।

Approval unit को authority unit के करीब रखें। Read-only status token और production deployment token को एक approval के पीछे न रखें, क्योंकि उनके परिणाम अलग हैं। Release record पढ़ने वाला tool उसे create करने की क्षमता चुपचाप न पाए, केवल इसलिए कि दोनों operations एक ही API इस्तेमाल करती हैं।

Model Context Protocol specification tools invoke करने से पहले clients को user consent लेने की सलाह देती है। यह सही guidance है, लेकिन consent का एक failure mode है: लोग बार-बार आने वाले, खराब तरीके से बताए गए prompts approve करते रहते हैं और prompt अंततः कोई जानकारी देना बंद कर देता है। Prompt fatigue का हल actions की पूरी category को हमेशा के लिए approve करना नहीं है। उस tool boundary को ठीक करें जो vague या excessive prompts पैदा करती है।

Sallyport की decision ladder सभी actions से पहले locked vault रखती है, default रूप से per-session authorization माँगती है और किसी specific credential के हर use पर decision आवश्यक बना सकती है। ऐसे credentials के लिए per-call approval इस्तेमाल करें जिनके हर उपयोग की जाँच आप करना चाहेंगे, जैसे deployment या write-capable API credential। इसे generic HTTP tool को वही credential देने का बहाना न बनाएँ।

अच्छे approval test के पीछे एक स्पष्ट sentence होना चाहिए: «यह signed process, इस path से launch होकर, इस run के लिए इस service से status पढ़ने हेतु इस credential का उपयोग कर सकता है।» अगर आप यह ईमानदारी से नहीं कह सकते, तो request deny करें और authority map पर लौटें।

Success पर भरोसा करने से पहले failure paths test करें

Happy path पर काम करने वाले tool ने security review पास नहीं की है। आपको देखना होगा कि inputs गलत होने पर, credential मौजूद न होने पर, network unexpected जगह की ओर जाने पर और helper process fail होने पर वह कैसे व्यवहार करता है।

Tool को test account या isolated project में ऐसे credential के साथ चलाएँ जिसका scope व्यावहारिक रूप से सबसे छोटा हो। Serialization और size limits जाँचने के लिए वास्तविक data जैसा test data इस्तेमाल करें, लेकिन केवल यह देखने के लिए production secrets किसी unreviewed tool को न दें कि क्या होता है।

यह पाँच भागों वाला test sequence अपनाएँ:

1. एक valid request के साथ tool call करें और उसका process tree, outbound destination तथा audit record capture करें।
2. Undeclared field, maximum-length value, line breaks वाली value और permitted project से बाहर का valid-looking identifier भेजें। Server को request करने से पहले हर एक को reject करना चाहिए।
3. हर उपलब्ध input और configuration route से unapproved host force करें। अगर tool HTTP इस्तेमाल करता है, तो redirects भी शामिल करें। Tool को इसे refuse करना चाहिए और sensitive input उजागर किए बिना refusal record करनी चाहिए।
4. Server के चलते रहने के दौरान credential हटाएँ या revoke करें, फिर valid request दोहराएँ। पुष्टि करें कि अगला action hidden cache या inherited environment से सफल होने के बजाय fail हो।
5. Parent agent process kill करें और देखें कि कोई server या helper process बचा तो नहीं। Agent के समाप्त होने के बाद access बनाए रखने वाले background worker के लिए स्पष्ट कारण और अलग review चाहिए।

Evidence को tool version के साथ रखें: manifest, source revision या package digest, इस्तेमाल किए गए commands, observed endpoints, sample redacted audit record और remaining risks स्वीकार करने वाले व्यक्ति का नाम। यह केवल paperwork नहीं है। Versioned evidence के बिना बाद का package update tool बदल देता है और सभी मान लेते हैं कि पुरानी review अभी भी लागू है।

एक failure पर विशेष ध्यान दें। मान लें document-search tool repository_path स्वीकार करता है और shell string के ज़रिए helper call करता है। सामान्य requests काम करती हैं। बाद में agent को ticket में embedded instruction मिलती है, जिसमें shell punctuation वाला path खोजने को कहा गया है। Helper developer account के तहत दूसरा command चलाता है, credential file पढ़ता है और tool result को अपने approved search endpoint पर भेज देता है। हर component ने वही किया जिसकी उसके author को उम्मीद थी। Composition fail हुई, क्योंकि schema ने path की अनुमति दी, shell ने उसकी दोबारा व्याख्या की और outbound payload ने arbitrary helper output स्वीकार किया। Isolated functions नहीं, chains test करें।

Access removal के लिए config entry हटाना पर्याप्त नहीं है

Agent configuration से MCP server हटाने पर सामान्य launch path रुक जाता है। इससे cache में copy हुआ token revoke नहीं होता, चल रहा server बंद नहीं होता, agent process से SSH key नहीं हटती और remote service पर access invalidate नहीं होता।

Access देते समय ही removal की योजना बनाएँ। Credential owner को पता होना चाहिए कि उसे कहाँ revoke करना है, जहाँ संभव हो tool को अलग credential इस्तेमाल करना चाहिए और operator को पता होना चाहिए कि कौन-सा process तथा local files हटाने हैं। Shared developer tokens simple removal को incident बना देते हैं, क्योंकि आप यह नहीं बता सकते कि कौन-सा use tool का था।

HTTP इस्तेमाल करने वाले tool के लिए पहले remote token revoke या disable करें। फिर MCP server और सभी child helpers रोकें, tool का local credential reference हटाएँ और launch configuration delete करें। अंत में वही request दोबारा चलाएँ और denied result सुरक्षित रखें। SSH के लिए remote account या repository से संबंधित public key हटाएँ, local helper processes समाप्त करें और alternate identities के लिए agent configuration जाँचें।

Local vault lock को remote revocation न समझें। Lock लगे रहने तक वह उस vault के ज़रिए future use रोकता है। लेकिन पहले भेजे जा चुके data को वापस नहीं ले सकता, कहीं और रखे token को invalidate नहीं कर सकता और उस unrelated process को नहीं रोक सकता जिसने पहले credential inherit कर लिया था।

Incident से पहले removal को testable बनाएँ। Runbook में remote revocation location, expected denial response, server command, config location और उन log fields की छोटी entry जोड़ें जो attempt के fail होने की पुष्टि करें। अगर tool owner यह entry नहीं दे सकता, तो integration अभी पूरी नहीं हुई है।

Narrow tool बार-बार दोहराए जा सकने वाला भरोसा कमाता है

Review में टिकने वाले tools आम तौर पर अच्छे अर्थ में boring होते हैं। वे कुछ typed fields लेते हैं, एक known service से connect करते हैं, जरूरत पड़ने पर known executable चलाते हैं, agent को केवल जरूरी result लौटाते हैं और बाद में जाँचने योग्य record छोड़ते हैं।

Broad tools flexible लगते हैं, क्योंकि वे design decisions को runtime पर agent के ऊपर डाल देते हैं। साथ ही वे एक approval को destinations, data और commands की ऐसी authority में बदल देते हैं जिसकी किसी ने review नहीं की। Flexibility अपने control वाले code में रखें और agent को narrow operation दें।

Custom tool approve करने से पहले एक input, एक destination, एक credential scope या एक child process हटाने की कोशिश करें। अगर कोई यह नहीं समझा सकता कि वह item क्यों रहना जरूरी है, तो उसे हटा दें। Review आसान होगी और eventual incident response भी।