האבטחה של DeepSeek V4 Pro נקבעת גם על ידי מעטפת ההפעלה

ארגונים שמפעילים סוכנים המבוססים על DeepSeek V4 Pro צריכים לבחון תצורה מלאה של מודל–Harness–משימה–סביבה, ולא את המודל לבדו. העובדה שהמודל זמין דרך ממשקי Web, מובייל, API, OpenAI Responses API או אינטגרציית Codex יכולה להעיד על תאימות טכנית — אך אינה מוכיחה שה-prompts, הכלים, ההרשאות, הזיכרון, מנגנוני הניסיון החוזר או תופעות הלוואי פועלים באותה צורה בכל סביבת הרצה.

הכלל התפעולי פשוט: מאשרים רק תצורה מקובעת ומזוהה במדויק, לאחר שהתצורה הזו עברה הערכת בטיחות משלה.

למה ה-Harness משנה את הסוכן בפועל

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

הבדלים מהותיים יכולים להופיע ב:

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

לכן אותו backend של DeepSeek V4 Pro עשוי להציג פרופיל סיכון שונה כאשר הוא מופעל דרך Harness אחר או בסביבת ביצוע אחרת. סכמת API תואמת היא מאפיין של אינטגרציה — לא תעודת בטיחות.

מה מלמדות תוצאות AgentS4D — ומה הן לא מלמדות

מחקר AgentS4D בחן תצורות הרצה שלמות, ולא רק תשובות מבודדות של מודלים. במסגרת המחקר נבדקו 328 מקרי בדיקה שהוזרקו בהם סיכונים, בארבעה Harness-ים ובחמישה backends של מודלים — בסך הכול 6,560 הרצות בסביבת sandbox. החוקרים דיווחו על 4,461 הרצות לא בטוחות, כלומר 68.0%, ועל 4,344 הרצות — 66.22% — שהיו גם לא בטוחות וגם סווגו כהשלמה מוצלחת. 13

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

אין להציג את הנתונים האלה כשיעור התקריות של DeepSeek V4 Pro בפרודקשן. המחקר השתמש במקרי בדיקה שנבנו בכוונה כדי להחדיר סיכונים, בסביבת sandbox מבוקרת, ואיחד תוצאות של שילובים שונים בין מודלים ל-Harness-ים. תמהיל המשימות, אמצעי הבקרה, החשיפה לתוכן עוין, הנכסים וההגדרות של נזק בסביבת ייצור יהיו שונים. המחקר מוכיח שיש למדוד את בטיחות סביבת ההרצה ישירות — לא שהוא מנבא מה יקרה בכל פריסה. 135

להגביל את הנזק המרבי של פעולת הסוכן

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

להשתמש בזהויות ייעודיות ובהרשאות מינימליות

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

להגביל מערכות קבצים ורשת

• יש לחבר לסוכן רק שורש Workspace ייעודי.
• נתיבים שאינם רלוונטיים צריכים להיות בלתי נגישים — לא רק מוסתרים.
• יש לאפשר ברשימת היתר יעדי רשת, שיטות, פורטים, ובמקרים הרלוונטיים גם נפח תעבורה יוצאת.
• יש להפריד בין הרשאות קריאה, טיוטה, כתיבה ל-staging וכתיבה לפרודקשן.
• סודות צריכים להישמר אצל broker או במערכת של אסימונים קצרי-חיים.
• אין להציב פרטי התחברות ארוכי-חיים ב-prompts, בקובצי Workspace, במשתני סביבה או בפלט של כלים.

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

לבדוק את שרשרת הביצוע המלאה

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

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

כלים צריכים לאכוף את המדיניות מחוץ למודל

קריאת כלי שנוצרה על ידי המודל היא בקשה בלתי מהימנה. שרת הכלים — לא המודל — חייב לאכוף את כללי ההרשאה והבטיחות.

השתמשו בסכמות צרות ומגבילות, הכוללות למשל:

• ערכי enum מוגבלים ומגבלות אורך;
• נרמול נתיבים ומזהי משאבים מפורשים;
• רשימות היתר ליעדים;
• מגבלות עימוד וגודל תוצאות;
• אימות ארגומנטים מחוץ למודל;
• בדיקת הרשאה בצד השרת עבור הפונה, הלקוח, היעד והפעולה הספציפיים.

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

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

