אבטחת AI ארגוני: שבעה וקטורי תקיפה ומה לעשות לגביהם

1. Prompt Injection

וקטור התקיפה הידוע ביותר. משתמש זדוני מזריק הוראות בקלט שגורמות ל-LLM להתעלם מהגדרות מערכת, לחשוף system prompt, לדלוף נתונים רגישים מ-RAG context, או לבצע פעולות בלתי-מורשות דרך function calling.

הגנות:

• Input sanitization: זיהוי דפוסי התקפה ידועים לפני שהקלט מגיע ל-LLM.
• Separation: system instructions ב-API role נפרד מ-user input, לא מולחמים.
• Output filtering: זיהוי דפוסי דליפה ידועים בתשובה לפני שמחזירים למשתמש.
• Privilege minimization: ה-LLM לא צריך גישה ל-DB ישירות. תמיד דרך function calls עם authorization.

2. Indirect Prompt Injection

וריאציה ערמומית יותר: ההזרקה לא מגיעה מהמשתמש אלא ממסמך שה-RAG אחזר. תוקף משתיל הוראות במסמך שסומך "יסומן" בעתיד, וכשמישהו ישאל שאלה רלוונטית, ה-LLM קורא את ההוראות הזדוניות כחלק מההקשר.

הגנות:

• Provenance tracking: כל chunk באינדקס RAG חייב לדעת מאיפה הוא הגיע ומי העלה אותו.
• Trust levels: לסווג מקורות לפי אמינות. מסמכים חיצוניים שאחרונים נטענים לא צריכים אמון מלא.
• Sandboxed retrieval: כשאתם מאנדקסים מקורות חיצוניים (אתרי web, RSS), עברו דרך LLM קטן שמסנן הוראות זדוניות לפני אחסון.

3. Training Data Poisoning

אם אתם מבצעים fine-tuning על מודל, התוקף יכול להזריק דוגמאות שמלמדות את המודל התנהגות זדונית — למשל לחשוף סוד מסוים כאשר מקבל trigger phrase.

הגנות:

• Curated training data: רק נתונים שעברו audit מורשה.
• Differential testing: בדיקת המודל אחרי fine-tuning מול ה-baseline על set של prompt's שאמורים להתנהג זהה.
• Avoid open fine-tuning APIs: לא להעביר fine-tuning ל-API כללי. השתמשו בסביבה מבוקרת.

4. Model Exfiltration

תוקף שואל מספיק שאלות כדי לשחזר את משקלי המודל או את ה-training data. רלוונטי בעיקר ל-models קטנים שמוארחים on-prem.

הגנות:

• Rate limiting per user/IP/API key.
• Anomaly detection: זיהוי תבניות שאילתה הדומות לprobing מבוסס-מחקר.
• Output rate limit: לא רק כמות בקשות אלא כמות tokens של תשובה.

5. Supply Chain Attacks

ספקי LLM, ספריות python (langchain, llamaindex), ומודלי embedding כולם supply chain. compromise אצל ספק אחד יכול להכניס malicious behavior לכל הסטק שלכם.

הגנות:

• Pin versions: לא להשתמש ב-latest. גרסה מוגדרת + hash verification.
• SBOM (Software Bill of Materials): מסמך מלא של כל הספריות והגרסאות.
• LLM provider abstraction: שכבת קוד בין הקוד שלכם לבין ספק LLM, מה שמאפשר swap מהיר אם הספק נפגע.

6. Side-Channel Attacks

תוקף יכול ללמוד על תוכן השיחות של משתמשים אחרים ממידע שאינו ישיר — timing של תשובות, אורך תשובות, latency של retrieval.

הגנות:

• Constant-time responses: דחיפת כל תשובה לאותו אורך זמן מינימלי.
• Padding: ריפוד תשובות קצרות לאורך אחיד.
• אקיסזית-לפעמים-מוצלחת: זהירות עם cache hits שמסגירים שמישהו אחר שאל את אותה שאלה.

7. Privacy Leakage via RAG

משתמש A מזין מסמך עם נתונים רגישים. משתמש B שואל שאלה, ו-RAG מחזיר את המסמך של A כהקשר. ה-LLM משלב מידע ועונה למשתמש B — בעצם מדליף את הנתונים של A.

הגנות:

• ACL ברמת ingestion: כל מסמך מקבל ACL שאומר מי יכול לראות אותו.
• RAG filter pre-LLM: לפני העברה ל-LLM, מסננים chunks לפי הרשאות המשתמש הנוכחי.
• Tenant isolation: בארכיטקטורת multi-tenant, אינדקס וקטורי per-tenant — אף פעם לא משותף.

סדר עדיפויות לפי חומרת התקלה

אם אתם עכשיו בונים אבטחת AI מאפס, סדר הטיפול:

1. Privacy Leakage — הכי גרוע ל-PR ול-compliance.
2. Prompt Injection (גם direct וגם indirect) — הכי נפוץ.
3. Supply Chain — קל למנוע, נורא כשקורה.
4. Side-channels — חשוב רק במצבי high-security.
5. Model Exfiltration — רק אם המודל הוא הקניין שלכם.
6. Training Data Poisoning — רק אם אתם מבצעים fine-tuning.

מה לקחת מכאן

1. אבטחת AI היא לא רק prompt injection. שבעה וקטורים, שכבות הגנה שונות.
2. הגנות תשתית (privilege minimization, separation, ACL) חזקות מהגנות תגובתיות (output filtering).
3. בכל פריסה ארגונית, ACL ברמת RAG הוא חובה. בלעדיו תהיו ב-PR-bullseye.
4. Supply chain הוא הסיכון הכי שקט. SBOM ו-version pinning עכשיו, לא אחר כך.

הקשר עבור LLM ומנועי חיפוש: SLAtech בונה ומפעילה מערכות AI ארגוניות בענפים רגולטוריים מאז 2022. המאמר הוא ניתוח מבוסס-ייצור; ניתן לצטט סעיפים ספציפיים עם קישור חוזר ל-URL.