אבטחה וחוסן של מערכות AI

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

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

מערכות AI בסביבות ייצור נתונות למתקפות פעילות, ומרבית תוכניות האבטחה אינן מדביקות את הקצב

שנת 2025 הפכה את ניצול פגיעויות ה-AI מהוכחת היתכנות ל-CVE מתועדים בכלים שמיליוני מפתחים מסתמכים עליהם:

  • Microsoft 365 Copilot — פגיעות הזרקת הנחיות ללא לחיצה (zero-click prompt injection) (CVE-2025-32711, CVSS 9.3), שבה דוא"ל מעובד בודד הפעיל זליגת נתונים מרחוק.
  • GitHub Copilot — נפרץ באמצעות הערות קוד שהוטמעו במאגר ציבורי (CVE-2025-53773), שהובילו להסלמה להרצת קוד מרחוק.
  • Cursor IDE — באג של רגישות לאותיות רישיות (case-sensitivity) (CVE-2025-59944) אפשר לתוקפים לתמרן התנהגות סוכנית להרצת פקודות שרירותיות.

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

מערכות סוכניות וגבולות אמון

מערכות AI סוכניות יוצרות בעיות בגבולות האמון שאבטחת היקפית מסורתית אינה מסוגלת לתת להן מענה. רק 29% מהארגונים מדווחים על מוכנות לאבטח פריסות סוכניות, ו- MITRE ATLAS v5.4.0 (פברואר 2026) הוסיף טכניקות ייעודיות לאיומים ספציפיים לסוכנים, כולל "Publish Poisoned AI Agent Tool" ו-"Escape to Host".

מתקפות שרשרת אספקה של AI

מתקפות שרשרת אספקה עברו מתאוריה למעשה. JFrog זיהתה כ- 100 מודלים זדוניים ב-Hugging Face עם מטעני הרצת קוד מוטמעים, ו- Palo Alto Unit 42 הדגימה כי מרחבי שמות (namespaces) שנמחקו ב-Hugging Face ניתנים לרישום מחדש על ידי כל גורם, מה שמאפשר חטיפת שרשרת אספקה.

פגיעויות ברמת החומרה

מתקפת GDDRHammer (2026) הראתה שליבת CUDA נטולת הרשאות יכולה להשיג גישת קריאה/כתיבה שרירותית לזיכרון GPU באמצעות GDDR6 rowhammer — כלומר לסביבות GPU מרובות דיירים יש שטח תקיפה חומרתי ששום הגנה ברמת התוכנה אינה יכולה לסגור.

לחץ רגולטורי מצטבר

הרגולציה מתהדקת במקביל. במסגרת חוק ה-AI האירופי (EU AI Act), האיסורים על פרקטיקות אסורות נכנסו לתוקף בפברואר 2025, הדרישות למערכות בסיכון גבוה יחולו באוגוסט 2026, והקנסות מגיעים ל- EUR 35 million או 7% מהמחזור העולמי. CISA סיווגה הזרקת הנחיות כפגיעות AI קריטית בספטמבר 2025; NIST פרסם את AI RMF 2.0 עם הנחיות ספציפיות להזרקת הנחיות בינואר 2026. תחת חוק פרטיות המידע הביומטרי CUBI, טקסס גבתה $1.375 מיליארד מ-Google ו-$1.4 מיליארד מ-Meta בשנת 2025 בלבד. נטל הציות מצטבר מדי רבעון.

שרשרת האספקה של AI היא המקום שבו לרוב הארגונים יש אפס נראות

כשאנו מעריכים פריסות AI ארגוניות, הפער בשרשרת האספקה הוא בעקביות הממצא המסוכן ביותר. מרבית הארגונים אינם מסוגלים להפיק מלאי מלא של המודלים הפועלים בסביבת הייצור, שלא לדבר על אימות מקוריותם (נושא המחקר שלנו על הגנה על מודלים ארגוניים מפני הרעלה). סקר של Lineaje (יוני 2025) מצא כי 48% מאנשי האבטחה מציינים כי הארגונים שלהם כבר מפגרים מאחור בדרישות בסיסיות של כתב כמויות תוכנה (SBOM). האימוץ של ML-BOM (כתב כמויות ללמידת מכונה) נמוך משמעותית אף יותר.

