tool calling agent: איך מונעים שימוש לרעה בכלים (פעולות בלתי מורשות)

ai agent, כלים חזקים מדי ומי בכלל שומר על השומר?

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

הסיפור הזה, שלא באמת חריג היום, מחדד משהו בסיסי: ברגע שאנחנו נותנים ל-tool calling agent אפשרות "להרים טלפון" לכלים אמיתיים – API של בנק, מערכת הזמנות, מערכת רכש, שירות ענן – אנחנו כבר לא מדברים רק על צ'אטבוט חביב שעונה על שאלות. אנחנו מדברים על סוכן אוטונומי, ai agent שיכול להזיז כסף, לפגוע בנתונים, לשנות הרשאות. ואם לא שמים גבולות מאוד ברורים, הוא גם יעשה את זה בטעות, בלי כוונה רעה, פשוט כי ככה האוטומציה שלו עובדת.

מה זה בכלל tool calling agent, ולמה כולם מתלהבים?

בשנתיים האחרונות צמח לו ז'אנר חדש בעולם ה-AI הארגוני: לא עוד "מודל שפה" שיושב לו בפינה ועונה תשובות, אלא ai agent שיודע לקרוא לכלים חיצוניים – tool calling. במילים פשוטות: זה לא רק בינה מלאכותית שחושבת, אלא גם בינה מלאכותית שעושה.

הסוכן הזה יכול:

• לקרוא ל-API של מערכת פיננסית ולהעביר תשלום (או להכין הוראת תשלום)
• לשלוח מיילים או הודעות וואטסאפ ללקוחות
• לעדכן רשומות במערכות CRM ו-ERP
• לפתוח טיקטים במערכות תמיכה טכנית
• להפעיל תהליכים מורכבים בענן – דיפלוי, הקפאת שרתים, מחיקת משאבים ועוד

השילוב בין ai agent לבין היכולת לקרוא לכלי פעולה אמיתי – tool calling agent במובן העמוק – הוא המקום שבו נוצרה ההבטחה הגדולה: "סוכן" אוטונומי שיכול לטפל במשימות קצה-לקצה. מהקלטת הבקשה, דרך קבלת ההחלטה, ועד לתוצאה בפועל במערכת.

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

רגע, זה כמו בוט אוטומציה? לא בדיוק

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

בוט מסורתי עושה X כשקורה Y, לפי חוקים קשיחים. אם מגיע מייל עם כותרת מסוימת, הוא פותח משימה. אבל agent מבוסס AI יכול לפרש הקשר, להבין כוונות, "לנחש" מה המשתמש באמת רצה, ולהפעיל כמה כלים ברצף. כשמכניסים לתוך זה גישה לנתונים רגישים או לפעולות מערכת – השילוב הזה עלול להיות נפיץ.

איך נראה שימוש לרעה בפועל? לא תמיד צריך האקר מתוחכם

כאשר מדברים על "שימוש לרעה בכלים" בתוך tool calling agent, רוב האנשים ישר מדמיינים האקר רוסי, מקליד בשתיים בלילה מול מסך ירקרק. בפועל, המציאות לפעמים הרבה יותר אפורה.

השימוש לרעה הכי נפוץ: כוונות טובות, תוצאות רעות

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

הוא כותב ל-agent: "בבקשה תעדכן שעבור לקוח 123 כל ההזמנות הפתוחות סופקו, ושנציג אישר מתן החזר מלא". ה-agent, שמכויל ל-service first, רואה נוסח מנומס, בודק שהלקוח קיים, לא רואה התנגשות ברורה במדיניות, ומבצע. בלי כוונה זדונית מהצד של המתכנתים, קיבלתם פעולה בלתי מורשית שהמערכת לא הייתה אמורה לאפשר.

מידע רגיש זורם החוצה – דרך הדלת הראשית

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

כשמודל שפה "ממציא" תהליך עסקי

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

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

היכן מתחבאת האחריות? מודל, כלים או בני אדם

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

שכבת המודל: לא לסמוך על ה-ai agent כ"שומר חוק"

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

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

