סקירה כללית של Agent Gateway

‫Agent Gateway היא שכבת האכיפה של האבטחה והמשילות של Google Cloud Agent Governance. הוא משמש כנקודת הכניסה והיציאה של הרשת מוגדרת-התוכנה לכל האינטראקציות של הסוכנים בסביבות זמן ריצה מנוהלות, בפלטפורמות של קונטיינרים, במכונות וירטואליות של תשתית כשירות (IaaS) ובסביבות חוצות-עננים.

‫Agent Gateway מאפשר למנהלי אבטחה ופלטפורמות בארגון לאכוף מצבי אבטחה עקביים עם הרשאות מינימליות לכל האינטראקציות של הסוכנים – בין אם הן מתרחשות בין משתמשים אנושיים לסוכנים, בין סוכנים לכלים של Model Context Protocol‏ (MCP) או בין סוכנים אוטונומיים עצמם.

‫Agent Gateway והסביבה העסקית של Agent Platform.
הסביבה העסקית של Agent Gateway ו-Agent Platform (לחצו כדי להגדיל).

רכיבי הליבה של ניהול הנתונים

הרכיבים הבאים של Agent Platform פועלים יחד כדי לספק ארכיטקטורה מאוחדת של Agent Governance:

  • ‫Agent Identity (מי שלח את הבקשה?): מקצה מזהה ייחודי ומאובטח (מזהה SPIFFE) לכל סוכן. הזהות הזו משמשת כחתימה הדיגיטלית של הסוכן לצורך אימות, בקרת גישה וביקורת.

    זהויות של סוכנים מאובטחות כברירת מחדל באמצעות בקרת גישה מבוססת-הקשר, שאוכפת אימות קריפטוגרפי מקצה לקצה באמצעות mTLS ו-DPoP.

  • ‫Agent Registry (אילו יעדים אושרו?): הוא משמש כספרייה מרכזית לכל הסוכנים, הכלים, שרתי Model Context Protocol‏ (MCP) ונקודות הקצה (כמו ממשקי API חיוניים של Google Cloud ) שאושרו בארגון. ‫Agent Gateway משתמש בספרייה הזו כדי לבדוק את ההרשאות לפני שהוא מאפשר חיבורים.

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

    • מערכת גישה מאוחדת לכללי מדיניות (UAP) של IAM: כללי גישה שמקשרים בין הזהות של הנציג לבין כלים ונקודות קצה שאושרו ב-Agent Registry. כברירת מחדל, כל החיבורים חסומים, אלא אם מדיניות IAM מפורשת מעניקה גישה.
    • הגנה מוגברת על המודל: מסנני אבטחת תוכן שמצורפים לשערים. ‫Model Armor סורק את הפרומפטים של המשתמשים ואת התשובות של הכלים בזמן אמת כדי לחסום מתקפות של החדרת פרומפטים, דליפות של מידע אישי רגיש ותוכן פוגעני.
    • כללי פיקוח בשפה טבעית: כללים שכתובים בשפה פשוטה וקובעים איך הנציגים משתמשים בכלים. הם אוכפים כללים עסקיים בזמן הריצה כדי למנוע מהנציגים לבצע פעולות לא מכוונות, כמו הפעלת שילובים לא בטוחים של כלים.
    • כללי מדיניות לניהול טוקנים: כללי מדיניות שעוקבים אחרי השימוש בטוקנים של מודל שפה גדול (LLM) ומשייכים אותם, ואוכפים תקציבי טוקנים משותפים בין הנציגים והאפליקציות שלכם כדי למנוע צריכת טוקנים בלתי מבוקרת ועלייה חדה ובלתי צפויה בעלויות.
    • מנועי הרשאות בהתאמה אישית: תוספים מותאמים אישית שמפנים לבדיקת הרשאות, שמאפשרים להקצות החלטות לגבי הרשאות למערכות של צד שלישי באמצעות Service Extensions.

    באופן פנימי, כל סוגי המדיניות האלה נאכפים באמצעות כללי מדיניות הרשאה או קישורי תוספים שמנוהלים דרך Service Extensions.

  • Agent Gateway (איפה המדיניות נאכפת?): משמש כנקודת הכניסה והיציאה העיקרית לתנועה ברשת בין לקוחות לסוכנים ובין סוכנים לכל מקום, ומחיל מדיניות אבטחה ומשילות על כל התנועה שעוברת דרך השער. איך Agent Gateway אוכף את כללי המדיניות

  • יכולת התבוננות לעומק בסוכנים: Agent Gateway יוצר נתוני טלמטריה של יכולת התבוננות לכל האינטראקציות של הסוכנים בשכבת הרשת, ומייצא אותם אל Agent Observability כדי לספק לכם הבנה מקיפה של פעולות הסוכנים.