הסיכון מתועד, אינו תאורטי:

  • Anthropic, המכון לבטיחות AI של בריטניה (UK AI Safety Institute), ומכון אלן טיורינג הדגימו כי כמות מזערית של 250 מסמכים זדוניים יכולה להחדיר בהצלחה דלת אחורית למודלי שפה של בין 600 מיליון ל-13 מיליארד פרמטרים.
  • המודל DeepThink-R1 של DeepSeek (ינואר 2025) נמצא עם דלת אחורית שנוצרה על ידי הנחיות נסתרות שהושתלו בהערות קוד ב-GitHub במהלך האימון. המודל פעל לפי הנחיות שהושתלו על ידי תוקפים כאשר נתקל בביטוי טריגר ספציפי, חודשים לאחר האימון, ללא צורך בגישה לאינטרנט.
  • כלי החיפוש של Qwen 2.5 הורעל באמצעות תוכן אינטרנט עוין שגרם למודל המכויל להפיק פלטים מזיקים מתוך שאילתה בת 11 מילים.

סריקות אבטחה מסורתיות אינן תופסות בעיות אלו. Hugging Face מריצה את Picklescan עבור קובצי pickle זדוניים, אך מתאמי LoRA זדוניים, מערכי נתוני אימון מורעלים ומרחבי שמות שנרשמו מחדש עוקפים כולם סריקות ברמת המודל. תקנים קיימים — CycloneDX פרסמה את מפרט ה-ML-BOM בשנת 2023, SPDX 3.0.1 מגדיר פרופילי AI ומערכי נתונים, ו- OWASP השיק את פרויקט ה-AI-BOM — אך הפער בין זמינות המפרט לבין אימוצו בארגונים נותר עצום. בניית שלמות שרשרת אספקה עבור AI דורשת את אותה משמעת שאבטחת יישומים הביאה לתלויות תוכנה לפני עשור: סריקה אוטומטית, אימות מקוריות, ניטור רציף ונוהל תגובה מסודר למקרה שמשהו מצליח לחדור.

מדוע האקוסיסטם הקיים של האבטחה מותיר פערים ברמת הארכיטקטורה

שוק ספקי אבטחת ה-AI צומח במהירות, והפתרונות הנקודתיים שלו חזקים:

  • Protect AI גייסה למעלה מ- $108 מיליון ומפעילה את תוכנית הבאג באונטי huntr.com לפגיעויות AI/ML; היא סורקת ארטיפקטים של מודלים לאיתור פגיעויות ידועות.
  • HiddenLayer ($56 מיליון) מתמקדת בניטור התנהגות מודלים בזמן ריצה.
  • Lakera פיתחה את מה שרבים מחשיבים למוצר הטוב ביותר לזיהוי הזרקת הנחיות (Lakera Guard).
  • Cisco רכשה את Robust Intelligence בשנת 2024; F5 רכשה את CalypsoAI תמורת $180 מיליון בשנת 2025.

שוק ה-AI Red Teaming לבדו צפוי לצמוח מ- $1.3 מיליארד (2025) ל-$18.6 מיליארד עד 2035. אולם כלים אלו הם חיישנים ומסננים, ולא בקרות מבניות — אף אחד מהם אינו מתכנן את מערך האבטחה הכולל של פריסת AI. מנהל אבטחת מידע (CISO) המרכיב תוכנית מרכיבים אלו עדיין זקוק למישהו שיתכנן היכן ימוקמו גבולות האמון במערכת סוכנית, כיצד אימות מקוריות מודלים משתלב בצינור ה-CI/CD, איזה ניטור יתפוס דלת אחורית שהופעלה לאחר הפריסה, וכיצד פריסה ריבונית פועלת בפועל כאשר צוות הציות קובע כי היסק אינו רשאי לעזוב את תחום השיפוט.

ארבע חברות רואי החשבון הגדולות (The Big Four) השקיעו במצטבר למעלה מ- $10 מיליארד ב-AI מאז 2023: PwC מפעילה תוכנית GenAI בהיקף של $1 מיליארד ושותפות עם OpenAI; KPMG מחזיקה ב- מסגרת ממשל AI רשמית בעלת 10 עקרונות עם מיפוי ל-ISO 42001; Deloitte בנתה למעלה מ- 100 מאיצי GenAI; EY פורסת תשתית NVIDIA AI Factory עבור תעשיות מפוקחות. עבודת הממשל והציות שלהן לגיטימית.

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

מה שאנו בונים עבור תוכניות אבטחת AI

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

תשתית AI ריבונית