שכבת הכלים: "חוזה" ברור בין ה-agent לבין ה-API

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

• הגדרת סכנה (risk level) – עד כמה הפעולה עלולה להיות הרסנית
• כללי throttling – כמה פעמים מותר לבצע אותה בזמן נתון
• חוקים ברורים לגבי מי רשאי לקרוא לה, ובאילו נסיבות
• מנגנוני "אישור כפול" לפעולות רגישות – אפילו אם הן מגיעות מה-agent

במילים אחרות, tool calling agent לא אמור לדבר ישירות עם מערכת בנקאית או עם מערכת HR. הוא צריך לדבר עם "פרוקסי" אחראי, שמוודא שהוא לא עושה דברים בלתי סבירים. הפרוקסי הזה יודע להגיד: "רגע, אתה ai agent, אבל הפעולה הזו דורשת אישור אנושי".

שכבת התהליכים: לא להשאיר את ה-agent לבד בחדר

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

אחת הפרקטיקות הבריאות שראיתי: כל פעולה ברמת high risk שה-agent מתכנן לבצע – נשלחת קודם לאישור אנושי בצורה קריאה: "זה מה שאני עומד לעשות, זה למה". זה נראה קצת כאילו ה-agent כותב "מזכר" למנהלת, אבל זה מדויק: זה מחזיר את האחריות האנושית למשחק.

ישראל על המפה: רגולציה, יצירתיות, ושטח אפור

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

כשסטארט-אפ ישראלי פוגש רגולטור שמרני

במגזר הפיננסי, הרגולטור הישראלי לא אוהב הפתעות. כלים כמו tool calling agent שמסוגל לבצע הוראות תשלום, לעדכן סיכונים או להמליץ על השקעות אוטומטיות – מעלים שאלות קשות: מי אחראי אם ה-agent מבצע פעולה בלתי מורשית? האם זה באג תוכנה, הפרת רגולציה, או פשוט "טעות אנוש" מסוג חדש?

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

התרבות הארגונית הישראלית: "יהיה בסדר" פוגש אוטומציה מסוכנת

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

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

איך בונים ai agent שלא ייהפך לנזק ארגוני? תובנות, לא צ'ק-ליסט

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

1. להפריד בין "לחשוב" לבין "לבצע"

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

למשל, במקום לאפשר ל-agent להפעיל מיידית את כל הכלים, תנו לו להרכיב תכנית: "על סמך מה שהבנתי, אני מציע לבצע את שלוש הפעולות הבאות". אחר כך, שכבת מדיניות (ולפעמים גם אדם) תחליט מה באמת מבצעים.

2. הרשאות מינימליות, גם ל-agent "חכם"

אחד הסטנדרטים הוותיקים באבטחת מידע – least privilege – צריך לחזור בקול רם כשמדובר ב-tool calling agent. ה-agent לא צריך גישה מלאה לניטור הענן, לכל הטבלאות במסד הנתונים, לכל קבצי ה-SharePoint. רק למה שהוא באמת חייב, וגם זה תחת מגבלות.

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

3. "במה מותר לי לגעת?" – שיחה כנה עם עצמכם

לפני שמחברים את ה-agent למערכות ליבה, כדאי לשאול כמה שאלות כואבות: מה יקרה אם מחר בבוקר ה-agent ימחק בטעות 1,000 רשומות? מה יקרה אם הוא ישלח מייל לכל הלקוחות עם מידע לא נכון על מחירים? מה יקרה אם הוא יאשר בטעות מבצע שלא קיים?

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

4. תיעוד ובקרה: לא רק לוגים, גם סיפור

עוד נקודה מביכה לפעמים: ארגונים אוספים לוגים, אבל כמעט אף אחד לא מסתכל עליהם באמת. במקרה של tool calling agent, הלוגים הם קו ההגנה האחרון – וגם המקום שבו מבינים בדיעבד מה קרה כשהכול התחרבש.

