העובד לא הדביק סיסמה בצ׳אט. הוא לא הוריד קובץ נגוע. הוא לא אישר תשלום חשוד. הוא רק ביקש מסוכן AI לסכם מיילים, לפתוח משימות, לבדוק קבצים, לשלוח תשובה ללקוח ולעדכן מערכת. מבחינת העסק זו אוטומציה. מבחינת תוקף זו זהות חדשה עם ידיים, עיניים והרשאות.
זה לא מאמר נגד AI. להפך. ארגון שיחסום כל שימוש חכם בבינה מלאכותית ידחוף עובדים למעקפים פרטיים ויאבד נראות. זה מאמר נגד אוטומציה בלי בעלים, בלי גבולות, בלי לוגים ובלי יכולת לעצור פעולה מסוכנת בזמן. במאמר שלנו על שיחת AI אחת והמידע בחוץ עסקנו בדלף שנוצר כאשר מידע רגיש עובר לכלי חיצוני. כאן הסיכון גדול יותר: לא רק מה העובד כותב לכלי, אלא מה הכלי מורשה לעשות בשם הארגון.
הטעות הגדולה: חושבים על סוכן AI ככלי, לא כזהות
כלי רגיל ממתין לפעולה. סוכן AI מתכנן רצף פעולות. הוא יכול לקרוא מייל, לחלץ נתונים, לחפש במסמכים, לפתוח קריאה, לנסח תגובה, לשלוח בקשה לאישור, לעדכן שדה במערכת, ובמקרים מסוימים גם להפעיל פעולה מתקנת. בנקודה הזו השאלה כבר אינה האם המודל חכם. השאלה היא מי נתן לו הרשאה, לאיזה מידע, באיזה הקשר, לאיזו מטרה, ולמי יש סמכות לכבות אותו.
ב Microsoft Security מתארים את סוכני ה AI כיישויות שיכולות לתכנן, לשרשר פעולות בין מערכות ולהפעיל כלים גם כאשר אין אדם שמאשר כל צעד בנפרד. ההמלצה שם ברורה: להתייחס לכל סוכן כאל בעל זהות נפרדת, עם בעלים אנושי, תפקיד מוגדר, הרשאות מצומצמות, גבולות שימוש בכלים ותיעוד שמאפשר להבין מה קרה. זו בדיוק נקודת המעבר בין שימוש מועיל לבין סיכון עסקי.
הבעיה אינה מתחילה ברגע שהסוכן עושה משהו זדוני. היא מתחילה הרבה לפני, ברגע שבו צוות כלשהו מחבר אותו למערכות ארגוניות עם הרשאה רחבה כי זה מקצר פיילוט. קריאה לכל הקבצים. גישה לכל תיבת צוות. הרשאת כתיבה למערכת משימות. חיבור למאגר ידע פנימי. ואז עוד חיבור קטן ליומן, ועוד חיבור קטן לכלי דיוור, ועוד חיבור קטן ל CRM. כל הרשאה נראית סבירה לבד. יחד הן יוצרות יכולת שאף אחד לא תכנן באמת.
איך מתקפה כזו נראית בשטח
דמיינו סוכן AI שמסייע למחלקת שירות. הוא קורא פניות לקוחות, מסכם אותן, מציע תשובות ומעדכן סטטוס במערכת. כדי לעבוד טוב הוא מקבל גישה לתיבת הדוא״ל של התמיכה, למסמכי נהלים, למערכת לקוחות ולכלי פתיחת משימות. עכשיו תוקף שולח פנייה שנראית תמימה: בקשה לבדוק תקלה בחשבון. בתוך הטקסט או בקובץ המצורף נמצאת הוראה נסתרת שמיועדת למודל, לא לעובד. ההוראה אומרת לסכם נתוני לקוחות רגישים ולצרף אותם לתגובה, או לפתוח משימה עם קישור חיצוני, או להתעלם מהנחיות קודמות.
זה נשמע כמו מדע בדיוני עד שקוראים את OWASP בנושא Prompt Injection. ההסבר שלהם חד: הזרקת הוראות יכולה להגיע ישירות מהמשתמש או בעקיפין ממקורות חיצוניים כמו אתרים וקבצים, וההשפעה תלויה בהקשר העסקי ובמידת היכולת שניתנה למערכת. כאשר המודל רק עונה בטקסט, הנזק מוגבל יותר. כאשר הוא מחובר לכלים, הרשאות ונתונים, כל טעות יכולה להפוך לפעולה.
לכן המשפט ״המודל לא יקבל הוראה לעשות דבר אסור״ אינו בקרה. הוא תקווה. בקרת אבטחה אמיתית אינה נשענת על כך שהסוכן יבין נכון כל מסמך, כל מייל וכל דף אינטרנט. היא נשענת על גבולות קשיחים: הסוכן לא יכול לייצא קובץ רגיש, לא יכול לשלוח הודעה מחוץ לארגון בלי אישור, לא יכול למחוק מידע, לא יכול לשנות הרשאות, ולא יכול לקרוא מאגר שאינו קשור לתפקיד שלו.
הקשר המסוכן בין סוכני AI לבין OAuth
סוכני AI חיים על חיבורים. כדי להיות שימושיים הם מבקשים הרשאות לאפליקציות ענן. כאן נכנס אחד הסיכונים הכי לא מובנים בארגונים: חלון אישור שנראה לגיטימי יכול להעניק לאפליקציה גישה מתמשכת בלי לחשוף סיסמה. כתבנו על זה בהרחבה במאמר האפליקציה שאישרתם הרגע פתחה לתוקף את הענן, והמציאות רק מחמירה כאשר האפליקציה היא סוכן שמבצע פעולות.
ה FBI הזהיר כי במתקפות OAuth Consent Phishing התוקף לא חייב לגנוב סיסמה. אם המשתמש מאשר אפליקציה זדונית דרך מסך הרשאות אמיתי, היא יכולה לקבל גישה למיילים, קבצים ומידע רגיש, והחלפת סיסמה לבדה אינה מספיקה כי צריך לבטל את הטוקן דרך הגדרות האבטחה. ההסבר מופיע ב אזהרת IC3 הרשמית. Microsoft תיארה גם שימוש לרעה במנגנוני הפניה של OAuth לצורכי פישינג והפצת נוזקה דרך כתובות שנראות אמינות יותר למשתמשים, כפי שמפורט ב מחקר Microsoft Defender.
הלקח לא שייך רק למתקפות פישינג. הוא שייך לכל חיבור AI לארגון. אם סוכן מקבל הרשאת OAuth רחבה, ואם אין בקרה על מי אישר, אילו scopes ניתנו, מה תאריך הפעילות האחרון ואילו פעולות בוצעו בפועל, הארגון לא מנהל חדשנות. הוא מנהל אזור עיוור. וכמו שכתבנו במאמר האימות עבר. התוקף כבר בפנים, אימות רב שלבי אינו מספיק כאשר הפעולה המסוכנת מתרחשת אחרי שהאמון כבר ניתן.
הסכנה השקטה: סוכן שמחבר מידע שאדם אחד לא היה אמור לראות
יש ארגונים שמסתכלים על הרשאות בצורה צרה מדי: האם לסוכן יש גישה למייל, כן או לא. האם יש לו גישה לקבצים, כן או לא. זו טעות. הסיכון האמיתי נוצר בשילוב. סוכן עם גישה למייל, תיקיות לקוחות, מערכת מכירות ויומן הנהלה יכול לבנות תמונה עסקית שאף עובד בודד לא אמור לקבל. הוא יכול לקשר בין חוזה, מחירון, מועד חידוש, תלונת לקוח ופרטי קשר של מקבל החלטה.
ב Google Cloud מזהירים בתחזית הסייבר שלהם לשנת 2026 מפני מעבר מ Shadow AI ל Shadow Agent: עובדים יפעילו סוכנים עצמאיים למשימות עבודה, גם ללא אישור ארגוני, וייצרו צינורות בלתי נראים למידע רגיש, דלף, הפרות תאימות וגניבת קניין רוחני. אותה תחזית מדגישה שסוכני AI מחייבים תפיסת זהות חדשה, הרשאות זמניות ומדויקות, ושרשרת האצלה ברורה. אפשר לקרוא על כך ב Cybersecurity Forecast 2026 של Google Cloud.
מבחינת 010, זה אחד המשפטים החשובים ביותר לשנת העבודה הקרובה: הבעיה אינה רק מי משתמש ב AI. הבעיה היא איזה AI משתמש בארגון. סוכן לא מאושר שמחובר לחשבון פרטי, לתוסף דפדפן או לאפליקציית ענן יכול לעקוף מדיניות בלי רעש. בהקשר הזה מומלץ לקרוא גם את המאמר שלנו על תוסף אחד בדפדפן יכול לחשוף את כל הארגון, כי הדפדפן הופך לזירה שבה סשנים, תוספים, כלי AI והרשאות נפגשים.
איך בונים אבטחת סוכני AI בלי להרוג חדשנות
התגובה הלא נכונה היא איסור גורף. עובדים ימשיכו להשתמש בכלים שנותנים להם תפוקה. השאלה היא האם הארגון יספק מסלול בטוח, או שישאיר את העובדים לחפש לבד. אבטחת AI טובה מתחילה בשליטה, לא בפחד. היא צריכה לאפשר שימוש, אבל רק כאשר יש מיפוי, בעלות, הרשאות, ניטור ותהליך תגובה.
- מלאי מלא של סוכנים וחיבורים: אספו רשימה של סוכני AI, אפליקציות OAuth, תוספי דפדפן, כלי אוטומציה, מפתחות API וטוקנים. מי שלא מופיע במלאי אינו מנוהל.
- זהות נפרדת לכל סוכן: אל תפעילו סוכן דרך חשבון עובד רגיל או חשבון שירות משותף. לכל סוכן צריכה להיות זהות משלו, בעלים עסקי, בעלים טכני ומטרה כתובה.
- הרשאות לפי משימה: הפרידו בין קריאה, כתיבה, יצוא, מחיקה וניהול. סוכן שמסכם מסמכים אינו צריך למחוק מסמכים. סוכן שפותח משימה אינו צריך לקרוא את כל תיקיית הנהלה.
- רשימת כלים מאושרים: הגדירו מראש אילו פעולות מותרות לסוכן. לא רק איזה מידע הוא רואה, אלא אילו כלים הוא יכול להפעיל ומה נחשב פעולה בסיכון גבוה.
- אישור אנושי לפעולות רגישות: יצוא קבצים, שליחת מייל חיצוני, שינוי הרשאות, מחיקה, פתיחת גישה לספק ועדכון נתוני תשלום חייבים אישור אדם.
- טוקנים קצרים וביטול מהיר: הרשאה זמנית עדיפה על הרשאה שנשארת לנצח. תרגלו השבתה של סוכן, ביטול טוקנים וסיבוב סודות גישה. המאמר שלנו על API Keys וסודות גישה מרחיב למה סוד שנשאר פתוח הוא אירוע שמחכה לקרות.
- לוגים של פעולה, לא רק לוגים של שיחה: תיעוד של תשובת המודל לא מספיק. צריך לדעת איזה סוכן פעל, בשם מי, באיזו הרשאה, מול איזה משאב, איזה כלי הופעל, מה השתנה ומה מזהה האירוע.
- DLP שמבין AI: מדיניות מניעת דלף צריכה לזהות העברת נתוני לקוחות, קוד, חוזים, שכר, מידע פיננסי וסודות מסחריים אל כלי AI או דרכם.
- בדיקות הזרקת הוראות: בדקו מסמכים, מיילים ואתרים שמוזנים לסוכן. נסו לגרום לו לחרוג מהתפקיד, לחשוף מידע או להפעיל כלי שלא הותר לו. עדיף למצוא את זה בתרגיל מאשר בדוח אירוע.
- ניטור ב SIEM/SOC: אירועי אישור אפליקציה, שימוש בטוקנים, פעולות סוכן, גישה חריגה למידע ויצוא קבצים צריכים להגיע לניטור. בלי זה, אין דרך לחבר בין פעולה קטנה לאירוע גדול.
מה הנהלה צריכה לשאול לפני שמאשרים סוכן AI
אישור סוכן AI אינו החלטה של צוות חדשנות בלבד. זו החלטת סיכון. לפני שמחברים סוכן למידע אמיתי, ההנהלה צריכה לקבל תשובות קצרות וברורות:
- איזו בעיה עסקית הסוכן פותר, ומה יקרה אם הוא יפעל לא נכון?
- לאילו מערכות ומידע הוא מחובר?
- מי הבעלים שלו בארגון?
- אילו פעולות הוא יכול לבצע בלי אישור אדם?
- אילו פעולות חסומות לחלוטין?
- איך מבטלים אותו בתוך דקות?
- אילו לוגים מגיעים למערך הניטור?
- איך נזהה דלף, שימוש חריג או הרחבת הרשאות?
- מתי מבצעים סקירת הרשאות מחדש?
אם אין תשובות, אין סוכן בשל. יש ניסוי פתוח על מידע ארגוני. זו אמירה חדה, אבל היא עדיפה על האשליה שהכול בסדר כי הכלי הגיע מספק מוכר או כי מישהו קרא לו פיילוט.
איפה 010 נכנסת לתמונה
אנחנו לא מסתכלים על אבטחת AI כשכבה נפרדת. סוכן AI נוגע בזהויות, בדוא״ל, בענן, בדפדפן, בעמדות הקצה, ב DLP, בגיבוי, בספקים וב SOC. לכן הטיפול חייב להתחיל מתוך מעטפת הגנת סייבר ולא מתוך רשימת כלים מנותקת.
בפועל, העבודה הנכונה מתחילה בסקר סיכונים שממפה שימושי AI קיימים, אפליקציות מאושרות, תוספים, טוקנים, הרשאות וקווי מידע רגישים. לאחר מכן מצמצמים הרשאות, מגדירים מדיניות שימוש, מחברים אירועים ל SIEM/SOC, מפעילים מודיעין סייבר לחשיפות זהויות וסודות, ומחזקים מודעות עובדים סביב הרשאות AI ולא רק סביב מיילים חשודים. מי שרוצה להבין למה ניטור בלי תגובה אינו מספיק, יכול לקרוא את SOC בלי תגובה הוא רק מסך יפה.
השורה התחתונה
סוכן AI יכול לחסוך שעות עבודה, לשפר שירות, לקצר תהליכים ולהחזיר לאנשים זמן. אבל סוכן AI עם הרשאות רחבות, בלי בעלים, בלי גבולות ובלי ניטור הוא לא חדשנות. הוא עובד דיגיטלי שאף אחד לא בדק לפני שהכניסו אותו לחדר הכספות.
הפעולה המומלצת שלנו ברורה: עוד השבוע, הפיקו רשימת סוכני AI וחיבורי AI בארגון, בדקו אילו הרשאות ניתנו להם, חסמו אישורים חופשיים, הגדירו בעלים, חברו לוגים לניטור, ותכננו תרגיל אחד של הזרקת הוראות ודלף מידע. לא בעוד רבעון. עכשיו.
כי המתקפה הבאה לא חייבת להתחיל בהאקר שמקליד פקודה. היא יכולה להתחיל בסוכן שניסה לעזור יותר מדי.