המאגר של LLM Guard עבר למצב ארכיון ב-9 ביולי 2026, מה שמסיים את כל עדכוני הקוד והמודלים.
למה השינוי הזה חשוב
LLM Guard היה אחד ממעט ערכות הכלים החינמיות המתוחזקות על ידי הקהילה, שאפשרו למפתחים להוסיף "מסילות" (rails) – בדיקות שיושבות לפני או אחרי מודל שפה גדול (LLM) – מבלי לשלם עבור שירות מנוהל. עם הקפאת הפרויקט, ההגנות הללו נעלמות. במקביל, שוק אבטחת ה-AI הרחב יותר עובר איחוד: Protect AI נספגה על ידי Palo Alto Networks, Lakera על ידי Check Point, ו-OpenAI רכשה את promptfoo. השוק עובר מריבוי פרויקטים עצמאיים למספר מצומצם של הצעות ברמת הפלטפורמה, ומפתחים חייבים להחליט היכן להציב את קו ההגנה הבא שלהם.
שלושת בעיות ה-guardrail שיש לפתור
- Input rails – מסננים שבוחנים את הפרומפט של המשתמש לפני שהוא מגיע למודל, וחוסמים ניסיונות הזרקה (injection) וטכניקות פריצה (jailbreak).
- Output rails – סורקים שמעריכים את תגובת המודל, ומדכאים שפה רעילה, חומר המוגן בזכויות יוצרים או חשיפה לא מכוונת של נתונים פרטיים.
- Red-team testing – ערכת בדיקות אדברסריאלית (adversarial) המופעלת במהלך הפיתוח (בדרך כלל בצינורות CI/CD) כדי לוודא שהמודל וההגנות שלו עומדים בפני דפוסי תקיפה ידועים. שלב זה חושף חולשות לפני שהן מגיעות לסביבת הייצור; זהו אינו מסנן runtime.
התייחסות לבדיקות red-team כחסימה בזמן אמת עלולה לתת תחושת ביטחון כוזבת.
חלופות קוד פתוח שעדיין פעילות
| כלי | רישיון | שימוש אידיאלי |
|---|---|---|
| NeMo Guardrails | Apache 2.0 | דיאלוגים מורכבים מרובי-סבבים ו-retrieval-augmented generation; משתמש בשפת Colang הייחודית להגדרה של לוגיקת ה-guardrail. |
| Guardrails AI | Apache 2.0 | אימות הדרגתי – הוספת חוק אחד בכל פעם עבור סיכון ספציפי כמו ניבולי פה או נושאים אסורים. |
| Presidio | MIT | זיהוי ומיסוך (masking) של מידע מזהה אישי (PII) במצב offline; כיום בבעלות הקהילה, אך עליכם להגדיר את רשימת הישויות בעצמכם כדי למנוע התראות שווא (false positives) רבות. |
| Llama Prompt Guard 2 | מסווג מארח עצמי (self-hosted) המתמקד בזיהוי הזרקות פרומפט וניסיונות jailbreak. | |
| promptfoo | MIT | מסגרת עבודה (framework) ל-red-team שמתממשקת עם צינורות CI; יכול להריץ מאות וקטורי תקיפה נגד המודל שלכם ולדווח על אלו שהצליחו. |
פרויקטים אלו עדיין מקבלים תרומות מהקהילה, וקוד המקור שלהם זמין בחינם לאירוח עצמי או להטמעה בתוך צינורות (pipelines) מותאמים אישית.
guardrails מנוהלים ששווה לבחון
אם אתם מעדיפים פתרון מוכן לשימוש (turnkey), שני ספקי הענן הגדולים כוללים כעת guardrails כחלק מההצעות שלהם ל-LLM:
- Amazon Bedrock Guardrails – מדיניות ניתנת להגדרה שניתן להפעיל או לכבות לפי בקשה.
- Azure Prompt Shields – מסנני runtime דומים המשולבים בשירות Azure OpenAI Service.
שניהם גובים תשלום לפי בקשה; מיליון קריאות יכולות להגיע במהירות למאות דולרים. צוותים המודעים לתקציב צריכים לבצע מודלים של תעבורה צפויה לפני הפעלתם בקנה מידה רחב.
איך לבנות מחדש את ערימת האבטחה (security stack) שלכם
- מפו את ה-"lethal trifecta" (השלישייה הקטלנית). זהו היכן האפליקציה שלכם נוגעת ב-(א) מאגרי נתונים פרטיים, (ב) קלט משתמש לא מהימן, ו-(ג) קריאות רשת חיצוניות. הסרת כל אחד מהמרכיבים הללו מפחיתה את שטח התקיפה יותר מכל guardrail בודד.
- הטמיעו את Presidio בשלב מוקדם. הריצו אותו על כל נתון שאתם מתכננים להזין למודל. התאימו אישית את רשימת הישויות – קבוצת ברירת המחדל מסמנת מחרוזות תמימות רבות כ-PII, מה שעלול לשבש עיבוד downstream.
- הוסיפו input rail. התחילו עם מסווג קל משקל כמו Llama Prompt Guard 2 או guard מבוסס חוקים מ-Guardrails AI. חסמו דפוסי הזרקה ברורים לפני שהם מגיעים למודל.
- שכבו את בדיקות הפלט. NeMo Guardrails או Guardrails AI יכולים לבצע עיבוד-פוסט (post-process) לתגובת המודל, ולהסיר שפה רעילה או קטעים חסויים שחמקו.
- שלבו את promptfoo ב-CI. התייחסו לדוחות שלו כאל רשימת תיוג (checklist); כל עקיפה (bypass) שמתגלה צריכה להיות מקודדת כחוק ב-input rail או ב-output rail שלכם.
- תעדו (Log) כל חסימה. שמרו את הבקשה המקורית, את סיבת הדחייה ואת הפעולה שננקטה. ללא לוגים, לא תוכלו לכייל ספים (thresholds) או לבצע ביקורת תאימות (audit compliance).
נקודת מבט נגדית: שירותים מנוהלים מול קוד פתוח
guardrails מנוהלים חוסכים לך את העומס התפעולי של אירוח עצמי (self-hosting), עדכוני אבטחה (patching) והרחבה (scaling) של מסווגים. עם זאת, הם כובלים אותך למודל התמחור והמדיניות של הספק, מה שעשוי שלא להתאים לדרישות רגולטוריות ספציפיות. כלים בקוד פתוח מעניקים לך שליטה מלאה ויכולים לרוץ בשרתים מקומיים (on-premise), אך הם דורשים מאמץ הנדסי כדי לשמור עליהם מעודכנים וכדי לנטר טכניקות תקיפה חדשות. על צוותים לשקול את עלות זמן הצוות מול העמלות לכל בקשה (per-request fees) של guardrail מבוסס ענן.
מה כדאי לעקוב אחריו בהמשך
- מפות דרכים של ספקים (Vendor roadmaps). עקבו אחר ההכרזות על מוצרי אבטחת AI של Palo Alto ו-Check Point; סביר להניח שהם ישלבו את היכולות של הכלים שנרכשו בתוך חבילות מוצרים רחבות יותר.
- פעילות קהילתית. העריכו את חיוניותם של פרויקטים כמו NeMo Guardrails ו-Presidio על ידי בחינת פעילות pull-request אחרונה ותדירות גרסאות. מאגר (repo) שאינו פעיל עשוי להעיד על כך שמתהווה חלופה חדשה יותר.
- הנחיות רגולטוריות. ככל שממשלות מחמירות את הכללים בנוגע לתוכן שנוצר על ידי AI והגנה על נתונים, כל אסטרטגיית guardrail חייבת להיות ניתנת לביקורת (auditable). רישום (logging) ועקיבות (traceability) יהפכו למחייבים בתחומי שיפוט רבים.
שורה תחתונה
עם הפסקת הפעילות הרשמית של LLM Guard, מפתחים חייבים לשלב בין מגוון מסנני קלט (input filters), מנקי פלט (output sanitizers) ובדיקות אדברסריות (adversarial testing) כדי לשמור על בטיחות האפליקציות המבוססות על LLM שלהם. פרויקטים בקוד פתוח כגון NeMo Guardrails, Guardrails AI, Presidio, Llama Prompt Guard 2 ו-promptfoo מספקים את אבני הבניין, בעוד ש-guardrails מבוססי ענן (cloud-native) מציעים נוחות במחיר. הגורם המכריע אינו הכלי שתבחרו, אלא האם תקימו תהליך שיטתי — ביקורת, הגנה, בדיקה ורישום (audit, protect, test, and log) — שיישאר צעד אחד לפני סביבת האיומים המשתנה.