כלי הקידוד מבוססי ה-AI מותקפים — האם צוות הפיתוח שלכם בטוח?

הבעיה

הוראה נסתרת שהוטמנה בקובץ README גרמה ל-GitHub Copilot להעניק לעצמו הרשאה להריץ פקודות מעטפת, להוריד תוכנה זדונית ולהקים בוטנטים. זה לא תרחיש היפותטי. זה קרה באוגוסט 2025, כאשר חוקרי אבטחה חשפו את CVE-2025-53773 — פגיעות קריטית בדירוג 7.8 מתוך 10 בסולם החומרה.

וזה מה שהפך אותה למפחידה כל כך. מפתח פשוט ביקש מ-Copilot "לסקור את הקוד" או "להסביר את הפרויקט". ה-AI קרא הוראה מורעלת שהוסתרה בקובץ של הפרויקט. לאחר מכן הוא שינה בשקט קובץ הגדרות כדי להפעיל את מה שהחוקרים כינו "מצב YOLO". במצב הזה, ה-AI יכול היה להריץ פקודות במחשב של המפתח שלכם ללא שום אישור אנושי. הוא יכול היה להוריד תוכנה זדונית. הוא יכול היה לגנוב אישורי גישה. הוא יכול היה להפוך את תחנת העבודה לצומת בבוטנט.

זו לא הייתה הפריצה היחידה. באותה שנה, מטמון ה-Bing של מיקרוסופט חשף מאגרים פרטיים של יותר מ-16,000 ארגונים — בהם IBM, Google ו-PayPal. והאקר החדיר פקודות הרסניות לתוסף ה-VS Code הרשמי של Amazon Q, שהותקן אצל יותר מ-950,000 משתמשים. שלושה אירועים נפרדים. שלוש שיטות תקיפה שונות. חוט משותף אחד: לכלי ה-AI שלכם יש יותר כוח ממה שאתם חושבים, והתוקפים יודעים לנצל את זה.

מדוע זה חשוב לעסק שלכם

אלה אינם סיכונים תיאורטיים הקבורים במאמר מחקרי. הם פגעו במערכות פרודקשן, בחברות אמיתיות ובמפתחים אמיתיים. זה מה שהמספרים אומרים לכם:

• יותר מ-16,000 ארגונים ראו את מאגרי הקוד הפרטיים שלהם נחשפים דרך מטמון ה-Bing של Microsoft Copilot, ובכלל זה קוד מקור קנייני ותיעוד פנימי.
• יותר מ-300 טוקנים פרטיים ומפתחות API חולצו — מפתחות שפתחו גישה לסביבות של AWS, Google Cloud, OpenAI ו-Hugging Face.
• יותר מ-950,000 מפתחים התקינו את תוסף Amazon Q הפגוע לפני שהקוד הזדוני התגלה.
• יותר מ-20,000 מאגרים נשאבו מארכיונים שהארגונים האמינו שהם פרטיים.

חשבו מה נמצא כרגע במאגרי הקוד של החברה שלכם. אישורי גישה למסדי נתונים. מפתחות API. מסמכי ארכיטקטורה פנימיים. לוגיקת טיפול בנתוני לקוחות. אם המפתחים שלכם משתמשים בעוזרי קידוד מבוססי AI המחוברים לשירותים חיצוניים, ייתכן שאתם כבר חשופים.

התמונה הרגולטורית מחמירה את המצב. רשימת ה-OWASP Top 10 לשנת 2025 עבור יישומי מודלים שפתיים גדולים (LLM) מונה כעת התקפות של "Excessive Agency" ושל "Supply Chain" בין הסיכונים בדרגה העליונה. מבקרים ורגולטורים משתפים את הפער במהירות. אם כלי ה-AI שלכם יכולים להריץ פקודות ללא אישור אנושי, זהו פער תאימות שהדירקטוריון שלכם צריך לדעת עליו. ואם הנתונים שלכם מופיעים במטמון של צד שלישי אחרי שמחקתם אותם, ייתכן שתעמדו בפני הפרות של הגנת המידע שאף לא ידעתם שהן אפשריות.

מה באמת קורה מתחת למכסה המנוע

הבעיה המרכזית פשוטה: רוב כלי הקידוד מבוססי ה-AI הם מעטפות דקות שנבנו מעל מודלי שפה כלליים. הם מנבאים את המילה הבאה הסבירה ביותר על בסיס דפוסים. הם לא מבינים אמת — הם מבינים סבירות. ויש להם גישה רחבה הרבה מדי למערכות שלכם.

חשבו על זה כמו גיוס מתמחה נלהב במיוחד שדובר כל שפה בשטף אבל חסר שיקול דעת. אתם מוסרים לו את אישורי המנהל שלכם ואומרים לו "לעזור". הוא יעשה כל מה שמישהו יבקש — כולל זר שמחליק לו פתק לתוך ערימת הקריאה.

בדיוק זה קרה עם פגיעות ה-Copilot. ה-AI ירש את מלוא ההרשאות של המפתח שלכם. הזרקת פרומפט נסתרת — קבוצת הוראות שהתחפשה להערת קוד או לטקסט README — הורתה ל-AI לשנות את קובץ התצורה שלו עצמו. ברגע שהפך את המתג, הוא יכול היה להריץ כל פקודה על המחשב. בקרות הגישה המסורתיות לא עזרו, כי ה-AI פעל "בשם" המשתמש.