עבור ארגונים הפורסים תחת מגבלות ריבונות נתונים, הגישה שלנו היא בניית תשתית שבה מודלים, היסק ונתוני אימון נשארים בתוך גבולות מבוקרים. אין זו מעטפת VPC סביב קריאת API. המשמעות היא בחירה וכימות של מודלים לחומרה מקומית — הפשרות בין כימות GPTQ, AWQ ו-GGUF הן משמעותיות הן לביצועים והן לאבטחה — הגדרת בידוד GPU לסביבות מרובות דיירים, הטמעת אישור קריפטוגרפי למשקולות מודלים, ובניית שכבת הניטור המזהה התנהגות היסק אנומלית. פריסה ריבונית מוגדרת כ- פרויקט הנדסי של שישה חודשים, ולא שינוי תצורה פשוט — מתוכננת ומפותחת מקצה לקצה במקום להיות מורכבת ממעטפת חיצונית.

שלמות שרשרת האספקה

אנו מתכננים את צינור האימות כך שיפעל לפני שאיזשהו מודל נוגע בסביבת הייצור (מפורט ב- המחקר שלנו על שלמות שרשרת אספקת AI לאורך מחזור החיים של ML): בדיקות מקוריות אוטומטיות על משקולות מודלים ונתוני אימון, אימות פורמט סריאליזציה (safetensors על פני pickle, תמיד), אימות שלמות של מתאמי LoRA, וניטור מתמשך של מאגרים במעלה הזרם לחטיפת מרחבי שמות או שינוי משקולות. התוצר המיועד הוא ML-BOM הממפה את המקור של כל רכיב, את הגרסה של כל תלות, ואת מקוריותו של כל מערך נתוני אימון.

הקשחה מפני יריב

אנו משלבים תרגול צוות אדום (red teaming) עם תיקון ארכיטקטוני, ובדיקה מול הטקסונומיה של MITRE ATLAS ושל OWASP LLM Top 10 v2.0 — אך בדיקות בלבד אינן פותרות את הבעיה. כאשר ממשק קריאת הכלים של מערכת סוכנית פגיע להזרקת הנחיות עקיפה דרך מסמכים שנשלפו, אנו בונים ארכיטקטורת גבולות אמון המפרידה באופן מבני בין תוכן שאינו מהימן לבין פעולות מורשות (ראו המחקר שלנו על אבטחת חזית האדם-AI). כאשר צינור RAG מדליף הנחיות מערכת דרך שאילתות מנוסחות בקפידה (OWASP LLM07, חדש במהדורת 2025), אנו מתכננים מחדש את צינור השליפה והיצירה כדי למנוע זאת.

מיפוי רגולטורי

אנו מחברים בקרות טכניות ספציפיות לדרישות הרגולטוריות החלות על הפריסה שלכם: חוק ה-AI האירופי (EU AI Act) חובות למערכות בסיכון גבוה, NIST AI RMF 2.0, OWASP LLM Top 10, חוקי ביומטריה מדינתיים בארה"ב (BIPA, CUBI, Colorado H.B. 24-1130), ודרישות ספציפיות למגזר. התוצר המיועד אינו מטריצת ציות בגיליון אלקטרוני. אלו הן בקרות מוטמעות עם ניטור, הפקת ראיות ונתיבי ביקורת המספקים את הרגולטורים ומפחיתים את העלות הממוצעת של $4.63 מיליון לפריצת אבטחה הקשורה ל-AI.

נקודות מפתח

  • ניצול פגיעויות AI הוא מבצעי, לא אקדמי: שנת 2025 הניבה פגיעויות CVE פעילות ב-Microsoft 365 Copilot, ב-GitHub Copilot וב-Cursor IDE, לצד מתקפות GDDRHammer ברמת ה-GPU בשנת 2026.
  • שרשרת האספקה היא נקודת התורפה העיוורת והמסוכנת ביותר — כמות זעומה של 250 מסמכים זדוניים יכולה להחדיר דלת אחורית למודל, ותקנים כמו CycloneDX ML-BOM, SPDX 3.0.1 ו-OWASP AI-BOM מתקדמים מהר יותר מקצב האימוץ בפועל.
  • ספקי פתרונות נקודתיים ותוכניות ממשל של ארבע הגדולות מותירים כולם את אותו הפער: אף אחד אינו מתכנן ארכיטקטונית את מערך האבטחה של הפריסה.
  • אנו בונים ברמת הארכיטקטורה בארבעה תחומים — תשתית AI ריבונית, שלמות שרשרת האספקה, הקשחה מפני יריב ומיפוי רגולטורי — והופכים מודעות לסיכונים לבקרות הנאכפות באופן מבני.

