אבטחת סוכני בינה מלאכותית מחוץ למודל

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

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

ב-Aniccai אני פוגש מנהלים טכנולוגיים שרוצים להטמיע ⁨תהליכי עבודה אוטונומיים⁩ (Agentic Workflows) במערכות המידע שלהם. כמעט תמיד, הגרסה הראשונה של מנגנוני הבטיחות נכתבת ישירות בתוך הפרומפט. הם מוסיפים שתי פסקאות של כללים נוקשים, מריצים עשר בדיקות פשוטות, ומשוכנעים שהסוכן מוכן לייצור. ואז מגיע משתמש מתוחכם, הזרקת מידע עקיפה מרעילה את חלון ההקשר, והסוכן מאשר תשלום שאסור היה לו לאשר.

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

נקודות מפתח

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

הכשל המבני של מעקות בטיחות מבוססי פרומפט

⁨הזרקת פרומפט⁩ (Prompt Injection) היא למעשה עקיפת הרשאות. היא שוברת את ההיררכיה בין מתכנן המערכת לבין משתמש הקצה בכך שהיא ממזגת הוראות מערכת עם נתונים חיצוניים בלתי מהימנים.

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

במאמר המחקר If Agents Were Angels, No Governance Would Be Necessary: Out-of-Band Policy Enforcement at a Trusted Tool Boundary (arXiv:2608.27646), הדגימו מארק מילסטון ועמיתיו את הפער הזה. בבדיקות מול מערכות ארגוניות המדמות את Jira ו-ServiceNow, שיעור הכשלים צנח מ-57.6% ל-0.2% ברגע שהבדיקות עברו מהפרומפט אל שער אכיפה חיצוני. זהו הבדל תפעולי עצום.

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

⁨ירושת הרשאות⁩: גישת ניהול מלאה כברירת מחדל

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

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

בסקירה המעמיקה Authorization Architectures for Tool-Using AI Agents (arXiv:2609.15906), מיפו ראקש קומאר סורפאני ושותפיו את שרשרת הכשל הזו. הם הראו כי פעולה בטוחה דורשת היררכיה מוגדרת היטב הכוללת את המשתמש, המפעיל, סוכן התיאום ונקודת הקצה של הכלי.

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

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

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

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

גוגל הדגימה את עקרונות הגישה הזו במאמר Build zero-trust AI agents that judge intent, not just syntax (Google Developers Blog). הם הראו כיצד בדיקות תחביר בלבד נכשלות מול משתמש המבקש בנימוס החזר כספי על רישיון תוכנה שאינו ניתן להחזרה. הצבת מנוע מדיניות סמנטי עצמאי לפני הפעלת הכלי אפשרה לשער לחסום את הפעולה לפי חוקי העסק עוד לפני שמפתחות התשלום הופעלו.

יצרניות חומרה מקדמות את הרעיון הזה ישירות לתשתית הפיזית. בפרסום NVIDIA Open Agent Safety Platform: A Reference for Continuous In-Silicon Agent Monitoring (NVIDIA Technical Blog), מתוארת סביבת עבודה שבה סוכנים מבודדים ברמת הליבה, וכרטיסי תקשורת ייעודיים מנטרים את תעבורת הנתונים למודל מחוץ לטווח ההשפעה שלו. המודל אינו יכול לעקוף את מנגנון הבקרה, פשוט משום שהבקר יושב פיזית על נתיב הרשת.

זיהום זרימת מידע ומתקפות מרובות שלבים

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

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

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

כדי להתמודד עם אתגר זה, הוצגה מסגרת AgentFlow: A Flow-Centric Policy Language and Framework for Securing LLM Agent Systems (arXiv:2608.22868). המערכת עוקבת אחר נתיבי המידע בסביבת הריצה של הסוכן ומתייגת תוכן חשוד כשהוא נע בין כלים שונים. בבדיקות מקיפות, גישה זו מנעה פריצות לחלוטין תוך שמירה על רציפות התפקוד העסקי.

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

בניית רצפת הבטיחות הדטרמיניסטית

כיצד מיישמים זאת הלכה למעשה בארגון?

ראשית, הגדירו ⁨מכונת מצבים⁩ (State Machine) קשיחה סביב הסוכן. מכונת מצבים היא מודל חישובי המגדיר שלבים מוגדרים ומעברים מותרים בלבד ביניהם. אם הסוכן נמצא בשלב "בירור פרטי פנייה", שער הכלים חוסם באופן מוחלט כל ניסיון להפעיל פונקציית ביצוע תשלום, ללא קשר למה שהמודל מנסה לטעון. הסוכן אינו יכול לקצר תהליכים משום שהיכולת הטכנית אינה חשופה עבורו בשלב זה.

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

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

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

מקורות

• If Agents Were Angels, No Governance Would Be Necessary: Out-of-Band Policy Enforcement at a Trusted Tool Boundary (arXiv:2608.27646)
• Authorization Architectures for Tool-Using AI Agents (arXiv:2609.15906)
• AgentFlow: A Flow-Centric Policy Language and Framework for Securing LLM Agent Systems (arXiv:2608.22868)
• Build zero-trust AI agents that judge intent, not just syntax (Google Developers Blog)
• NVIDIA Open Agent Safety Platform: A Reference for Continuous In-Silicon Agent Monitoring (NVIDIA Technical Blog)

שאלות נפוצות

מדוע הנדסת פרומפטים אינה מספקת לאבטחת סוכני AI?

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

מהו שער אכיפת מדיניות מחוץ למודל?

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

כיצד מתקפות מרובות שלבים עוקפות מעקות בטיחות רגילים?

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

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

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

דברים שחשוב לזכור

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

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