הבקרות האלה חשובות משום שקריאת JSON שנראית תקינה עדיין יכולה להכיל יעד שאינו מורשה, נתיב מסוכן, היקף פעולה רחב מדי או פעולה שאמורה לדרוש ביקורת אנושית.

להגדיר מראש את ההתנהגות של מצב וזיכרון

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

לפחות יש להגדיר:

• בידוד: הפרדה לפי משתמש, לקוח, משימה וסביבה; ללא שיתוף משתמע בין סשנים.
• שמירה: זמן חיים, הצפנה, בקרת גישה וכללי מחיקה.
• איפוס: דרך מתועדת לניקוי ההקשר, הזיכרון, מצב ה-Workspace, פרטי ההתחברות והמטמונים בין הרצות.
• ניסיונות חוזרים וזמני קצוב: מספרים ותקציבים מוגבלים; ניסיון חוזר חייב לשמור על אידמפוטנטיות ולא להרחיב הרשאות בשקט.
• הרצה מקבילית: כללי נעילה וטיפול בהתנגשויות בקבצים משותפים, באישורים ובפעולות חיצוניות.

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

כל מקור סיכון הוא קלט בלתי מהימן

Prompt injection לא חייב להגיע בהודעה ישירה של המשתמש. הוראות מסוכנות יכולות להיות מוטמעות ב:

• מסמכים שהועלו וקובצי Repository;
• דפי Web שנשלפו;
• Skills ותוספים חיצוניים;
• תשובות של שירותי כלים;
• זיכרון שנשמר;
• סיכומים והקשר שנשמר במטמון;
• טקסט שסיפק המשתמש.

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

צ'קליסט שחרור ייעודי ל-Harness

לפני אישור פריסה, יש להקפיא ולתעד את התצורה המדויקת:

1. מודל וניתוב: מזהה וגרסת המודל, נתיב הספק, הגדרות inference או רמת מאמץ, ומתאמי תאימות.
2. התנהגות ה-Harness: גרסת ה-Harness, prompt המערכת, לוגיקת הסשן, כללי הניסיונות החוזרים וזמני הקצוב, מדיניות תהליכי-בן ומימוש הזיכרון.
3. כלים ומדיניות: הגדרות וגרסאות כלים, גרסאות מדיניות, ספי אישור, לוגיקת הרשאה וגבולות האמון של שרתי הכלים.
4. הרשאות: זהויות, היקפים, שורשי מערכת קבצים, יעדי רשת, מקורות פרטי התחברות ונתיבי כתיבה לפרודקשן.
5. סמנטיקת מצב: בידוד, שמירה, איפוס, התנהגות מטמון, הרצה מקבילית וגבולות בין סשנים.
6. כיסוי עוין: Prompt injection דרך כל מקור סיכון, ניסיונות confused deputy, חשיפת פרטי התחברות, מעבר נתיב, SSRF או ניצול יציאה מהרשת, תשובות זדוניות של כלים, שכפול בעקבות ניסיון חוזר, הרעלת זיכרון ועקיפת אישורים.
7. ראיות: גרסאות prompts ומדיניות, קריאות כלים ותוצאותיהן, אישורים, החלטות מדיניות, הבדלי Workspace, בקשות יוצאות, הזהות ששימשה, התוצרים הסופיים, תוצאת ההשלמה ותוצאת הבטיחות — כולם תחת מזהה הרצה יציב.

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

להריץ מחדש את הבדיקות בכל שינוי בתצורה

יעד האישור הוא התצורה המקובעת, ולא תווית קבועה כמו “סוכן DeepSeek V4 Pro”. יש להריץ מחדש את חבילת הבדיקות הספציפית לתצורה לאחר כל שינוי מהותי ב:

• המודל או נתיב הספק;
• הגדרות inference או רמת המאמץ;
• prompt המערכת או המתאם;
• לוגיקת ה-Harness או הסשן;
• כלים או שרתי כלים מרוחקים;
• מדיניות הרשאות ואישורים;
• ניתוב פרטי התחברות;
• התנהגות הזיכרון, הניסיונות החוזרים, זמני הקצוב או ההרצה המקבילית;
• גבולות הרשת או מערכת הקבצים.

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