סוכני ARTEX שלחו את זיכרון הקמפיין שלהם למלכודות של AWS

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

בגלל זה כדאי לקרוא את הדוח שאמזון פרסמה על ARTEX ב-13 בנובמבר. בין 3 באוקטובר ל-5 בנובמבר 2026, רשת המלכודות MadPot שלה קיבלה בקשות למודל שכללו זיכרון תפעולי של סוכנים.

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

איך שירות מודל מזויף קיבל הקשר אמיתי של קמפיין

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

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

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

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

תרשים הסבר המבוסס על הדוח של AWS. MadPot תיעדה את ההקשר שנשלח. פעילות קודמת שמתוארת בו דורשת ראיות נפרדות.

מה AWS ראתה ומה הרשומות טענו

הדוח הציבורי מציג כמה סוגים של ראיות.

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

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

מעגל גניבת המפתחות שתואר בזיכרון

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

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

הרשומות הזכירו שערי מודלים ופלטפורמות יישומים, ובהם One API, LiteLLM, Dify, Langflow ו-RAGFlow. הן תיארו פרטי גישה של ברירת מחדל, ממשקי ניהול חשופים, חולשות שלא תוקנו וסודות בקבצים ציבוריים. עצם האזכור של מוצר בדוח לא אומר שכל התקנה שלו פגיעה.

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

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

לקוח משכנע לא הוכיח עקיפה של בדיקת זהות

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

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

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

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

הגנו על פרטי גישה שהסוכנים יכולים להגיע אליהם

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

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

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

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

שמרו לוגים של סוכנים בלי ליצור מאגר סודות נוסף

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

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

האירוע הבא הוא הצעה למבנה לוג, לא מידע שנלכד אצל AWS:

{
  "run_id": "example-run-42",
  "tool_call_id": "example-call-7",
  "action": "read_object",
  "policy_decision": "deny",
  "tool_executed": false,
  "credential_ref": "workload-role",
  "outcome_source": "tool-broker"
}

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

תנו לשרת לקבוע את התוצאה

הדוגמה של בדיקות הזהות נותנת לקח הנדסי ברור. השלמת רצף בצד הלקוח אינה אישור.

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

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

מקורות

• דוח ARTEX של Amazon Threat Intelligence, מ-13 בנובמבר 2026
• המלצות האבטחה של AWS IAM
• מדריך הלוגים של OWASP

צילום ראשי: CERN Server, צילום של Florian Hirzinger מ-25 בפברואר 2009. רישיון CC BY-SA 3.0. הוקטן מ-3984 x 2656 ל-1920 x 1280 פיקסלים ונדחס כ-JPEG. הגרסה המעובדת מופצת באותו רישיון. זהו צילום ארכיוני של חדר שרתים להמחשה. הוא אינו מציג את AWS, את MadPot, את ARTEX או ארגון שנפגע. אין בו הבעת תמיכה.