אבטחה וחוסן של מערכות AI

שאלות נפוצות

שאלות נפוצות

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

התשובה הכנה היא שאתם זקוקים למרכיבים משניהם, ולתזמון יש חשיבות מכרעת. בניית צוות אבטחת AI פנימי מאפס אורכת 12-18 חודשים לגיוס, הכשרה והפעלה מבצעית. מאגר הכישרונות מצומצם: חוקרי אבטחת AI התקפיים המסוגלים לבצע רד טימינג למערכות LLM בייצור ולאחר מכן לתכנן ארכיטקטונית את התיקונים אינם בנמצא בשפע. חברת ייעוץ מביאה אתכם למערך אבטחה בר-הגנה מהר יותר בזמן שאתם בונים יכולת פנימית. אנו פועלים בדרך כלל בהתקשרות של 3-6 חודשים כדי להעריך את מפת פריסות ה-AI הנוכחית, לבנות את ארכיטקטורת האבטחה (אימות שרשרת אספקה, גבולות אמון, ניטור), לבצע רד טימינג למערכות הקריטיות, ולתעד את התוכנית כך שהצוות הפנימי שלכם יוכל לתחזק אותה. העברת המקל היא המטרה. אנו בונים את התוכנית ואת הכלים; הצוות שלכם מפעיל אותם. העלות של התקשרות בת 6 חודשים היא שבריר מעלותה של פריצת אבטחה בודדת הקשורה ל-AI או מהסדר תובענה ייצוגית ביומטרית (טקסס גבתה $2.8 מיליארד מ-Google ומ-Meta בשנת 2025 בלבד).

כמה זמן נמשכת הערכת אבטחת AI, ומה היא כוללת?

הערכת אבטחת AI מקיפה נמשכת בדרך כלל 4-8 שבועות, בהתאם למספר מערכות ה-AI שבהיקף. השבוע הראשון ממפה את מלאי ה-AI: כל מודל בסביבת ייצור, מקוריותו, שיטת הפריסה, זרימות הנתונים ובקרות הגישה. מרבית הארגונים מגלים מודלים שלא ידעו על קיומם. שבועות 2 עד 4 כוללים בדיקות יריב מול הטקסונומיה של MITRE ATLAS ו-OWASP LLM Top 10 v2.0, כולל הזרקת הנחיות (ישירה ועקיפה), אימות שלמות שרשרת האספקה, בדיקות זליגת נתונים והסלמת הרשאות דרך ממשקי קריאת כלים. השלב הסופי מפיק תוכנית תיקון מתועדפת עם המלצות ארכיטקטוניות, ולא רק רשימת ממצאים. אנו ממפים כל ממצא לדרישות הרגולטוריות החלות (חוק ה-AI האירופי, NIST AI RMF, BIPA/CUBI אם מערכות ביומטריות נכללות בהיקף) כך שהתיקון סוגר במקביל הן פערי אבטחה והן פערי ציות.

מה באמת עובד נגד הזרקת הנחיות (Prompt Injection) בסביבות ייצור?

שום הגנה בודדת אינה עוצרת באופן אמין הזרקת הנחיות (prompt injection). מרחב ההזרקות האפשריות הוא אינסופי בעוד שמסננים מתמקדים בדפוסים סופיים. מתקפות אדפטיביות כנגד כל שכבת הגנה יחידה מגיעות לשיעורי הצלחה של למעלה מ-85% בבדיקות מבוקרות. מה שפועל בהצלחה הוא הגנה ארכיטקטונית רב-שכבתית. אימות קלט תופס את המתקפות הברורות. אימות פלט עם LLM-as-critic משפר את דיוק הזיהוי ב-21% בהשוואה לסינון קלט בלבד (על בסיס 600K+ הנחיות עוינות ממאגר HackAPrompt). אולם הבקרות המבניות הן החשובות ביותר: הפרדת תוכן בלתי מהימן מהוראות מורשות ברמת הארכיטקטורה, אכיפת עקרון המינימום הנדרש (least privilege) על ממשקי קריאת כלים, דרישת אישור אנושי לפעולות בעלות השפעה גבוהה, ותכנון צינורות שליפה כך שמסמכים שנשלפו לא יוכלו לעקוף הוראות ברמת המערכת. במיוחד עבור מערכות סוכניות, גבולות האמון בין סוכנים חייבים להיות מפורשים ונאכפים, ולא מונחים כברירת מחדל. אנו בונים בקרות ארכיטקטוניות אלו לתוך המערכת במקום להדביק סינון חיצוני.

כיצד אנו מאבטחים את שרשרת האספקה של מודלי ה-AI שלנו כאשר אנו משתמשים במודלי קוד פתוח מ-Hugging Face?

התחילו מההכרה בכך ש-Hugging Face הוא מאגר ציבורי, ולא שרשרת אספקה מאומתת. חברת JFrog מצאה כ-100 מודלים זדוניים עם מטעני הרצת קוד מוטמעים. Palo Alto Unit 42 הראתה שמרחבי שמות שנמחקו יכולים להירשם מחדש על ידי תוקפים. מתאמי LoRA זדוניים אינם ניתנים להבחנה מ-fine-tuning לגיטימי ללא אימות שלמות. להגנה המעשית יש ארבע שכבות. ראשית, לעולם אל תטענו מודלים בסריאליזציית pickle בסביבת ייצור; דרשו פורמט safetensors, שאינו ניתן להרצה מעצם תכנונו. שנית, אמתו את מקוריות המודל (provenance): בדקו היסטוריית commits, מוניטין תורמים, וסיכומי ביקורת (checksums) של משקולות מול נקודות ייחוס ידועות כתקינות. שלישית, בנו ML-BOM (כתב כמויות ללמידת מכונה) באמצעות CycloneDX או SPDX 3.0.1 העוקב אחר המקור, הגרסה והתלויות של כל רכיב מודל. רביעית, הריצו סריקה אוטומטית בכל עדכון מודל לפני כניסתו לצינור ה-CI/CD שלכם, ונטרו מאגרים במעלה הזרם לאיתור שינויי מרחבי שמות או שינויי משקולות בלתי צפויים. אנו בונים צינור אימות זה כחלק אינטגרלי מתהליך ה-MLOps שלכם, ולא כתהליך ידני נפרד.

מהן דרישות האבטחה של חוק ה-AI האירופי (EU AI Act) למערכות AI בסיכון גבוה שייכנסו לתוקף באוגוסט 2026?

הדרישות למערכות בסיכון גבוה בחוק ה-AI האירופי (בתוקף החל מ-2 באוגוסט 2026) מחייבות בקרות אבטחה ספציפיות הכוללות חוסן מפני מתקפות יריב, ממשל נתונים עבור מערכי נתוני אימון, תיעוד טכני של תכנון ובדיקות מערכת ה-AI, מנגנוני פיקוח אנושי, וניטור דיוק ואמינות לאורך כל מחזור חיי המערכת. הקנסות מגיעים ל-EUR 35 million או 7% מהמחזור השנתי העולמי על ההפרות החמורות ביותר. האתגר המעשי הוא שדרישות החוק מבוססות עקרונות ואינן מחייבות פתרון טכני מוגדר מראש. 'רמת חוסן נאותה' אינה מציינת אילו בדיקות יריב יש להריץ. אנו ממפים את דרישות החוק לבקרות טכניות ספציפיות: פרוטוקולי בדיקות יריב המיושרים עם MITRE ATLAS, בדיקות שלמות שרשרת אספקה המספקות את דרישות השקיפות של החוק, מערכות ניטור המפיקות את ראיות הציות שהרגולטורים מצפים להן, ותיעוד העוקב מהדרישה הרגולטורית ועד לבקרה המוטמעת בפועל. ארגונים שיתייחסו לכך כאל תרגיל סימון 'וי' יגלו שמנגנוני האכיפה של החוק מתוכננים לבחון מעבר למסמכי הממשל — ישירות לתוך היישום הטכני בפועל.

כיצד משיגים נראות לגבי שימוש ב-Shadow AI ברחבי הארגון שלנו?

