सुरक्षित tool calls के लिए AI एजेंट डेटा मिनिमाइज़ेशन

AI एजेंट को ग्राहक रिकॉर्ड केवल इसलिए नहीं मिलना चाहिए कि शायद बाद में उसे उसमें से कोई एक तथ्य चाहिए। हर टूल कॉल का अनुबंध छोटा होना चाहिए: कार्रवाई, उसे पूरा करने के लिए ज़रूरी न्यूनतम फ़ील्ड और ऐसा आउटपुट जो एजेंट को बताए कि क्या हुआ, बिना ग्राहक डेटा का नया ढेर थमाए।

टीमें अक्सर सक्षम एजेंट और सुविधाजनक आंतरिक API के बीच की सीमा पर डेटा लीक करती हैं। वे एजेंट को सामान्य customer lookup देती हैं, पूरा response लौटाती हैं और उसे उपयोगी context कहती हैं। इससे हर अगला prompt, transcript, retry, debug trace और tool result उस रिकॉर्ड के फैलने की नई जगह बन जाता है।

इसका समाधान कोई चतुर redaction prompt नहीं है। यह डिज़ाइन अनुशासन है: हर कार्रवाई को उपलब्ध कराने से पहले उसका नक्शा बनाएँ, execution boundary पर संकीर्ण request लागू करें और raw upstream response को एजेंट से दूर रखें।

टूल की अनुमति का अर्थ पूरे रिकॉर्ड का अधिकार नहीं है

किसी API को कॉल करने की अनुमति और API द्वारा लौटाए जा सकने वाले हर फ़ील्ड को देखने की अनुमति दो अलग निर्णय हैं। टीमें इन्हें इसलिए मिला देती हैं क्योंकि service account अक्सर बड़े object को पढ़ सकता है, जबकि agent tool को उसका छोटा-सा हिस्सा चाहिए।

मान लें कि एजेंट को तय करना है कि payment reminder भेजना है या नहीं। Delivery service को recipient address, template identifier और invoice reference चाहिए हो सकते हैं। एजेंट को शायद केवल eligible: true, सुरक्षित display name और action reference चाहिए। उसे payment history, customer notes, tax information या sender द्वारा पर्दे के पीछे इस्तेमाल किया जाने वाला address नहीं चाहिए।

एक broad get_customer tool समस्या को न्योता देता है। उसके बनते ही prompts उसे असंबंधित कामों में इस्तेमाल करने लगते हैं, क्योंकि proper action tool बनाने से वह आसान लगता है। फिर लोग instructions से इसकी भरपाई करते हैं, जैसे «sensitive fields उजागर न करें»। Instructions JSON response से फ़ील्ड हटाती नहीं हैं।

इन तीन सवालों को अलग रखें:

• क्या यह agent process यह कार्रवाई शुरू कर सकता है?
• इसे पूरा करने के लिए executor को कौन-से फ़ील्ड चाहिए?
• कार्रवाई पूरी होने के बाद एजेंट को कौन-से तथ्य चाहिए?

हर सवाल का अपना constraint होना चाहिए। Access control पहले सवाल का उत्तर देता है। Request validation दूसरे का। Response shaping तीसरे का। एक all-purpose API token और flexible JSON endpoint इनमें से किसी का भी अच्छा उत्तर नहीं देते।

यह अंतर तब सबसे महत्वपूर्ण होता है जब एजेंट किसी टूल को बार-बार इस्तेमाल करता है। Demo में एक बार का broad lookup सहने योग्य लगता है। असली run में retry के बाद एजेंट उसे फिर कॉल कर सकता है, अगले request में उसका output उद्धृत कर सकता है या उसे दूसरे टूल को भेज सकता है। पहली अनावश्यक फ़ील्ड कई अनावश्यक प्रतियों में बदल जाती है।

डेटा मैप database table के बजाय कार्रवाई के आसपास बनाएँ

उपयोगी data map एक verb और बाहरी प्रभाव से शुरू होता है। «Read customer» इस उद्देश्य के लिए कार्रवाई नहीं है। «जाँचें कि invoice overdue है या नहीं» और «shipment label बनाएँ» कार्रवाइयाँ हैं, क्योंकि दोनों का स्पष्ट recipient, उद्देश्य और अपेक्षित परिणाम है।