יתרונות מרכזיים

‫Agent Gateway נותן מענה למורכבויות של אבטחה, תאימות ורשתות בהפעלת סוכני AI בקנה מידה נרחב בסביבות זמן ריצה הטרוגניות של מחשוב.

למפתחי AI:

  • חדשנות פשוטה: אתם יכולים להתמקד בפיתוח הלוגיקה של הנציג, בלי לנהל את הניתוב הבסיסי של ה-VPC, את ההגדרות של Envoy או את החלפת האישורים של mTLS.
  • תיווך פרוטוקולים: חיבור חלק של סוכנים באמצעות Model Context Protocol‏ (MCP), ‏ Agent-to-Agent‏ (A2A), ‏ REST או gRPC, תוך עמידה בתקני המשילות של הארגון.
  • לא תלוי במסגרת: תמיכה בסוכנים שנוצרו באמצעות מסגרות AI סטנדרטיות או לקוחות בהתאמה אישית בכל סביבת זמן ריצה.
  • העברה וזהות מאובטחות: סיום אוטומטי של לחיצות ידיים (handshakes) של mTLS ושילוב עם מנהל האימות של Agent Identity בפלטפורמת Agent, כדי לטפל באופן שקוף בלחיצות ידיים של OAuth 2.0 ובאיחוד שירותי אימות הזהות של עומסי עבודה (WIF).

לצוותי אבטחה ולאדמינים של פלטפורמות בארגונים:

  • ניהול מרכזי בכל סביבות זמן הריצה: הגדרה ואכיפה של כללי מדיניות גישה מאוחדים, בקרת גישה מבוססת-תפקידים (RBAC) של כלים ואמצעי הגנה בכל סביבות זמן הריצה המנוהלות, אשכולות של Google Kubernetes Engine (GKE), שירותי Cloud Run ואשכולות שהם לא שלGoogle Cloud Kubernetes.
  • מעקות בטיחות ל-AI: יירוט וניקוי של הנחיות נכנסות ומטענים ייעודיים (payloads) יוצאים של כלים באמצעות ספקי בטיחות משולבים כמו Model Armor, כדי לחסום החדרת הנחיות, פריצות ודליפת נתונים רגישים.
  • אבטחה היקפית והגנה מפני זליגת נתונים: העבירו תנועה ישירה דרך מחברי רשת פרטיים של רשתות VPC כדי לאכוף כללים מחמירים של VPC Service Controls.
  • ניראות מקצה לקצה: תיעוד של נתוני מעקב מועשרים של OpenTelemetry בשכבה 7 ובשכבה 8 ויומני גישה ב-Cloud Logging וב-Cloud Trace, כדי לאפשר ביקורת מלאה.

נתיבי גישה מנוהלים

‫Agent Gateway מאפשר שני נתיבי גישה מנוהלים עיקריים: מלקוח לסוכן (ingress) ומסוכן לכל מקום (egress).

מצבי הפעולה של Agent Gateway.
מצבי הפעולה של Agent Gateway (לחצו כדי להגדיל).
  • מלקוח לסוכן (Ingress): אבטחת התקשורת בין לקוחות (כמו אפליקציות אינטרנט, ממשקי שורת פקודה למפתחים או מערכות חיצוניות) לבין סוכנים או כלי MCP שמתארחים. השער משמש כנקודת אכיפה של מדיניות בממשק הקצה, מאמת את פרטי הכניסה של המשתמשים ובודק את ההנחיות.

  • מסוכן לכל מקום (תעבורת נתונים יוצאת): שולטת בבקשות יוצאות שהסוכנים יוזמים לכלים חיצוניים, לשרתי MCP מרוחקים, לממשקי API של SaaS או לסוכנים במורד הזרם. אכיפת זהות שקשורה לעומס העבודה, תאימות של מרשם היעד, מדיניות גישה של ניהול זהויות והרשאות גישה (IAM) וניקוי המטען הייעודי (payload).

מודלים של פריסה

כדי לתמוך בארכיטקטורות שונות של אפליקציות AI, ‏Agent Gateway מספק מודלים גמישים של פריסה שקובעים איפה ואיך מקצים, מנהלים ומשלבים את תשתית ה-proxy של השער עם עומסי העבודה של הסוכנים. לא משנה אם הסוכנים פועלים בסביבות זמן ריצה בניהול מלא של Google Cloud, באשכולות Kubernetes בניהול עצמי, במכונות וירטואליות או בסביבות חוצות-עננים, Agent Gateway מציע אפשרות פריסה שמותאמת להעדפות השליטה בתשתית ולדרישות של היקף הרשת.

