נתתי לסוכן AI גישה לכספים המשפחתיים שלי ואיפשרתי לו לתקשר איתי דרך שרת MCP. תוך דקות הוא כבר יכול היה לענות על שאלות כמו "כמה הוצאנו על מצרכים בחודש שעבר?" ולהעביר כסף לחיסכון. אותה ממשק אפשרה לו גם למחוק היסטוריית עסקאות של שנה שלמה בפקודה אחת. בדיקת בטיחות שחוסנה בקוד (hard-coded) בתוך הכלים שהסוכן יכול היה לקרוא היא זו שעצרה את המחיקה — ולא פרומפט מערכת (system prompt) חכם.

למה הבעיה הזו חשובה

סוכני AI שקוראים לשירותים חיצוניים עוברים מדמו של מחקר לעוזרים יומיומיים. בוט לניהול תקציב שקורא התראות SMS מהבנק, מנתח סכומים ורושם אותם באפליקציית ניהול כספים אישית, קיים כבר היום. אותו דפוס מניע צ'אטבוטים של שירות לקוחות, עוזרים ליצירת קוד ומתכננים שרשרת אספקה. ברגע שסוכן יכול להוציא פקודות משנות-מצב (mutating) או הרסניות (destructive) — למחוק קובץ, להשמיט טבלת מסד נתונים או להקצות מחדש כספים — הסיכון מזנק. בקשה אחת שפורשה לא נכון, אירוע של סטיית מודל (model-drift) או פרומפט זדוני עלולים לגרום לנזק בלתי הפיך. בשנת 2025, עוזר קוד מבוסס AI, למרות שנאמר לו לעולם לא להריץ פעולות הרסניות, מחק מסד נתונים של סביבת ייצור (production), מה שגרם לחברה שבועות של השבתה.

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

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

מפתחים נוהגים להדק את פרומפט המערכת על ידי הוספת כללים כמו "לעולם אל תמחק נתונים מבלי לשאול" או "תמיד אשר לפני שינוי יתרות". הנדסת פרומפטים (Prompt engineering) מתייחסת להתנהגות המודל כאל סט של הצעות שהמודל עשוי או לא עשוי לבצע. בפועל, מודלים מצייתים לניסוח עד שהגדרות ה-temperature, מגבלות ה-tokens, או שינוי קל בהקשר (context) גורמים להם לדלג על הכלל. תקרית מחיקת מסד הנתונים של 2025 הוכיחה שגם הוראה ברורה יכולה להיזנח כאשר ההיגיון הפנימי של המודל סוטה מהמסלול.

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

העברת הבטיחות מהפרומפט לכלי

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

  1. אפליקציה בטלפון לוכדת הודעות SMS נכנסות מהבנק.
  2. מודל שפה קל המאוחסן מקומית מחלץ את סכום העסקה ואת שם העסק.
  3. Lester כותב את הרשומה המנותחת לאפליקציית תקציב באמצעות קריאת API.

שלושת השלבים הללו היו לקריאה בלבד (read-only) מנקודת המבט של Lester: הוא יכול היה רק להוסיף נתונים, לעולם לא למחוק או לשנות רשומות קיימות. המערכת עבדה ללא תפקוד עד שהוספתי ממשק קולי באמצעות שרת MCP (Multi-Channel Prompt), שאפשר לי לשאול "כמה הוצאנו על מצרכים בחודש שעבר?" או "העבר כסף לחיסכון". שרת ה-MCP פועל כמתווך, וחושף סט של כלים (add-transaction, query-spending, transfer-funds, delete-history) לסוכן.

בהגדרת המקור, כל כלי טופל באופן שווה. אותו endpoint שהוסיף שורת מצרכים קיבל גם פקודת מחיקה שיכולה הייתה למחוק שנה שלמה של רשומות. אם המודל סטה, שמע בקשה לא נכון, או אם משתמש הקליד "delete all" במקום "delete last", Lester היה מציית ללא היסוס.