हर प्रस्तावित टूल के लिए schema लिखने से पहले एक छोटा रिकॉर्ड बनाएँ:

Trusted lookup वाला कॉलम कठिन काम करता है। यह बताता है कि executor को कौन-सी जानकारी चाहिए, लेकिन एजेंट को नहीं। उस lookup को boundary के पीछे ले जाएँ। एजेंट invoice reference भेजे और आपके नियंत्रण में चलने वाली service कार्रवाई की जाँच के बाद recipient को resolve करे।

invoice_ref को email address की छिपी हुई कॉपी या customer name वाले compound identifier में न बदलें। Opaque reference आकस्मिक disclosure घटाते हैं, लेकिन अपने-आप system को private नहीं बनाते। अगर कोई reference किसी को भी customer object query करने देता है, तो उसे authorization, expiration और audience restriction की ज़रूरत फिर भी है।

European Union का General Data Protection Regulation Article 5(1)(c) में संबंधित सिद्धांत स्पष्ट रूप से बताता है: personal data उद्देश्य के लिए पर्याप्त, प्रासंगिक और आवश्यक चीज़ों तक सीमित होना चाहिए। «उद्देश्य के लिए» वाला हिस्सा वह जगह है जहाँ engineering teams अक्सर लापरवाह हो जाती हैं। उद्देश्य «एजेंट को अपना काम पूरा करने में मदद करना» नहीं है। उद्देश्य boundary पर होने वाली खास कार्रवाई है, जैसे एक reminder भेजना या एक support case खोलना।

Data map उन फ़ील्ड को भी सामने लाता है जिन्हें किसी भी दिशा में boundary पार नहीं करनी चाहिए। Free-text notes की अपनी पंक्ति होनी चाहिए। उनमें अक्सर चिपकाए गए ईमेल, पहचान दस्तावेज़, credentials, स्वास्थ्य जानकारी और ग्राहक की बिना फ़िल्टर की शिकायत होती है। Generic notes field का अर्थ सीमित नहीं होता, इसलिए routine tool request में उसकी जगह नहीं है।

Strict schema execution से पहले सुविधा वाले फ़ील्ड रोकते हैं

Schema को उन फ़ील्ड को अस्वीकार करना चाहिए जिनकी कार्रवाई को ज़रूरत नहीं है। Extra properties को चुपचाप अनदेखा करना उदार लगता है, लेकिन इससे परीक्षण के दौरान leak छिप जाता है और developers को लगता रहता है कि फ़ील्ड आगे पहुँच गई।

मान लें कि एजेंट को refund review का अनुरोध करना है। यह request contract केवल case reference और चुना हुआ reason स्वीकार करता है। यह customer-controlled amounts, addresses और मनमाने notes को अस्वीकार करता है।

{
  "name": "request_refund_review",
  "description": "Create a review task for an existing support case.",
  "input_schema": {
    "type": "object",
    "additionalProperties": false,
    "required": ["case_ref", "reason_code"],
    "properties": {
      "case_ref": {
        "type": "string",
        "pattern": "^case_[A-Za-z0-9]{16}$"
      },
      "reason_code": {
        "type": "string",
        "enum": ["duplicate_charge", "service_not_received", "other"]
      }
    }
  }
}

customer_email, shipping_address, amount या conversation_text वाले request को validation पर स्पष्ट परिणाम के साथ असफल होना चाहिए, जैसे:

{
  "error": "invalid_request",
  "message": "Unexpected property: customer_email"
}

यह error एजेंट को contract का उपयोग करने के लिए कहता है और developer को बताता है कि अनचाहा फ़ील्ड boundary तक पहुँचा। Error में अस्वीकृत value को वापस न दो। Debugging के लिए पूरा failed request serialize करने के कारण error handlers ने कई production paths से ज़्यादा leaks किए हैं।

