लोकल AI एजेंटों के लिए MCP stdio security boundaries

लोकल MCP सर्वरों को अक्सर सुरक्षित मान लिया जाता है, क्योंकि वे stdio के ज़रिए बात करते हैं और उसी Mac पर चलते हैं जिस पर एजेंट चलता है। जैसे ही सर्वर किसी बाहरी API को कॉल कर सकता है, SSH चला सकता है, credential file पढ़ सकता है या डेवलपर के अधिकार से shell command शुरू कर सकता है, यह निष्कर्ष गलत साबित हो जाता है। लोकल transport नेटवर्क का एक चरण हटा देता है। अनुरोध पाने वाले प्रोसेस के अधिकार कम नहीं होते।

महत्वपूर्ण सीमा सीधी है: MCP सर्वर को संदर्भ और सख्ती से सीमित computation दिखाना चाहिए। Credentials और मशीन से बाहर जाने वाली कार्रवाइयां किसी trusted action gateway के पास होनी चाहिए। इन भूमिकाओं को मिलाने पर language model को untrusted instructions से स्थायी authority तक पहुंचने का आसान रास्ता मिल जाता है। मैंने यह गलती एक साफ-सुथरे one-file tool के रूप में शुरू होते देखी है, जो बाद में tokens, subprocess calls और ऐसे exceptions का ढेर बन गया जिन्हें incident के दौरान कोई समझा नहीं सकता था।

Stdio transport है, trust का फैसला नहीं

MCP stdio security की शुरुआत इस बात को स्वीकार करने से होती है कि standard input और output intent को authenticate नहीं करते। MCP client सर्वर शुरू करता है और pipes के ज़रिए JSON-RPC messages का आदान-प्रदान करता है। Model Context Protocol specification stdio को transport के रूप में बताती है: सर्वर standard input से messages पढ़ता है और standard output पर लिखता है। यह दावा नहीं किया गया है कि transport किसी अनुरोध को सुरक्षित, इंसान से approved या आपके अपेक्षित model से आया हुआ साबित करता है।

कोई लोकल client सीधे tools/call अनुरोध भेज सकता है। वह सामान्य model loop को बायपास कर सकता है, मशीन की गति से calls दोहरा सकता है, tool description में मना किए गए arguments चुन सकता है और मिलने वाले हर result को बचाकर रख सकता है। अगर कोई compromised editor extension client शुरू करती है, तो server के पास यह जानने का कोई जादुई तरीका नहीं है कि caller Claude Code या कोई दूसरा अपेक्षित caller नहीं था, जब तक आसपास का design उसे यह जानकारी न दे।

सामान्य process tree भी उतना isolation नहीं देता जितना लोग मानते हैं। अगर आपका agent आपके login के तहत MCP server शुरू करता है, तो वह server आम तौर पर आपकी user identity, working directory, environment, file permissions, network access और environment variables में छोड़ा गया secret material हासिल कर लेता है। Pipe उस authority को छोटा नहीं बनाती।

हर tool call को ऐसे process से आया untrusted request मानें जिसने model को समझाकर, या model का रूप धरकर, उसे भेजा है। यह सख्त लगता है क्योंकि यह सख्त है। यही मान्यता prompt injection, buggy clients, copied configuration और raw JSON-RPC script से request test करने वाले developer के सामने भी टिकती है।

Server को reusable authority से पहले रुक जाना चाहिए

MCP server को उस बिंदु से पहले रुक जाना चाहिए जहां उसे reusable credential दिखाने या संभालने की ज़रूरत पड़े। इसके अच्छे काम हैं indexed repository खोजना, build output parse करना, payload format करना, जानबूझकर exposed project file पढ़ना और review के लिए proposed command बनाना। इन्हें खराब तरीके से लिखने पर ये काम नुकसान पहुंचा सकते हैं, लेकिन इनके लिए ऐसा secret नहीं चाहिए जो session खत्म होने के बाद भी उपयोगी रहे।

बाहरी कार्रवाइयों का मालिक अलग होना चाहिए। Authenticated API request, SSH connection, package publish, production query या issue update untrusted input को परिणाम वाली identity से जोड़ता है। Credential उस component में रखें जो खुद request करे, फिर MCP server या agent को सीमित result लौटाए।