מודלים של פריסת Agent Gateway בתשתית של VPC בניהול עצמי, בניהול של Google ובתשתית חוצת-עננים (cross-cloud).
מודלים של פריסת Agent Gateway בגבולות התשתית (לחצו כדי להגדיל).

סיכום של מודלי הפריסה

סביבת המארח של הסוכן מודל פריסה נתמך תשתית שרת proxy מסמכים
‫Agent Runtime ו-Gemini Enterprise

‫Agent Gateway ב- Google Cloud

(בניהול Google)

לא רלוונטי (בניהול Google) סקירה כללית

הגדרה
GKE

‫Agent Gateway ב- Google Cloud

(בניהול עצמי)

מלקוח לסוכן: GKE Gateway API

‫Agent-to-Anywhere לקישוריות בין אשכולות וקישוריות חיצונית: Secure Web Proxy

‫Agent-to-Anywhere לקישוריות בין פודים: Ambient networking

בקרוב
Cloud Run

‫Agent Gateway ב- Google Cloud

(בניהול עצמי)

‫Client-to-Agent: מאזן עומסים של אפליקציות (ALB)

‫Agent-to-Anywhere: שרת Proxy מאובטח לאינטרנט

בקרוב
סביבות חוצות-עננים (לא שלGoogle Cloud) ‫Agent Gateway ל-cross-cloud שרת proxy של Envoy בניהול עצמי בסביבה שלכם בקרוב

‫Agent Gateway ב- Google Cloud

‫Agent Gateway ב- Google Cloud מנהל את הסוכנים ואת שרתי ה-MCP שפועלים בסביבות המחשוב של Google Cloud , כולל Agent Runtime,‏ Gemini Enterprise,‏ GKE ו-Cloud Run. בהתאם לסביבת המארח, Google מנהלת בשבילכם את התשתית של שרת ה-Proxy של השער, או שאתם מצרפים את Agent Gateway למשאבים של שרת ה-Proxy ואיזון העומסים שאתם מנהלים בפרויקט שלכם. בכל סביבות זמן הריצה של Google Cloud , אתם משתמשים באותו מישור בקרה מרכזי כדי לנהל את זהויות הסוכנים, את הרשומות ב-Agent Registry ואת מדיניות הגישה.

ב-Agent Runtime וב-Gemini Enterprise

‫Agent Gateway מספק תשתית שערים שמנוהלת באופן מלא על ידי Google, ללא צורך בתחזוקה, שמתארחת ישירות ב- Google Cloud. הוא עבר אופטימיזציה ספציפית לסוכנים שפועלים ב-Agent Runtime וב-Gemini Enterprise.

  • ארכיטקטורה ותשתית: Google מנהלת באופן מלא גם את שירותי הניהול של השער וגם את תשתית שרת ה-proxy. הארגונים לא צריכים להגדיר שרת proxy, לנהל מאגר תגים או לבצע תחזוקה ידנית.
  • יכולות עיקריות: סיום מובנה של mTLS ללא תחזוקה, כללי מדיניות גישה של IAP, סריקת הנחיות והגנה מפני אובדן נתונים (DLP) של Model Armor וכללי מדיניות פיקוח בשפה טבעית.
  • תרחיש שימוש עיקרי: מתאים לצוותים בארגונים שמפתחים סוכני AI ללא שרת (serverless) ב- Google Cloud , ורוצים ניהול מקיף בלי לנהל את תשתית הרשת.

פרטים על ההגדרה מופיעים במאמר סקירה כללית על Agent Gateway ב-Agent Platform.

ב-GKE