Schema validation server-owned fields की सुरक्षा अकेले नहीं करती। Request में ऐसा case_ref हो सकता है जो किसी दूसरे account का हो, या किसी दूसरे agent को जारी किए गए action reference के साथ valid reason_code जुड़ा हो। Executor को reference को उसके issuer, इच्छित action और lifetime से बाँधना चाहिए। Action reference को public database primary key नहीं, claim ticket समझें।

जब एजेंट untrusted या बहुत व्यापक context से शुरू करता है, तो request builder इस्तेमाल करें। Builder को केवल अनुमत फ़ील्ड निकालकर नया object बनाना चाहिए। बड़े object में से कुछ ज्ञात खतरनाक keys हटाने का तरीका न अपनाएँ। Denylist redaction तब विफल होती है जब नया फ़ील्ड आ जाए, nested object का आकार बदल जाए या developer अलग नाम वाला alias इस्तेमाल करे।

ALLOWED_REASONS = {"duplicate_charge", "service_not_received", "other"}

def build_refund_request(case_ref, reason_code):
    if not isinstance(case_ref, str) or not case_ref.startswith("case_"):
        raise ValueError("invalid case_ref")
    if reason_code not in ALLOWED_REASONS:
        raise ValueError("invalid reason_code")
    return {"case_ref": case_ref, "reason_code": reason_code}

यह छोटा function एक आम गलती रोकता है: पूरे case dictionary को client library में भेज देना, क्योंकि library arbitrary keyword arguments स्वीकार करती है। Explicit return object उबाऊ है। Customer-data boundary पर उबाऊ होना अच्छी बात है।

Tool output का अपना contract होना चाहिए

Raw tool output एजेंट का context है, भले ही टूल को input में ग्राहक डेटा कभी न मिला हो। हर response को ऐसा material समझें जिसे एजेंट उद्धृत, संभाल, बदल या किसी दूसरे system को भेज सकता है।

Shipment बनाने के बाद provider response में recipient का पूरा address, telephone number, carrier account information, label data, routing details और internal diagnostic fields हो सकते हैं। एजेंट को आम तौर पर केवल shipment reference और यह जानना होता है कि वह ग्राहक को order भेजे जाने की सूचना दे सकता है या नहीं।

Agent-facing response को service-facing result से अलग परिभाषित करें:

{
  "status": "created",
  "shipment_ref": "ship_Q7J4K2P8",
  "customer_message_allowed": true
}

Execution service विस्तृत carrier response को वहाँ store या pass कर सकती है जहाँ operations staff को उसकी ज़रूरत हो। उसे केवल debugging की सुविधा के लिए वापस नहीं लौटाना चाहिए। अगर किसी operator को receipt चाहिए, तो उसके लिए protected interface दें। Agent transcript को troubleshooting database न बनाएँ।

Error responses के साथ भी यही करें। Upstream API अस्वीकृत street address, account number या request का उद्धृत हिस्सा लौटा सकती है। उसे एजेंट के लिए सीमित error code में बदलें, जैसे recipient_unavailable, reference_invalid या provider_retryable। Protected diagnostic details operators के लिए बने system में रखें।

Model Context Protocol specification tools को structured inputs और results वाली callable functions के रूप में परिभाषित करती है। यह structure developers को response types लागू करने की साफ जगह देता है। Prose dump या arbitrary JSON लौटाने वाला tool यह लाभ खो देता है। Narrow response schema agent behavior को test करना भी आसान बनाता है, क्योंकि अगला निर्णय केवल ज्ञात फ़ील्ड पर निर्भर कर सकता है।

details नाम का फ़ील्ड तभी लौटाएँ जब उसकी exact structure और sensitivity rules स्पष्ट हों। अस्पष्ट escape hatch स्थायी बन जाता है। Incident के दौरान कोई वहाँ raw result रख देगा और फिर हटाना भूल जाएगा।

Redaction, pseudonym और secrecy अलग-अलग controls हैं

किसी नाम को token से बदलने का अर्थ यह नहीं कि डेटा अब सुरक्षित रूप से साझा किया जा सकता है। ऐसा स्थिर token जिसे customer database से जोड़ा जा सके, अधिकांश व्यावहारिक threat models में personal data ही रहता है। केवल एक caller और थोड़े lifetime तक सीमित one-time action reference की failure mode कहीं छोटी होती है।

