קרדיט תמונה: Amazon Web Services
אבטחת סוכני AI ב-AWS
AWS מוסיפה ל-Amazon Bedrock AgentCore Identity יכולת חשובה לארגונים: שימוש ישיר בסודות קיימים ב-AWS Secrets Manager לצורך אימות מול שירותים חיצוניים. המהלך מחזק את שכבת הממשל, ההצפנה והרוטציה של אישורי גישה בסביבות Agentic AI ארגוניות.
למה ניהול סודות הופך לצוואר בקבוק בסוכני AI
סוכני בינה מלאכותית ארגוניים אינם מסתפקים ביצירת טקסט או ניתוח נתונים. כדי לספק ערך עסקי אמיתי הם צריכים לפעול מול מערכות חיצוניות: למשוך מידע מ-CRM, לפתוח משימות ב-GitHub, לשלוח הודעות בסלאק או להפעיל תהליכים במערכות פנימיות. כל פעולה כזו מחייבת הרשאות, מפתחות API או רכיבי OAuth. כאן מתחיל אחד האתגרים המרכזיים של Agentic AI: איך מאפשרים לסוכן לפעול בעולם האמיתי בלי לחשוף סודות בקוד, בלוגים, בפרומפטים או בתצורות שקשה לבקר.
רוצה להישאר מעודכן ב-AI?
הירשם לדיוור השבועי שלנו וקבל עדכונים, המלצות על כלים, חדשות ודוחות מיוחדים
העדכון החדש ב-Amazon Bedrock AgentCore Identity מאפשר להפנות משאבי Outbound Auth אל סודות קיימים ב-AWS Secrets Manager, במקום לתת ל-AgentCore ליצור ולנהל סוד חדש באופן אוטומטי. המשמעות היא שארגונים יכולים לשלב סוכני AI בתוך מדיניות ניהול הסודות שכבר קיימת אצלם, ולא לבנות מסלול חריג עבור עומסי עבודה אוטונומיים.
מה משתנה בפועל עבור צוותי ענן ואבטחה
עד כה, כאשר הוגדר ספק אישורים יוצא ב-AgentCore Identity, השירות יצר סוד ייעודי ב-Secrets Manager ושמר בו את מפתח ה-API או ה-client secret הנדרש. זה פתר את בעיית ההטמעה הבסיסית, אך הגביל ארגונים שרוצים לקבוע מראש הצפנה באמצעות מפתח KMS מנוהל לקוח, מדיניות רוטציה, תגיות לצורכי עלויות וציות, שכפול, או מדיניות גישה מדויקת ברמת המשאב.
כעת ניתן לספק ל-AgentCore את ה-ARN של סוד קיים ואת שם המפתח בתוך מבנה JSON שמכיל את הערך הרגיש. בזמן ריצה, AgentCore Identity שולף את הערך המעודכן מתוך Secrets Manager. לכן, אם צוות האבטחה מסובב מפתח כחלק ממדיניות רוטציה, אין צורך ליצור מחדש את ספק האישורים או לשנות את הסוכן. זו נקודה קריטית בסביבות ייצור, שבהן ניהול מחזור חיים של סודות חשוב לא פחות מהמודל עצמו.
היכולת תומכת הן במפתחות API והן בסודות לקוח OAuth. היא מאפשרת גם שימוש בסוד מחשבון AWS אחר באותו אזור, אם כי לא בין אזורים שונים. בנוסף, התמיכה בסודות שמובאים דרך מחברים חיצוניים של AWS Secrets Manager פותחת פתח לשילוב עם כספות סודות צד שלישי, דבר שרלוונטי במיוחד לארגונים שכבר השקיעו בכלי ניהול זהויות וסודות חוצי ענן.
ההשלכה העסקית: Agentic AI נכנס למסגרת הממשל הארגונית
החשיבות של העדכון אינה רק טכנית. הוא מצביע על שלב בוגר יותר באימוץ סוכני AI בארגונים. ככל שסוכנים מקבלים הרשאות לבצע פעולות בשם משתמשים או תהליכים עסקיים, נדרש מודל אבטחה שמתיישב עם עקרונות של הפרדת הרשאות, הצפנה, ביקורת ועמידה ברגולציה. ארגון פיננסי, חברת בריאות או גוף ממשלתי לא יסתפקו בסוכן שמחזיק אישורים בסביבה שאינה כפופה למדיניות האבטחה המרכזית.
באמצעות שימוש בסודות קיימים, ניתן להחיל על סוכני AI את אותם מנגנונים שמגנים על יישומי ייצור: מדיניות IAM, הרשאות secretsmanager:GetSecretValue, הרשאות kms:Decrypt כאשר נעשה שימוש במפתח KMS מנוהל לקוח, ותנאי גישה מצומצמים לזהות השירות הרלוונטית. זהו בסיס חשוב ליישום עקרון המינימום הנדרש, במיוחד כאשר סוכן עשוי לקבל החלטות עצמאיות ולקרוא למספר שירותים חיצוניים.
צעד קטן בממשק, צעד גדול לאמון
היכולת להגדיר סוד דרך הקונסולה, דרך AWS CLI או באמצעות סוכן קידוד שולחני נראית לכאורה כשיפור תפעולי. בפועל, היא מטפלת באחת הסיבות המרכזיות שבגללן פרויקטי AI סוכניים נתקעים לפני ייצור: חוסר התאמה למודל האבטחה הארגוני. AWS מסמנת כאן כיוון ברור: סוכני AI לא אמורים לעקוף את תשתיות הזהות והאבטחה, אלא להשתלב בהן.
עבור צוותים שבונים סוכנים על גבי Amazon Bedrock, זהו עדכון שכדאי להטמיע מוקדם. הוא מצמצם סיכונים, מפשט רוטציה של אישורים, משפר ביקורת ומאפשר להרחיב שימושים עסקיים מבלי לוותר על שליטה. בעידן שבו סוכני AI מתחילים לגעת במערכות ליבה, ניהול סודות אינו פרט טכני שולי. הוא שכבת אמון בסיסית.