यह अंतर अक्सर धुंधला हो जाता है, क्योंकि दोनों components लोकल executables हो सकते हैं। वे एक-दूसरे के विकल्प नहीं हैं:

• MCP server agent request को सीमित operation या operation के request में बदलता है।
• Action gateway credential रखता है, तय करता है कि यह process उसका इस्तेमाल कर सकता है या नहीं, external call चलाता है और जो हुआ उसका record रखता है।
• Agent को output मिलता है, authenticated action को gateway के बाहर दोहराने का साधन नहीं।

API_TOKEN=... को tool result के रूप में न भेजें। Vault reference भेजकर उसे सुरक्षित न मानें। ऐसा command expose न करें जो private key को stdout पर छापे और यह भरोसा न करें कि model उसे देखने से बच जाएगा। Client को secret मिलते ही बाद का हर control केवल सलाह रह जाता है।

Gateway को all-purpose shell API भी नहीं बनना चाहिए। run(command) आकर्षक shortcut है, क्योंकि इससे tool design की ज़रूरत नहीं रहती। लेकिन इससे argument parsing, file access, network destinations और अक्सर secret access एक opaque string को मिल जाते हैं। इसके बजाय narrow actions बनाएं: get_deployment_status, create_issue, run_readonly_query या named host और सीमित command family वाला ssh_exec। Narrow actions validation और review को संभव बनाते हैं।

Tool schemas calls का वर्णन करते हैं, उन्हें सीमित नहीं करते

किसी tool के लिए JSON Schema उपयोगी input validation है, लेकिन authorization नहीं। MCP specification tools को input schemas publish करने को कहती है और clients उनका इस्तेमाल calls बनाने में कर सकते हैं। फिर भी model schema-valid कोई भी value चुन सकता है। इससे भी खराब बात यह है कि ढीले implementations अक्सर schema-valid string स्वीकार करते हैं और बाद में उसे shell command या URL में जोड़ देते हैं, जहां उसका अर्थ बदल जाता है।

मान लें कि कोई tool deployment status लाने के लिए है:

{
  "name": "deployment_status",
  "inputSchema": {
    "type": "object",
    "properties": {
      "environment": {"enum": ["staging", "production"]},
      "service": {"type": "string", "pattern": "^[a-z0-9-]{1,48}$"}
    },
    "required": ["environment", "service"],
    "additionalProperties": false
  }
}

यह schema अनपेक्षित top-level field को रोकता है और service में दिखाई देने वाले shell punctuation को अस्वीकार करता है। लेकिन यह caller को production देखने की अनुमति नहीं देता, यह साबित नहीं करता कि service मौजूदा repository का हिस्सा है और server द्वारा URL बनाने के बाद HTTP destination को सीमित नहीं करता। Schema validator पूछता है, «क्या इसका आकार सही है?» Authorization पूछता है, «क्या यह caller इस identity के साथ अभी यह कार्रवाई कर सकता है?» इन दोनों सवालों को code और review में अलग रखें।

खराब implementation अक्सर ऐसा दिखता है:

subprocess.run(
    f"ssh {host} systemctl status {service}",
    shell=True,
    check=True,
)

भले ही host और service ढीले schema से पास हो जाएं, shell parsing एक दूसरी language और एक दूसरा attack surface बना देती है। Argument vectors का इस्तेमाल करें, connection खोलने से पहले अनजान hosts को अस्वीकार करें और gateway को credential किसी fixed identifier से चुनने दें। Agent से मिला path या token name स्वीकार न करें।

HTTP के लिए connect करने से पहले URL parse करें, https अनिवार्य करें, normalized hostname की तुलना approved exact host list से करें और redirects को बंद करें या दोबारा validate करें। किसी allowed host से internal address या attacker-controlled endpoint पर redirect होने से सामान्य दिखने वाला request credential disclosure में बदल सकता है। url.startswith("https://api.example.com") जैसे prefix check पर निर्भर न रहें। User information, ports और lookalike hostnames string checks को अविश्वसनीय बना देते हैं।

Approval point पर process identity दिखाई देनी चाहिए

