ב-Amazon Bedrock AgentCore: איך מונעים מה-AI להשתולל

אז מה בעצם קרה כאן? מי מכם שמפתחים AI Agents ומעבירים אותם לפרודקשן יודעים שהבלגן האמיתי מתחיל אחרי הפיילוט. שליטה, אבטחה ומשאבים — שלושת האתגרים הגדולים. ל-Amazon Web Services יש חדשות: היא מוסיפה ל-Amazon Bedrock AgentCore שתי יכולות חדשות ומשמעותיות, אחת לתעבורת ה-AI ואחת לאבטחה, שמתמודדות בדיוק עם הכאבים האלה.

בואו נתחיל בחלק שמתקשר ישירות לעלויות ולזמינות: הגבלת קצב (Rate Limiting) בתעבורת AI. ה-Agents שלכם מדברים עם מודלים, כלים חיצוניים ו-APIs. עכשיו, עם AgentCore Gateway, תוכלו להגדיר מגבלות מדויקות — לאיזה משתמש, לכמה בקשות ולאיזה כלי מותר לפנות.

איך זה עובד בפועל? אפשר להגדיר מגבלות בשלושה ממדים:

1. בקשות לדקה/שנייה (RPM/RPS): לכל סוגי היעדים. בקשה שלוקחת 50 מילי־שניות ובקשה שרצה 90 שניות — שתיהן ״עולות״ אותו דבר.
2. טוקנים לדקה (TPM): רלוונטי רק ליעדי inference — כלומר, מודלים. המערכת מעריכה מראש כמה טוקנים הבקשה תצרוך, ״תופסת״ מקום, ואז מתחשבת בצריכה האמיתית כשהתשובה חוזרת. זה מונע ״זלילת״ משאבים לא צפויה.
3. חיבורים במקביל (CPS): מגבלה על מספר החיבורים הארוכים שיכולים להיות פתוחים בו-זמנית. קריטי כשיש קריאות streaming שלוקחות זמן.

למי זה טוב? אם יש לכם קבוצות משתמשים שונות, תוכלו להגדיר מדיניות שונה. קבוצת ״Basic״ עם מגבלות מחמירות יותר, קבוצת ״Advanced״ עם גמישות וקבוצת ״Beta״ שיכולה לבדוק מודלים חדשים עם תקרת צריכה מוגדלת. הכול מנוהל מול ספק הזהות, כמו Microsoft Entra ID, באמצעות JWT ומדיניות RBAC. המטרה: לוודא ששירותי ה-inference שלכם לא קורסים תחת עומס, ושכל משתמש יקבל חוויית שימוש צפויה ומבוקרת.

למנוע מה-Agent ״להשתולל״ עם מדיניות Temporal

החלק השני, ואולי המרתק יותר, מטפל בבעיה עמוקה הרבה יותר: אבטחת ה-Agent עצמו. כלים קיימים מטפלים בבקשה בודדת. אבל Agents מודרניים הם לא ״בקשה בודדת״. הם רצף של פעולות, לעיתים אוטונומיות לחלוטין. בקשה אחת יכולה להיות בטוחה בפני עצמה, אבל מסוכנת בהקשר של הבקשה שבאה לפניה. לדוגמה: Agent קורא ממקור נתונים לא מהימן, ״ממציא״ מזהה חשבון באמצעות הזיה (hallucination) ומעביר אותו הלאה. הבדיקה הבודדת עברה, אבל הנזק נעשה.

Temporal Policies נוצרו בדיוק כדי לפתור את זה. הן מאפשרות להגדיר כללים מבוססי־מצב (stateful) שבודקים את הבקשה הנוכחית בהקשר של ההיסטוריה של ה-Agent באותה סשן. והכי חשוב: המדיניות רצה בפרימטר של ה-Gateway, מחוץ לקוד של ה-Agent עצמו. ככה, גם אם יש באג, פרומפט זדוני או שה-Agent מנסה לתמרן — הוא לא יכול לעקוף את הכללים.

מה אפשר לאכוף עם זה?

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

רגע, ומה עם משאבים למשימות כבדות? AWS גם מכריזה על Runtime Instances — סביבת מחשוב מתמשכת ל-Agents שצריכים לעבוד שעות או ימים. היא מספקת GPU, שיתוף קבצים בין Agents ויכולת ״להרדים״ את הסשן ולחזור אליו מאוחר יותר, ובכך לחסוך בעלויות. זה פתרון משלים ל-runtime microVMs הקיימים, לתרחישים מורכבים יותר.

למה זה חשוב לכם? אם אתם מזיזים Agents מ-PoC לפרודקשן, היכולות האלה נותנות לכם שכבה קריטית של שליטה ואבטחה. הגבלת קצב מגינה על עלויות התשתית שלכם ועל זמינות השירותים שלכם. מדיניות Temporal נותנת לכם ״חגורת בטיחות״ לאוטונומיה של ה-Agent, שהיא החלום והסיוט בו-זמנית. זה צעד משמעותי בהפיכת Agents מטכנולוגיה מרשימה לטכנולוגיה מהימנה וניתנת לניהול.