AI Guardrails — בניית גבולות והרשאות לסוכני AI

מאת צוות מדיה דיל · 09.08.2026 · AI · 6 דק׳

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

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

למה לא מספיק לסמוך על הנחיה טובה

הגישה האינטואיטיבית — "נכתוב ב-System Prompt שהסוכן לא יעשה X" — היא לא הגנה אמיתית. הנחיות בפרומפט הן המלצות התנהגותיות, לא אכיפה טכנית. מודל שפה יכול "להשתכנע" לעקוף הוראה כזו על ידי קלט מתוחכם (Prompt Injection), או פשוט לטעות בתום לב כשהוא מפרש מצב מורכב. Guardrails אמיתיים הם מגבלות שנאכפות מחוץ למודל — בקוד, בהרשאות מערכת, בשכבת תשתית — כך שגם אם המודל "מנסה" לחרוג, הפעולה פשוט לא תתאפשר טכנית.

סיווג פעולות לפי רמת סיכון

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

עיקרון הליבה: Least Privilege

לכל Agent, לכל כלי, ולכל שרת MCP צריכה להיות בדיוק ההרשאה המינימלית הנדרשת לתפקידו — לא יותר. Agent שרק צריך לקרוא נתונים מקבל credentials read-only. Agent שמטפל בתחום צר (למשל החזרות כספיות) לא מקבל גישה לכל מסד הנתונים, אלא רק לטבלאות הרלוונטיות. העיקרון הזה נראה מובן מאליו, אבל בפועל, לחץ זמן בפיתוח מוביל לעיתים קרובות למתן הרשאות רחבות "ליתר ביטחון" — בדיוק ההפך מהעיקרון. ראו הרחבה בLeast Privilege לסוכני AI והרשאות סוכנים.

הפרדה בין הרשאות זמן-פיתוח להרשאות זמן-ריצה

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

ולידציה של קלט ופלט

שתי נקודות קריטיות לבדיקה: קלט — כל מידע חיצוני שנכנס להקשר (קלט משתמש, תוצאות כלים, מסמכי RAG) הוא ערוץ תקיפה פוטנציאלי, במיוחד כשמקורו לא מהימן (מסמך חיצוני, אתר אינטרנט). ראו Prompt Injection עקיף. פלט — לפני שפעולה שהמודל מבקש לבצע אכן מתבצעת, יש לבדוק שהיא הגיונית ובגבולות הצפויים: סכום כספי בטווח סביר, פעולה על משאב שהמשתמש אכן מורשה לגעת בו, פרמטרים שלא חורגים ממה שהכלי מצפה לו. ולידציה כזו היא שכבת קוד רגילה — לא AI — שבודקת את הפלט של ה-AI לפני שהוא הופך למעשה בעולם האמיתי.

function validateAction(action, context) {
  if (action.type === "refund" && action.amount > MAX_AUTO_REFUND) {
    return { allowed: false, reason: "requires_human_approval" };
  }
  if (!context.user.permissions.includes(action.resource)) {
    return { allowed: false, reason: "insufficient_permissions" };
  }
  return { allowed: true };
}

שערי אישור לפעולות בלתי הפיכות

לא כל פעולה צריכה אישור אנושי — זה יהרוג את היתרון של אוטומציה. אבל פעולות בלתי הפיכות או בעלות השפעה גבוהה (מחיקת נתונים, תשלום, שליחת תקשורת חיצונית ללקוח, שינוי הרשאות) צריכות שער אישור לפני ביצוע. הגדרת הגבול — מה עובר אוטומטית ומה דורש אישור — היא החלטה עסקית שצריכה להיעשות במפורש, לא להיווצר במקרה מהעדר חשיבה. ראו שערי אישור וHuman-in-the-Loop.

הגבלת תקציב פעולות (Action Budget)

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

הגנה מרובת שכבות (Defense in Depth)

אף שכבת הגנה בודדת לא מספיקה — כל אחת יכולה להיכשל. ארכיטקטורה בטוחה משלבת כמה שכבות במקביל: Sandboxing — הרצת פעולות מסוכנות (הרצת קוד, גישה לקבצים) בסביבה מבודדת שלא יכולה לפגוע במערכת האמיתית (ראו AI Sandboxing); Policy Engine — שכבה מרכזית שאוכפת כללי מדיניות על כל פעולה, לא רק בקוד מפוזר (ראו מנועי מדיניות ל-AI); וAudit Log — תיעוד מלא של כל פעולה שבוצעה, כדי שאם משהו חורג, אפשר לזהות ולתקן במהירות (ראו Audit Logs ל-AI).

ניטור חריגות כאיתות מוקדם

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

דוגמה מהשטח

Agent פנימי שטיפל בעדכוני מלאי קיבל בהתחלה גישת כתיבה ישירה למסד הנתונים הראשי, כדי לפשט את הפיתוח. כעבור זמן קצר התגלה תרחיש שבו נתוני קלט לא תקינים ממערכת חיצונית גרמו ל-Agent לעדכן כמות מלאי שגויה עבור עשרות פריטים בבת אחת — לא בגלל "כוונה רעה" של המודל, אלא כי לא הייתה שכבת ולידציה שבדקה שהערכים החדשים הגיוניים ביחס לערכים הקודמים. הפתרון: הוספת בדיקת סבירות (sanity check) שדוחה שינוי שחורג מטווח סביר ומעביר אותו לאישור ידני, יחד עם צמצום הרשאות ה-Agent לטבלה ספציפית בלבד במקום גישה למסד הנתונים כולו.

שאלות נפוצות

האם Guardrails מאטים את המערכת?

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

מה ההבדל בין Guardrails לבין Evals?

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

איך מתמודדים עם Prompt Injection דרך מסמכים חיצוניים?

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

האם צריך Guardrails גם ב-Agent פנימי שלא חשוף למשתמשי קצה?

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

מי אחראי בארגון על הגדרת ה-Guardrails?

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

איך בודקים שה-Guardrails עצמם עובדים כמו שצריך?

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

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

תגיות: AI Guardrails · AI Safety · Least Privilege · Approval Gates · Prompt Injection · AI Security

← חזרה לבלוג · צור קשר