בעיית מטמון ה-Bing פועלת אחרת, אבל נובעת מאותו שורש. כאשר כלי ה-AI שלכם תלוי במנוע חיפוש חיצוני לקבלת הקשר, אתם מאבדים שליטה על מחזור החיים של הנתונים שלכם. Bing סרק את המאגרים הציבוריים שלכם. הפכתם אותם לפרטיים. העותקים במטמון נשארו. ה-AI שלכם המשיך להגיש אותם לכל מי שביקש. המסמך הטכני מכנה זאת "Zombie Data" — מידע שממשיך לחיות במערכות אחזור של AI הרבה זמן אחרי שחשבתם שהשמדתם אותו.

בשני המקרים, הארכיטקטורה עצמה היא הפגיעות. שום כמות של בקשות מה-AI "להיזהר" לא תתקן מערכת שמעולם לא תוכננה עם גבולות קשיחים.

מה עובד (ומה לא)

נתחיל במה שנכשל.

לומר ל-AI להיזהר. רוב בטיחות ה-AI כיום מסתמכת על הוראות לשוניות — בעיקרון לבקש מהמודל "להיות שימושי ולא מזיק". הפריצות של 2025 הוכיחו שתוקפים עוקפים הוראות כאלה באמצעות הזרקת פרומפטים וג'יילברייקינג. מילים לא עוצרות הרצת קוד.

להסתמך על בקרות גישה מסורתיות. החומת אש והרשאות מבוססות התפקידים שלכם לא תוכננו עבור סוכני AI שיורשים את הרשאות המשתמש. ניצול ה-Copilot לא פרץ דרך חומת אש. הוא שכנע את ה-AI לשנות את קובץ ההגדרות שלו עצמו.

לסמוך על ספקי AI צד שלישי עם הנתונים שלכם. כאשר ה-AI שלכם תלוי במטמוני חיפוש חיצוניים או ב-APIs של צד שלישי, אתם מעבירים את השליטה במחזור החיים של הנתונים שלכם לגורם אחר. משבר ה-Zombie Data הראה שנתונים שנמחקו יכולים להישאר זמן בלתי מוגבל במערכות שאתם לא שולטים בהן.

אז מה באמת עובד? אתם צריכים מעקות ארכיטקטוניים (guardrails) — מגבלות קשיחות המובנות בזמן הריצה של המערכת, ולא רק הוראות בפרומפט.

1. בידוד קלט. התייחסו לכל פרומפט שה-AI קורא — כולל קבצי README, הערות קוד ותיעוד פרויקט — כאל קלט עוין פוטנציאלי. אכפו גבולות מחמירים בין מה שה-AI יכול לקרוא לבין מה שהוא יכול להריץ. קבצי תצורה מסוימים וקריאות מערכת צריכים להיות בלתי נגישים פיזית למנוע ה-AI, ללא קשר למה שנכתב בפרומפט.

2. שערי לוגיקה דטרמיניסטיים. שלבו את מודל השפה שלכם עם מערכת מבוססת חוקים שמשמשת כנקודת בקרה. ה-AI מציע פעולה. מנוע לוגיקה נפרד בודק את הפעולה מול חוקים מקודדים מראש — כמו "לעולם לא להריץ פקודות מעטפת ללא אישור אנושי" או "לעולם לא למחוק משאבים בסביבת פרודקשן". אם הפעולה מפרה חוק, המערכת מטילה עליה וטו לפני הביצוע. זו הליבה של מה שנקרא גישה נוירו-סימבולית — שילוב של יכולת השפה של ה-AI עם מערכת נימוק נפרדת שאוכפת את החוקים שלכם.

3. אחזור נתונים בלולאה סגורה. פרסו את מודלי ה-AI שלכם כולם בתוך הסביבה שלכם עצמכם. ואפס הסתמכות על מטמוני חיפוש חיצוניים או על APIs של צד שלישי לאחזור הקשר. כאשר מערכת האחזור פועלת על התשתית שלכם, חשיפות של Zombie Data הופכות לבלתי אפשריות מבחינה טכנית, כי אף מערכת חיצונית לעולם לא נוגעת בנתונים שלכם.

היתרון של שביל הביקורת חשוב במיוחד עבור צוותי התאימות שלכם. כאשר כל פעולה של ה-AI עוברת דרך שער לוגיקה דטרמיניסטי, אתם מקבלים רשומה מלאה וניתנת לאימות של מה שה-AI עשה ומדוע. כל פעולה מוצעת, כל בדיקת חוק, כל וטו — הכול מתועד. כאשר תהליך הערכת האבטחה והחיזוק כולל את הארכיטקטורה הזו, אתם יכולים להראות לרגולטורים ולמבקרים בדיוק כיצד ה-AI שלכם מקבל החלטות. זה ההבדל בין לקוות שה-AI שלכם יתנהג יפה לבין להוכיח זאת.

מחזור הפריצות של 2025 הוכיח גם שקבצי פרומפט הם משטח התקיפה החדש. הארגון שלכם צריך להתייחס לתבניות פרומפט כאל קוד הניתן להרצה. פירוש הדבר חתימה קריפטוגרפית, בקרת גרסאות וסקירת אבטחה לפני שכל תבנית פרומפט יכולה להשפיע על התנהגות של סוכן AI. פריצת Amazon Q הצליחה כי קובץ פרומפט זדוני בשם "cleaner.md" בוצע בו commit ישירות אל עץ המקור — ואף אחד לא תפס את זה לפני שהוא נשלח אל כמעט מיליון מפתחים.

כלי ה-AI שלכם צריכים לעבוד בשבילכם, לא נגדכם. אבל לשם כך נדרשת ארכיטקטורה שתוכננה לבטיחות מיסודה — ולא בטיחות שהוברגה כתוספת מאוחרת.

קראו את הניתוח הטכני המלא להעמקה בכל אחת מהפריצות ובדפוסים הארכיטקטוניים הספציפיים שמונעים אותן. תוכלו גם לחקור את הגרסה האינטראקטיבית לסיור מודרך.