Google Cloud פרסמה ב־9 בנובמבר 2026 את תחזית האבטחה שלה ל־2027, ובה מסר ברור: סוכני AI עומדים להפוך מרכיב תפעולי מרכזי בארגון — ולכן צריך לנהל אותם כזהויות עצמאיות ולא כתוספת לחשבון של עובד.
התחזית נכתבה בידי בכירים מ־Google, Google Cloud ו־Mandiant. היא אינה דיווח על מוצר יחיד או הבטחה טכנולוגית, אלא הערכת כיוון: התקפות אוטונומיות מתקצרות מדקות לשניות, קוד נכתב בקצב גבוה יותר, וסוכנים מקבלים גישה לכלים, נתונים ותהליכים עסקיים. כתוצאה מכך, מנגנוני האבטחה הקיימים נדרשים לעבור מבקרה תקופתית להחלטות רציפות ומתועדות.
1. לכל סוכן AI תהיה זהות משלו
לפי Google, שימוש בחשבונות שירות משותפים או ב־Tokens רחבים יוצר נקודת כניסה מסוכנת. Prompt Injection או כלי MCP זדוני עלולים לנצל הרשאה שניתנה לסוכן לצורך משימה תמימה, ואז לנוע לרוחב בין מערכות.
המודל המוצע הוא להרחיב את Zero Trust עד לרמת הפעולה הבודדת: לכל סוכן יהיו אישורים נפרדים, הרשאות מינימליות, זמן חיים מוגבל והקשר ברור. אותה פעולה יכולה להיות מאושרת ביום אחד ולהיחסם ביום אחר אם מקור הבקשה, היעד או דפוס ההתנהגות נראים חריגים.
2. Decision Trace יהפוך לדרישת יסוד
כאשר סוכן משנה מחיר, מעדכן הרשאה, פורס קוד או מפעיל תהליך כספי, לוג רגיל אינו מספיק. Google מדגישה את הצורך בשרשרת החלטה מלאה ועמידה לשינוי:
- אילו נתונים והוראות נכנסו לסוכן;
- איזה מודל או רכיב קיבל את ההחלטה;
- באילו כלים נעשה שימוש ובאילו פרמטרים;
- איזו מדיניות אפשרה את הפעולה;
- מה הייתה התוצאה והאם ניתן לבטל אותה.
מבחינה מעשית, ארגונים צריכים לדרוש Telemetry אחידה מהמודל, משכבת התזמור, מה־API Gateway וממערכת הזהויות. בלי חיבור בין השכבות, קשה לשחזר אירוע או להוכיח שהפעולה עמדה במדיניות.
3. מרכז האבטחה יעבור מהתראות לדוקטרינה
Google צופה שסוכנים הגנתיים יבצעו העשרה, הצלבה ו־Triage באופן אוטומטי, ורק לאחר מכן יעבירו לאנליסט מסקנה מאומתת. ההתראה תהיה תוצר של חקירה ראשונית ולא נקודת הפתיחה שלה.
זה אינו מבטל את האנליסט האנושי. תפקידו משתנה: להגדיר את רמת הסיכון, לקבוע אילו פעולות אפשר לבצע אוטונומית, לבדוק חריגים ולוודא שכל החלטה ניתנת להסבר מהיר ולביטול. אוטומציה ללא גבולות ברורים עלולה להגדיל נזק באותה מהירות שבה היא אמורה לצמצם אותו.
4. הפיתוח וההגנה יסגרו את הלולאה
כלי Coding אוטונומיים מושכים חבילות, ספריות וכלי צד שלישי ישירות אל בסיס הקוד. התחזית מזהירה מפני הרעלת שרשרת אספקה, כלים חיצוניים ושרתי MCP שסוכן עשוי לסמוך עליהם אוטומטית.
התגובה המוצעת היא חיבור בין סביבת ה־Runtime לקוד המקור: כאשר מתגלה חשיפה אמיתית, המערכת תוכל לקשר אותה לשורת הקוד הרלוונטית, לבדוק אם החולשה ניתנת לניצול ולהציע תיקון שנבדק לפני פריסה. גם כאן, תיקון אוטומטי אינו פוטר מבדיקות Regression, Code Review ואישור אנושי לשינויים בעלי השפעה גבוהה.
5. Red Team לפני חיבור לייצור
Google ו־Mandiant ממליצות לבצע בדיקות תקיפה רציפות לסוכנים לפני שהם מקבלים גישה לתהליכים קריטיים. הבדיקות צריכות לכלול Prompt Injection עקיף, עקיפת Guardrails, שימוש לרעה בכלים, דליפת Secrets וניסיון לגרום לסוכן לבצע פעולה מחוץ למשימה.
בארגונים עם מספר גדול של סוכנים, מומלץ להימנע מסוכן כללי אחד בעל הרשאות רחבות. צוות של סוכנים מתמחים — למשל Hunter, מנתח Malware ומגיב לאירועים — מאפשר להפריד הרשאות, זיכרון וכלים, ולתעד נקודות מעבר בין תפקידים.
מה לעשות כבר עכשיו?
- לבנות מלאי של סוכנים, מודלים, כלי MCP וחשבונות השירות שהם משתמשים בהם.
- להקצות לכל סוכן זהות עצמאית והרשאות קצרות טווח לפי משימה.
- לתעד קריאות כלים, פרמטרים, החלטות ותוצאות במערכת מרכזית.
- להגדיר פעולות שמחייבות אישור אנושי ופעולות שניתנות לביטול אוטומטי.
- לבדוק Prompt Injection ושרשרת אספקה לפני חיבור לנתונים אמיתיים.
- לחבר ממצאי Runtime לקוד, לבעלות ולתהליך תיקון מדיד.
התחזית אינה אומרת שכל ארגון יפעיל SOC אוטונומי כבר בינואר. היא כן מצביעה על שינוי ארכיטקטוני: ברגע שסוכן יכול לפעול בשם הארגון, הוא הופך לישות שצריך לזהות, להגביל, לנטר ולחקור.
מקור
תמונה: Johnny Guitar / Unsplash, ברישיון Unsplash. דף המקור, היוצר והרישיון מתועדים במדיה.
