MCP टूल के विवरण प्रोडक्शन की गलतियां कैसे रोकते हैं

MCP टूल का विवरण किसी असुरक्षित प्रोडक्शन कॉल को शुरू होने से पहले रोक सकता है, या खतरे को किसी दोस्ताना क्रिया-शब्द के पीछे छिपा सकता है। ज्यादातर आकस्मिक प्रोडक्शन कार्रवाइयां एजेंट के नुकसान पहुंचाने का फैसला करने से शुरू नहीं होतीं। वे तब शुरू होती हैं, जब अस्पष्ट विवरण किसी विनाशकारी टूल को निरीक्षण वाले टूल जैसा दिखाता है।

हर ऐसी टूल परिभाषा को एक छोटे ऑपरेशनल कॉन्ट्रैक्ट की तरह लिखें जो सिस्टम की स्थिति बदलती है: लक्ष्य सिस्टम का नाम, होने वाला प्रभाव और पुष्टि की जरूरत, तीनों स्पष्ट करें। इनमें से कोई बात छूट जाए तो विवरण मॉडल से ऐसी सुरक्षा सीमा का अनुमान लगाने को कहता है, जिसे आपके कोड को साफ-साफ लागू करना चाहिए था।

मैंने पर्याप्त एक्शन इंटरफेस देखे हैं कि «manage», «sync», «deploy» और «cleanup» जैसे लेबलों पर भरोसा नहीं करता। लेखक के लिए ये सुविधाजनक होते हैं, लेकिन उस व्यक्ति के लिए महंगे पड़ते हैं जिसे समझाना पड़ता है कि टेस्ट अनुरोध लाइव अकाउंट तक कैसे पहुंच गया। अच्छा विवरण असुविधाजनक बातों को नजरअंदाज करना मुश्किल बना देता है।

टूल का विवरण प्रोडक्ट कॉपी नहीं, निष्पादन चेतावनी है

MCP टूल के विवरण को एजेंट और उसके मानव ऑपरेटर को बताना चाहिए कि कॉल सफल होने पर क्या होगा। उसे क्षमता का प्रचार नहीं करना चाहिए, किसी आंतरिक सबसिस्टम का सार नहीं देना चाहिए और टूल के नाम को लंबे वाक्य में दोहराना नहीं चाहिए।

Model Context Protocol के टूल स्कीमा में टूल नाम और inputSchema के साथ पढ़ने योग्य description भी होता है। MCP स्पेसिफिकेशन readOnlyHint और destructiveHint जैसे टूल एनोटेशन की अनुमति देता है। ये एनोटेशन क्लाइंट को टूल दिखाने में मदद करते हैं, लेकिन स्पेसिफिकेशन के अनुसार क्लाइंट को इन्हें केवल संकेत मानना चाहिए। ये अनुमति जांच नहीं हैं। इसलिए कॉल आपकी सेवा तक पहुंचने से पहले वास्तविक परिणाम पढ़ने के लिए विवरण अब भी जरूरी है।

इन दो परिभाषाओं पर ध्यान दें:

{
  "name": "delete_backup",
  "description": "Deletes a backup.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "backup_id": { "type": "string" }
    },
    "required": ["backup_id"]
  }
}

{
  "name": "delete_production_backup",
  "description": "Permanently deletes one backup from the Production PostgreSQL backup store. This removes a recovery point and cannot be undone. Ask the user to confirm the backup ID and its timestamp before calling this tool.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "backup_id": {
        "type": "string",
        "description": "Immutable backup ID returned by list_production_backups."
      }
    },
    "required": ["backup_id"],
    "additionalProperties": false
  },
  "annotations": {
    "destructiveHint": true,
    "readOnlyHint": false
  }
}

दूसरी परिभाषा केवल सावधान सुनाई नहीं देती। यह एजेंट को लक्ष्य, अपरिवर्तनीय परिणाम, ऑब्जेक्ट की सुरक्षित पहचान का तरीका और बातचीत में जरूरी ठहराव देती है। समीक्षक को भी इतनी जानकारी मिलती है कि वह इम्प्लीमेंटेशन की बारीकियां जांचने से पहले कॉल अस्वीकार कर सके।

यह न मानें कि जोरदार क्रिया-शब्द समस्या हल कर देता है। «Destroy», «delete» से अधिक चेतावनी देता है, लेकिन फिर भी यह नहीं बताता कि कौन सा अकाउंट, कौन सा डेटा वर्ग या पुष्टि कैसे संभाली जाएगी। यह संदर्भ विवरण में होना चाहिए।

