גוגל שדרגה את המודל ברירת המחדל עבור ה-Gemini API Managed Agents שלה ל-Gemini 3.6 Flash והוסיפה שלושה בקרים ממוקדי מפתחים — environment hooks, budget caps ו-scheduled triggers — וכל זאת במסלול חינמי. צוותים מקבלים כעת ניהול עלויות ואוטומציה ברזולוציה עדינה יותר, אך מופיעה גם נקודת החלטה אבטחתית חדשה, ו-hook שאינו מוגדר כהלכה עלול להיות מנוצל לרעה.
יכולות חדשות
- Environment hooks יושבים בתוך ה-sandbox של הסוכן ומאפשרים לקוד לחסום, לבחון או לתעד (log) כל קריאת כלי לפני שהיא רצה.
- Budget controls מאפשרים למפתחים להגדיר מגבלות קשיחות על סכום ההוצאה של הסוכן על קריאות, ובכך מונעים חיובים בלתי נשלטים.
- Scheduled triggers מאפשרים לסוכנים לפעול בזמנים שנקבעו מראש, מה שהופך את ה-API ל-cron קל משקל עבור תהליכי עבודה קבועים ואוטומטיים.
- ה-default model הוא כעת Gemini 3.6 Flash.
- גישה במסלול חינמי.
למה זה חשוב למפתחים
Hooks מעניקים לצוותים דרך לאכוף מדיניות פנימית — כגון דחיית קריאות הנוגעות לנתונים רגישים — מבלי לשכתב את הסוכן. Scheduled triggers מאפשרים ל-API לבצע משיכות נתונים שגרתיות או בדיקות סטטוס באופן אוטומטי. יחד, הם מקרבים את Gemini לפלטפורמה מוכנה לייצור (production-ready) המציעה הן גמישות והן עלויות צפויות.
חששות אבטחה
אותם בקרים שמחמירים את הממשל (governance) פותחים גם שטח תקיפה חדש. אם hook נשאר פתוח או מוגדר באופן שגוי, קריאת כלי זדונית עלולה לחמוק מביקורות ולהגיע למערכות המשך (downstream systems). Scheduled triggers, למרות היותם שימושיים, עלולים לשמש כנשק להפעלת פעולות זולות ורציפות שנשארות תחת מגבלות התקציב אך גורמות נזק — למשל, איסוף נתונים (scraping) מציפני או דפוסי מניעת שירות (DoS). Budget caps, שנועדו לשמש כאמצעי הגנה, עלולים לספק לתוקף תקרת הוצאות לעבוד בתוכה, מה שמקשה על זיהוי ניצול לרעה בעלות נמוכה.
התייחסו ל-hooks כאל גבול אבטחה קריטי. בדקו קריאות מורשות באופן קבוע, ודאו שהתיעוד (logging) מקיף, ובחנו את התנהגות הטריגרים בתנאי קצה.
מה כדאי לעקוב אחריו
שורה תחתונה: השדרוגים ב-Gemini API מעניקים למפתחים כלים עוצמתיים לאוטומציה ובקרת עלויות, אך הם גם מעבירים חלק מנטל האבטחה אל הצוותים שמטמיעים אותם. הגדרה נכונה של environment hooks וניטור של משימות מתוזמנות חשובים כעת בדיוק כמו מעקב אחר החשבון.