Agent Onboarding — איך מכניסים סוכן חדש לסביבת פרודקשן בבטחה

מאת צוות מדיה דיל · 12.08.2026 · Agent Infrastructure · 5 דק׳

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

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

שלב ראשון: הרשאות מינימליות מההתחלה

העיקרון המנחה הוא Least Privilege — הסוכן מקבל בדיוק את ההרשאות שהוא צריך לתפקד, ולא יותר, ומתחיל תמיד ברמת ההרשאה הנמוכה ביותר האפשרית שעדיין מאפשרת לו לעבוד. במקום להעניק גישת כתיבה מלאה לבסיס הנתונים מהיום הראשון, נכון להתחיל עם גישת קריאה בלבד, לבדוק שהסוכן מתפקד נכון ברמה הזו, ורק אז להוסיף הרשאות כתיבה מוגבלות לטבלאות ספציפיות — לא לסכימה שלמה. אותו עיקרון חל על גישת רשת: allowlist מפורש של הדומיינים שהסוכן צריך, לא גישה פתוחה "כדי שלא יהיו הפתעות". כל הרשאה שהסוכן מקבל היא משטח סיכון פוטנציאלי, ובשלב ה-onboarding, כשעדיין לא יודעים בביטחון מלא איך הסוכן יתנהג בעולם האמיתי, צמצום משטח הסיכון הוא ההגנה הכי אפקטיבית שיש.

שלב שני: Shadow Mode לפני ביצוע אמיתי

הצעד הכי משתלם לפני מתן יכולת ביצוע אמיתית הוא הרצת הסוכן ב-Shadow Mode: הוא מקבל תעבורת פרודקשן אמיתית, מקבל החלטות אמיתיות, אבל הפעולות בפועל לא מבוצעות — רק נרשמות ומושוות למה שהיה קורה בפועל (אם יש process קיים, אנושי או אוטומטי, שמבצע את אותה משימה כרגע). Shadow Mode חושף פערים בין מה שהסוכן "חושב" שנכון לבין מה שקורה בפועל, בלי לקחת שום סיכון תפעולי אמיתי. זו הדרך היעילה ביותר לגלות מקרי קצה שהבדיקות לא כיסו — כי תעבורת פרודקשן אמיתית מכילה תמיד וריאציות שאף מפתח לא חשב עליהן מראש, ובניגוד לסביבת בדיקות, Shadow Mode חושף אותן בלי סיכון.

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

שלב שלישי: Rollout הדרגתי עם Circuit Breaker

גם אחרי Shadow Mode מוצלח, מעבר ישיר ל-100 אחוז מהתעבורה הוא סיכון מיותר. הפרקטיקה הנכונה היא Canary Rollout: מתחילים עם אחוז קטן מהתעבורה האמיתית (5-10 אחוז), עם ניטור צמוד במיוחד באותם ימים ראשונים, ומגדילים בהדרגה רק אחרי שהמדדים מוכיחים יציבות. במקביל, חובה מנגנון Circuit Breaker אוטומטי: אם שיעור השגיאות של הסוכן חורג מסף מוגדר בפרק זמן קצר, המערכת עוצרת אותו אוטומטית ומחזירה את התעבורה לתהליך הקודם (אנושי או אוטומטי), בלי להמתין שמישהו ישים לב וילחץ ידנית על כפתור עצירה. ההבדל בין ארגון שסופג תקרית קטנה לארגון שסופג משבר הוא לרוב בדיוק המהירות שבה מנגנון כזה מזהה ועוצר בעיה, לפני שהיא מספיקה להתפשט לכל התעבורה.

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

שלב רביעי: רישום ב-Registry וקישור למחזור החיים

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

מה קורה כשמשהו כבר השתבש

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

שאלה ארגונית נוספת שקל לדלג עליה: מי בכלל אחראי על ה-Onboarding עצמו: מי בפועל "חותם" על מוכנות הסוכן לפרודקשן? בהרבה צוותים, האחריות מתפזרת בין מי שבנה את הסוכן (שרוצה להשיק כמה שיותר מהר) לבין מי שאחראי על תשתית הפרודקשן (שלרוב לא מעורב מספיק מוקדם כדי להשפיע על התכנון). הפתרון הארגוני שעובד בפועל הוא checklist מוסכם מראש — לא מסמך שנכתב אחרי תקרית ראשונה, אלא רשימה קבועה שכל סוכן חדש עובר לפני אישור: הרשאות מינימליות מתועדות, תוצאות Shadow Mode, תוכנית Rollout ומדיניות Circuit Breaker, ותהליך rollback מוגדר. כשה-checklist הזה קיים מראש ומוסכם על כל הצדדים, השיחה על "האם מוכנים להשיק" הופכת משיחה על תחושות בטן לשיחה על עובדות מתועדות — וזה בדיוק ההבדל בין תהליך שאפשר לשכפל בביטחון לכל סוכן חדש, לבין תהליך שתלוי כל פעם מחדש במי שנמצא בחדר באותו רגע. הגישה הזו עקבית עם העקרונות הרחבים יותר של הטמעת מערכות AI בסביבת פרודקשן, שמפורטים במדריך הטמעת מערכות AI בפרודקשן, ועם הרעיון של הפרדת אחריות בין לוגיקת הסוכן לשכבת התפעול שמתואר במדריך Managed Agents.

תגיות: Agent Onboarding · Shadow Mode · Canary Rollout · Least Privilege · Circuit Breaker · Agent Registry

← חזרה לבלוג · צור קשר