पहले वाक्य में लक्ष्य सिस्टम रखें

पहले वाक्य में प्रभावित सटीक सिस्टम, वातावरण या अकाउंट सीमा सहित, पहचान में आना चाहिए। «डेटाबेस» से डिस्पोजेबल लोकल कंटेनर, साझा टेस्ट सेवा, staging tenant या प्रोडक्शन ग्राहक लेजर, कुछ भी समझा जा सकता है। API endpoint एक जैसा होने पर भी ये अलग कार्रवाइयां हैं।

ऐसे नाम चुनें जिन्हें ऑपरेटर अपने काम में पहचानता हो। «Production payments account», «staging Kubernetes cluster», «customer tenant northwind» या «repository mobile-api release branch» लिखें। आंतरिक उपनामों से बचें, जब तक हर इच्छित ऑपरेटर उन्हें न जानता हो और नाम आर्ग्युमेंट में भी न आता हो।

यह क्रम इसलिए काम करता है क्योंकि जोखिम को तकनीकी विवरण से पहले रखता है:

[Target system]. [Action and result]. [Confirmation rule].

उदाहरण:

Production identity directory. Disables the selected user account and ends active sessions. Ask the user to confirm the username before calling.

लक्ष्य हैंडलर से मेल खाना चाहिए, लेखक के इरादे से नहीं। अगर टूल environment आर्ग्युमेंट लेता है, तो «Updates staging» कहने वाला विवरण उस क्षण गलत हो जाता है जब कोई कॉलर production भेजता है। ऑपरेशन को वातावरण के अनुसार अलग टूल में बांटें या साफ-साफ बताएं कि आर्ग्युमेंट किन मानों की अनुमति देता है।

अलग-अलग टूल चलाना आमतौर पर आसान होता है:

list_staging_feature_flags
set_staging_feature_flag
list_production_feature_flags
request_production_feature_flag_change

यह डिजाइन दोहराव वाला लग सकता है। दोहराव उस टूल चयन से सस्ता है जिसमें set_feature_flag सही दिखाई देता है और बाद में पता चलता है कि वैकल्पिक आर्ग्युमेंट production पर लागू हो गया।

नामों के साथ भी यही अनुशासन रखें, लेकिन नाम पूरी चेतावनी नहीं दे सकते। टूल सूचियां नामों को छोटा कर देती हैं। समान नामों के बीच चुनते समय एजेंट कभी-कभी विवरण पर ध्यान देता है। दबाव में इंसान दोनों को देखता है। जहां संभव हो, लक्ष्य दोनों जगह रखें और ऐसा पूरा विवरण लिखें जो नाम दिखाई न देने पर भी स्पष्ट रहे।

एक अपवाद वह टूल है जिसे immutable resource URI मिलता है और जिसका host पहले ही वातावरण तय कर देता है। फिर भी विवरण में host या अकाउंट वर्ग लिखें। UUID किसी इंसान को यह नहीं बताता कि वह development रिकॉर्ड है या लाइव ग्राहक का।

प्रभाव को पूर्ण हो चुके परिणाम की तरह लिखें

सुरक्षित विवरण बताता है कि कॉल सफल होने के बाद दुनिया कैसी दिखेगी। इससे लेखक को निरीक्षण और बदलाव, वापस किए जा सकने वाले और स्थायी बदलाव, तथा अनुरोध और निष्पादन के बीच फर्क करना पड़ता है।

अस्पष्ट «manage» शब्द की तुलना करें:

Manages service deployments.

इसमें कई अलग परिणाम छिप जाते हैं। डिप्लॉयमेंट टूल रिलीज बना सकता है, मौजूदा रिलीज को प्रमोट कर सकता है, इंस्टेंस रीस्टार्ट कर सकता है, ट्रैफिक बदल सकता है, कोड रोलबैक कर सकता है या केवल स्थिति दिखा सकता है। जब किसी ऑपरेशन का असफल होने का तरीका या अनुमोदन नियम अलग हो, तो उसके लिए अलग टूल रखें।

स्पष्ट परिणाम लिखें:

Creates a deployment request for the Production catalog service. It does not change running instances. A release manager must approve the request in the deployment system.

या:

Changes Production catalog traffic so the specified release receives 100 percent of requests. Existing requests may finish on the prior release. Ask the user to confirm the release version before calling.

अनुरोध बनाने और उसे चलाने का फर्क HTTP POST और PATCH के फर्क से अधिक महत्वपूर्ण है। अनुरोध ऑब्जेक्ट फिर भी काम शुरू कर सकता है, कोटा खर्च कर सकता है या लोगों को सूचना भेज सकता है, इसलिए उस प्रभाव को भी लिखें। लेकिन अगर वह केवल अनुमोदन आइटम खोलता है, तो उसे लाइव डिप्लॉयमेंट न कहें।

शिष्ट या घुमावदार शब्दों से बचें। «Retires» का अर्थ archive, disable, delete या billing समाप्त करना हो सकता है। «Cleans up» का अर्थ अस्थायी फाइलें हटाना या ग्राहक के एक्सपोर्ट की एकमात्र बची हुई कॉपी मिटाना हो सकता है। वास्तविक क्रिया और ऑब्जेक्ट लिखें: deletes, disables, rotates, promotes, transfers, sends, charges या publishes।

जिन कार्रवाइयों का प्रभाव देर से होता है, उसमें देरी बताएं। DNS बदलाव API लौटने के बाद लागू हो सकता है। उपयोगकर्ता को हटाने से भविष्य का एक्सेस रुक सकता है, जबकि ऑडिट रिकॉर्ड बने रह सकते हैं। क्रेडेंशियल बदलने से पुराने secret इस्तेमाल करने वाले क्लाइंट निष्क्रिय हो सकते हैं। एजेंट को यह संदर्भ चाहिए, ताकि वह पहले निर्भर सिस्टमों की जांच कर सके।

अगर एक कॉल कई ऑब्जेक्ट प्रभावित करती है, तो उसका दायरा भी लिखें। «चुना गया रिकॉर्ड मिटाता है» और «दिए गए query से मेल खाने वाले सभी रिकॉर्ड मिटाता है» अलग बातें हैं। एकवचन क्रिया के पीछे छिपा batch endpoint परेशानी पैदा करता है।

पुष्टि की भाषा किसी वास्तविक नियंत्रण का वर्णन करे

पुष्टि वाला वाक्य तभी उपयोगी है, जब इम्प्लीमेंटेशन और संचालन प्रक्रिया उसका पालन करें। ऐसे टूल पर «requires confirmation» लिखना जो तुरंत चल जाता है, दिखावा है और अंततः एजेंट इसे उजागर कर देगा।

तीन अलग तरीके हैं। विवरण में वही तरीका लिखें जिसका आप सच में उपयोग करते हैं।

1. एजेंट अपनी बातचीत में उपयोगकर्ता से पूछता है और फिर कार्रवाई करता है। यह एजेंट के विवरण का पालन करने पर निर्भर है और बदले हुए या लापरवाह क्लाइंट को नहीं रोकता।
2. टूल किसी अलग व्यक्ति या सिस्टम की मंजूरी के लिए अनुरोध बनाता है। कॉल का अपना प्रभाव होता है, लेकिन वर्णित प्रोडक्शन बदलाव प्रतीक्षा करता है।
3. निष्पादन गेटवे कार्रवाई रोकता है और क्रेडेंशियल भेजने या लक्ष्य सिस्टम से संपर्क करने से पहले मानव अनुमोदन मांगता है।

इन तरीकों को «confirmation required» में समेटें नहीं। इनसे मिलने वाली सुरक्षा और ऑडिट प्रमाण अलग-अलग हैं।

ऐसी क्रियाएं इस्तेमाल करें जिनसे कर्ता और समय स्पष्ट हों:

Before calling, ask the user to confirm the repository name and release tag.

Calling this tool submits a change request. The deployment system requires a release manager to approve it before any production release begins.

This action gateway asks a human to approve every call before it sends the request to the Production payments API.

अंतिम वाक्य लागू की गई सीमा बताता है। पहला एजेंट को दिया गया निर्देश है। दोनों उपयोगी हो सकते हैं, लेकिन एक समान नहीं हैं।

एजेंट से अस्पष्ट पुष्टि मांगने को कभी न कहें। बताएं कि व्यक्ति को किन तथ्यों की मंजूरी देनी है। deletion के लिए resource name, account और retention status जरूरी हो सकते हैं। transfer के लिए source, destination, amount और currency। release के लिए service, version और traffic scope। विवरण में औपचारिक रस्म नहीं, गलत लक्ष्य पकड़ने वाले तथ्य मांगें।