Redaction किसी object से ज्ञात values हटाती है। Internal system को operator को record दिखाना हो तो यह मदद करती है, लेकिन agents के लिए primary boundary के रूप में यह नाज़ुक है। Field names बदलते हैं, content nested structures में चला जाता है और free text में ऐसी जानकारी होती है जिसे कोई fixed redaction list भरोसेमंद ढंग से नहीं खोज सकती।

Pseudonymization किसी direct identifier की जगह दूसरा identifier रखती है। जब recipient mapping resolve नहीं कर सकता, तब इससे exposure घटता है। यह तब विफल होती है जब वही agent उस identifier से broad lookup tool call कर सकता है, token असंबंधित tools में दिखाई देता है या value स्वयं अर्थ रखती है। acme-health-urgent-001 केवल इसलिए opaque नहीं है कि उसमें email sign नहीं है।

Secrecy तब आती है जब resolving data और credentials boundary के trusted side पर रहते हैं। एजेंट constrained instruction भेजता है और service केवल अनुमत कार्रवाई के लिए protected information resolve करती है। यही अंतर उस आम गलती को रोकता है जिसमें «sanitized» customer object एजेंट को देकर मान लिया जाता है कि काम पूरा हो गया।

Data minimization को authorization से अलग रखें। सही authorization वाला एजेंट भी बहुत अधिक डेटा पा सकता है। उलटे, unauthorized caller को बहुत कम डेटा मिल सकता है, लेकिन वह कम डेटा भी नुकसान पहुँचा सकता है। दोनों controls लागू करें और उनका स्वतंत्र परीक्षण करें।

Broad credentials narrow schemas को कम विश्वसनीय बनाते हैं

Perfect request schema उस agent की भरपाई नहीं कर सकता जिसके पास underlying API को सीधे call करने वाला credential हो। अगर एजेंट secret पढ़ सकता है या अपने runtime से उसका उपयोग कर सकता है, तो वह सावधानी से बनाए गए tool को bypass करके provider से अधिक समृद्ध response माँग सकता है।

Credentials वहीं रखें जहाँ action execute होता है, जहाँ model reasoning करता है वहाँ नहीं। Narrow request validate करने के बाद executor authorization header या SSH identity जोड़ता है। एजेंट को secret, placeholder या environment variable में उसकी कॉपी कुछ भी नहीं दिखना चाहिए।

RFC 6749 में वर्णित OAuth 2.0 client को दी जाने वाली access को scopes से सीमित करता है। Scope उपयोगी है, लेकिन कई implementations scope को पूरे विभाग के broad pass की तरह मानती हैं। customers.read scope अभी भी full-record lookup की अनुमति दे सकता है। Credential scope को action-specific endpoints और response filtering के साथ जोड़ें। वरना scope केवल यह सीमित करता है कि agent किस बड़े collection को खोज सकता है।

Authority को effect के अनुसार अलग रखें। Draft बनाने वाले agent को उसे भेजने का अधिकार भी न दें। Refund review माँगने वाला agent refund जारी न कर सके। यह विभाजन केवल एक workflow चलाने के लिए general-purpose administrative credential जोड़ने का दबाव घटाता है।

macOS teams के लिए Sallyport API और SSH credentials को encrypted vault में रखता है और credential एजेंट को बताए बिना HTTP या SSH action execute करता है। यह व्यवस्था तभी मदद करती है जब call खुद संकीर्ण रहे; protected token भी overbroad request को authorize कर सकता है।

Support workflow दिखाता है कि डेटा कहाँ फैलता है

एक आम leak उचित अनुरोध से शुरू होता है: support agent को failed delivery का उत्तर तैयार करने दें। पहला implementation get_order(order_id) उपलब्ध कराता है, जो order, customer profile, delivery address, payment status, support history और carrier events लौटाता है। एजेंट को carrier event और एक approved update भेजने की अनुमति चाहिए।

