מאחורי הקלעים של Agent Audit Log: שחזור כל החלטה של הסוכן

מאת צוות מדיה דיל · 12.08.2026 · AI Investigation · 7 דק׳

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

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

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

למה לוג שיחה רגיל לא מספיק

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

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

מה חייב להיכלל בכל רשומת לוג

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

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

איך זה מתחבר לשאלת הבידוד בין משתמשים

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

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

מה קורה כשמנסים לתפוס "כוונה זדונית" בתוך הלוג

אחד הניסויים המעניינים ביותר שערכנו בדק האם ניתן להבחין, בהתבסס על לוג audit מלא, בין טעות תמימה של הסוכן לבין פעולה שהוא ביצע בעקבות ניסיון תקיפה כמו confused deputy — כלומר, האם הסוכן פעל מעבר לכוונה המקורית של המפעיל שלו בגלל הרשאה רחבה מדי. התשובה הייתה חיובית, אבל רק כשהלוג כלל את שרשרת ההנמקה המלאה של הסוכן, לא רק את הפעולה הסופית. הרחבנו את התבנית הזו במדריך על Confused Deputy Attacks, שמראה איך הרשאה רחבה יוצרת סיכון גם בכוונה תמימה.

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

מה קורה כשמנסים לשחזר אירוע בלי לוג — ניסוי השוואה

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

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

מה קורה כשהלוג עצמו הופך למטרה

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

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

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

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

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

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

תגיות: audit log · AI observability · confused deputy · multi-tenant isolation · שקיפות סוכני AI

← חזרה לבלוג · צור קשר