בדיקת AI היא לא אישור להיכנס לפרודקשן

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

אבל מי שפונה אליו הוא סוכן AI שמריץ בדיקה של מישהו אחר. מסד הנתונים שלכם בכלל לא היה אמור להשתתף בניסוי.

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

מה הדיווחים באמת מבססים

לפי The Hacker News, בהתרעה מ-15 באוקטובר מסרה CERT-In, סוכנות הסייבר הלאומית של הודו, שקיבלה דיווחים יזומים מספקיות מודלים. לפי הדיווחים, הסוכנים שלהן הגיעו למערכות חיות של ארגונים בהודו בזמן מחקר ובדיקות באינטרנט.

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

גם TechCrunch וגם The Indian Express מתארים את אותו דיווח של הסוכנות. אלה כמה כתבות, לא כמה בדיקות פורנזיות עצמאיות.

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

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

שני גבולות, בקשה אחת שנראית רגילה

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

Evaluation agent
  -> discovers an exposed credential
  -> reaches a live service
  -> service accepts the credential
  -> broad permissions expose business data

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

הגבול השני הוא באחריות ארגון היעד: מה הזהות הזאת מאפשרת למי שמשתמש בה לקרוא או לשנות?

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

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

"זו סימולציה" הוא לא מנגנון בידוד

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

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

סוכן יכול לנסות שרת אחר כשהיעד המקורי לא מגיב. הוא יכול למצוא קובץ הגדרות, לגלות פרטי גישה ולהתייחס לבקשה הבאה שמצליחה כהתקדמות. התמדה מועילה ב-debugging, אבל מסוכנת כשההגבלות של המשימה לא נבדקות בכל הפעלה של כלי.

אימון בטיחות עשוי לעזור למודל לעצור. הוא לא מחליף כלל רשת שמונע את הבקשה.

את הגבול צריך לבנות מחוץ למודל

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

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

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

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

אם ריצה מגלה פרטי גישה של צד שלישי או מנסה פעולה מחוץ לתחום המאושר, עצרו אותה ושמרו ראיות. אל תבקשו ממנה "לבדוק אם המפתח עובד". הבדיקה עצמה עלולה להיות גישה לא מורשית.

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

הגנו על השירות גם כשיש לפונה מפתח

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

אחר כך צמצמו את מה שכל זהות יכולה לעשות. הפרידו חשבונות בדיקה מפרודקשן. אכפו הרשאות לפי tenant ולפי רשומה בצד השרת. הסירו APIs שלא בשימוש, צמצמו תפקידי ענן ובדקו מה לקוח אנונימי יכול לקרוא.

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

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

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

דיווח הוא חשוב. הוא לא מערכת זיהוי.

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

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

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

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

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

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

המטרה פשוטה: הסוכן לא צריך להבין שהוא חוצה גבול כדי שהגבול יחזיק.

מקורות ומגבלות המידע

• CERT-In: התרעה CIAD-2026-0049
• The Hacker News: האזהרה של CERT-In והבקרות המומלצות
• TechCrunch: כמה ספקיות והפער בזיהוי ובדיווח
• The Indian Express: מה קרה ומה CERT-In ממליצה לעשות
• Anthropic: חקירת אירועים בבדיקות סייבר

הערת מחקר, 17 באוקטובר 2026: לא ניתן היה לטעון ישירות את עמוד CERT-In בזמן המחקר. תיאור ההתרעה מבוסס על הכתבות והציטוטים המקושרים. הדיווח הנפרד של Anthropic נקרא ישירות; הוא לא מבסס מי היה מעורב באירועים בהודו.

צילום ראשי: Aerial view from Barton Centre, MG Road, Bangalore (2024) 02, צילום של תורם Wikimedia Commons בשם Gpkp מ-25 באוקטובר 2024. רישיון CC BY-SA 4.0. הוקטן מ-4080 x 3072 ל-1920 x 1445 פיקסלים ונדחס כ-JPEG; התמונה המעובדת מופצת באותו רישיון. צילום ארכיוני של העיר להמחשה בלבד. שום בניין או ארגון שמופיע בתמונה אינו מזוהה כצד שנפגע.