AI Policy Engines — שכבת מדיניות בין המודל למערכת

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

כשההחלטה 'האם לאשר את הפעולה הזו' מפוזרת בין קוד ה-Agent, ה-Prompt וקריאות API נפרדות, אי אפשר לתחזק אותה. מנוע מדיניות מרכזי הוא הפתרון הארכיטקטוני.

בצוות שמריץ כמה עשרות Agents, כל אחד עם קוד משלו, מתגלה תופעה מוכרת: הלוגיקה של "מתי מותר לבצע פעולה רגישה" מפוזרת בכל מקום — קצת ב-prompt ("אל תמחק רשומות בלי אישור"), קצת בקוד ה-Agent (if-statement שבודק סכום), וקצת בהרשאות ה-API עצמו. כשצריך לשנות כלל אחד — למשל להעלות את סף האישור מ-500 ל-1000 ש"ח — צריך לחפש אותו בשלושה מקומות שונים, בשלוש שפות שונות, ולתקווה שלא שכחו Agent רביעי. זו בדיוק הבעיה שמנוע מדיניות מרכזי (Policy Engine) נועד לפתור: להוציא את החלטות "מותר/אסור/דורש אישור" מהקוד המפוזר, ולרכז אותן במקום אחד, נבדק, וניתן לביקורת.

מה זה Policy Engine ולמה AI Agents מחייבים אותו

Policy Engine הוא שירות (או ספרייה) שמקבל תיאור של פעולה מבוקשת — מי מבקש, מה הפעולה, על איזה משאב, באיזה הקשר — ומחזיר החלטה: לאשר, לחסום, או להעביר לאישור אנושי. הרעיון עצמו לא חדש (הוא הבסיס ל-Zero Trust ברשתות ותשתיות), אבל ל-AI Agents יש סיבה מיוחדת לצורך בו: מודל שפה הוא לא דטרמיניסטי, ולכן אי אפשר לסמוך אך ורק על ה-prompt כדי לאכוף גבולות. הפרומפט הוא הנחיה למודל; מנוע המדיניות הוא בקרה חיצונית שבודקת את הפלט בפועל, בלי תלות בכך שהמודל "יזכור" לציית.

ארכיטקטורת PDP/PEP — הפרדת החלטה מאכיפה

המודל הארכיטקטוני המבוסס הוא הפרדה בין שני רכיבים:

• Policy Decision Point (PDP) — השירות שמחזיק את חוקי המדיניות ומקבל את ההחלטה, בהינתן בקשה.
• Policy Enforcement Point (PEP) — הנקודה שבה ההחלטה נאכפת בפועל, בדרך כלל ממש לפני ביצוע tool call או קריאת API.

ה-PEP יושב לרוב בתוך AI Gateway או ברמת ה-orchestration של ה-Agent, בעוד ה-PDP הוא שירות נפרד שאפשר לעדכן, לבדוק ולנטר בלי לגעת בקוד ה-Agent עצמו. ההפרדה הזו היא מה שמאפשר לצוות אבטחה לשלוט במדיניות בלי להיות תלוי בכל שינוי בקוד Agent בודד.

Policy as Code — למה זה לא קובץ קונפיגורציה רגיל

הגישה המקצועית לכתיבת מדיניות היא Policy as Code: חוקים כתובים בשפה ייעודית (כמו Rego של Open Policy Agent), נשמרים ב-git, עוברים code review, ונבדקים באמצעות טסטים אוטומטיים — בדיוק כמו קוד רגיל. זה שונה מקובץ JSON סטטי של הרשאות כי הכללים יכולים להיות דינמיים ולוגיים, לא רק רשימות:

# דוגמה עקרונית לכלל מדיניות (בסגנון Rego)
allow_refund {
  input.action == "refund.issue"
  input.amount <= 200
  input.agent.role == "support-agent"
  input.ticket.owner == input.requesting_user
}

require_approval {
  input.action == "refund.issue"
  input.amount > 200
  input.amount <= 2000
}

deny {
  input.action == "refund.issue"
  input.amount > 2000
}

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

קלט למנוע המדיניות: מה חייבים להעביר

מנוע מדיניות טוב רק בטוב הקלט שהוא מקבל. עבור AI Agents, הקלט הרלוונטי כולל בדרך כלל:

