AI Safety Incidents

פרומפט אחד, סוכן אחד, חשבון AWS שלם: מבט מבפנים על AgentCorruption ב-Amazon Bedrock AgentCore

מחבר

Elias Hawthorne

תאריך פרסום

Oct 12, 2026

מודלים אחרונים · 20צפו בכל המודלים →

בנצ'מרקים: Artificial Analysis · מתעדכן יומית

חזרה לכל הפוסטים

ב-8 באוקטובר 2026, Zenity Labs חשפה AgentCorruption: שרשרת של פגמים ב-Amazon Bedrock AgentCore, הפלטפורמה המנוהלת של AWS לפריסה והרצה של סוכני AI, שאפשרה לפרומפט יחיד בשפה טבעית לסוכן ציבורי אחד להשתלט על כל סוכן AgentCore באותו חשבון AWS ובאותו אזור. המחקר פורסם לצד הרצאה ב-SecTor 2026 בטורונטו, שבה מנהל מחקר האבטחה של Zenity, תמיר ישי שרבט, הציג אותה (Dark Reading, 8 באוקטובר 2026). הפרסום של Zenity עצמה, המיוחס לשרבט, ללנה סלאמה, לדמיטרי לוזובוי ולז'ואאו דונאטו, נפתח במנגנון: סוכן AgentCore שיש לו כלי כלשהו המסוגל לבצע בקשה יוצאת יכול להיות מוכוון לקרוא ל-AWS Instance Metadata Service (IMDS) בכתובת ה-link-local 169.254.169.254, שמחזירה אישורים זמניים עבור תפקיד ההרצה של הסוכן עצמו. Zenity מציינת שהיא ייצאה את האישורים האלה למכונה שלה ואישרה שהם עבדו משם. לא הוקצה מזהה CVE.

הארכיון מתעד זאת כפגיעות — משהו שהתגלה, לא בהכרח נוצל — עם גבוההחומרה {{4}}גבוהה{{/4}}, ביטחון A, ללא נזק אמיתי מתועד ומעורבות AI מאושרת. הצדדים חלוקים על המסגור אף שהם מסכימים על ההתנהגות: AWS אמרה ל-Dark Reading שהמחקר "מצייר באופן לא מדויק התנהגות צפויה ומתועדת כפגיעות."

מה שהשרשרת למעשה הייתה

AgentCore אורזת כל סוכן כמכולה ומריצה אותו בכל סשן בFirecracker MicroVM. הפוסט הראשון של Zenity בסדרה משחזר את כל נקודת האחיזה באמצעות בקשה בשפה פשוטה לסוכן בדיקה שנבנה עם Strands SDK, מסגרת הסוכנים בקוד פתוח של AWS, שמגיעה עם כלי מובנה לבקשות HTTP וכלי shell. ה-MicroVM לא הגבילה תעבורה לשירות המטא-דאטה, כך שהבקשה הגיעה מתוך המופע ו-IMDS השיב לה. לאחר מכן החוקרים עברו על נקודות הקצה: שם תפקיד ה-IAM, אישורי ה-STS הזמניים עצמם, נקודת הקצה של user-data — שהחזירה את מזהה החשבון, ARNs מלאים, כתובת ה-URL של סביבת הריצה וה-Amazon Elastic Container Registry (ECR) URI של תמונת הסוכן — ותגיות מופע הכוללות שרשרת תעודות mTLS, מפתח פרטי וכתובת URL חתומה מראש לאחסון פנימי. Zenity אומרת שאותה תוצאה התקבלה דרך כלי ה-shell, מכיוון שכשל הבידוד נמצא ברמת הפלטפורמה ולא בכלי בודד כזה או אחר.

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

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

הפגם השני, שדווח בנפרד, הוא שתפקיד ההרצה ש-AgentCore צירף לסוכנים כברירת מחדל לא היה מוגבל לסוכן אחד. Zenity מתארת הרשאות המשתרעות על כל משאב AgentCore בחשבון ובאזור, כולל bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, bedrock-agentcore:CreateEvent, bedrock-agentcore:DeleteEventובקצה שרשרת האישורים, bedrock-agentcore:GetResourceApiKeyוsecretsmanager:GetSecretValue.