מעבר ל"מי קרא לאיזה כלי ומתי", כדאי לתעד גם את ההסבר של ה-agent לעצמו: למה הוא בחר לבצע פעולה מסוימת. יש היום מסגרות שבהן ה-ai agent "חושב בקול" (מה שנקרא chain-of-thought פנימי), וחלק מההסבר הזה אפשר לשמור בצורה מצונזרת. במקרים של תקרית, אין תחליף ליכולת לחזור אחורה ולהבין מה גרם לו להרים את הטלפון לכלי הלא נכון.

5. חינוך משתמשים: לא לדבר עם ה-agent כאילו הוא קסם

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

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

שאלות ותשובות נפוצות על ai agent וכלי פעולה

האם ai agent יכול באמת לבצע פעולות לא מורשות בלי שמישהו ינסה "לתקוף" אותו?

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

איך אפשר לצמצם את הסיכון בלי להרוג את כל הרעיון של אוטומציה חכמה?

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

האם אפשר לסמוך על מודל השפה עצמו ש"יבין" את החוקים?

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

מה ההבדל בין ai agent לבין צ'אטבוט רגיל מבחינת אבטחה?

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

כמה זה רלוונטי לחברות בינוניות או קטנות בישראל?

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

טבלה: עיקרי הסיכונים והפתרונות ב-tool calling agent

סיכון מרכזי	איך הוא מתבטא ב-ai agent	כיוון אפשרי לפתרון
פעולות בלתי מורשות	ה-agent מפעיל כלי שמבצע שינוי ממשי (כסף, נתונים) בלי אישור מתאים	הפרדת שכבת "חשיבה" מביצוע, הרשאות מינימליות, אישורים כפולים לפעולות רגישות
דליפת מידע רגיש	קריאה לכלי שמחזיר נתונים שהמשתמש לא אמור לראות (שכר, בריאות, סודות מסחריים)	הגדרת מגבלות מידע ברמת ה-API, פילטור תשובות, בקרת הרשאות לפי פרופיל משתמש
שגיאות עסקיות קשות	ה-agent "ממציא" כלל עסקי (למשל, סוגר משימות ישנות) וגורם להפסדים או לתקלות שירות	הטמעת מדיניות ברורה בכלים, סף פעולה (threshold) שממנו נדרש אישור אנושי
שימוש זדוני פנימי	עובד מנוסה "מנסח" בקשות כדי לעקוף תהליכים דרך ה-agent	לוגים מפורטים, ניטור אנומליות, הפרדת תפקידים, הגבלת גישה לכלים רגישים
היעדר מעקב ואודיט	קשה להבין בדיעבד למה ה-agent ביצע פעולה מסוימת ומי צריך לשאת באחריות	רישום תיעודי של החלטות ה-agent, הקלטה של "הסבר הפעולה", נהלי חקירת תקלות
טעות תפיסתית – אמון יתר ב-AI	משתמשים מתייחסים ל-agent כאל "אוטוריטה" ומוותרים על שיקול דעת	הדרכת משתמשים, שיקוף גבולות הסמכות של ה-agent, חיזוק תרבות של בדיקה ואימות

ולבסוף: בין אוטומציה לאחריות

tool calling agent הוא לא עוד באזז-וורד. זה שינוי פרדיגמה אמיתי: ממערכות שעונות תשובות למערכות שפועלות. מ-ai agent "מדבר" ל-agent שמרים טלפון לכלים, קובע פגישות, מזיז כספים, משנה נתונים. ובכל פעם שאנחנו מעבירים פעולה כזו למכונה, אנחנו גם מעבירים אליה חלק מהאחריות – גם אם מבחינה משפטית זה עדיין עלינו.

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

אם אתם נמצאים בשלב שבו אתם שוקלים לחבר ai agent לכלים אמיתיים בארגון – מערכות פיננסיות, לקוחות, תפעול – זה הרגע לעצור לרגע, לשאול את השאלות הקשות, ולוודא שהבסיס האדריכלי, הארגוני והאתי קיים. נשמח לסייע בייעוץ ראשוני ללא עלות, במיוחד אם אתם מרגישים שtool calling agent הוא צעד מתבקש – אבל גם קצת מפחיד – בארגון שלכם.