एजेंट lookup call करके पूरा record पा लेता है। फिर वह चुने हुए details message-drafting tool को भेजता है। अब drafting prompt में address और history भी हैं, जबकि दोनों message से संबंधित नहीं हैं। Failed tool call पूरा prompt error log में भेज देती है। Engineer diagnosis के लिए उस error को issue में कॉपी करता है। मूल broad response चार अलग-अलग retention problems बन चुका है।

Workflow को अलग तरह से बनाएँ। एजेंट को assess_delivery_update action दें, जो order_ref स्वीकार करे। Execution service caller का authority verify करे, order को internally fetch करे, carrier status पढ़े, contact rule लागू करे और केवल यह लौटाए:

{
  "status": "contact_allowed",
  "event_code": "delivery_delayed",
  "approved_template": "delivery_delay_notice",
  "order_ref": "ord_9VJ3R6M1"
}

एजेंट तय कर सकता है कि स्थिति approved message के योग्य है या नहीं। अलग send_approved_delivery_update action order_ref और approved_template स्वीकार करे। वह email address या free-text body स्वीकार न करे। Consent और order state verify करने के बाद service recipient को resolve करे और template render करे।

यह design अधिक restrictive लगता है, क्योंकि यह सचमुच ऐसा है। यही restriction उद्देश्य है। एजेंट customer profile को किसी दूसरे काम में आसानी से इस्तेमाल नहीं कर सकता और बाद का tool गलती से डेटा नहीं पा सकता।

इसका उत्तर generic «tool को flexibility चाहिए» तर्क से न दें। Flexibility trusted application code के अंदर होनी चाहिए, जहाँ आप उसका परीक्षण, review और data handling audit कर सकें। Broad request और response objects के ज़रिए flexibility एजेंट को देने पर लागत हर prompt और downstream system पर चली जाती है।

Approval screens हर छिपे हुए फ़ील्ड की जाँच नहीं कर सकतीं

Approval unauthorized actions से बचाती है, लेकिन oversized payload की भरोसेमंद निगरानी नहीं कर सकती। व्यक्ति छोटा summary देखता है, समय के दबाव में निर्णय लेता है और action approve करता है। अगर service request के भीतर अनावश्यक address या history छिपा दे, तो approval ने disclosure कम नहीं किया।

Approval tool design का विकल्प बन जाए तो गलत incentive पैदा होता है। Developers फ़ील्ड जोड़ते रहते हैं क्योंकि «हर call को user approve करता है»। जल्द ही approval card इतना विस्तृत हो जाता है कि पढ़ना कठिन हो जाता है, या इतना छोटा कि निर्णय लेना मुश्किल हो। लोग बार-बार आने वाली सामान्य दिखने वाली कार्रवाइयों को approve करते रहते हैं और ध्यान नहीं देते कि किसी request में नया फ़ील्ड जुड़ गया है।

Approval interface दिखने से पहले allowlist लागू करें। Interface में कार्रवाई और उसके सीमित parameters दिखाएँ। Approver को यह चुनना चाहिए कि send approved delivery update for ord_9VJ3R6M1 को authorize करना है या नहीं, न कि serialized customer record की हर पंक्ति देखनी है।

उन effects के लिए per-call approval इस्तेमाल करें जिनमें हर execution पर मानवीय ध्यान चाहिए। इसे personal data scanner की तरह इस्तेमाल न करें। Approval देखने वाले व्यक्ति के पास हर nested field ज़रूरी है या नहीं तय करने के लिए न समय होगा, न पूरा context।

एक अच्छा review test सरल है: कहानी से approver को हटा दें। क्या tool contract फिर भी trusted service से अनावश्यक डेटा बाहर जाने से रोकता है? अगर नहीं, तो boundary बहुत कम काम कर रही है।

Audit records को actions साबित करने चाहिए, नया data store नहीं बनना चाहिए

जब एजेंट ग्राहक की ओर से कार्रवाई करे तो evidence चाहिए। Evidence के लिए full payload का स्थायी, agent-readable archive आवश्यक नहीं है।