पुष्टि नियम का दायरा भी होना चाहिए। «प्रोडक्शन बदलाव से पहले मंजूरी लें» कमजोर है, अगर एक ही सत्र एक मंजूरी के बाद दस कॉल चला सकता है। अगर वास्तविक नियंत्रण पूरे सत्र के लिए मंजूरी देता है, तो उसे प्रोडक्ट दस्तावेज में लिखें और यह दावा न करें कि हर कॉल पर अलग ठहराव मिलता है।

जब हैंडलर छिपा काम करता है तो read-only दावे विफल होते हैं

किसी टूल को read-only तभी कहें, जब उसका हैंडलर जानबूझकर लक्ष्य सिस्टम में बदलाव न करता हो। यह शब्द व्यवहार बताता है, HTTP method, डेटाबेस अनुमति के नाम या लेखक की आशा नहीं।

GET अनुरोध session रीफ्रेश कर सकता है, last accessed फ़ील्ड बदल सकता है, export बना सकता है, report job शुरू कर सकता है या लागत वाला cache fill कर सकता है। POST अनुरोध भी सुरक्षित हो सकता है, अगर वह dry run करता है और कुछ सेव नहीं करता। लेबल चुनने से पहले हैंडलर और उसके downstream calls देखें।

MCP का readOnlyHint एनोटेशन उन क्लाइंटों के लिए उपयोगी है जो निरीक्षण टूल से जुड़ी रुकावट कम करना चाहते हैं। फिर भी यह केवल संकेत है, इसलिए सर्वर को अपनी सीमा लागू करनी होगी। इससे भी जरूरी है कि विवरण ऑपरेटर को चौंकाने वाले अपवाद लिखे।

यह विवरण भ्रामक है:

Read-only tool for checking invoice status.

अगर endpoint document view event बनाता है, third party token रीफ्रेश करता है या remote calculation शुरू करता है, तो यह गलत है। अधिक ईमानदार रूप:

Retrieves the current status of one Production invoice. It does not edit the invoice or charge the customer. The billing provider records this request in its access log.

निरीक्षण कार्रवाई के लिए access log आमतौर पर स्वीकार्य है। लेकिन compliance नियम, retrieval की लागत या reads पर प्रतिक्रिया देने वाला workflow हो, तो यह महत्वपूर्ण बन जाता है। हर विवरण को कानूनी नोटिस बनाए बिना ऐसे प्रभाव लिखें।

जहां संभव हो, dry run और निष्पादन अलग रखें। dry_run boolean वाला deploy टूल एक ही परिभाषा में दो सुरक्षा प्रोफाइल रखता है। एजेंट default छोड़ सकता है, सर्वर के उसे मानने को गलत समझ सकता है या payload बदलना भूलकर दोबारा इस्तेमाल कर सकता है। plan_production_deployment और execute_production_deployment टूल चयन, लॉग और समीक्षा में अंतर साफ करते हैं।

यही नियम validation टूल पर भी लागू होता है। «Validate configuration» सुरक्षित सुनाई देता है, लेकिन कुछ provider validation के दौरान संसाधन बनाते या लाइव dependency से संपर्क करते हैं। ऐसा हो तो इसे कार्रवाई की तरह लिखें और उचित पुष्टि नियम लगाएं।

एक व्यापक टूल अनुमोदन में गलतियां पैदा करता है

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

इस पैटर्न से बचें:

{
  "name": "admin",
  "description": "Administer users, deployments, secrets, and configuration across environments.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "operation": { "type": "string" },
      "environment": { "type": "string" },
      "payload": { "type": "object" }
    },
    "required": ["operation", "environment", "payload"]
  }
}

यह परिभाषा समीक्षा की उपयोगी इकाई नष्ट कर देती है। समीक्षक टूल कार्ड देखकर नहीं बता सकता कि कॉल स्थिति लाएगी, क्रेडेंशियल बदलेगी या उपयोगकर्ता मिटाएगी। operation string महत्वपूर्ण अर्थ को देर से आने वाले आर्ग्युमेंट में भेज देती है, जिसे नजरअंदाज करना आसान है।

इसके बजाय इरादे और जोखिम के आधार पर विभाजित करें:

get_production_deployment_status
plan_production_deployment
submit_production_deployment_request
rotate_production_service_credential
create_production_user_access_request

हर endpoint के लिए अलग टूल जरूरी नहीं है। अलग टूल वहां चाहिए जहां लक्ष्य, प्रभाव या पुष्टि बदलती है। कोई batch टूल तब भी batch रह सकता है, जब वह हमेशा एक सीमित resource type को छूता हो और हमेशा समान अनुमोदन मांगता हो। उसके विवरण में बताएं कि वह कई ऑब्जेक्ट प्रभावित कर सकता है और कॉलर चयन को कैसे सीमित करता है।

आर्ग्युमेंट के विवरण भी जरूरी हैं। टूल विवरण बताता है कि ऑपरेशन क्या करता है, जबकि आर्ग्युमेंट विवरण खतरनाक विकल्पों को सीमित करता है। जहां संभव हो, environments और action types के लिए enums इस्तेमाल करें। अनपहचाने मान सर्वर साइड पर अस्वीकार करें। freeform string में «production» लिखकर विवरण के भरोसे न रहें।

सीमित टूल बेहतर ऑडिट रिकॉर्ड भी बनाता है। जर्नल में rotate_production_service_credential लिखा हो तो जांचकर्ता आर्ग्युमेंट खोले बिना कार्रवाई का वर्ग समझ जाता है। admin लिखा हो तो उसे payload से इरादा फिर से बनाना पड़ता है।

हैंडलर से पहले विवरण लिखें

इम्प्लीमेंटेशन से पहले ऑपरेशनल कॉन्ट्रैक्ट लिखने पर अस्पष्ट जरूरतें तब सामने आती हैं, जब इंटरफेस बदलना अभी सस्ता होता है। अगर आप सफल कॉल के बाद होने वाले परिणाम को एक साधारण वाक्य में नहीं लिख सकते, तो टूल की सीमा अभी स्थिर नहीं है।

हर action टूल के लिए यह समीक्षा क्रम अपनाएं:

1. लक्ष्य को ऑपरेटर की भाषा में लिखें, जिसमें environment, account या tenant शामिल हो।
2. शाब्दिक क्रिया से पूरा परिणाम लिखें और बताएं कि बदलाव वापस किया जा सकता है या नहीं।
3. अनुमोदन करने वाले व्यक्ति, मंजूरी के बिंदु और यह बताएं कि वह प्रति कॉल है या प्रति सत्र।
4. वाक्य की तुलना handler behavior, defaults, retries और downstream APIs से करें।
5. identifiers, scope controls और लक्ष्य बदलने वाली हर value के लिए आर्ग्युमेंट विवरण जोड़ें।

चौथा कदम उन विफलताओं को पकड़ता है जिन्हें चमकदार दस्तावेज छिपा देते हैं। Retry से charge या message दो बार हो सकता है, जब तक downstream request idempotency mechanism इस्तेमाल न करे। छोड़ा गया environment production में बदल सकता है। हैंडलर किसी friendly name को कई resources में बदल सकता है। विवरण implementation की गलती ठीक नहीं कर सकता, लेकिन उसे लिखने से गलती सामने आ जाती है।

एक उपयोगी आंतरिक परीक्षण यह है कि टूल का नाम हटाकर केवल विवरण और input schema किसी दूसरे इंजीनियर को दिखाएं। उनसे पूछें कि सफल कॉल के बाद क्या होगा और वे किस अनुमोदन की अपेक्षा रखते हैं। अगर उनका उत्तर handler से अलग है, तो कॉन्ट्रैक्ट या कोड ठीक करें।

सामान्य भाषा वाले प्रॉम्प्ट से भी जांच करें। «पुराना डेटा साफ करो», «नया वर्जन लाइव करो» और «Jordan का अकाउंट ठीक करो» ऐसे अनुरोध हैं जो व्यापक टूल को आकर्षक बनाते हैं। सुरक्षित एजेंट पहले निरीक्षण टूल इस्तेमाल करेगा, missing identifier पूछेगा या ठोस कार्रवाई अनुमोदन के लिए दिखाएगा। अगर वह सीधे प्रोडक्शन deletion पर पहुंच सकता है, तो विफलता मॉडल के व्यवहार से बहुत पहले interface design में शुरू हो चुकी है।