‫Agent Gateway מרחיב את הפיקוח של Agent Platform לסוכנים ולשרתי MCP שאתם מריצים באשכולות GKE שלכם. צוותי הפלטפורמה מגדירים את הפיקוח באמצעות משאבים מקוריים של Kubernetes ו-Google Kubernetes Engine Gateway API. אותם כללי מדיניות, Agent Registry ו-Agent Identity שחלים על סוכנים ב-Agent Runtime חלים גם על סוכנים ב-GKE.

  • ארכיטקטורה ותשתית: אתם מריצים את תשתית שרת ה-proxy בפרויקט שלכם.
    • Client-to-Agent: תנועת הלקוחות נכנסת לאשכול דרך GKE Gateway, שהוא מאזן עומסים אזורי של אפליקציות (ALB).
    • Agent-to-Anywhere: Ambient Networking של GKE מפנה את תעבורת הסוכנים היוצאת אל Secure Web Proxy בלי שרתי proxy צדדיים, והמדיניות נאכפת לפני שהתעבורה יוצאת מהאשכול. התנועה בין הסוכנים בתוך האשכול כפופה לשרתי פרוקסי סביבתיים בשכבה 7 שפועלים בכל מרחב שמות.
  • יכולות עיקריות: הגדרת מדיניות מקורית של Kubernetes, בקרת גישה מבוססת-זהות באמצעות זהות SPIFFE של כל סוכן, סינון של הנחיות ותשובות באמצעות Model Armor, בדיקת TLS של תנועת סוכנים יוצאת ומנועי מדיניות בהתאמה אישית באמצעות קישורי תוספים.
  • תרחיש שימוש עיקרי: צוותי פלטפורמה ואבטחה שמריצים סוכנים ב-GKE ורוצים לנהל את תנועת הסוכנים הנכנסת, היוצאת ובתוך האשכול באמצעות כלי Kubernetes שהם כבר משתמשים בהם.

בקרוב תהיה תמיכה ב-Agent Gateway לסוכני GKE. יכולים להיות שינויים בתכונות ובתזמון. כדי לבקש גישה מוקדמת, הירשמו לגרסת טרום-השקה (Preview).

ב-Cloud Run

‫Agent Gateway מרחיב את הפיקוח של Agent Platform לסוכנים ולשרתי MCP שאתם פורסים ב-Cloud Run. אתם מצרפים את Agent Gateway לתשתית הרשת שאתם כבר מנהלים בפרויקט שלכם ב-Google Cloud . ‫Secure Web Proxy מנהל את התנועה היוצאת של הסוכנים, ומאזן עומסים של אפליקציות (ALB) מנהל את התנועה הנכנסת לסוכנים. ‫Agent Gateway אוכף את כללי המדיניות בשני הנתיבים על סמך הזהות של הסוכן ושל המתקשר, בלי לשנות את הקוד של הסוכן.

  • ארכיטקטורה ותשתית: אתם מריצים את תשתית שרת ה-proxy בפרויקט שלכם.

    • Client-to-Agent: בתעבורת נתונים מלקוח לסוכן, הלקוחות מגיעים לסוכנים דרך מאזן עומסים אזורי של אפליקציות (ALB) – חיצוני ללקוחות באינטרנט או פנימי ללקוחות ברשת ה-VPC. ‫Agent Gateway מחובר למאזן העומסים, ולכן הוא מאמת ובודק כל בקשה נכנסת לפני שהיא מגיעה לנציג.
    • ‫Agent-to-Anywhere: בתנועה מסוג Agent-to-Anywhere, רשת Ambient Networking של Cloud Run מיירטת את התנועה היוצאת מהקונטיינר של הסוכן. לאחר מכן, הוא מעביר את התנועה הזו דרך תעבורת נתונים יוצאת (egress) של Direct VPC, באמצעות מנהרה עם אימות הדדי (mTLS) שנושאת את זהות הסוכן, למכונה של Secure Web Proxy ברשת ה-VPC שפועלת כנקודת אכיפת המדיניות.

    אתם יוצרים ומנהלים את המשאבים של Secure Web Proxy ושל מאזן העומסים, ושולטים ברשת ה-VPC, באישורים ובמתחם האבטחה ההיקפית של הרשת.

  • יכולות עיקריות: מדיניות גישה מבוססת-זהות לשיחות יוצאות לכלים, למודלים ולממשקי API, אימות והרשאה של שיחות נכנסות באמצעות שרת proxy לאימות זהויות (IAP), סינון של הנחיות, תשובות ומטענים ייעודיים (payloads) של כלים בשני הכיוונים באמצעות הגנה מוגברת על המודל, בדיקת TLS של תעבורת נתונים יוצאת באמצעות רשות אישורים בשליטתכם, וקבוצה מרכזית אחת של כללי מדיניות בשירותי Cloud Run רבים, עם Policy Engine בהתאמה אישית באמצעות קישורי תוספים.

  • תרחיש לדוגמה: צוותי אבטחה ופלטפורמה שמריצים סוכנים ב-Cloud Run וצריכים ניהול מרכזי של תנועת הסוכנים הנכנסת והיוצאת. זה כולל ארגונים שדורשים אכיפת אבטחה בתשתית שנפרדת מזמן הריצה של האפליקציה, וארגונים שמנתבים תנועה דרך רשת VPC מסוג Hub-and-Spoke לצורך בדיקה.

