Red Hat מכניסה סוכני AI לפרודקשן: בלי מפתחות אמיתיים

אם סוכן AI יכול לקרוא קבצים, להריץ פקודות shell ולפנות לרשת, הוא לא רק צורך תשתית — הוא מבצע פעולות שעלולות להזיק לעסק. זו בדיוק הבעיה ש-Red Hat הגיעה איתה ל-KubeCon + CloudNativeCon North America בסולט לייק סיטי, עם מסר אחד ברור: Kubernetes כבר יודע לנהל קונטיינרים, עכשיו צריך שהוא ידע גם להציב גבולות אכיפים לסוכנים אוטונומיים.

ההבדל בין צ'אטבוט לסוכן הוא כל הסיפור. צ'אטבוט עונה, סוכן פועל. כל כלי או פריט גישה שהוא משתמש בו מרחיב את פוטנציאל הנזק. כפי שניסח זאת Joe Fernandes, סגן נשיא ומנהל כללי של Red Hat AI: "במשך שנים בנינו תוכנה, אבל התוכנה הזו דטרמיניסטית. היא עושה מה שתכנתנו אותה לעשות. סוכנים שונים. הם לא דטרמיניסטיים, אתם נותנים להם מטרה, ואתם לא יודעים אילו פעולות הם יבצעו כדי להגיע אליה."

מה בעצם השינוי בתפיסת האבטחה?

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

הלב של המהלך הוא OpenShell, סביבת הרצה לסוכנים ש-Nvidia השיקה במרץ, עם Red Hat כחברה מייסדת. Red Hat עובדת עם Nvidia ועם הקהילה כדי לשלב את הטכנולוגיה ב-Red Hat AI ובפלטפורמת ה-hybrid cloud הפתוחה שלה. OpenShell מציב סוכנים בסביבות הרצה מבודדות ומחיל policy על הגישה שלהם — שילוב של sandboxing, policy מודעת לתהליכים, שליטה בגישה לרשת ובפרטי גישה.

הטריק המעניין כאן הוא מה ש-Jessica Forrester, מהנדסת בכירה ומנהלת ארכיטקטית ראשית של Red Hat AI, תיארה: הסוכן אף פעם לא מקבל מפתחות אמיתיים. "עם OpenShell, הסוכן שלכם לא מקבל שום מפתח אמיתי לשום דבר. הגישה מוסווית בכניסה ומוחלפת ביציאה. אם משהו משכנע אותו למסור את המפתחות שלו, הוא לא באמת מוסר מפתחות אמיתיים." במילים אחרות — גם prompt injection מוצלח לא מניב גישה אמיתית למערכות.

לא רק סנדבוקס: זהות, הרשאות ורשת

השכבות ממשיכות מעבר לבידוד. OpenShell יכול להריץ סוכנים ב-Kata Containers, שלכל אחד מהם kernel נפרד, בתוך מכונות וירטואליות מלאות ב-OpenShift Virtualization ומאחורי בקרות egress ברשת. Red Hat גם הציגה בידוד ברמת ה-kernel בפלטפורמה שלה. מעל זה פועל מנגנון ה-sandboxed containers של OpenShift, שמוסיף הגבלות ברמת האפליקציה בתוך גבול של מכונה וירטואלית.

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

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

llm-d 1.0 והעומס שהסוכנים מייצרים

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

כאן נכנס llm-d, שמיועד בדיוק לעומסים עתירי context שסוכנים מייצרים. הפרויקט נוסד על ידי Red Hat, IBM, Google Cloud, CoreWeave ו-Nvidia — כלומר, לא יוזמה של שחקן בודד — והוא הגיע לגרסה 1.0. מבחינת מי שבונה פלטפורמות, זה הצעד שמעביר את הפרויקט משלב ניסוי לשלב שאפשר להסתמך עליו.

ניהול סוכנים בקנה מידה, ואיפה זה פוגש את השוק

מעבר לסוכן בודד, Red Hat עובדת עם OpenAI Group PBC על OpenClaw Enterprise, פרויקט לניהול אלפי סוכנים אישיים בקנה מידה. OpenShell זמין בגרסת preview בתוך Red Hat AI.

ההקשר הרחב: אימוץ מהיר של OpenClaw החזיר את תשומת הלב לשאלת אבטחת הסוכנים. סוכן שקורא קבצים, מריץ פקודות shell ומבצע קריאות רשת צריך הרשאות מוגדרות היטב ובידוד כדי לפעול בבטחה בסביבה ארגונית. Chris Wright, ה-CTO של Red Hat, כבר הזהיר במאי שסוכנים שפועלים באמת בעסק צריכים sandboxing והגנות least-privilege: "אתם חייבים לתת לו את הסנדבוקס הנכון. אתם חייבים לשים הגנות סביב הסוכן, לתת לו את ההרשאות המינימליות כדי שהוא לא יתבלבל בין read ל-read-write — זה הבדל עצום."

מנקודת מבט אנליטית, יש כאן הבחנה שחוזרת אצל אנליסטים: הפער בין לראות מה הסוכן עשה לבין להוכיח מה הוא היה מורשה לעשות. Paul Nashawaty מ-theCUBE Research מזהה enforcement בזמן ריצה, הרשאה מואצלת וראיות ביקורת ניתנות לאימות כדרישות שמתחזקות ככל שמערכות אוטונומיות נכנסות לפרודקשן. "זה יוצר הזדמנות לפלטפורמות שיכולות לאחד פיתוח אפליקציות, תזמור תשתית, אבטחה ו-observability במקום להוסיף עוד שכבה של כלים מנותקים", הוא אומר.

מה זה אומר למי שבונה כאן

אם אתם עובדים עם Kubernetes, המסר הזה לא תיאורטי. OpenShift נשאר שכבת הבסיס, ו-Red Hat מנסה להפוך את ניהול הסוכנים לעוד workload שיושב על אותו stack שאתם כבר מתחזקים — במקום ערימת כלי אבטחה נפרדת לכל סוכן. עבור צוותי platform engineering בישראל, זה בעיקר שינוי בשאלות שהם ישאלו לפני deploy: איזו זהות יש לסוכן, לאיזו רשת הוא יכול לצאת, ואילו מפתחות הוא בכלל רואה. אם התשובה היא "הוא רואה הכול", הסנדבוקס הוא לא הפתרון — הוא רק התחלה.

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