त्रुटियों और परिणामों में सुरक्षा सीमा बनी रहनी चाहिए

सावधानी से लिखा विवरण अपना बहुत सा मूल्य खो देता है, अगर टूल का परिणाम चलाए गए लक्ष्य को छिपा दे या error एजेंट को अधिक व्यापक कार्रवाई आजमाने को कहे। एजेंट और ऑपरेटर को यह जांचने के लिए पर्याप्त प्रमाण लौटाएं कि क्या हुआ।

सफल state change के लिए canonical target identifier, की गई कार्रवाई और नया state लौटाएं। केवल ok न लौटाएं।

{
  "status": "completed",
  "target": {
    "environment": "production",
    "service": "catalog",
    "release": "2025.06.14-3"
  },
  "action": "traffic_promoted",
  "traffic_percent": 100,
  "request_id": "relreq_8a2f"
}

अनुमोदन पर रुकने की स्थिति में बताएं कि लक्ष्य तक कुछ नहीं पहुंचा। इससे एजेंट उस कॉल की भरपाई करने से बचता है जो केवल किसी व्यक्ति की प्रतीक्षा कर रही है।

{
  "status": "approval_required",
  "action": "rotate_production_service_credential",
  "target": "production/catalog-api",
  "executed": false,
  "approval_scope": "this call"
}

Errors में भी यही सावधानी रखें। «Forbidden» तकनीकी रूप से सही, लेकिन संचालन के लिए बेकार है। बताएं कि लक्ष्य अस्वीकार हुआ, environment अमान्य था, approval नहीं मिला या request remote system तक पहुंचने के बाद विफल हुई। explanation में secret कभी न दिखाएं और एजेंट को state बदलने वाली request बिना जांच दोहराने की सलाह न दें।

बाहरी प्रभाव वाली कार्रवाइयों में idempotency का परिणाम साफ दिखना चाहिए। अगर network timeout remote service के transfer स्वीकार करने या release बनाने के बाद आया, तो एजेंट को stable request ID से request status पूछना चाहिए। Retry path को अनुमान नहीं लगाना चाहिए। विवरण हर retry नियम नहीं बता सकता, लेकिन irreversible call वाले टूल के साथ status टूल और recovery में मदद करने वाला result shape होना चाहिए।

विवरण के पीछे enforcement जरूरी है

साधारण भाषा गलत चयन कम करती है, लेकिन unrestricted production token रखने वाले प्रोसेस को नहीं रोक सकती। क्रेडेंशियल और अंतिम network action ऐसी सीमा के पीछे रखें जो कॉल को अस्वीकार, मंजूर और रिकॉर्ड कर सके।

Sallyport MCP से जुड़े एजेंटों के लिए यही व्यवस्था इस्तेमाल करता है: एजेंट शामिल किए गए sp mcp shim का उपयोग करता है, जबकि ऐप API और SSH credentials को अपने encrypted vault में रखकर मंजूर कार्रवाइयां खुद चलाता है। इसकी per-session authorization और चुनी गई keys के लिए optional per-call approvals पुष्टि के वाक्य को अच्छे व्यवहार की विनती के बजाय लागू किया गया व्यवहार बनाती हैं।

इससे कमजोर टूल डिजाइन उचित नहीं हो जाता। गेटवे को वही कॉल दिखती है जो आती है। आपका tool schema अब भी तय करता है कि कॉल «इस production backup को मिटाएं» कहती है या deletion को सामान्य admin operation के पीछे छिपाती है। handler में argument validation लागू करें, जहां remote system अनुमति दे वहां credentials को इच्छित लक्ष्य तक सीमित करें और ऐसा audit record रखें जिसमें प्रोसेस और कार्रवाई स्पष्ट हों।

Model Context Protocol की authorization guidance भी दूसरी परत में यही बड़ी बात कहती है: authorization स्पष्ट जांच वाले protocol flow में होना चाहिए, model instruction में नहीं। विवरण को पढ़ने योग्य human contract मानें। server authorization, credential custody और approval को वे controls मानें जो उस contract को सच बनाते हैं।

आज उपलब्ध सबसे खतरनाक टूल लें और उसका नाम देखे बिना विवरण फिर से लिखें। अगर आप दो या तीन सीधे वाक्यों में production target, पूरा होने वाला प्रभाव और approval scope नहीं बता सकते, तो उस टूल को अभी autonomous agent को न दें।