בקצרה
אבטחה מתחילה בצמצום יכולות, הרשאות ועצמאות. זהות המשתמש, כללים עסקיים ואישור פעולה צריכים להיאכף גם מחוץ למודל. בידוד, תיעוד והתאוששות משלימים את ההגנה.
טעות בתשובה אפשר לעיתים לתקן בהודעה נוספת. טעות בפעולה יכולה להשאיר אחריה הזמנה, שינוי הרשאה או הודעה שכבר נשלחה. המעבר מצ׳אט לסוכן משנה לכן את השאלה המרכזית באבטחה.
לא מספיק לשאול אם המודל עונה באופן אחראי. צריך לדעת בשם מי הוא פועל, למה הוא רשאי לגשת ואיזה מנגנון יעצור פעולה שאינה מותרת.
הסיכון אינו דורש מודל ״זדוני״. בקשה עמומה, נתון ישן או פרשנות שגויה יכולים להספיק. אבטחה טובה מתכננת את הגבולות גם למקרה שבו הסוכן משוכנע שהוא עוזר.
שלוש דרכים לתת לסוכן יותר מדי כוח
OWASP מתאר את סיכון Excessive Agency דרך שלושה גורמים: יותר מדי יכולות, יותר מדי הרשאות ויותר מדי עצמאות. ההבחנה מועילה משום שכל גורם דורש טיפול אחר.
סוכן שסורק מסמכים אינו זקוק בהכרח לכלי מחיקה. זו שאלת יכולת. כלי קריאה שמחובר לחשבון מנהל בעל גישה לכל לקוחות הארגון יוצר בעיית הרשאות. כלי תקין ומוגבל שמבצע שינוי משמעותי בלי בדיקה נדרשת יוצר בעיית עצמאות.
אפשר לטפל בגורם אחד ולהשאיר את האחרים פתוחים. הסרת כפתור מממשק הסוכן אינה מצמצמת בהכרח את הרשאות החשבון שמאחוריו. הוספת אישור אנושי אינה מונעת מכלי לקרוא מידע שלא נדרש למשימה.
לכן הרשימה הראשונה שצריך להכין אינה ״אילו מודלים מותקנים״. היא מפת יכולות: קריאה, כתיבה, שליחה, מחיקה והפעלת קוד, עם זהות ותחום גישה לכל אחת.
זהות הסוכן אינה זהות המשתמש
במערכת פשוטה נראה שיש אדם אחד וסוכן אחד. בפועל עשויים להשתתף המשתמש, שירות התיאום, שרת הכלים ומערכת היעד. לכל רכיב יכולה להיות זהות אחרת.
כאשר הסוכן פועל בשם משתמש, צריך לשמר את הקשר הזה לאורך המסלול. אם כלי מקבל בקשה ממשתמש מוגבל אבל מפעיל אותה עם חשבון שירות רחב, מגבלת המשתמש עלולה ללכת לאיבוד.
לעיתים חשבון שירות הוא בחירה נכונה, למשל בתהליך רקע מוגדר. במקרה כזה צריך לצמצם אותו לתפקיד המסוים ולהגדיר אילו בקשות יכולות להפעיל אותו. עצם העובדה שהבקשה הגיעה מתוך שיחת AI אינה הרשאה.
גם תקן חיבור אינו עושה זאת אוטומטית. מפרט ההרשאות של MCP לתעבורת HTTP, בגרסה שנבדקה, מגדיר מנגנוני OAuth ובדיקת היעד שאליו נועד האסימון. זהו חלק חשוב מהתשתית, אך עדיין צריך לבדוק את ההרשאות העסקיות של הפעולה.
המאמר על MCP, ACP ו־A2A מסביר מדוע תאימות לפרוטוקול ויכולת פעולה בטוחה הן שאלות קשורות אך שונות.
להפריד בין הרשאה טכנית לזכאות עסקית
משתמש יכול להיות מורשה להיכנס למערכת ההזמנות, בלי להיות רשאי לשנות כל הזמנה. הוא יכול להיות מורשה להציע החזר, בלי להיות רשאי לאשר אותו בכל סכום.
לכן בדיקת פעולה צריכה לכלול גם את הרשומה ואת המצב הנוכחי שלה. האם היא שייכת לתחום האחריות של המשתמש? האם הפעולה מתאימה לשלב בתהליך? האם הסכום או היקף השינוי נמצאים בגבולות שהוגדרו?
הבדיקות האלה צריכות להתבצע בשירות שמבצע את הפעולה, ולא להישאר כטקסט בתוך הוראות המודל. המודל יכול להסביר מדיניות; הוא אינו צריך להיות האוכף היחיד שלה.
כך גם קל יותר לשנות מדיניות. שינוי תקרה עסקית צריך להיות ברור וניתן לבדיקה, ולא תלוי באופן שבו המודל פירש פסקה ארוכה.
כלי מצומצם עדיף לעיתים על כלי כללי חזק
כלי כללי נוח לפיתוח: הוא מאפשר לסוכן לבצע הרבה פעולות בלי לבנות ממשק לכל אחת. המחיר הוא שקשה יותר להבין מראש את היקף ההשפעה האפשרי.
במשימה עסקית חוזרת יש יתרון לכלי עם מטרה ברורה. למשל, יצירת טיוטת תשובה שונה משליחתה; קריאת מצב הזמנה שונה משינויו. הפרדה מאפשרת לתת הרשאות לפי צורך ולהפעיל בקרה רק במקום המתאים.
אין פירוש הדבר שכלי קוד או דפדפן אינם שימושיים. הם חשובים בסביבות מתאימות. אבל כאשר בוחרים בהם, צריך להבין איזה חלק מהבקרה עובר לסביבת ההרצה, לחיבורי הרשת ולמערכות היעד.
בOpenHands על שרת פרטי אפשר לראות מדוע עצם ההרצה המקומית אינה מבטיחה בידוד. אותו עיקרון חל על סוכנים עסקיים: מיקום המחשב אינו הגדרת הרשאה.
בידוד תהליך אינו בידוד מידע
Sandbox יכול להגביל את סביבת הריצה, אך יכולותיו תלויות במימוש ובהגדרות. קובץ שמחובר לסביבה, שירות נגיש ברשת או הרשאה רחבה לכלי עשויים להישאר זמינים גם כשהתהליך רץ במכולה.
לכן בודקים כמה גבולות נפרדים: מערכת קבצים, רשת, זהויות, סודות וגישה לנתונים. גבול אחד אינו תחליף לאחר.
יש להקפיד במיוחד על הפרדת לקוחות ושיחות. זיכרון ארוך טווח יכול לעזור לסוכן, אך אסור שיהפוך למסלול שבו מידע מהקשר אחד עובר לאחר בלי הרשאה. אותו דבר נכון למטמון, לקבצים זמניים ולתוצאות חיפוש.
המטרה אינה לשמור את כל ההיסטוריה בכל מחיר. המטרה היא לשמור רק מה שנדרש, למשך הזמן הנדרש ובתחום הגישה המתאים.
מה אישור טוב צריך לכלול
אישור הוא החלטה על פעולה מסוימת, לא הצבעת אמון כללית בסוכן. כדי שההחלטה תהיה משמעותית, המשתמש צריך לראות מה ישתנה, היכן ובאיזה היקף.
בפעולה רגישה כדאי להציג השוואה בין מצב קודם למצב מוצע. אם מדובר בשליחה, מציגים יעד ותוכן. אם מדובר בשינוי רשומה, מציגים מזהה ושדות. המערכת צריכה לקשור את האישור למה שבוצע בפועל.
אישור יכול גם להתיישן. כאשר הנתונים השתנו או שהסוכן החליף פרמטרים, יש לבדוק אם ההחלטה המקורית עדיין תקפה. אחרת נוצר פער בין מה שהאדם ראה לבין מה שהכלי ביצע.
כדי להימנע מעייפות אישורים, לא מבקשים את אותה תשובה על כל קריאה חסרת סיכון. מגדירים מראש פעולות אוטומטיות, פעולות מותנות ופעולות שנעצרות לבדיקה. n8n וסוכני AI מציג דוגמה להפרדה ברמת הכלי.
גם הקלט צריך להישאר בגבול שלו
סוכן שמחובר למקורות מידע עשוי לפגוש תוכן שמנסה להשפיע על התנהגותו. לכן אבטחת הרשאות צריכה להתחבר להגנה מפני Prompt Injection.
אבל אין צורך להמתין לזיהוי מושלם של תוכן בעייתי כדי להגביל פעולה. אם הכלי אינו מורשה לשלוח מידע ליעד מסוים, הבקשה צריכה להיחסם גם כשהמודל לא זיהה את הבעיה.
זו הסיבה שהפרדה בין מידע לסמכות היא שכבה אחת במערכת רחבה יותר. סינון והנחיות מפחיתים סיכון; אכיפה בכלים מצמצמת את מה שטעות יכולה לגרום.
אותו היגיון חל על פלט. תשובה מסודרת אינה הופכת נתון לאמין, ופרמטר בפורמט תקין אינו הופך פעולה למותרת.
מה צריך לראות ביומן הפעולות
תיעוד טוב מאפשר לענות על שאלות קונקרטיות: מי ביקש, איזה כלי הופעל, על איזו רשומה, תחת איזו מדיניות ומה הייתה התוצאה. כדאי לקשור את האירועים למזהה משימה משותף.
אין צורך להסתמך על הסבר חופשי של המודל לגבי מה שעשה. ראיה לפעולה צריכה להגיע מהכלי או ממערכת היעד. אם מערכת חיצונית לא אישרה השלמה, אין לדווח שהפעולה הסתיימה רק מפני שהסוכן התכוון לבצע אותה.
מצד שני, יומן עשיר מדי עלול להפוך למאגר מידע רגיש חדש. מצמצמים תוכן, מסתירים פרטי גישה ומגבילים מי יכול לקרוא את התיעוד. גם שמירת ראיות דורשת מדיניות.
| שכבה | שאלה שצריך לענות עליה |
|---|---|
| בקשה | מי יזם את העבודה ומה היקפה? |
| החלטה | איזו פעולה הוצעה ואיזו מדיניות חלה? |
| אישור | מה בדיוק אושר, אם נדרש אישור? |
| ביצוע | מה החזיר הכלי ומה השתנה במערכת? |
| התאוששות | מה ניתן לעצור, לתקן או לבטל? |
עצירה ושחזור הם חלק מהמערכת
מערכת שפועלת ברקע צריכה דרך לעצור נתיב פעולה בלי לפרק את כל השירות. אפשר להגביל כלי, להשבית חיבור או לעצור תור, בהתאם לארכיטקטורה.
לא כל פעולה ניתנת לביטול. הודעה שכבר נשלחה אינה חוזרת להיות טיוטה. לכן חשוב לסווג מראש פעולות הפיכות, פעולות שניתן לפצות עליהן ופעולות שאי אפשר להחזיר לאחור.
בתרגיל התאוששות בודקים לא רק שהשירות עולה מחדש, אלא שהוא יודע מה כבר בוצע. הפעלה חוזרת אחרי תקלה יכולה להיות מסוכנת אם היא משחזרת את התהליך אך שוכחת את מצב הפעולות.
הדבר קשור ישירות להטמעת AI בעסק: יכולת לעצור ולחזור למסלול ידני היא תנאי להרחבה, לא תוספת לאחר שהכול כבר מחובר.
השורה התחתונה
אבטחת סוכנים אינה מסתכמת בשאלה אם המודל מסרב לבקשה בעייתית. היא עוסקת בחלוקת כוח: מי יכול לקרוא, להחליט, לאשר ולבצע.
ככל שהסוכן מועיל יותר, חשוב יותר שהסמכות שלו תהיה מדויקת. מערכת שמגבילה יכולות, בודקת זכאות ושומרת ראיות מאפשרת לתת לסוכן עבודה אמיתית בלי להפוך כל טעות שלו לטעות של כל הארגון.
שאלות נפוצות
האם סוכן לקריאה בלבד בטוח לחלוטין?
לא. גם קריאה יכולה לחשוף מידע למשתמש הלא נכון או להעבירו לספק שאינו מתאים. היא מצמצמת סיכוני שינוי, לא את כל סיכוני המידע.
האם חשבון מנהל נחוץ כדי שהסוכן יעבוד טוב?
לא כברירת מחדל. יש להתאים הרשאות למשימה. חיבור רחב עשוי להקל על הקמה, אך מגדיל את היקף ההשפעה של טעות.
האם Sandbox מחליף בקרת הרשאות?
לא. הוא מגביל היבטים של סביבת ההרצה. הרשאות לשירותים, גישה למידע וזהות המשתמש דורשות בקרה משלהן.
מתי אפשר להגדיל עצמאות?
כאשר יש ראיות לביצועים בגבולות הנוכחיים, בדיקות מתאימות, ניטור ודרך התאוששות. הגדלה צריכה להיות ממוקדת בסוג פעולה, לא הרשאה כללית לסוכן.