HTML card titled 'One prompt, one role, four capabilities', kicked 'AgentCorruption · the path Zenity Labs describes' and subtitled 'The studied attack path, with the AWS permission Zenity names at each step. No CVE was assigned; AWS disputes the vulnerability framing.' Four stacked bands run down the card. Step 1, 'Foothold through a chat message': a public-facing agent holding any tool that can make an outbound request is asked, in plain language, to fetch 169.254.169.254; the Firecracker MicroVM did not restrict traffic to the metadata service, so the request came from inside the instance and IMDS returned the agent's own execution-role credentials as a temporary STS key pair and session token. Step 2, 'Every agent in the account and region': permissions logs:DescribeLogGroups and region-wide ECR read; agent IDs were derived from CloudWatch log groups named /aws/bedrock-agentcore/runtimes/AGENT_ID-ENDPOINT_NAME, and ECR repository names followed the convention bedrock-agentcore-AGENT_NAME, so every agent's container image and source code could be pulled. Step 3, 'Conversations, sessions and persistence': permissions InvokeAgentRuntime, ListEvents, ListActors, ListSessions, CreateEvent, DeleteEvent and GetMemory; read private conversations across users and sessions, invoke internal agents, inject an assistant-role event into a live session, and plant a memory that sends the agent to an attacker-controlled page before each answer. Step 4, 'Credentials outside AWS': permissions secretsmanager:GetSecretValue and bedrock-agentcore:GetResourceApiKey; provider names recovered from scraped agent source code or by enumerating 2 x (10+26)^5 = 120,932,352 likely default names, reaching API keys and OAuth secrets for third-party services. A footer reads 'Steps and permissions as described by Zenity Labs on 8 October 2026. AWS states the behaviour described is documented and expected, and disputes the vulnerability framing. Card rendered by OrcaRouter.'

יכולת הספירה הפכה את תווי התחליף האלה לרשימת מטרות. Zenity השתמשה בהרשאת התפקיד :DescribeLogGroups, מכיוון ש-AgentCore נותן שם לקבוצת הלוגים של CloudWatch של כל סוכן /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME}, והסיקה מזהי סוכנים משמות קבוצות הלוגים האלה. שמות מאגרי ECR עקבו אחרי מוסכמה שהחוקרים הבחינו בה — bedrock-agentcore-<agent_name> — כך שניתן היה למשוך כל תמונת סוכן באזור. משאבי זיכרון נמצאו באותו אופן, מתבנית קבוצת הלוגים /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}, והרשאות התפקיד ListActors, ListSessions ו-ListEvents הניבו את מזהי השחקן והסשן שנדרשו כדי לקרוא את תוכן השיחה.

המאמר של Zenity מציג הדגמה קונקרטית של תנועה רוחבית: כניסה דרך סוכן חשוף לאינטרנט, גילוי הכלים של billing_agent באותו אזור, איתור קובץ בשם billing.json, וחילוצו באמצעות כלי לקריאת קבצים. הודעה לעיתונות מתארת את אותו תרחיש במונחים כלליים — תוקף שנכנס דרך סוכן שירות לקוחות חשוף לאינטרנט יכול לעבור לסוכן פיננסי פנימי שפרוס באותו אזור, להפעיל אותו, ולהגיע לנתונים, לכלים, לאישורים המקושרים ולשיחות הפרטיות שלו.

הזיכרון היה החלק שהאריך ימים מעבר לפרומפט

AgentCore Memory שומר את השיחה עצמה כזיכרון לטווח קצר ומאחסן רשומות שחולצו כזיכרון לטווח ארוך, תוך שימוש באסטרטגיות בשם SEMANTIC, USER_PREFERENCE, SUMMARIZATION ו-EPISODIC. Zenity השתמשה בCreateEvent כדי לכתוב אירועי שיחה אל משאבי הזיכרון של סוכנים אחרים. הפוסט שלה זהיר בנוגע למה שהפרימיטיב הזה יכול ולא יכול לעשות: CreateEvent אינו מאפשר לקורא לבחור מרחב שמות לטווח ארוך או לדרוס רשומה ישירות — האסטרטגיות המוגדרות של זיכרון היעד הן שקובעות מה יחולץ והיכן זה ינחת. Zenity גם מתארת את DeleteEvent ככזה שמשמש להסרת אירועי תוצאת כלים כך שסוכן מסיק מסקנה שגויה מנתונים חסרים, וכדי לטשטש עקבות באמצעות מחיקת האירוע שנטע זיכרון.

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

אישורים מעבר ל-AWS

