Vercel השיקה את גרסה 7 של ה-AI SDK שלה עם תכונת scoped tool context שמאלצת כל כלי בסוכן AI לקבל רק את הסודות (secrets) שהוא מצהיר עליהם במפורש. על ידי הגבלת החשיפה, מפתחים יכולים למנוע מכלי צד-שלישי לראות בטעות כל פרט גישה (credential) המאוחסן בסביבה שלהם.

למה השינוי הזה חשוב

סוכני AI מרכיבים לעיתים קרובות שירותים חיצוניים מרובים — בדיקת הזמנות, יצירת כרטיסי תמיכה, עיבוד תשלומים — שכל אחד מהם דורש מפתחות API או כתובות URL משלו. הקיצור הנפוץ הוא להעביר את אובייקט ה-process.env המלא לכל כלי:

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

התבנית הזו יוצרת הרחבת הרשאות משתמעת (implicit privilege expansion): הוספת כלי חדש מעניקה לו באופן מיידי גישה לכל הסודות הקיימים, כולל סיסמאות למסדי נתונים או אסימוני תשלום, ללא כל התראה בביקורת קוד. הסיכון הוא שכלי פגום או בעייתי עלול לדלוף בפתאומיות פרטי גישה שלא נועדו עבורו מעולם.

איך scoped tool context עובד

ב-SDK 7, כלי מצהיר על context schema — הגדרה מבוססת Zod של השדות המדויקים שהוא זקוק להם. כאשר הסוכן מפעיל כלי, הקורא מספק אובייקט toolsContext המכיל רק את השדות שהוכרזו. ה-SDK מאמת את המבנה לפני הביצוע, וכל מפתח חסר או עודף יגרום לשגיאה.

דמו מינימלי מציג שני כלים עם דרישות נפרדות:

  • lookupOrder – זקוק ל-baseUrl כדי לקרוא לשירות הזמנות פנימי.
  • createTicket – זקוק ל-supportToken כדי לפתוח כרטיס תמיכה.

כל כלי מייצא contextSchema המפרט את המפתח היחיד הנדרש לו. כאשר הסוכן רץ, הוא מעביר:

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

רק lookupOrder רואה את baseUrl; createTicket לעולם לא נוגע בו, ולהיפך. ה-SDK אוכף את הגבול הזה בזמן ריצה (runtime), ובכך הופך תלות נסתרת לרשימת יכולות מפורשת שניתן לבקר (audit) בביקורת קוד.

יתרונות אבטחה

  • מגביל חשיפת נתונים – פרטי הגישה נשארים במקום שבו הם נחוצים.
  • מאמת את ההקשר (context) – שדות שאינם תואמים או חסרים יביאו להפסקת הביצוע.
  • הופך יכולות למפורשות – בודקים יכולים לראות בדיוק למה כל כלי יכול לגשת.
  • מצמצם את רדיוס הנזק (blast radius) – אם כלי נפרץ, התוקף מקבל רק את הסודות שהכלי הורשה לגשת אליהם.

התכונה הזו אינה מחליפה sandboxing מסורתי. מפתחים עדיין חייבים להשתמש בטשטוש לוגים (log redaction), בקרת יציאת רשת (network egress controls) ורוטציה קבועה של אסימונים (token rotation). scoped context הוא גבול; הוא לא אוטם את החדר.

מה מפתחים צריכים להתאים

  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 יזרוק שגיאה אם תנסו לתת לכלי סוד שהוא לא ביקש.

נקודת מבט נגדית

חלק מהצוותים עשויים לטעון שהגדרות ה-schema הנוספות מוסיפות boilerplate ומאיטות את פיתוח אב-הטיפוס (prototyping). למרות שזה נכון, המחיר הוא צנוע — רק כמה שורות לכל כלי — ותמורה האבטחה גדלה ככל שמספר השירותים המשולבים עולה. בסביבות המטפלות בנתוני תשלום או במידע אישי, קשה להתעלם מהתועלת.

מה כדאי לעקוב אחריו בהמשך

  • מדדי אימוץ – משתמשים מוקדמים מדווחים על פחות מקרים של דליפת סודות.
  • כלי קהילה – תוספים (plug-ins) שמייצרים באופן אוטומטי context schemas מקובצי הגדרה.
  • גרסאות SDK עתידיות – רמזים לכך ש-Vercel עשויה להרחיב את ה-scoped contexts כך שיכללו הרשאות רשת ומגבלות קצב (rate-limit caps).

אם אתם כבר בונים סוכני AI באמצעות ה-SDK של Vercel, הצעד הראשון הוא לבקר את השימוש הנוכחי שלכם ב-process.env. זהו ערך בודד שניתן להסיר מכל קריאות הכלים ולהחליף את תבנית ה-"catch-all" ב-toolsContext מוגדר (scoped). התוצאה היא מצב אבטחה הדוק יותר מבלי להקריב את הגמישות שהופכת סוכני AI לחזקים כל כך.