Human approval button तभी मदद करता है जब वह बताए कि कौन request कर रहा है और उस approval से कौन-सी authority मिलेगी। «Allow agent access» कमजोर है, क्योंकि इसमें वह executable छिप जाता है जिसे permission मिलेगी और permission कितनी देर रहेगी यह भी पता नहीं चलता। इससे लोग गतिविधि की एक अस्पष्ट category को approve करने के आदी हो जाते हैं।

बेहतर design requesting process की पहचान उसकी code-signing authority, parent relationship, executable path और process lifetime से करता है। तब इंसान किसी label को स्थायी रूप से approve करने के बजाय किसी ज्ञात client के एक run को approve कर सकता है। Process बंद होते ही उसका approval खत्म होना चाहिए। नए process के लिए नया निर्णय चाहिए।

Code signing यह साबित नहीं करती कि client के अंदर हर prompt या plugin harmless है। यह एक छोटा लेकिन उपयोगी सवाल हल करती है: authority किस signed executable ने मांगी? यह फर्क तब महत्वपूर्ण है जब कोई malicious या बदला हुआ local program भरोसेमंद नाम का इस्तेमाल करे। macOS आपको code-signing information देता है जिसे gateway किसी process को कार्रवाई करने देने से पहले दिखा सकता है।

Sallyport per-session authorization के लिए process identity का इस्तेमाल करता है, जबकि उसका locked vault हर कार्रवाई को तब तक रोकता है जब तक user Mac के hardware-gated controls से उसे खोल न दे। यह model जानबूझकर छोटा है: locked vault, नए process के लिए approval और किसी खास credential के हर इस्तेमाल के लिए optional approval।

Approval fatigue दूर करने के लिए complicated natural-language policy न बनाएं। दर्जनों exceptions बढ़ जाने के बाद लोग dense rule set का भरोसेमंद मूल्यांकन नहीं कर सकते। थोड़े ऐसे फैसले रखें जो developer को साफ दिखाई दें: secrets उपलब्ध हैं या नहीं, इस run में कौन-सा process कार्रवाई कर सकता है और किन credentials के लिए हर बार नई confirmation चाहिए।

Approval scope कार्रवाई से होने वाले नुकसान के अनुरूप होना चाहिए

Issue tracker पढ़ने या development service की स्थिति जांचने जैसे बार-बार होने वाले low-impact कामों के लिए एक session approval ठीक है। जब वही approval destructive database changes, package publication, money movement, customer communications या production SSH access को भी चुपचाप शामिल करने लगे, तो यह खतरनाक हो जाता है।

हर credential की अपनी approval sensitivity रखें। Process को session approval मिलने के बाद read-only token काम कर सकता है। Production write token या SSH key के लिए हर इस्तेमाल पर confirmation होनी चाहिए। Gateway को इतना context दिखाना चाहिए कि इंसान कार्रवाई का फैसला कर सके: credential identity, target host या service, method या command class और साफ किए गए arguments। Secret खुद न दिखाएं।

Approval को concrete request को authorize करना चाहिए, इस वादे को नहीं कि agent बाद में ठीक व्यवहार करेगा। अगर tool call POST /releases कहती है, तो approval view को इसे «release API का इस्तेमाल» में नहीं बदलना चाहिए। Method, final destination और operation name ही वे तथ्य हैं जो harmless read और irreversible write के बीच फर्क बताते हैं।

लोकप्रिय विकल्प broad allowlist है: किसी domain, shell binary या पूरे workday के लिए agent को approve करना। यह तब तक efficient लगता है जब तक injected instruction उसी allowed capability को किसी दूसरे repository, endpoint या argument की ओर नहीं मोड़ देता। Broad grants interruptions कम करते हैं, लेकिन review का बोझ उस समय पर डाल देते हैं जब actual call दिखाई नहीं देती।

Expiration का भरपूर इस्तेमाल करें। Client process खत्म होते ही session grant भी खत्म हो जाना चाहिए। Per-call decision उस एक operation के बाद समाप्त हो। अगर gateway को बाद में लंबे grants देने हों, तो scope और expiry स्पष्ट रखें। Cached approval को permanent trust जैसा न दिखने दें।

SSH को shell escape hatch नहीं, अपनी boundary चाहिए