הפוסט האחרון בסדרה סוגר את המעגל בכל הנוגע לכלים מחוברים. AgentCore Identity ו-Outbound Auth מאחסנים אישורי גישה לכלים כסודות ב-AWS Secrets Manager, תחת שמות הבנויים משם ספק ומתבנית קבועה כגון bedrock-agentcore-identity!default/apikey/{provider_name}. Zenity שחזרה שמות ספקים באמצעות גרידת קוד המקור של הסוכן שכבר משכה מ-ECR, ואחרים שחזרה בכוח גס: היא מדווחת שסיומת ברירת המחדל בת חמשת התווים נוצרת בצד הלקוח מספרות ומאותיות קטנות, ומניבה 2 x (10+26)^5 = 120,932,352 צירופים בשני סוגי הספקים. בקצב הבקשות שיכלה להחזיק מול Secrets Manager, אומרת Zenity שספירה מלאה אורכת כמה שעות — יותר מזמן החיים של אישורי ה-STS — ולכן בנתה לולאה שחזרה ושאלה את נקודת הקצה IMDS של הסוכן לקבלת אישורים טריים עם פקיעתם של הישנים. Zenity מוסיפה שמשתני סביבה היו קריאים דרך נקודת הקצה metadata user-data, כאשר כל שם נושא את הקידומת CONTAINER_ENV_, כולל המפתח שבו משתמש סוכן כדי להזדהות מול ספק המודל שלו, ושהפעלה של כל סוכן שהתגלה עם פרומפט מתאים אספה את הערכים הללו בקנה מידה רחב.

מבוסס, ושנוי במחלוקת מטעמים טכניים.

מה שנקבע הוא צר וספציפי. סוכני AgentCore יכלו להגיע ל-IMDS ולקבל את אישורי הגישה הזמניים של תפקיד ההרצה של עצמם — AWS אינה חולקת על כך, ומתארת זאת בהצהרתה כ"מתועד וצפוי". תפקיד ההרצה כברירת מחדל נשא הרשאות שהיו בהיקף החשבון והאזור ולא בהיקף של סוכן בודד; AWS שינתה אותו מאז, ו-Zenity אומרת שהבדיקות שלה אישרו את הצמצום. המחקר הוא הדגמה, לא קמפיין שנצפה: שרבאת אמר ל-Dark Reading ש-Zenity לא ראתה ראיות לכך שהפגם נוצל בשטח לפני התיקון, וייחס זאת בחלקו לקושי לזהות אילו ארגונים מריצים סוכנים על AgentCore, והוסיף שהוא "בטוח ב-100% שיש דרכים לעשות זאת".

מה שנוי במחלוקת הוא אם בכלל ראוי לקרוא לכך פגיעות. הצהרת AWS, כפי שנמסרה ל-Dark Reading ול-The Next Web, אומרת: "AWS מודעת למחקר שפורסם על Amazon Bedrock AgentCore, שמציג באופן לא מדויק התנהגות צפויה ומתועדת כפגיעות. סוכן יכול לגשת למשאבים בחשבון AWS אחר רק אם המפתח מעניק במפורש הרשאות גם לתפקיד ההרצה של הסוכן וגם למשאב היעד." הצהרת AWS שמובאת בפוסטים של Zenity עצמה שומרת על המהות של המשפט הראשון — "ההתנהגות המתוארת מתועדת וצפויה" — ומוסיפה שלקוחות צריכים להעניק לתפקידי הרצה רק את ההרשאות שהסוכנים שלהם זקוקים להן. שני דברים עומדים ביסוד המחלוקת. AWS ממסגרת את הגבול במונחים של גישה למשאבים בחשבון AWS אחר, בעוד שהממצא של Zenity עוסק בסוכנים בתוך חשבון AWS ואזור בודדים; והתפקידים ש-Zenity מתארת הגיעו מברירות המחדל של הפלטפורמה ולא מלקוח שכתב מדיניות ביד.

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

ציר הזמן של הגילוי

