מחקר Zenity: פרומפט אחד אפשר גישה לסודות דרך סוכן AI ב־AWS
לפי Zenity, ניסוי ב־Amazon Bedrock AgentCore אפשר גישה לסוכנים, לשיחות ולסודות באותו חשבון ואזור AWS. אמזון טוענת שזו התנהגות מתועדת ולא חולשה.
פרומפט אחד לסוכן AI יכול להפוך לשאלת אבטחה של סביבת הענן שסביבו: זה הסיכון שמציף מחקר AgentCorruption, שפרסמה Zenity Labs ב־8 באוקטובר 2026. לדברי החברה, בניסוי ב־Amazon Bedrock AgentCore התאפשרה גישה לסוכנים נוספים, לשיחות ולסודות באותו חשבון AWS ובאותו אזור ענן. AWS חולקת על הגדרת הממצאים כחולשה, והחוקרים זיהו צמצום הרשאות עוד לפני הפרסום.
מה נחשף: גישה מעבר לסוכן שאליו פנו
לפי Zenity, פנייה לסוכן במסגרת הניסוי אפשרה להשיג הרשאות ולהגיע למשאבים נוספים בסביבה שנבדקה. הנקודה החשובה אינה רק תוכן התשובה שהסוכן החזיר, אלא היקף הגישה שהתאפשר דרכו. כשסוכן מחובר למערכות ארגוניות, ההפרדה בין שיחה לבין פעולה בעלת השלכות הופכת לשאלת תכנון והרשאות, ולא רק לשאלה של איכות המודל.
לממצא יש גבול ברור: מדובר באותו חשבון ובאותו אזור ענן. התחקיר אינו מתאר גישה לכל לקוחות AWS, ואינו מבסס טענה למעבר מחשבון של ארגון אחד לחשבון של ארגון אחר. הוא גם אינו מציג ראיה לקמפיין תקיפה פעיל נגד לקוחות. ההבחנה הזאת חיונית כדי להבין מה הודגם, בלי להפוך ניסוי אבטחה לכותרת על פריצה גורפת.
גם הביטוי ״פרומפט אחד״ דורש הקשר. הוא מתאר את נקודת הפנייה בניסוי, אך אינו מוכיח שכל סוכן בכל תצורה חשוף לאותה תוצאה. מהתחקיר המצורף אי אפשר לקבוע אילו תנאים חייבים להתקיים בכל סביבת לקוח, או להסיק שכל התקנה של AgentCore מאפשרת את אותה גישה. לכן הממצא מצדיק בדיקת הרשאות ממוקדת, לא קביעה שכל שימוש בשירות אינו בטוח.
המחלוקת עם AWS: חולשה או התנהגות מתועדת?
AWS מסרה שמדובר בהתנהגות מתועדת ולא בחולשה. לצד זאת, החוקרים זיהו צמצום הרשאות עוד לפני פרסום המחקר. אלה שני פרטים שמשנים את אופן קריאת הסיפור: אין בסיס להציג את המצב כתקלה גורפת שנותרה ללא מענה, אך גם אין די במידע שנמסר כדי לקבוע שכל תצורה ארגונית מוגנת כעת או שכל סיכון הקשור להרשאות הוסר.
ברמה המעשית, המחלוקת מעלה שאלה רחבה יותר מהתווית ״חולשה״. יכולת יכולה להיות מתועדת ועדיין להעניק לסוכן גישה רחבה מזו שהעסק התכוון לתת לו. מנגד, עצם קיומה של גישה למשאב נוסף אינו מוכיח שהשירות עקף גבול אבטחה שהבטיח לאכוף. צוותי הפיתוח צריכים לברר מהו הגבול שהמערכת מבטיחה, ומהו הגבול שהם עצמם נדרשים להגדיר.
השאלה המעשית היא לא רק אם הסוכן פעל לפי ההוראות, אלא אם היו לו סמכויות שלא היה צריך לקבל מלכתחילה.
מה לא להסיק מהמחקר: לא הוכחה גישה לכל לקוחות AWS, לא תוארה פריצה פעילה גורפת, ואין בתחקיר בסיס לקבוע שכל סביבות AgentCore נותרו חשופות. הממצאים מיוחסים לניסוי של Zenity, ועמדת AWS היא שאין מדובר בחולשה.
למה הרשאות הן חלק מהתנהגות הסוכן
כדי להבין את המשמעות, אפשר לחשוב על תרחיש ארגוני היפותטי: סוכן שירות לקוחות צריך לקרוא פניות ולנסח תשובות, בעוד סוכן כספים מטפל במסמכים פנימיים. אם ההרשאות הזמינות לסוכן השירות כוללות גם משאבים של סוכן הכספים, ההפרדה העסקית בין התפקידים אינה בהכרח הפרדה טכנית. זו דוגמה לבעיה אפשרית, ולא תיאור של סביבה שהופיעה במחקר.
מכאן נגזר עיקרון תכנון: הוראה בטקסט, כגון ״אל תיגש למידע של מחלקה אחרת״, אינה תחליף להגבלת גישה במערכת שמבצעת את הפעולה. רצוי שהשכבה שמאשרת קריאה, כתיבה או הפעלת כלי תבדוק את ההרשאה בלי להסתמך רק על החלטת הסוכן. אם פעולה אינה נחוצה למשימה, עדיף שלא תהיה זמינה לו מלכתחילה.
ההבחנה הזאת רלוונטית גם לאופן הבדיקה. הדגמה שבה הסוכן משיב נכון על שאלות רגילות אינה בוחנת בהכרח את גבולות הסמכות שלו. לצד בדיקות שימושיות, כדאי לבדוק מה קורה כשהוא מתבקש להגיע למשאב שאינו שייך לתפקידו. הצלחה במבחן כזה היא סירוב שנאכף בשכבת הגישה, ולא רק תשובה מנומסת שהסוכן בחר לנסח.
המשמעות לצוותים ולעסקים בישראל
עבור עסק ישראלי שמחבר סוכן לתמיכה בעברית, למסמכי לקוחות או למערכת תפעולית, הבדיקה מתחילה במפת הגישה ולא בשפת השיחה. בתרחיש שבו כמה סוכנים פועלים באותו חשבון ובאותו אזור ענן, חשוב לברר אם חלוקת התפקידים ביניהם מגובה בהפרדת הרשאות. שימוש בחשבון משותף אינו כשלעצמו הוכחה לחשיפה, אבל הוא סיבה לבדוק את הגבולות בפועל.
- למפות לכל סוכן את המשאבים והפעולות הזמינים לו בפועל, ולהשוות אותם למשימה העסקית שאושרה.
- לבדוק בנפרד גישה לסודות, לשיחות ולמשאבים של סוכנים אחרים, ולא להסתפק בבדיקת מקור המידע הראשי.
- לבקש מספק האינטגרציה פירוט הרשאות והסבר לצורך בכל הרשאה רחבה, גם כשההגדרה נשענת על תצורה מתועדת.
- לבצע בדיקות חריגה בסביבה מורשית עם נתוני דמה, בלי לחשוף מידע אמיתי של לקוחות או עובדים.
- להגדיר מי בארגון בודק את יומני הפעילות ומי מוסמך לשנות הרשאות כשמתגלה גישה שאינה נחוצה.
לעסק קטן שמקבל סוכן כמוצר מוכן, לא תמיד יש גישה להגדרות הענן. במקרה כזה, אפשר להפוך את הבדיקה לשאלות קבלה לספק: אילו מערכות הסוכן יכול להפעיל, האם הוא חולק הרשאות עם רכיבים אחרים, וכיצד מוכיחים שמשאב אסור אכן חסום. אלה שאלות קונקרטיות יותר מהבטחה כללית שהפתרון ״מאובטח״.
מה הלאה: לבדוק את הגבול, לא רק את הכותרת
נכון ל־11 באוקטובר 2026, התמונה בתחקיר כוללת ניסוי שפרסמה Zenity, צמצום הרשאות שזוהה לפני הפרסום ומחלוקת עם AWS על סיווג ההתנהגות. עדיין חסר כאן בסיס לקביעה גורפת על מצבה של כל סביבת לקוח. מי שמפעיל סוכנים צריך לבדוק את התצורה הנוכחית שלו, ולא להסתמך רק על הכותרת המחקרית או על עצם קיומו של תיעוד.
הלקח המעשי אינו להפסיק להפעיל סוכני AI, אלא להתייחס להרשאות שלהם כחלק מרכזי מהמוצר. לפני הרחבת שימוש מסוכן בודד למערך סוכנים, כדאי לדרוש הוכחה שכל אחד מהם מוגבל לתפקידו. כך גם מחקר שהסיווג שלו שנוי במחלוקת יכול לשמש לבדיקה מועילה, בלי לייחס לו ממצאים שלא הוצגו.
שאלות נפוצות
מהו מחקר AgentCorruption של Zenity?
זהו מחקר שפרסמה Zenity Labs ב־8 באוקטובר 2026 על סוכנים ב־Amazon Bedrock AgentCore. לפי החברה, בניסוי שערכה פנייה לסוכן אפשרה להשיג הרשאות ולגשת לסוכנים, לשיחות ולסודות באותו חשבון AWS ובאותו אזור ענן.
האם AgentCorruption מאפשר גישה לכל לקוחות AWS?
לא. הממצאים המתוארים נוגעים לגישה בתוך אותו חשבון ובאותו אזור ענן, ולא למעבר בין כלל לקוחות AWS. החוקרים זיהו צמצום הרשאות עוד לפני הפרסום, ו־AWS מסרה שמדובר בהתנהגות מתועדת ולא בחולשה.
מה כדאי לבדוק בהרשאות של סוכני AI ב־AWS?
כדאי למפות לאילו משאבים כל סוכן יכול לגשת בפועל, ולהשוות זאת לצרכים של המשימה שהוגדרה לו. מומלץ לבדוק במיוחד גישה לסודות, לשיחות ולסוכנים אחרים, ולבצע בדיקות חריגה רק בסביבה מורשית עם נתוני דמה.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות