MCP सुरक्षा और प्राधिकरण

MCP यह मानकीकृत करता है कि क्षमताओं का वर्णन और आह्वान कैसे किया जाता है। यह यह तय नहीं करता कि किसी एजेंट को कौन-सी क्षमताएँ मिलनी चाहिए या किसी उपयोगकर्ता ने किन पार्श्व प्रभावों को अनुमोदित किया है।

चार अलग-अलग निर्णय

कनेक्शन प्रमाणीकरण — क्या यह क्लाइंट इस सर्वर से कनेक्ट हो सकता है?
क्षमता दृश्यता — मॉडल को कौन-से उपकरण और संसाधन दिख सकते हैं?
निष्पादन प्राधिकरण — क्या यह पहचान इस विशिष्ट क्रिया को इस संसाधन पर अभी कर सकती है?
मानवीय अनुमोदन — क्या किसी परिणामकारी क्रिया के लिए किसी व्यक्ति को उसके सटीक इनपुट और प्रभावों की पुष्टि करनी चाहिए?

इन निर्णयों को एक autoApprove कॉन्फ़िगरेशन सूची में न मिलाएँ।

स्थानीय stdio सर्वर

एक स्थानीय चाइल्ड प्रक्रिया एप्लिकेशन होस्ट के भीतर एक शक्तिशाली स्थिति विरासत में लेती है।

एक पूर्ण, समीक्षा किया गया executable path उपयोग करें।
पैकेज और binary versions pin करें; latest tags से बचें।
केवल आवश्यक environment variables पास करें।
command-line arguments में secrets न रखें।
filesystem roots और working directories को प्रतिबंधित करें।
जब सर्वर untrusted input संभालता हो, तो OS sandbox profile लागू करें।
server descriptions, resources, और results को untrusted content मानें।

JSON-loading और runtime add/update paths server IDs को validate करते हैं। McpServerManager configured command को sandbox नहीं करता।

Remote Streamable HTTP

McpHttpClientBuilder निम्न लागू कर सकता है:

bearer tokens;
caller-selected API-key header;
arbitrary reviewed headers;
fixed OAuth 2.0 client-credentials token acquisition;
request timeouts; और
expired-session response के बाद एक bounded session reinitialization.

OAuth2Config पूरा MCP authorization flow नहीं है। यह protected-resource metadata discovery, authorization-server discovery, browser authorization, PKCE, या resource-indicator negotiation नहीं करता। जब deployment को उस flow की आवश्यकता हो, तो rmcp's authorization APIs या identity component का उपयोग करें।

Token request को सीमित करें ताकि धीमा या अनुपलब्ध authorization server connection setup को अटका न सके, और ध्यान दें कि client client secret को कभी वापस नहीं echo करता — token-endpoint error bodies को logs तक पहुँचने से पहले redacted किया जाता है:

use adk_tool::mcp::OAuth2Config;
use std::time::Duration;

let auth = OAuth2Config::new(client_id, token_url)
    .with_secret(client_secret)
    .with_scopes(vec!["mcp.read".into(), "mcp.invoke".into()])
    .with_timeout(Duration::from_secs(10)); // token request timeout

डिफ़ॉल्ट token-request timeout 30 seconds है।

टूल एक्सपोज़र और निष्पादन

with_tools या with_filter का उपयोग करें ताकि अनावश्यक क्षमताएँ model request से बाहर रहें। फिर execution time पर ADK-Rust tool authorization और confirmation लागू करें।

परिणामकारी tools के लिए:

व्यक्ति को अंतिम resolved arguments दिखाएँ;
allow-once और durable policy के बीच अंतर करें;
approval को exact function-call ID से बंधा रखें;
जहाँ संभव हो external writes को idempotent बनाएं;
approval decision और tool outcome को साथ में संग्रहीत करें; और
returned evidence की जाँच किए बिना सफल protocol response को कभी successful business outcome का प्रमाण न मानें।

सूचना-संग्रह

Elicitation अधिक जानकारी के लिए server request है, न कि ऐसा निर्देश जिसे application को मानना ही हो। संदेश, URL, requested fields, और metadata की समीक्षा करें। unsupported या unexpected requests को अस्वीकार करें। उपयोग से पहले सभी स्वीकार किए गए form values को validate करें।

लॉगिंग और secrets

environment variables, authorization headers, API keys, elicitation answers, और sensitive tool arguments को redacted करें। इसके बजाय server ID, tool name, task ID, status, timing, approval, और एक bounded result summary रिकॉर्ड करें।