लोकल agent designs अक्सर SSH के मामले में अनुशासन खो देते हैं। Developers के पास पहले से SSH agent, host aliases, forwarded keys और terminal में arbitrary commands टाइप करने की आदत होती है। इसलिए MCP server को user के मौजूदा environment के साथ ssh चलाने देने का मन होता है। इससे agent को हर उस identity और host rule का caller बना दिया जाता है जहां आपका shell पहुंच सकता है।

OpenSSH agent forwarding की एक गंभीर सीमा बताता है: जिस remote user को forwarded agent socket तक पहुंच मिल सकती है, वह आपके local agent से operations का अनुरोध कर सकता है, भले ही private keys निकाल न सके। Forwarding जारी रहने तक इतना ही आपके रूप में कार्रवाई करने के लिए काफी है। Autonomous agent को इस रास्ते को casually नहीं अपनाना चाहिए, क्योंकि इससे authority मूल host से आगे फैल जाती है।

Agent work के लिए dedicated SSH identity इस्तेमाल करें और उसे named host record से बांधें। Server पर उस identity को account के लिए उचित options से सीमित करें, जैसे forced command और जहां use case अनुमति दे वहां forwarding बंद करना। Local side पर host और identity को agent control से बाहर रखी configuration से चुनें। Agent host: build-staging और limited command action मांग सकता है, लेकिन उसे arbitrary hostname, private-key path या -o ProxyCommand=... नहीं भेजना चाहिए।

Action gateway जिस request को validate कर सकता है, उसका न्यूनतम रूप यह है:

{
  "action": "ssh_exec",
  "host_id": "build-staging",
  "command_id": "read_service_status",
  "args": {"service": "worker"}
}

Gateway build-staging को ज्ञात host, host key policy, account और dedicated credential से map करता है। read_service_status को fixed argument vector से map करता है। यह payload को shell string में concatenate नहीं करता। Rejected request का कारण audit record में होना चाहिए, लेकिन उसमें secret material या terminal में संभावित रूप से hostile data दोहराया नहीं जाना चाहिए।

अगर आपको arbitrary remote diagnosis चाहिए, तो उसे per-call confirmation और स्पष्ट output limits वाली अलग, high-friction operation बनाएं। Arbitrary shell access को check_server जैसे खुशमिजाज tool name के पीछे न छिपाएं।

Audit records को उस actor से बचा रहना चाहिए जिसने कार्रवाई की

उसी process द्वारा लिखी गई text log जो कार्रवाई करता है, तब तक ही evidence है जब तक वह process उसे बदलना न चाहे। Agent activity के लिए ऐसा record चाहिए जिससे operator पूरे run और हर external call को दोबारा बना सके और बाद में deletion या editing का पता लगा सके।

Process identity, session identifier, time, action type, credential identifier, approved target, साफ की गई request shape, approval result, response status और error category record करें। Session journal और action journal अलग रखें। Session view पूछता है, «किस agent run के पास authority थी?» Action view पूछता है, «उस authority से उसने क्या किया?» Investigator को flat lines के stream से एक को दूसरे का अनुमान लगाने के लिए मजबूर न करें।

Hash chain integrity check का व्यावहारिक तरीका देती है। हर record के लिए पिछले record digest और नए encrypted record के canonical bytes पर digest निकालें। नया digest record के साथ रखें। Verifier plaintext की ज़रूरत के बिना बदला हुआ record, बीच से हटाया गया record या बदला हुआ क्रम पहचान सकता है।

Audit verifier agent से स्वतंत्र चलना चाहिए और उसे credentials की access नहीं होनी चाहिए। Command interface इतना साधारण हो सकता है:

$ sp audit verify
records: 184
first sequence: 1
last sequence: 184
chain: valid

इस output shape से operator को ticket या incident record में capture करने के लिए कुछ निश्चित मिलता है। Verification fail होने पर command को वह पहला sequence बताना चाहिए जहां continuity टूटी और nonzero exit status लौटाना चाहिए। «Log unreadable» investigation के लिए बहुत अस्पष्ट है।

