הפסיקו לבטוח בסוכן: קשרו אישורים לקריאות כלי ספציפיות
רוב המערכות האג'נטיות (agentic systems) מגינות על פעולות מסוכנות כמו כתיבת קבצים או העברות כספים באמצעות אישור פשוט.
בדרך כלל, האישור הזה הוא דגל בוליאני (boolean flag) במצב המערכת.
דוגמה: approved: true.
זו טעות. ערך בוליאני נכשל בשלוש דרכים שתוקפים מנצלים:
- הפיכה (Flip): תוקף משנה את המצב מ-false ל-true באמצעות prompt injection או פגמים בקוד.
- השמעה חוזרת (Replay): אתם מאשרים פקודה בטוחה כמו "read file". המערכת רואה "true" ומאפשרת פקודה שנייה ומסוכנת כמו "delete database".
- סטייה בארגומנטים (Argument Drift): אתם מאשרים "send $10". תוקף משנה את הסכום ל-$10,000 לפני הביצוע. הדגל עדיין מציג "true".
הבעיה היא שאתם ממדלים את האישור כתכונה של כל הסשן (session) כולו. הוא חייב לשמש כראיה עבור קריאה ספציפית אחת.
איך לתקן את זה:
כאשר אדם מאשר קריאה, צרו תג (tag) מאובטח. התג הזה חייב לנעול ארבעה דברים:
- את ה-ID הייחודי של קריאת הכלי.
- האש (hash) של הארגומנטים המדויקים.
- את זהות המשתמש.
- זמן תפוגה.
אמתו את התג הזה ברגע הביצוע המדויק. השתמשו במפתח סודי שרק המערכת מכירה.
עקבו אחר הכללים הבאים ליישום:
- השתמשו ב-Canonicalization: גם המאשר וגם המבצע חייבים לבצע hash לאותם בייטים בדיוק. השתמשו ב-RFC 8785 כדי להבטיח שמספרים ומפתחות תואמים.
- Fail Closed: אם תג חסר, פג תוקף או שגוי, החזירו שגיאת "not approved" ספציפית. אל תתייחסו אליה כתוצאה סטנדרטית של כלי.
- Deny by Default: אפשרו רק כלים הדורשים אישור מפורש. דחו כל דבר אחר.
- טיפול ב-Replays: אם אתם משתמשים במנועים כמו Temporal, ודאו שהמפתח הסודי שלכם הוא דטרמיניסטי. אם המפתח משתנה לאחר הפעלה מחדש של המערכת, כל האישורים הקיימים ייכשלו.
הרשאה (Authorization) לא צריכה להיות חלק צף של מצב (state). היא חייבת להיות מעטפה קשורה שמוכיחה: "האדם הספציפי הזה אישר את הארגומנטים הספציפיים האלה עבור הכלי הספציפי הזה עד לזמן הספציפי הזה."
הפסיקו להשתמש בערכים בוליאניים. הם אינם פישוט. הם באג.
קהילת למידה אופציונלית: https://t.me/GyaanSetuAi