Vercel ने अपने AI SDK का version 7 रोल आउट किया है, जिसमें scoped tool context फीचर दिया गया है जो यह सुनिश्चित करता है कि AI agent का प्रत्येक tool केवल उन्हीं secrets को प्राप्त करे जिन्हें उसने स्पष्ट रूप से घोषित (declare) किया है। एक्सपोज़र को सीमित करके, डेवलपर्स तीसरे पक्ष (third-party) के tools को उनके environment में स्टोर किए गए हर credential को गलती से देखने से रोक सकते हैं।

यह बदलाव क्यों महत्वपूर्ण है

AI agents अक्सर कई बाहरी सेवाओं को आपस में जोड़ते हैं—जैसे order lookups, ticket creation, payment processing—जिनमें से प्रत्येक को अपने स्वयं के API keys या URLs की आवश्यकता होती है। एक सामान्य शॉर्टकट हर tool को पूरा process.env object सौंप देना है:

execute(input, { context: process.env })

यह पैटर्न एक implicit privilege expansion पैदा करता है: एक नया tool जोड़ने से उसे तुरंत सभी मौजूदा secrets तक पहुँच मिल जाती है, जिसमें database passwords या payment tokens भी शामिल हैं, और इसके लिए किसी code review flag की आवश्यकता नहीं होती। जोखिम यह है कि कोई समझौता किया गया (compromised) या त्रुटिपूर्ण (buggy) tool अचानक उन credentials को लीक कर सकता है जो उसके लिए कभी निर्धारित ही नहीं थे।

scoped tool context कैसे काम करता है

SDK 7 में, एक tool एक context schema घोषित करता है—जो कि उन सटीक fields की एक Zod-आधारित परिभाषा है जिनकी उसे आवश्यकता है। जब agent किसी tool को invoke करता है, तो caller एक toolsContext object प्रदान करता है जिसमें केवल वही घोषित fields होते हैं। SDK execution से पहले इसके shape को validate करता है, और किसी भी missing या extra keys के कारण error आ जाता है।

एक न्यूनतम डेमो दो tools को दिखाता है जिनकी आवश्यकताएं अलग-अलग हैं:

  • lookupOrder – एक internal order service को कॉल करने के लिए baseUrl की आवश्यकता होती है।
  • createTicket – एक support ticket खोलने के लिए supportToken की आवश्यकता होती है।

प्रत्येक tool एक contextSchema export करता है जो उसकी एकमात्र आवश्यक key को सूचीबद्ध करता है। जब agent चलता है, तो वह पास करता है:

{
  lookupOrder: { baseUrl: "https://orders.internal" },
  createTicket: { supportToken: "s3cr3t-token" }
}

केवल lookupOrder ही baseUrl देख पाता है; createTicket इसे कभी नहीं छूता, और इसके विपरीत भी। SDK runtime पर इस सीमा (boundary) को लागू करता है, जिससे एक छिपी हुई निर्भरता (hidden dependency) एक स्पष्ट capability list में बदल जाती है जिसे reviewers audit कर सकते हैं।

सुरक्षा संबंधी लाभ (Security upside)

  • डेटा एक्सपोज़र को सीमित करता है – credentials वहीं रहते हैं जहाँ उनकी आवश्यकता होती है।
  • context को validate करता है – mismatch या missing fields होने पर execution रुक जाता है।
  • capabilities को स्पष्ट बनाता है – reviewers देख सकते हैं कि प्रत्येक tool वास्तव में किस चीज़ तक पहुँच सकता है।
  • blast radius को कम करता है – यदि कोई tool compromised हो जाता है, तो हमलावर को केवल वही secrets मिलते हैं जिनकी उस tool को अनुमति थी।

यह फीचर पारंपरिक sandboxing का स्थान नहीं लेता है। डेवलपर्स को अभी भी log redaction, network egress controls, और regular token rotation का उपयोग करना चाहिए। Scoped context एक सीमा है; यह कमरे को पूरी तरह सील नहीं करता है।

डेवलपर्स को क्या बदलाव करने की आवश्यकता है

  1. प्रत्येक tool के लिए एक schema परिभाषित करें – SDK के साथ आने वाली Zod library का उपयोग करें।
  2. एक सीमित toolsContext पास करें – catch-all process.env से बचें।
  3. मौजूदा agents की समीक्षा करें – उन secrets की पहचान करें जिन्हें tool calls से हटाया जा सकता है।
  4. automated tests जोड़ें – सुनिश्चित करें कि extra data डालने पर context validation विफल हो जाए।

एक quick start ऐसा दिखता है:

mkdir scoped-tools && cd scoped-tools
npm init -y
npm install ai zod
npm install -D typescript tsx @types/node

demo.ts बनाएँ, प्रत्येक tool का contextSchema घोषित करें, और इसे tsx demo.ts के साथ चलाएँ। यदि आप किसी tool को ऐसा secret देने की कोशिश करते हैं जिसकी उसने मांग नहीं की थी, तो SDK error throw कर देगा।

प्रतिपक्ष (Counter-point)

कुछ टीमें तर्क दे सकती हैं कि अतिरिक्त schema definitions से boilerplate बढ़ जाता है और prototyping धीमी हो जाती है। हालांकि यह सच है, लेकिन इसकी लागत मामूली है—प्रति tool बस कुछ ही लाइनें—और एकीकृत सेवाओं (integrated services) की संख्या के साथ सुरक्षा का लाभ बढ़ता जाता है। Payment data या व्यक्तिगत जानकारी को संभालने वाले environments में, इस trade-off को नज़रअंदाज़ करना कठिन है।

आगे क्या देखें

  • Adoption metrics – शुरुआती adopters कम secret-leak घटनाओं की रिपोर्ट कर रहे हैं।
  • Community tooling – ऐसे plug-ins जो configuration files से context schemas को auto-generate करते हैं।
  • Future SDK releases – संकेत हैं कि Vercel scoped contexts का विस्तार network permissions और rate-limit caps को शामिल करने के लिए कर सकता है।

यदि आप पहले से ही Vercel के SDK के साथ AI agents बना रहे हैं, तो पहला कदम अपने वर्तमान process.env उपयोग का ऑडिट करना है। उस एकल मान (single value) की पहचान करें जिसे सभी tool calls से हटाया जा सकता है और catch-all pattern को एक scoped toolsContext से बदल दें। इसका परिणाम AI agents की शक्ति देने वाली flexibility से समझौता किए बिना एक मजबूत security posture प्राप्त करना है।