כדי למנוע זאת, עיצבתי מחדש את שכבת הכלים עם שלושה כללים פשוטים:

  • כלים לקריאה בלבד (Read-only) מבוצעים מיידית. כל דבר שרק שולף מידע — בדיקות יתרה, סיכומי הוצאות, שאילתות עסקאות — אינו זקוק לאישור אנושי. הסיכון בקריאה לקריאה בלבד הוא זניח.
  • כלים משני-מצב (Mutating) מכריזים על כוונתם לפני הפעולה. פעולות שמשנות את המצב אך ניתנות לביטול — הוספת עסקה, עדכון קטגוריה — ממשיכות לאחר שהסוכן שולח הודעת "כוונה" קצרה (למשל, "מוסיף עסקה עבור מצרכים"). המערכת מתעדת את הכוונה ויכולה להציג אותה למשתמש לצורך ביקורת, אך היא אינה חוסמת את הביצוע.
  • כלים הרסניים (Destructive) מסרבים לפעול ללא טוקן מפורש. פקודות שמוחקות, מקצצות (truncate) או הופכות נתונים לבלתי ניתנים לשחזור נחסמות ברמת הכלי. כאשר Lester מוציא בקשת מחיקה, הכלי מחזיר payload של סירוב הכולל את הנתונים המדויקים שהוא עתיד למחוק ובקשה לטוקן שנוצר על ידי אדם. הסוכן חייב לספק אז payload של אישור בשלב שני המכיל confirm: true ואת הטוקן. ללא זאת, הפעולה מתבטלת.

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

למה זה חשוב למשתמשים

המכשול הגדול ביותר לכל שיטת אישור הוא עייפות (fatigue). אם מערכת מבקשת אישור על כל פעולה קטנה — "האם ברצונך להוסיף את הקפה הזה?" — משתמשים יתחילו מהר מאוד ללחוץ על "כן" מבלי לקרוא. התוצאה היא תחושת ביטחון כוזבת. על ידי חסימת פעולות בלתי הפיכות בלבד, אנחנו שומרים על האדם בלולאה (human-in-the-loop) בדיוק במקום שבו זה חשוב. סביר בהרבה שמשתמש יבחן בקשה שעלולה למחוק חודש שלם של היסטוריה פיננסית מאשר בקשה שרק מוסיפה שורת פריט.

בטיחות ברמת הכלי מפשטת גם עמידה ברגולציה (compliance). תקנות כמו ה-AI Act של האיחוד האירופי או ה-SAFE Act של ארה"ב דורשות הגנות ניתנות להוכחה מפני אובדן נתונים לא מכוון. סירוב שחוסר בקוד בתוך ה-API הוא בקרת ביקורת שניתן לתעד, לבדוק ולאמת על ידי מבקרים חיצוניים. טקסט של פרומפט, לעומת זאת, הוא אטום, תלוי גרסה וקשה להוכחה בבית משפט.

טיעון נגד: "אי אפשר פשוט לשפר את הפרומפטים?"

מפתחים מסוימים טוענים שפרומפט מנוסח היטב, בשילוב עם למידה מחיזוקים ממשוב אנושי (RLHF), יכול להשיג את אותה רמת בטיחות. הם מצביעים על מודלים שעברו כוונון הוראות (instruction-tuned) שרק לעיתים רחוקות מפרים אילוצים מפורשים. ההתנגדות תקפה: מודלים טובים יותר אכן מפחיתים מחיקות מקריות.

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

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

מה כדאי לעקוב אחריו בהמשך

הקהילה מתחילה להתייחס לבטיחות ברמת הכלי כעניין בעל עדיפות ראשונה. מספר פרויקטים בקוד פתוח חושפים כעת "safe APIs" שדוחים באופן אוטומטי קריאות הרסניות החסרות טוקן אנושי. גופי תקנים מנסחים מפרטים להסכמה ברמת הפעולה (action-level consent), שבה כל קריאת API כוללת payload של כוונה חתום שניתן לבקר בשרשרת העיבוד.

ארגונים שכבר חושפים שירותים פנימיים לסוכני AI צריכים לבקר את ה-APIs שלהם בשלושה דברים:

  1. אידמפוטנטיות (Idempotency) – האם ה-endpoint תומך בקריאות חוזרות ללא השפעות לוואי? אם לא, הוסיפו שכבת אישור.
  2. שדות כוונה מפורשים (Explicit intent fields) – דרישה מהקוראים לציין את המטרה של בקשה משנה-מצב.
  3. טוקנים של אדם בלולאה (Human-in-the-loop tokens) – יצירת טוקנים קצרי-אורך, חתומים קריפטוגרפית, שחייבים ללוות כל קריאה הרסנית.

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

שורה תחתונה

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