• זהות מבצע הפעולה — מה שנקבע בשכבת Identity & Authentication.
• הפעולה המבוקשת — שם ה-tool, הפרמטרים המדויקים שלו.
• מקור ההוראה — האם ההחלטה נובעת מהוראת משתמש ישירה או מתוכן חיצוני (מייל, מסמך, תוצאת חיפוש) — קריטי להגנה מפני Prompt Injection עקיף.
• הקשר עסקי — סכום, סוג משאב, שעת יום, היסטוריית פעולות אחרונות של אותו Agent.

מדיניות דינמית מול סטטית — למה AI דורש הערכה בזמן אמת

ברוב מערכות ה-authorization המסורתיות, המדיניות נבדקת פעם אחת בכניסה למערכת. אצל Agents, כל tool call הוא הזדמנות חדשה לפעולה מסוכנת, ולכן ההערכה חייבת לקרות בכל קריאה, לא רק בהתחברות. זה מטיל דרישת latency נמוכה על ה-PDP — לרוב עד כמה עשרות מילישניות — כדי לא להאט את ה-Agent בצורה שתפגע בחוויית המשתמש, נושא שקשור לאופטימיזציית latency כללית במערכות AI.

אינטגרציה עם Tool Registries ו-MCP

כשארגון עובד עם MCP וריבוי כלים מספקים שונים, מנוע המדיניות הופך לנקודת הבקרה הטבעית לכל קריאת כלי, ללא תלות במקור הכלי. במקום לסמוך על כך שכל שרת MCP חיצוני אוכף בעצמו הרשאות נכונות (הנחה מסוכנת — ראו Tool Poisoning), ה-PEP בשכבת ה-Gateway בודק כל tool call מול המדיניות המרכזית לפני שהוא בכלל מגיע לשרת החיצוני. זה הופך את רשימת הכלים המורשים לרשימה אחת, נשלטת ונבדקת, גם כשמקורות הכלים עצמם מגוונים ולא כולם תחת שליטה ישירה של הארגון.

שילוב עם Approval Gates

לא כל החלטת מדיניות היא בינארית. תוצאה נפוצה ושימושית של PDP היא "דורש אישור" — לא לאשר אוטומטית, לא לחסום, אלא להעביר את הפעולה לתור אישורים אנושי. זה מחבר ישירות למנגנון Approval Gates, ומאפשר למדיניות להיות רב-רמתית: פעולות בטוחות עוברות אוטומטית, פעולות בסיכון בינוני עוברות אישור, ופעולות מסוכנות נחסמות מראש.

מנוע מדיניות כשירות משותף ל-Agents מרובים

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

הבחנה בין מדיניות אבטחה למדיניות עסקית

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

ביצועים: Caching של החלטות מדיניות

כאשר PDP נבדק בכל tool call, latency נהיה גורם קריטי. הפתרון הנפוץ הוא caching של החלטות לפי שילוב (זהות, פעולה, משאב) לזמן קצר — שניות עד דקות — כך שקריאות חוזרות לאותו סוג פעולה לא דורשות הערכה מלאה בכל פעם. חשוב להבדיל בין caching של מדיניות עצמה (בטוח, ואפילו רצוי — מפיצים עדכוני מדיניות לכל instance של ה-PDP) לבין caching של החלטה קונקרטית (מסוכן יותר, כי הקשר יכול להשתנות בין קריאה לקריאה — למשל יתרת תקציב שהתעדכנה). ככלל אצבע, מדיניות "מתי מותר" ניתנת ל-cache; נתונים דינמיים כמו "כמה כבר נוצל מהתקציב היום" צריכים תמיד קריאה טרייה.

גרסאות מדיניות ו-Rollback מהיר

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

טעויות נפוצות

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

ניטור בזמן אמת של דחיות חריגות

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

שאלות נפוצות

האם צריך מוצר ייעודי כמו Open Policy Agent, או אפשר לכתוב לוגיקה פנימית?

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

איך מנוע מדיניות שונה מ-Guardrails של המודל עצמו?

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

איפה מנוע המדיניות יושב בארכיטקטורה בפועל?

בדרך כלל כרכיב אמצעי ב-AI Gateway או בשכבת ה-orchestration, בין ה-Agent Runtime לבין הקריאה בפועל לכלים וממשקי API חיצוניים, כך שכל בקשה עוברת דרכו ללא אפשרות עקיפה נוחה.

מה עושים כשה-PDP עצמו נופל?

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

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

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

מה גודל הצוות המינימלי שמצדיק בניית מנוע מדיניות ייעודי?

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

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

תגיות: AI Policy Engine · Policy as Code · OPA · Policy Decision Point · Guardrails · Zero Trust AI

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