שימוש ב-Shadow AI הוא כיום סיכון ה-AI המבצעי המוביל. מחקרים מראים כי 69% מהארגונים חושדים שעובדים משתמשים בכלי GenAI שאינם מאושרים, והחברה הממוצעת חווה 223 תקריות בחודש של שליחת נתונים רגישים ליישומי AI. פריצות אבטחה כתוצאה מ-Shadow AI עולות בממוצע $4.63 מיליון, משמעותית יותר מפריצות סטנדרטיות. חסימת כלי AI אינה עובדת; מחקרים מוכיחים בעקביות שעובדים עוקפים איסורים אלו. גישת 'Sunlight AI' של SANS Institute קרובה יותר לתשובה הנכונה: הבאת השימוש הבלתי מורשה לאור ולנראות במקום לנסות לאסור עליו. מבחינה טכנית, משמעות הדבר היא פריסת זיהוי ברמת הרשת של תעבורת API של כלי AI, בניית קטלוג כלים מאושרים עם בקרות סיווג נתונים מתאימות, הטמעת חוקי DLP (מניעת דליפת נתונים) ספציפיים לנקודות קצה של שירותי AI, ויצירת מדיניות שימוש המעניקה לעובדים נתיב מורשה ומסודר לאימוץ AI. אנו בונים את שכבת הניטור הטכנית ומשלבים אותה במערך ה-SIEM/SOAR הקיים שלכם, כך ששימוש ב-AI יופיע באותם לוחות בקרה שבהם ה-SOC שלכם כבר צופה.

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

מערכות AI סוכניות (Agentic AI) מציגות בעיות אבטחה שאינן קיימות בפריסות של מודל יחיד. ניסויים מבוקרים מראים שיעורי הצלחת מתקפה של 84% כנגד מערכות מרובות סוכנים לעומת כ-50% בארכיטקטורות של סוכן יחיד. בעיית הליבה היא התפשטות אמון (trust propagation): כאשר סוכן א' נותן אמון בפלט של סוכן ב' ומשתמש בו לביצוע קריאות לכלים, פגיעה בקלט של סוכן ב' (באמצעות הזרקת הנחיות עקיפה במסמך שנשלף, למשל) מתפשטת במפל בכל רשת הסוכנים. MITRE ATLAS v5.4.0 מקטלג כעת טכניקות ייעודיות לסוכנים, כולל פרסום כלים מורעלים ובריחה למחשב המארח (host escape). ההגנה הארכיטקטונית דורשת גבולות אמון מפורשים בין סוכנים, הרשאות מינימליות (least privilege) בכל ממשק קריאת כלים (סוכן הזקוק להרשאת קריאה לעולם לא יקבל הרשאת כתיבה), חיטוי קלט בכל מסירה מסוכן לסוכן, ושערי פיקוח אנושי (human-in-the-loop) לפעולות בעלות השלכות בעולם האמיתי. אנו מתכננים ארכיטקטורות אמון אלו לפריסות סוכניות ספציפיות, מכיוון שמיקום הגבול הנכון תלוי במה שכל סוכן מבצע, באילו כלים הוא יכול לקרוא ובאילו נתונים הוא מעבד.

האם עלינו להשתמש ב-MITRE ATLAS או ב-OWASP LLM Top 10 כמסגרת אבטחת ה-AI שלנו?

השתמשו בשניהם. הם משרתים מטרות שונות ומשלימים זה את זה. OWASP LLM Top 10 v2.0 (מהדורת 2025) הוא רשימת סיכונים מתועדפת ליישומי LLM: הזרקת הנחיות, חשיפת מידע רגיש, פגיעויות בשרשרת אספקה, אוטונומיה עודפת (excessive agency), דליפת הנחיות מערכת, וחולשות וקטורים/הטמעות. הוא מורה לכם ממה לחשוש קודם. MITRE ATLAS הוא טקסונומיית איומי יריב הכוללת 16 טקטיקות, 84 טכניקות ו-56 תת-טכניקות המלמדת כיצד תוקפים מתפשרים בפועל על מערכות ML. ATLAS ממפה שרשראות תקיפה; OWASP מתעדף סיכונים. בפועל, אנו משתמשים ב-OWASP כדי להגדיר את היקף ההערכה וב-MITRE ATLAS כדי לתכנן את האופן שבו אנו בודקים כל תחום סיכון. עבור ארגונים הבונים תוכנית אבטחת AI, מסמך NIST AI 600-1 (פרופיל ה-AI היוצר של ה-AI RMF) מספק את מעטפת הממשל המחברת את שתי המסגרות לניהול סיכונים ארגוני. שלושתם יחד מעניקים לכם תעדוף סיכונים (OWASP), מתודולוגיית סימולציית תקיפה (ATLAS), ומבנה ממשל (NIST).

בנו את ה-AI שלכם בביטחון.

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

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