Action name, initiating process या session, timestamp, outcome, authorization decision और correlation reference दर्ज करें। Payload की integrity evidence चाहिए तो payload को खुद रखने के बजाय canonical, protected representation का cryptographic digest रखें। स्वीकार किए गए field names रखें, उनके sensitive values नहीं।

उदाहरण के लिए audit event का आकार ऐसा हो सकता है:

{
  "action": "send_approved_delivery_update",
  "session_ref": "sess_4KH8N2",
  "order_ref_digest": "sha256:8e4c...",
  "accepted_fields": ["order_ref", "approved_template"],
  "outcome": "sent",
  "authorized_by": "per_call"
}

Digest privacy risk को जादुई ढंग से मिटा नहीं देता। अगर input छोटी और ज्ञात सूची से आता है, तो attacker values का अनुमान लगाकर hashes की तुलना कर सकता है। Operators को details वापस पाने की ज़रूरत हो तो protected internal reference इस्तेमाल करें और उस system तक access सीमित रखें जिसमें मूल record है। Email address के plain hash को anonymous कभी न मानें।

Operational diagnostics को agent के अपने tool result से अलग रखें। Support staff को थोड़े समय के लिए upstream error body तक protected access चाहिए हो सकता है। एजेंट को नहीं। इस separation से deletion और retention story भी साफ रहती है, क्योंकि raw records हर journal में जमा नहीं होते।

Sallyport agent sessions और individual calls को write-blind encrypted, hash-chained audit log से project करता है। उसका sp audit verify command vault key के बिना offline chain verify कर सकता है। Integrity verification यह बताता है कि recorded event बदला गया है या नहीं। Event schema को अभी भी तय करना है कि उसमें शुरुआत से बहुत अधिक customer data तो नहीं है।

जानबूझकर अधिक डेटा भेजकर boundary का परीक्षण करें

केवल valid happy-path calls का privacy review उस behavior को छोड़ देता है जो सबसे अधिक accidental exposure करता है। जाँचें कि agent पूरा object भेजे तो क्या होता है, upstream service unexpected field लौटाए तो क्या होता है और request के बीच में exception आए तो क्या होता है।

ऐसा fixture इस्तेमाल करें जिसमें पहचानने योग्य नकली sensitive values हों और सुनिश्चित करें कि वे agent boundary पार न करें। Fixture में nested fields और free text भी रखें, क्योंकि flat examples redaction code को आसानी से पास कर देते हैं।

{
  "case_ref": "case_Ab92Kx71LmQ4Rt8P",
  "reason_code": "duplicate_charge",
  "customer": {
    "email": "[email protected]",
    "address": "17 Example Lane",
    "payment_note": "card ending 4242"
  },
  "conversation_text": "Customer says their medical appointment depends on delivery."
}

Expected result ऐसा validation failure होना चाहिए जिसमें केवल unexpected property का नाम हो। फिर चार जगह जाँच करें: agent-visible response, application logs, error tracking records और audit events। Developers अक्सर request validate कर लेते हैं, लेकिन भूल जाते हैं कि exception middleware ने original body दर्ज कर ली है।

Output के लिए भी contract tests जोड़ें। ऐसा upstream response mock करें जिसमें पूरा customer object हो और सुनिश्चित करें कि tool केवल documented fields भेजता है। Provider client बदलने पर यह परीक्षण करें। SDK upgrade agent prompt को छुए बिना response fields जोड़ सकता है।

अंत में transcript test चलाएँ। एजेंट को सामान्य task दें, उसके पास पहुँचने वाले सभी tool inputs और results capture करें और fixture values खोजें। यह test accidental prompt interpolation और debug text पकड़ता है जिन्हें schema tests छोड़ सकते हैं।

आमतौर पर redesign करने वाला पहला action broad lookup tool होता है। उसे ऐसी कार्रवाई से बदलें जो सचमुच कोई बाहरी प्रभाव डालती हो या एक सीमित decision लौटाती हो। अगर नया contract सुविधा के लिए बहुत संकीर्ण लगता है, तो अक्सर यह संकेत है कि system agent से ऐसा डेटा ढोने पर निर्भर था जिसकी उसे कभी ज़रूरत नहीं थी।