Gemini CLI של Google תבקש אישור לפני עריכת קובצי build

Gemini CLI 0.61.0, שיצא ביום רביעי, דורש אישור מפורש לפני שהסוכן עורך קובצי תצורת build, מריץ פקודות build או בדיקות לאחר עריכה כזו, או מריץ פקודות shell שארגומנטים שלהן נראים כמי שמגיעים מתוכן חיצוני לא מהימן. באותה מהדורה חוזק גם ה-sandbox האופציונלי, כך שפרטי ההזדהות והתצורה של המארח נשארים מחוץ להישג ידיהם של תהליכים שרצים בתוכו.

קובצי build כנקודת תקיפה

שינוי ב-package.json, ב-Makefile, ב-pyproject.toml או בקובץ BUILD של Bazel יכול למשוך תלות חדשה או להפעיל סקריפט, ו-Gemini CLI יכול לבצע עריכות כאלה על סמך חיפושי ווב וכלים חיצוניים, ואחר כך להריץ פקודות shell. אם תיעוד שנקרא בזמן תיקון באג מכיל הוראה מוסתרת להוסיף סקריפט postinstall, הסוכן עלול להריץ את הבדיקות ולהפעיל קוד זדוני בלי שהמפתח הקליד פקודה כלשהי.

Pull request ‎#29250 מכוון בדיוק לתרחיש הזה. עריכות בקובצי build מזוהים מחייבות כעת אישור, וה-CLI עוקב אחרי אילו קובצי build השתנו במהלך הסשן, כך שפקודות npm run, make או cargo מאוחרות יותר מוחזקות עד לאישור מפורש. חלון האישור מציג דיפים מלאים של קובצי ה-build, בלי לקצר אותם.

ארגומנטים לא מהימנים מחייבים אישור

הבדיקה השנייה נוגעת לארגומנטים של פקודות: תוכן שמגיע מהורדות ווב, מתשובות שרתי MCP, מ-Google Docs ומ-Buganizer, כלי מעקב הבאגים הפנימי של Google, נחשב כעת להקשר לא מהימן, וה-CLI שואל לפני הרצת פקודת shell שדגליה או ארגומנטים שלה תואמים אסימונים מתוכו. בחלון ההתראה אין אפשרויות אישור קבוע, כך שאי אפשר לתת "אשר תמיד" לקבוצת הפעולות הזו.

הבדיקות קשורות ל-restricted workspace mode, מצב בטוח שה-CLI מפעיל על תיקיות שהמשתמש לא סימן כמהימנות, וה-PR לא מפרט איך הן מתנהגות בתיקייה מהימנה או תחת אישור אוטומטי. התאמת האסימונים אינה עוקבת אחרי מקורו של כל ערך: היסטוריית הביקורת חשפה עקיפות קודמות — ארגומנטים במירכאות, קידומות של משתני סביבה, יעדי הפניה מחדש ב-shell וטיפול בנתיבי Windows — וכולן תוקנו לפני שהשינוי מוזג ב-11 בספטמבר.

ה-sandbox מרחיק פרטי הזדהות

Pull request נוסף, ‎#29214, מחזק את ה-sandbox. כשהוא פועל דרך Docker, Podman, LXC או Seatbelt של macOS, תיקיית ~/.gemini של המארח אינה נטענת יותר לתוכו; במקומה ה-CLI מעביר עותק מסונן של ההגדרות בלי מפתחות API, בלי hooks ובלי פקודות כלים מותאמות. לא ניתן להפעיל את ה-sandbox במיקומים רגישים כגון תיקיית הבית, וכללי Seatbelt חדשים חוסמים גישה לפרטי OAuth, להחלטות על תיקיות מהימנות ולקובצי ‎.env.

התיעוד של Google מתאר את ה-sandbox כמחסום אבטחה בין פעולות AI למערכת המארחת, אך מזהיר שהוא מצמצם סיכון ולא מבטל אותו. הפער מוחשי: ה-sandbox טוען את תיקיית הפרויקט כדי לאפשר עריכה, כך ש-package.json מורעל שנכתב בתוכו נשאר במאגר כשמפתח או משימת CI מריצים את ה-build מחוצה לו.

מאז 18 ביוני הכלי בקוד פתוח משרת בעיקר לקוחות ארגוניים ומפתחים עם מפתחות API בתשלום, לאחר שב-Google הודיעו במאי שמשתמשי Pro, Ultra והמסלול החינמי יעברו ל-Antigravity CLI הסגור. עבודת האבטחה ממשיכה להיעשות בפומבי.