פרויקט הקוד הפתוח Numbat מראה ש-hooks של סוכני AI אינם מהווים גבול אבטחה, ומספק למפתחים מסגרת עבודה המבוססת על ניטור (monitoring-first) כדי לשמור על סביבות עבודה בטוחות. על ידי התייחסות לכל סוכן כאל נקודת קצה ניתנת לצפייה (observable endpoint) שניתן לשחזר, ואם יש צורך – להפסיק, Numbat מאלצת צוותים לשאול את השאלות הנכונות לפני שהם מסתמכים על prompt בטיחות בלבד.
למה hooks של סוכני AI זקוקים ליותר מסתם prompt בטיחות
סוכני קוד (Coding agents) יכולים לקרוא כל קובץ בסביבת העבודה של המפתח, להפעיל כלי בנייה (build tools) מקומיים ולשלוח בקשות רשת. prompt שאומר "האם אתה בטוח?" לא ימנע מסוכן זדוני או פגום להוציא נתונים (exfiltrating data) או לשבש מאגר (repository). רוב הצוותים מתייחסים ל-hook שמחבר בין הסוכן למארח (host) כאל חומה שחוסמת התנהגות רעה, אך בפועל ה-hook הזה הוא רק נקודת מגע, לא שומר סף.
שלוש היכולות שכל אסטרטגיית הגנה חייבת לכסות
- תצפית (Observation) – על המארח להציג בזמן אמת מה הסוכן עושה. ללא לוגים או פלטים מה-hook, פעולה זדונית פשוט נעלמת ברקע.
- שחזור (Reconstruction) – לאחר תקרית, מהנדסים זקוקים להקשר מספיק כדי להרכיב מחדש את שרשרת האירועים מבלי לחשוף סודות נוספים. תמליל (transcript) המתעד כל בקשה, קריאת קובץ וקריאת רשת הוא חיוני.
- אכיפה (Enforcement) – המערכת חייבת לסרב לפעולה מסוכנת לפני שהיא מתבצעת. זה הולך מעבר לסתם תיעוד האירוע; זה דורש מנגנון שיכול להתערב, ולא רק לדווח.
Numbat בונה מודל יחיד המרכז נתונים מ-hooks מקומיים, לוגים של המערכת וקבצי סשן, ולאחר מכן מאפשר למפתחים להחיל חוקים המקיפים את כל שלוש היכולות. התיעוד מבהיר כי הניטור הוא מצב ברירת המחדל; אכיפה היא אופציה שניתן להפעיל (opt-in), אך היא עדיין משאירה את המארח בשליטה על ההחלטה הסופית.
ניטור לעומת אכיפה: ההבחנה החשובה
מפתחים רבים מערבבים בין "הגנה" לבין "ניטור". Numbat משרטטת קו בין השניים. גישת "ניטור תחילה" מעניקה לצוותים נראות לכל פעולה של הסוכן מבלי לשנות את התנהגותו. אם חוק מסוים מצביע מאוחר יותר על דפוס של שימוש לרעה, הצוות יכול להפעיל אכיפה עבור אותה פעולה ספציפית. נתיב האכיפה לא חוטף את הכלי שבבסיס; הוא פשוט מבקש מהמארח לדחות את הבקשה, ובכך שומר על סמכות המארח על המשאבים שלו תוך מתן רשת ביטחון.
תמליל שנוצר על ידי Numbat משמש כעקבות ביקורת (audit trail). הוא עוזר לחוקרים להבין מה השתבש בדיעבד, אך הוא אינו מונע מהבעיה להתרחש. זו הסיבה שהפרויקט ממליץ להתחיל בתצפית, לעבור לשחזור, ורק אז לשקול אכיפה ברגע שהנתונים ופרופיל הסיכון ברורים.
מטריצת כיסוי הסוכנים: רשימת תיוג מעשית
Numbat מגיעה עם מטריצת כיסוי המפרטת כל hook נתמך, רמת התצפית שהוא מספק, והיכן קיימים פערים. המטריצה אינה מסתירה תרחישים שאינם נתמכים; היא הופכת אותם לנראים כדי שצוותים יוכלו לתכנן בהתאם. שימוש במטריצה כרשימת תיוג יכול למנוע כשלים מפתיעים כאשר hook מפסיק לעבוד או כאשר סוכן רץ על פלטפורמה שהמטריצה מסמנת כ"לא נתמכת".
רשימת תיוג לצוותי הנדסה
- בצעו מלאי של כל מארח סוכן (agent host) (תוספי IDE, עטיפות CLI, מריצי CI) שהקוד שלכם נוגע בהם.
- החליטו האם אתם זקוקים רק לעקבות ביקורת, או גם למניעה בזמן אמת.
- בדקו את התנהגות המערכת כאשר hook נכשל – האם היא חוזרת לברירת מחדל בטוחה?
- שמרו על הרשאות מערכת ההפעלה ובקרות ברמת הרשת נפרדות משרשרת הכלים (toolchain) של הסוכן.
מעקב אחר הרשימה עוזר לצוותים להתאים את עמדת האבטחה שלהם ליכולות בפועל של ה-hooks עליהם הם מסתמכים.
מגבלות הגישה
Numbat אינה תחליף לפתרונות אבטחת נקודות קצה (endpoint security) מסורתיים. host hook יכול לדווח רק על מה שהמארח בוחר לחשוף; אם למערכת ההפעלה או למחסנית הרשת (network stack) של המארח חסר לוגינג מפורט, התצפית תהיה חלקית. אכיפה תלויה בנכונות של המארח לסרב לפעולות, מה שעשוי שלא להיות אפשרי עבור כל הכלים או הסביבות. הפרויקט מציין כי הכיסוי תלוי במה שהמארח מספק, וכי הערך של הכלי טמון בהפיכת התלות הזו לנראית לעין.
מפתחים שמניחים ש-prompt בטיחות הוא מספיק מסתכנים במתן גישה ללא בקרה לסוכנים לקוד, לפרטי גישה (credentials) ולמשאבי רשת. Numbat מחייבת מעבר מ-"לסמוך על ה-hook" ל-"לוודא מה ה-hook עושה", מהלך המתאים את פרקטיקת האבטחה למציאות של פיתוח מונע AI.
שורה תחתונה: התייחסו ל-AI-agent hooks כאל נקודות תצפית, לא כאל קירות; נטרו תחילה, ואכפו רק לאחר שתבינו את הנתונים ואת הסיכון.