أطلقت Vercel الإصدار 7 من AI SDK الخاص بها مع ميزة سياق الأدوات المحدود بنطاق (scoped tool context) التي تجبر كل أداة في وكيل الذكاء الاصطناعي (AI agent) على تلقي الأسرار التي تعلن عنها صراحةً فقط. ومن خلال الحد من التعرض، يمكن للمطورين منع الأدوات الخارجية من رؤية جميع بيانات الاعتماد المخزنة في بيئتهم عن طريق الخطأ.

لماذا يهم هذا التغيير

غالبًا ما تقوم وكلاء الذكاء الاصطناعي (AI agents) بربط خدمات خارجية متعددة — مثل البحث عن الطلبات، وإنشاء التذاكر، ومعالجة المدفوعات — وكل منها يتطلب مفاتيح API أو روابط URL خاصة به. والاختصار الشائع هو تسليم كائن process.env بالكامل إلى كل أداة:

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

يؤدي هذا النمط إلى توسيع الامتيازات الضمني: فإضافة أداة جديدة تمنحها فورًا إمكانية الوصول إلى جميع الأسرار الموجودة، بما في ذلك كلمات مرور قواعد البيانات أو رموز الدفع، دون أي تنبيه في مراجعة الكود. وتكمن المخاطرة في أن أداة مخترقة أو بها خلل قد تسرب فجأة بيانات اعتماد لم تكن مخصصة لها أبدًا.

كيف يعمل سياق الأدوات المحدود بنطاق

في الإصدار 7 من SDK، تعلن الأداة عن مخطط سياق (context schema) — وهو تعريف يعتمد على Zod للحقول الدقيقة التي تحتاجها. عندما يستدعي الوكيل أداة ما، يقوم المستدعي بتوفير كائن toolsContext يحتوي فقط على تلك الحقول المعلنة. يقوم SDK بالتحقق من الشكل قبل التنفيذ، وأي مفاتيح مفقودة أو إضافية تسبب خطأً.

يوضح عرض تجريبي بسيط أداتين بمتطلبات منفصلة:

  • lookupOrder – تحتاج إلى baseUrl لاستدعاء خدمة طلبات داخلية.
  • createTicket – تحتاج إلى supportToken لفتح تذكرة دعم.

تُصدر كل أداة contextSchema يسرد مفتاحها الوحيد المطلوب. وعند تشغيل الوكيل، فإنه يمرر:

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

تطلع lookupOrder فقط على baseUrl؛ بينما لا تلمس createTicket هذا المفتاح أبدًا، والعكس صحيح. يفرض SDK هذا الحد عند وقت التشغيل، محولاً التبعية المخفية إلى قائمة قدرات صريحة يمكن للمراجعين تدقيقها.

المزايا الأمنية

  • الحد من تعرض البيانات – تبقى بيانات الاعتماد حيث تبر الحاجة إليها.
  • التحقق من السياق – يؤدي عدم تطابق الحقول أو فقدانها إلى إيقاف التنفيذ.
  • جعل القدرات صريحة – يمكن للمراجعين رؤية ما يمكن لكل أداة الوصول إليه بالضبط.
  • تقليل نطاق الضرر – إذا تم اختراق أداة ما، فلن يحصل المهاجم إلا على الأسرار المسموح لتلك الأداة بالوصول إليها.

هذه الميزة لا تحل محل تقنيات العزل (sandboxing) التقليدية. يجب على المطورين الاستمرار في استخدام تنقيح السجلات (log redaction)، وضوابط خروج البيانات من الشبكة (network egress controls)، والتدوير المنتظم للرموز (token rotation). السياق المحدود بنطاق هو مجرد حد فاصل؛ وليس إغلاقًا تامًا للغرفة.

ما يحتاج المطورون إلى تعديله

  1. تحديد مخطط (schema) لكل أداة – استخدم مكتبة Zod التي تأتي مع SDK.
  2. تمرير toolsContext ضيق النطاق – تجنب استخدام process.env الشامل.
  3. مراجعة الوكلاء الحاليين – تحديد أي أسرار يمكن إزالتها من استدعاءات الأدوات.
  4. إضافة اختبارات مؤتمتة – للتأكد من فشل التحقق من السياق عند حقن بيانات إضافية.

بداية سريعة تبدو كالتالي:

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

أنشئ demo.ts ، وأعلن عن contextSchema لكل أداة، ثم قم بتشغيله باستخدام tsx demo.ts. سيقوم SDK بإصدار خطأ إذا حاولت إعطاء أداة سرًا لم تطلبه.

وجهة نظر معارضة

قد تجادل بعض الفرق بأن تعريفات المخططات الإضافية تزيد من الكود الروتيني (boilerplate) وتؤخر بناء النماذج الأولية. ورغم صحة ذلك، إلا أن التكلفة متواضعة — مجرد بضعة أسطر لكل أداة — وتزداد الفائدة الأمنية مع زيادة عدد الخدمات المتكاملة. وفي البيئات التي تتعامل مع بيانات الدفع أو المعلومات الشخصية، يصعب تجاهل هذه المقايضة.

ما يجب مراقبته لاحقًا

  • مقاييس الاعتماد – أفاد المتبنون الأوائل بوقوع حوادث تسريب أسرار أقل.
  • أدوات المجتمع – إضافات تقوم بتوليد مخططات السياق تلقائيًا من ملفات التكوين.
  • إصدارات SDK المستقبلية – تلميحات بأن Vercel قد تمد نطاقات السياق لتشمل أذونات الشبكة وحدود معدل الطلبات (rate-limit caps).

إذا كنت تقوم بالفعل ببناء وكلاء ذكاء اصطناعي باستخدام Vercel SDK، فإن الخطوة الأولى هي تدقيق استخدامك الحالي لـ process.env. حدد القيمة الوحيدة التي يمكن تجريدها من جميع استدعاءات الأدوات واستبدل النمط الشامل بـ toolsContext محدد النطاق. النتيجة هي وضع أمني أكثر إحكامًا دون التضحية بالمرونة التي تجعل وكلاء الذكاء الاصطناعي قويين.