Google Cloud השיקה שירות GKE Agent Sandbox מנוהל, בעוד שפרויקט הקוד הפתוח kubernetes-sigs/agent-sandbox מביא את אותה היכולת לכל אשכול (cluster) Kubernetes. שניהם מעניקים למפתחים קונטיינר Linux חד-פעמי עבור סוכני AI, תוך השארת שאר התשתית ללא שינוי.
למה קוד שנוצר על ידי AI זקוק ל"ארגז חול" (playpen)
סוכני AI מודרניים לא רק עונים על שאלות. הם כותבים סקריפטים, גולשים באינטרנט, מריצים פקודות shell ואפילו מפעילים שירותי אינטרנט. הכוח הזה יוצר פער אבטחה: הקוד שהם פולטים עלול להיות עם באגים, זדוני או אגרסיבי מדי. סוכן שמריץ rm -rf / או מתחבר למסד נתונים פנימי ללא הרשאה עלול לסכן מערכת שלמה.
Sandbox (ארגז חול) מבודד כל סוכן בתוך קונטיינר משלו — מכונה וירטואלית זעירה וחד-פעמית. אם הסוכן מתנהג בצורה לא תקינה, הנזק נשאר בתוך הקונטיינר הזה; המארח (host) ועומסי העבודה האחרים נשארים בטוחים. ההצעה החדשה של GKE והפרויקט המונע על ידי הקהילה הופכים את הרעיון הזה לשירות מוכן לשימוש.
שתי דרכים להשיג sandbox
- GKE Agent Sandbox – שירות מנוהל לחלוטין עבור לקוחות Google Cloud.
kubernetes-sigs/agent-sandbox– פרויקט קוד פתוח עבור כל אשכול Kubernetes.
שניהם חולקים את אותה ארכיטקטורת ליבה, הבנויה על פרימיטיבים (primitives) סטנדרטיים של Kubernetes.
איך המערכת בנויה
| רכיב | תפקיד |
|---|---|
| Sandbox | הקונטיינר המבודד שמריץ את הקוד של הסוכן. יש לו שם קבוע ואחסון קבוע (persistent storage) במידת הצורך. |
| SandboxTemplate | תוכנית (blueprint) המגדירה את תמונת הקונטיינר ואת מדיניות האבטחה — "מתכון" ל-sandboxes חדשים. |
| SandboxClaim | בקשה המוגשת על ידי סוכן (או הבקר שלו) כדי להקים sandbox מתבנית ספציפית. |
| SandboxWarmPool | מאגר של sandboxes שנוצרו מראש ומוכנים להקצאה מיידית. שמירה על קונטיינרים "חמים" מונעת את השיהוי (latency) של משיכת תמונות והפעלת pod חדש בכל פעם. |
כאשר סוכן זקוק לסביבה, הוא מגיש SandboxClaim. הבקר בודק את ה-warm pool, בוחר sandbox פנוי ומקשר אותו ל-claim. אם המאגר ריק, הוא יוצר sandbox חדש מהתבנית; אחרת, ההעברה מתבצעת תוך מילישניות.
כפתורי אבטחה שניתן לכוונן
- Default-deny networking – כברירת מחדל, sandbox אינו יכול להגיע לרשת הפנימית. עליכם להוסיף כללים מפורשים כדי לאפשר חיבורים יוצאים או נכנסים, מה שמונע חשיפה מקרית של שירותים פנימיים.
- רמות בידוד (Isolation levels) – בחרו את סביבת ההרצה (runtime) של הקונטיינר שתואמת את רמת הסיכון שלכם:
- קונטיינרים סטנדרטיים למהירות,
- gVisor עבור שכבת בידוד נוספת במרחב המשתמש (user-space), או
- Kata Containers עבור בידוד מבוסס חומרה המתנהג כמו VM קל משקל.
- SDKs – ספריות לקוח ב-Python וב-Go מאפשרות למפתחים ליצור, לתבוע (claim) ולהשמיד sandboxes באופן תכנותי, מה שמתאים לתזרים העבודה של צינורות (pipelines) מונעי AI.
מי מרוויח, ומי עשוי להתנגד
שורה תחתונה
מתן "קופסת Linux" חד-פעמית משל עצמם לסוכני AI מסיר את הלא-נודע הגדול ביותר מאוטומציה מונעת AI: הסיכון שהקוד שנוצר יהרוס את המארח. ה-GKE Agent Sandbox המנוהל של Google Cloud ופרויקט ה-kubernetes-sigs/agent-sandbox המנוהל על ידי הקהילה הופכים את הבידוד הזה לפרקטי הן עבור סביבות cloud-native והן עבור סביבות on-prem. ארגונים שצריכים לאזן בין גמישות לאבטחה מקבלים כעת כלי קונקרטי וטבעי ל-Kubernetes כדי לשמור על קוד שנוצר על ידי AI בתוך "ארגז חול" מבודד.