Tamper evidence और tamper prevention एक ही बात नहीं हैं। पर्याप्त access वाला local user पूरा log मिटा सकता है या storage को पीछे की स्थिति में ले जा सकता है। इस सीमा को स्पष्ट रखें। अगर stakes local rollback के विरुद्ध proof मांगते हैं, तो signed checkpoints को अलग controlled system में export करें। Local hash chain से ऐसा threat हल होने का दावा न करें जिसे वह संबोधित नहीं करती।

Secrets को environment variables और tool output से दूर रखें

Environment variables human shell session के लिए सुविधाजनक और autonomous agents के लिए कमजोर containment हैं। Child process उन्हें default रूप से inherit करता है। Debug logging उन्हें छाप सकती है। Environment सूची दिखाने वाला command उन्हें model को लौटा सकता है। Crash reports, support bundles, process inspection और copied terminal transcripts ने इसी तरह secrets उजागर किए हैं।

Workspace में credential file रखना इससे भी खराब है। Model उसे पढ़ सकता है, tool उसे upload कर सकता है, Git command उसे stage कर सकती है और indexing service उसकी copy बचा सकती है। File को hidden directory में ले जाने से दुर्घटनाओं की संख्या घट सकती है, लेकिन security boundary नहीं बदलती।

Credentials को action gateway के नियंत्रण वाले vault में रखें। Gateway fixed action mapping के आधार पर credential चुनता है और उसे केवल अपने HTTP या SSH operation में inject करता है। Response body तभी लौटाएं जब उसे filter करने के बाद agent के लिए सुरक्षित हो। Bearer token MCP result से कभी नहीं गुजरना चाहिए, redacted रूप में भी नहीं, क्योंकि redaction की गलती transcript का स्थायी हिस्सा बन जाती है।

HTTP के लिए raw pass-through के बजाय response contract बेहतर है। Deployment status action ऐसा result लौटा सकता है:

{
  "environment": "staging",
  "service": "worker",
  "state": "healthy",
  "revision": "a1b2c3d4"
}

उसे ऐसे response headers नहीं लौटाने चाहिए जिनमें session identifiers, internal routing details या नया token हो सकता है। Implementation से पहले तय करें कि agent को कौन-से fields चाहिए। Raw proxy response एक और shortcut है जिसे बाद में हटाना महंगा पड़ता है।

छोटी boundary को दबाव में चलाना आसान होता है

आप local agent integration की review बिना policy language या बड़े security program के कर सकते हैं। Action inventory से शुरू करें और हर action को दो buckets में डालें: या तो वह reusable authority के बिना local context पढ़ता या compute करता है, या फिर external service तक पहुंचता है और उसे gateway चाहिए।

हर external action के लिए लिखें कि fixed target identity क्या है, gateway कौन-सा credential चुनता है, agent किन exact arguments को प्रभावित कर सकता है, approval scope क्या है और कौन-सा audit record बनेगा। अगर किसी row में «arbitrary command», «any URL», «token from environment» या «agent chooses credential» लिखा है, तो boundary अभी पूरी नहीं हुई।

Agent को उपयोगी secret देने से पहले यह failure exercise चलाएं:

1. ऐसा raw schema-valid request भेजें जिसमें अनपेक्षित target या बहुत बड़ा argument हो।
2. Client process बंद होने के बाद पहले से approved request दोबारा चलाने की कोशिश करें।
3. Redirected HTTP request और forwarding options वाला SSH request आजमाएं।
4. Vault lock करें और पुष्टि करें कि network connection खुलने से पहले हर action fail हो जाती है।
5. Stored audit record में एक बदलाव करें और जांचें कि audit command टूटी हुई chain पहचानता है।

ये tests उन design errors को पकड़ते हैं जिन्हें एक pleasant demo छिपा देता है। Instructions का पूरी तरह पालन करने वाला model security test नहीं है।

सबसे साफ local architecture MCP server को साधारण और disposable रखता है। उसे उपयोगी context expose करने दें और narrowly designed operations का request करने दें। Secrets, process-aware approval, execution और auditable record को action boundary के पीछे रखें। जब कोई पूछे कि tool को production token सीधे क्यों नहीं मिल सकता, तो जवाब design में साफ होना चाहिए: अपना काम करने के लिए tool को token की ज़रूरत कभी थी ही नहीं।