בקרוב תהיה תמיכה ב-Agent Gateway לסוכנים ב-Cloud Run. התכונות ומועדי ההשקה עשויים להשתנות. כדי לבקש גישה מוקדמת, הירשמו לגרסת טרום-השקה (Preview).

‫Agent Gateway ל-cross-cloud

‫Agent Gateway חוצה-עננים מרחיב את הפיקוח של Agent Platform לסוכנים שפועלים באשכולות Kubernetes מחוץ ל- Google Cloud, כמו Amazon EKS,‏ Azure AKS,‏ Red Hat OpenShift או אשכולות במרכזי הנתונים שלכם. אתם מנהלים את הממשל באופן מרכזי ב- Google Cloud, וכללי המדיניות נאכפים בתוך האשכול שלכם.

  • ארכיטקטורה ותשתית: ב- Google Cloud נמצא מישור הניהול, שבו מגדירים את זהויות הסוכנים, רשומות המרשם וכללי המדיניות. אתם פורסים באשכול Kubernetes את Agent Gateway, רכיב קל שמבוסס על Envoy, ואת הרכיבים שתומכים בו. אתם אחראים על הרישות של האשכול, כולל ניתוב התעבורה של סוכן הניתוב לשער. התנועה של הנציג נשארת בסביבה שלכם. רק בדיקות המדיניות שאתם מגדירים, כמו סינון של Model Armor, קוראות ל-Google Cloud.
  • יכולות עיקריות: ניהול התנועה של הסוכנים לכל מקום, החלפת פרטי הכניסה של עומסי העבודה ב-Kubernetes בפרטי הכניסה של Agent Identity באמצעות איחוד שירותי אימות הזהות של עומסי עבודה, ואכיפת כללי מדיניות שאתם מגדירים באופן מרכזי, כמו Model Armor. הוא גם מרחיב את Agent Registry ואת Agent Observability (יומני גישה ומעקבים) לסוכנים מחוץ ל- Google Cloud.
  • תרחיש לדוגמה: ארגונים שמפעילים סוכנים בכמה עננים או במרכזי נתונים משלהם, ורוצים קבוצה אחת של מדיניות פיקוח, מרשם אחד ותצוגה אחת של פעילות הסוכנים לכל הסוכנים שלהם.

בקרוב: Agent Gateway חוצה-עננים. התכונות ולוח הזמנים עשויים להשתנות. כדי לבקש גישה מוקדמת, הירשמו לגרסת טרום-השקה (Preview).

פרוטוקולים נתמכים

‫Agent Gateway תומך בפרוטוקולים סטנדרטיים של תקשורת מבוססת-HTTP בין סוכנים בכל מודלי הפריסה, כולל:

  • ‫Model Context Protocol (MCP): שולט בקריאות API לכלי MCP יוצאות ונכנסות דרך Server-Sent Events (SSE) או בקשות HTTP POST.
  • ‫Agent-to-Agent‏ (A2A): מנהל את ממשקי ה-API להאצלת סמכויות בין סוכנים ולביצוע משימות.
  • ‫REST ו-gRPC: תמיכה בתעבורת נתונים מסוג HTTP/1.1 ו-HTTP/2 (gRPC) בפריסות של GKE,‏ Cloud Run ופריסות חוצות-עננים.

בתעבורת נתונים של MCP, ‏Agent Gateway בודק בקשות JSON-RPC כדי לחלץ שמות של כלים ומאפייני שיטות, וכך מאפשר מדיניות גישה מפורטת לכלים בכל המודלים של הפריסה. פרטים נוספים זמינים במאמר הרשאה שמבוססת על מאפייני MCP.

מגבלות

הפניות ל-API ול-gcloud

למידע נוסף על השיטות שזמינות ל-Agent Gateway, עיינו בנושאי העזר הבאים:

המאמרים הבאים

Codelab

איך מנהלים עומסי עבודה של סוכנים באמצעות Agent Gateway ב-Gemini Enterprise Agent Platform.

סקירה כללית

הכירו את הסביבה העסקית של ספקי אבטחת זהויות ו-AI שמשתלבים עם Agent Gateway.

מדריך

איך מציגים, מעדכנים, מוחקים ומבטלים את השיוך של משאבי Agent Gateway.

מדריך

איך מגדירים Agent Gateway.

פתרון בעיות

איך פותרים בעיות בקישוריות של Agent Gateway.