Nebius: לפני שהסוכן עולה לפרודקשן, חייבים לתת לו זהות משלו

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

Nir Chervoni, מנהל מוצרי אבטחה ב-Nebius, טוען שהבעיה לא מתחילה במודל ולא ב-guardrails. היא מתחילה בשכבה שכולם מדלגים עליה: זהויות, credentials, ניהול מפתחות ו-logging. בשיחה עם Rob Strechay, חוקר תחום ה-AI, הוא פירק את מה שצריך לקרות לפני שמודל AI או agent בכלל ניגשים למחשב — ומה כדאי לבדוק כשבוחנים ספק ענן AI.

המספרים שלא מתיישבים אחד עם השני

לפני הכול, שתי שורות נתונים שכדאי להחזיק מול העיניים:

• בסקר שנערך באוגוסט, מחצית מהארגונים דיווחו שיש להם agents בפרודקשן. מתוך הקבוצה הזאת, 61% אמרו שיש אצלם לפחות שיתוף חלקי של credentials בין agents. זה כמעט שלושה ארגונים מכל חמישה שכבר שמו סוכנים על תשתית חיה — ונתנו להם מפתחות משותפים.
• בסקר מספטמבר, רק 14% ממי שענו על שאלת ה-revocation אמרו שבעל תפקיד מוגדר יכול לשלול גישה ל-agent תוך דקות. אחד משבעה.

במילים אחרות: קצב הטמעת הסוכנים רץ הרבה יותר מהר מקצב ה-governance של הגישות. אתם משיקים capability חדש, ובמקביל מאבדים את היכולת לעצור אותו.

מה קורה כשסוכנים חולקים סיסמאות

לפי Chervoni, ל-credential משותף יש מחיר כפול: "כשלסוכנים יש credentials משותפים, אתם מפסידים שני דברים בבת אחת: אי אפשר לדעת מי עשה מה, ואי אפשר להגביל את הנזק כשאחד מהם נפרץ."

וזה גם עניין של המשכיות עסקית, לא רק של אבטחה. credential משותף יוצר תלות בין workloads. אם תשללו אותו כדי לעצור סוכן שנפרץ, אתם עלולים להוריד יחד איתו סוכנים אחרים שמשתמשים באותה גישה. במילים פשוטות: הפעולה שמצילה אתכם היא גם הפעולה שמפילה את מה שעובד. לכן Chervoni טוען שצריך לבחון בידוד ו-resilience ביחד — ולבדוק בפועל, בתרגיל, האם עצירת agent אחד עוצרת workloads שאינם קשורים, ומה קורה ל-sessions פעילים ולעבודה שכבר בתהליך.

קודם כל זהות, אחר כך מודל

אז מה צריך לקרות לפני שמשהו רץ? Chervoni מונה את היסודות, והם משעממים בכוונה:

1. לכל agent זהות משלו — באותה צורה שלמשתמש אנושי יש זהות משלו.
2. credentials קצרי־טווח ו-scoped למשימה — לא טווח רחב "ליתר ביטחון", אלא בדיוק מה שהסוכן צריך כדי לבצע את העבודה שלו.
3. ה-secrets יושבים ב-secrets manager — לא ב-prompts, לא בקובצי config, ולא ב-environment variables. זה אולי הלקח הכי מעשי מהשיחה.
4. מפתחות ההצפנה נשארים בשליטת הלקוח — לא נעולים אצל ספק הענן.
5. audit trail מלא שנכנס ל-SIEM של הארגון, ככה שהפעילות של הסוכן נראית כמו כל פעילות אחרת ברשת.

ב-Nebius, אגב, השקיעה קודם בדיוק בשכבה הזאת — identity and access management, key management services, secrets management ו-audit logs — ועובדת גם עם לקוחות שרוצים להביא את ה-KMS שלהם או רכיבי אבטחה אחרים מבית.

ה-guardrail לא יכפה לכם מדיניות גישה

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

והוא מסכם את זה כך: "לעולם אל תסמכו על guardrail כדי לאכוף משהו שמדיניות גישה יכולה לאכוף באופן דטרמיניסטי."

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

Confidential Computing מגיע ל-GPU — ומה הוא לא פותר

החלק השני של השיחה עסק ב-GPU confidential computing. הטכנולוגיה הזאת הייתה קיימת עד כה ברמת ה-CPU; עכשיו ה-GPU נכנס ל-trust boundary. הנתונים שזורמים בין CPU ל-GPU מוצפנים, וה-GPU עצמו ניתן ל-attestation.

בפועל, בחלק מהמימושים, הנתונים ומשקלי מודל AI נשארים מוגנים גם בזמן העיבוד — כולל מפני ספק הענן עצמו, ה-hypervisor ומנהלי המערכת של Nebius. ועדיין, הרכיב הכי חשוב כאן הוא ה-attestation: הוא מאפשר ללקוח לאמת את הסביבה לפני שהוא משחרר את המפתחות. אמון הוא משהו שבודקים, לא משהו שמניחים.

אבל יש גבולות, ו-Chervoni אומר אותם בלי לנסות למכור הבטחות: הטכנולוגיה לא מתקנת פגיעויות באפליקציה, לא עוצרת prompt injection, לא מכתיבה מה המודל יפלוט, ולא עוזרת אם זהות לגיטימית נפרצת. היא גם חזקה בדיוק כמו הצד שמאמת את ה-attestation. בשורה שלו: זה כלי לשרטוט trust boundary, לא שמיכה שמכסה הכול.

למי שמעריך הטמעות כאלה, Chervoni מציע שלוש שאלות: מי מאמת את ה-attestation, מה מחיר הביצועים, ומהי רמת הבשלות של התמיכה ב-multi-GPU בהיקף. הוא גם צפוי להרחיב על זה בפאנל ב-GTC Berlin.

ל-NVIDIA יש reference architecture שמחזק את הנקודה שזו הטמעה ברמת מערכת, לא פיצ'ר: תמונת confidential VM עם מדידה, confidential computing גם ב-CPU וגם ב-GPU, attestation verifier, key management שתומך ב-secure key release, ו-logging שלא חושף את התוכן המעובד.

מה לבדוק לפני שחותמים עם ספק ענן AI

המסקנה הרחבה יותר מהשיחה: כשבוחנים ספק, יכולות חישוב ותעודות אבטחה על הקיר אינן מספיקות. צריך ראיות שהבקרות עובדות גם בתנאי כשל — זהות שנפרצה, integrity check שנכשל, ניסיון לחצות גבול בין tenants.

כמה נקודות פרקטיות:

• בידוד tenants דורש הוכחה תפעולית — חוסן בתהליכי החלפת חומרה, רשתות ניהול, control planes משותפים ו-interconnects בין GPUs. מחקר עצמאי שנעשה על ספקי GPU cloud מצא סיכוני cross-tenant שנבעו בדיוק מהבסיס הזה: patch management, חשיפת רשת ו-control planes משותפים.
• בידוד צריך להיבחן בתרגיל — האם עצירת agent אחד עוצרת אחרים? מה קורה ל-sessions פעילים?
• Sovereignty זה לא רק מיקום — צריך לבחון גישה, עיבוד, retention ושליטה על מנגנוני ההגנה לאורך כל הפריסה.
• שכבות שונות עונות על שאלות שונות — תשתית, מדיניות גישה, פקדי אפליקציה ו-guardrails אינם מחליפים זה את זה.

אפשר להמשיך ולהוסיף עוד שכבת AI Security על המודל. רק כדאי לוודא קודם שאפשר לשלול לסוכן את המפתח — גם בשלוש בלילה, בלי להוריד את מה שעובד.