HTML card titled 'How the disclosure ran, and what AWS changed', subtitled 'Two reports, filed on different dates and answered separately. Dates as published by Zenity Labs and as reported by Dark Reading and The Next Web.' Eight rows run down a vertical timeline. 25 December 2025: Zenity Labs reports the IMDS access issue to AWS, report number one. 12 January 2026: Zenity Labs files a second report covering the over-privileged default execution role and the resulting blast radius. 14 February 2026: per AWS, as reported by Zenity, newly deployed AgentCore agents launch with IMDSv2 only, which requires a session token on each request. 25 February 2026: AWS tells Zenity the team is working on the underlying role issue, and the default execution role stays the same. 12 April 2026: AWS closes report number one as 'informative', noting the February IMDSv2 change. 22 June 2026: Zenity reviews the default execution role again and confirms its permissions are unchanged. 29 September 2026: the final pre-publication review finds substantial changes, with permissions to invoke other agents, read private conversations and access Secrets Manager removed and other permissions significantly restricted. 8 October 2026: research, press release and SecTor 2026 talk in Toronto; AWS gives its statement to press the same day; no CVE was assigned. A footer reads 'Timeline per Zenity Labs' disclosure notes, with AWS's IMDSv2 date as reported by Zenity and Dark Reading. Card rendered by OrcaRouter.'

Zenity הגישה שני דוחות ולא אחד, והם נענו באופן שונה. דוח הגישה ל-IMDS הוגש ב-25 בדצמבר 2025; AWS סגרה אותו ב-12 באפריל 2026 כ"אינפורמטיבי", וכתבה ש-AgentCore השתמשה ב-IMDSv2 רק מאז 14 בפברואר 2026, כאשר סוכנים שנפרסו לאחרונה הושקו בדרך זו. השינוי הזה חשוב לפרטים של המחקר הזה, מפני ש-IMDSv2 דורש אסימון סשן בכל בקשה ושובר את השליפה הפשוטה ללא אימות שבה השתמשו החוקרים כדי להשיג אישורים. הדוח השני, על תפקיד ברירת המחדל ורדיוס ההשפעה שלו, הוגש ב-12 בינואר 2026. AWS אמרה ל-Zenity ב-25 בפברואר 2026 שהצוות עובד על כך בעוד התפקיד נשאר כפי שהיה; Zenity בחנה את התפקיד שוב ב-22 ביוני 2026 ומצאה שהרשאותיו לא השתנו. בבדיקה אחרונה ב-29 בספטמבר 2026 נמצא שהתפקיד צומצם באופן משמעותי, וההודעה לעיתונות של Zenity קובעת שההסרה כללה הפעלה של סוכנים אחרים, קריאת שיחות פרטיות וגישה לסודות ב-AWS Secrets Manager, כאשר גם הרשאות אחרות הוגבלו באופן משמעותי. הפוסטים של Zenity עצמה מציינים ש-AWS הפכה מאז את IMDSv2 לברירת מחדל בפריסות AgentCore וששני הצדדים שיתפו פעולה לאורך התהליך.

מה לא ידוע

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

שרבט אמר ל-Dark Reading ש-Zenity בוחנת כעת פלטפורמות ענן אחרות לבעיות דומות של גישה למטא-דאטה, ושהחברה טרם נוקבת בשמותיהן. המסקנה שהוא הציג נוגעת להרשאות ולא רק לשירות המטא-דאטה: "גם אם מישהו מגיע ל-IMDS, רדיוס ההשפעה יהיה קטן בהרבה."

מדוע רשומה זו נשמרת

AgentCorruption אינו בולט משום שנקודות קצה של מטא-דאטה הן רעיון חדש. Sharbat הפנה את קהל SecTor לפרצת Capital One מ-2019, שבה SSRF הגיע ל-IMDS והפך לאישורים גנובים, ותיאר זאת ככשל של הרשאה מינימלית מאותו סוג. מה שחדש הוא הגורם שמבצע את המשיכה. הבקשה שהפיקה זהות AWS נעשתה על ידי סוכן AI שעשה את מה שהתבקש, בשפה פשוטה, דרך כלי שניתן לו כדי שיוכל להיות שימושי — והסוכן העביר את התשובה בחזרה. שני התנאים שהפכו את זה לבעיה ברמת החשבון היו נקודת קצה של מטא-דאטה שארגז החול לא חסם, ותפקיד ברירת מחדל רחב יותר מהסוכן שהחזיק בו.

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

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

פרומפט אחד, סוכן אחד, חשבון AWS שלם: מבט מבפנים על AgentCorruption ב-Amazon Bedrock AgentCore

מה שהשרשרת למעשה הייתה

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

הזיכרון היה החלק שהאריך ימים מעבר לפרומפט

אישורים מעבר ל-AWS

מבוסס, ושנוי במחלוקת מטעמים טכניים.

ציר הזמן של הגילוי

מה לא ידוע

מדוע רשומה זו נשמרת

מוצר

משאבים

לספקים

הצטרפו לקהילה שלנו

מהבלוג

ספקי מודלים