כללי מדיניות ניתנים להרחבה ב-Agent Gateway

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

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

תרחישים לדוגמה של הרחבת המדיניות בנושא סיכונים שקשורים ל-AI אקטיבי

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

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

מסגרת להרחבת המדיניות ב-Agent Gateway

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

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

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

• מפיקים: צוותי פלטפורמה פנימיים, שירותי Google של צד ראשון (כמו IAP ו-Model Armor) ושותפי ISV של צד שלישי, שמפתחים ומפרסמים תוספים לשירותים כדי שאחרים יוכלו להשתמש בהם.

• ‫ExtensionBinding: משאב שנוצר על ידי הצרכן ומקשר בין ProducerExtension לבין Agent Gateway, יחד עם תנאי התאמה שקובעים מתי התוסף מופעל. זהו המשאב היחיד שצרכן צריך ליצור כדי להתחיל להשתמש בתוסף.

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

תוספים מובנים של Google מאינטראקציה ישירה

שירותי Google מהדומיין הנוכחי (1P), כמו IAP ו-Model Armor, מציעים יכולות הרחבה בחבילות מוכנות מראש עם מודל תפעולי יעיל.

• צרכנים: מפתחי אפליקציות ומפעילי אבטחה פועלים כצרכנים. כדי להפעיל אימות בגישת אבטחה של אפס אמון או הגנה מפני החדרת פרומפטים, אתם צריכים ליצור משאב ExtensionBinding שמטרגט את מזהי ה-URI של נקודות הקצה של השירותים המוגדרים מראש של Google ישירות מהפרויקט של הצרכן.
• יצרן: Google פועלת כיצרן. ‫Google יוצרת, מארחת ומנהלת את Service Infrastructure הבסיסית של השירות ואת נקודות הקצה של התוספים ברחבי העולם (כמו iap.googleapis.com או modelarmor.us.rep.googleapis.com). אתם לא צריכים ליצור או לנהל משאב של ProducerExtension.

תוספים של הארגון ושל שותפים (צד שני/צד שלישי)

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

• יצרן: צוותי הנדסת פלטפורמה פנימיים (2P) או ספקי אבטחה של ספקי תוכנה עצמאיים (ISV) של צד שלישי (3P) פועלים כיצרנים. הספק יוצר שירות gRPC שתואם לפרוטוקול ext_proc של Envoy, מארח אותו בפרויקט ספק ייעודי (כמו שירות Cloud Run מאחורי מאזן עומסים של אפליקציות), חושף אותו באמצעות צירוף שירות של Private Service Connect ‏ (PSC) ומפרסם משאב ProducerExtension.

• צרכן: מפתחי אפליקציות ואדמינים של אבטחה בפרויקטים של צרכנים פועלים כצרכנים. אחרי שהיצרן נותן גישה באמצעות PSC, הצרכנים יוצרים ExtensionBinding בפרויקט שלהם שמפנה ל-URI הספציפי של המשאב ProducerExtension כדי לאכוף אמצעי בקרה מותאמים אישית (כמו מדיניות פיקוח בשפה טבעית או כללי חומת אש של צד שלישי) על עומסי העבודה שלהם.

תבניות פריסה

קישורי תוספים תומכים בתבניות פריסה גמישות כדי לאכוף משילות עקבית בכל נתיבי התנועה, וכדי לוודא שמדיניות המשילות פועלת באופן זהה, לא משנה איפה הסוכנים פרוסים. ‫ExtensionBinding API חל באופן אחיד על כל מודלי הפריסה של Agent Gateway.

נתיבים ליירוט תנועה מקצה לקצה

אתם יכולים להחיל קישורי תוספים כדי ליירט תנועה בנתיבי התקשורת הבאים בסביבה של הסוכנים:

• משתמש ← נציג (Ingress): יירוט בקשות נכנסות ממשתמשי קצה או מאפליקציות לקוח שמטרגטות את Agent Gateway כדי לאכוף אימות משתמשים, ניהול זהויות או הסרת תוכן זדוני או רגיש בהחדרת פרומפטים.
• סוכן ← כלי או MCP (תעבורת נתונים יוצאת): יירוט של שיחות יוצאות מסוכנים לשרתי Model Context Protocol‏ (MCP) או לממשקי API חיצוניים כדי לאמת הרשאות ולהסיר תוכן זדוני או רגיש מהקלט של הכלים.
• נציג ← מודל LLM (תעבורת נתונים יוצאת): סריקת ההנחיות לפני שהן מגיעות למודלים הבסיסיים וסינון התשובות של המודל כדי למנוע אובדן נתונים או פלט פוגעני.

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

מלקוח לנציג

מנציג לכל מקום

צרכנים: קישור תוספים ל-Agent Gateways

הצרכנים (כמו מפתחי אפליקציות או מפעילי אבטחה) מצרפים לוגיקה של משילות ואבטחה ל-Agent Gateways שלהם על ידי יצירת ExtensionBinding. המשאב הזה מקשר את עומס העבודה של היעד לתוסף ומצהיר על תנאי התאמה כדי להגדיר בדיוק מתי צריך להפעיל את התוסף (לדוגמה, יירוט תנועה שמיועדת לכלים חיצוניים ספציפיים או לשרתי MCP). אתם יכולים לציין תנאי התאמה ישירות בשורה (כמו בדוגמאות שבקטע הזה) או בקובץ YAML נפרד.

בהתאם לספק התוסף, השימוש מתבצע באחת משתי דרכים:

הגדרות הצרכן מאינטראקציה ישירה (1P)

בשירותי Google כמו IAP או "הגנה מוגברת על המודל", ‏Google מנהלת את תשתית הקצה העורפי ואת הרישום באופן גלובלי. כצרכנים, אתם לא צריכים לטרגט ל-URI ספציפי של משאב ProducerExtension. אתם יכולים לקשר את השירותים האלה ישירות לעומסי העבודה שלכם, על ידי העברת מחרוזות נקודות הקצה המוגדרות מראש (למשל, iap.googleapis.com או modelarmor.us.rep.googleapis.com) כיעד ב-ExtensionBinding.

קישור של תוסף IAP ל-Agent Gateway

בדוגמה הבאה מוצג משאב ExtensionBinding שמקשר בין שירות Google של צד ראשון (IAP) לבין Agent Gateway בפרויקט של הצרכן. בהתאם לשדה matchConditions שצוין, התוסף הזה מופעל כשנשלחת תנועה לשרת MCP.

1. יוצרים קובץ YAML עם ההגדרות הבאות:

   name: EXTENSION_BINDING_NAME
   target:
     resources:
     - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
   matchConditions:
   - to:
       destination:
         resources:
         - prefix: "urn:mcp"
   producerExtension: "iap.googleapis.com"
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫EXTENSION_BINDING_NAME: השם של משאב הקישור של התוסף.
   • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance by S3NS .
   • LOCATION: המיקום של השער ושל קישור התוסף.
   • ‫AGENT_GATEWAY_NAME: השם של Agent Gateway היעד.

2. מייבאים את הגדרת הקישור של התוסף:

   gcloud beta service-extensions extension-bindings import EXTENSION_BINDING_NAME \
    --location=LOCATION \
    --source=EXTENSION_BINDING_FILE_PATH

   מחליפים את EXTENSION_BINDING_FILE_PATH בנתיב לקובץ התצורה ב-YAML.

קישור של תוסף Model Armor ל-Agent Gateway

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

1. יוצרים קובץ YAML עם ההגדרות הבאות:

   name: EXTENSION_BINDING_NAME
   target:
     resources:
     - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
   matchConditions:
   - to:
       destination:
         resources:
         - prefix: "urn:mcp"
   producerExtension: "modelarmor.us.rep.googleapis.com"
   failOpen: true
   producerMetadata:
     model_armor_settings: '[{
       "request_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID",
       "response_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID"
     }]'
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫EXTENSION_BINDING_NAME: השם של משאב הקישור של התוסף.
   • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance .
   • ‫LOCATION: המיקום של המשאבים.
   • ‫AGENT_GATEWAY_NAME: השם של Agent Gateway היעד.
   • ‫TEMPLATE_PROJECT_ID: מזהה הפרויקט שבו נמצאות התבניות של Model Armor.
   • ‫REQUEST_TEMPLATE_ID: המזהה של התבנית של Model Armor שמשמשת להערכת הבקשות.
   • ‫RESPONSE_TEMPLATE_ID: המזהה של התבנית של Model Armor שמשמשת להערכת התשובות.

2. מייבאים את הגדרת הקישור של התוסף:

   gcloud beta service-extensions extension-bindings import EXTENSION_BINDING_NAME \
    --location=LOCATION \
    --source=EXTENSION_BINDING_FILE_PATH

   מחליפים את EXTENSION_BINDING_FILE_PATH בנתיב לקובץ התצורה ב-YAML.

הגדרות צרכן של צד שני או צד שלישי

אם אתם משתמשים בתוסף שירות שנוצר על ידי צוות פנימי אחר (2P) או ספק חיצוני (3P), אתם צריכים לוודא שלפרויקט שלכם ניתנה גישה מפורשת לשימוש בשירות. הגישה נשלטת על ידי הבעלים באמצעות הגדרת הקובץ המצורף עם השירות Private Service Connect. אחרי שמקבלים גישה, מקשרים את עומס העבודה באמצעות הפניה ל-URI הספציפי של המשאב ב-ProducerExtension שסופק על ידי היצרן ב-ExtensionBinding.

קישור מנועי הרשאות בהתאמה אישית

בדוגמה הבאה מוצג משאב ExtensionBinding שמקשר תוסף בהתאמה אישית מפרויקט של בעלים מצד שני או צד ג' ל-Agent Gateway בפרויקט של צרכן. התוסף הזה מופעל כשנשלחת תנועה לסוכן, על סמך השדה matchConditions שצוין.

1. יוצרים קובץ YAML עם ההגדרות הבאות:

   name: EXTENSION_BINDING_NAME
   target:
     resources:
     - "projects/CONSUMER_PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
   matchConditions:
   - to:
       destination:
         resources:
         - prefix: "urn:agent"
   producerExtension: "projects/PRODUCER_PROJECT_ID/locations/LOCATION/producerExtensions/PRODUCER_EXTENSION_NAME"
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫EXTENSION_BINDING_NAME: השם של משאב הקישור של התוסף.
   • ‫CONSUMER_PROJECT_ID: מזהה הפרויקט של הצרכן שמארח את Agent Gateway.
   • ‫LOCATION: המיקום של המשאבים.
   • ‫AGENT_GATEWAY_NAME: השם של Agent Gateway היעד.
   • ‫PRODUCER_PROJECT_ID: מזהה הפרויקט של הפרויקט המפיק שמארח את ProducerExtension.
   • ‫PRODUCER_EXTENSION_NAME: השם של המשאב ProducerExtension.

2. מייבאים את הגדרת הקישור של התוסף:

   gcloud beta service-extensions extension-bindings import EXTENSION_BINDING_NAME \
    --location=LOCATION \
    --source=EXTENSION_BINDING_FILE_PATH

   מחליפים את EXTENSION_BINDING_FILE_PATH בנתיב לקובץ התצורה ב-YAML.

נקודות צירוף של קישור תוספים

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

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

קישור של תוסף Model Armor לכל Agent Gateways בפרויקט

1. יוצרים קובץ YAML עם ההגדרות הבאות:

   name: EXTENSION_BINDING_NAME
   target:
     scope:
       parent: "projects/PROJECT_NUMBER"
       resourceTypes: "AGENT_GATEWAY"
   matchConditions:
   - to:
       destination:
         resources:
         - prefix: "urn:mcp"
   producerExtension: "modelarmor.us.rep.googleapis.com"
   failOpen: true
   producerMetadata:
     model_armor_settings: '[{
       "request_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID",
       "response_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID"
     }]'
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫EXTENSION_BINDING_NAME: השם של משאב הקישור של התוסף.
   • ‫PROJECT_NUMBER: מספר הפרויקט ב-Cloud de Confiance .
   • ‫TEMPLATE_PROJECT_ID: מזהה הפרויקט שבו נמצאות התבניות של Model Armor.
   • ‫LOCATION: המיקום של המשאבים.
   • ‫REQUEST_TEMPLATE_ID: המזהה של התבנית של Model Armor שמשמשת להערכת הבקשות.
   • ‫RESPONSE_TEMPLATE_ID: המזהה של התבנית של Model Armor שמשמשת להערכת התשובות.

2. מייבאים את הגדרת הקישור של התוסף:

   gcloud beta service-extensions extension-bindings import EXTENSION_BINDING_NAME \
    --location=LOCATION \
    --source=EXTENSION_BINDING_FILE_PATH

   מחליפים את EXTENSION_BINDING_FILE_PATH בנתיב לקובץ התצורה ב-YAML.

בבקשות שתואמות לעומס עבודה ספציפי, מופעלים גם הקישורים של התוספים ברמת הפרויקט וגם הקישורים של התוספים ברמת המשאב. אם אותו תוסף מוגדר גם ברמת המשאב וגם ברמת הפרויקט, הוא יופעל פעמיים.

תנאי התאמה להפעלת תוספים

תנאי ההתאמה קובעים מתי התוסף מופעל. אתם יכולים לציין תנאי התאמה ישירות בשורה (כמו בדוגמאות הקודמות בדף הזה) או בקובץ YAML.

בקטע הזה מופיעות הגדרות לדוגמה של קובצי YAML למצבים נפוצים, על סמך זרימת התנועה, מזהי ה-URN של משאבי היעד או המארחים של היעד:

• תעבורת נתונים יוצאת לשרתי כלים של MCP (סוכן ← כלי): יירוט תעבורת נתונים שנשלחת מסוכן לשרתי כלים מרוחקים של Model Context Protocol‏ (MCP):

  # Invoke extension for all agent traffic to remote MCP servers
  - to:
      destination:
        resources:
        - prefix: "urn:mcp"
  

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

  # Invoke extension on incoming user requests targeting agents
  - to:
      destination:
        resources:
        - prefix: "urn:agent"
  

• תעבורת נתונים יוצאת למודלים של LLM (נציג ← מודל LLM): יירוט בקשות שנשלחות מנציגים למודלים בסיסיים של LLM או לשרתי מודלים, על ידי התאמה למארח היעד:

  # Invoke extension on traffic sent to a specific model server
  - to:
      destination:
        hosts:
        - exact: "myexamplemodelserver.com"
  

מפיקים: פיתוח ופרסום של תוספים

אם אתם מפיקים בהתאמה אישית (צד שני או צד שלישי), אתם צריכים לארח את ההטמעה של תוסף השירות שמבוסס על ext_proc מאחורי קובץ מצורף של Private Service Connect. אחרי שהקובץ המצורף מוכן, יוצרים משאב ProducerExtension ומציינים את שלב עיבוד הבקשה שבו התוסף פועל, את הרשות לשימוש ואת ה-URI לקובץ המצורף של PSC לשירות ext_proc:

gcloud beta service-extensions producer-extensions create PRODUCER_EXTENSION_NAME \
  --phase authz \
  --extension-settings=service=projects/PRODUCER_PROJECT_ID/regions/REGION/serviceAttachments/PSC_ATTACHMENT_NAME,authority="example.provider.net"

מחליפים את מה שכתוב בשדות הבאים:

• ‫PRODUCER_EXTENSION_NAME: השם של המשאב ProducerExtension.
• ‫PRODUCER_PROJECT_ID: מזהה הפרויקט של הפרויקט המפיק.
• ‫REGION: האזור של הקובץ המצורף עם השירות Private Service Connect.
• ‫PSC_ATTACHMENT_NAME: השם של הקובץ המצורף עם השירות Private Service Connect.

אירוח תוספים מותאמים אישית ב-Cloud Run

לבעלים של שירותים מנוהלים שרוצים להריץ שירות ext_proc gRPC בהתאמה אישית בלי לנהל אשכולות או מכונות וירטואליות ייעודיים, Cloud Run הוא חלופה אידיאלית ללא שרת.

כדי לפרסם את התוסף ללא שרת (serverless) בתור ProducerExtension, צריך לחשוף אותו באמצעות Private Service Connect ‏(PSC). בגלל שמשאבי ProducerExtension דורשים URI של צירוף שירות PSC, וצירופי שירות מטרגטים כללי העברה של מאזן עומסים ולא שירותי Cloud Run באופן ישיר, צריך להציב מאזן עומסים של אפליקציות (באמצעות קצה עורפי של NEG ללא שרת) לפני שירות Cloud Run.

זהו תהליך העבודה הכללי לפריסת התוסף לאירוח ב-Cloud Run:

1. פריסת התוסף ב-Cloud Run: מארחים את התוסף המותאם אישית של ext_proc gRPC כשירות בקונטיינר ב-Cloud Run.

2. יצירת קבוצת נקודות קצה ברשת (NEG) ללא שרת (serverless): פורסים קבוצת נקודות קצה ברשת (NEG) ללא שרת (serverless) שמפנה לתוסף שפועל ב-Cloud Run.

3. הגדרת מאזן עומסים עם קצה עורפי של NEG ללא שרת: מגדירים מאזן עומסים אזורי של אפליקציות בתוך רשת ה-VPC, עם NEG ללא שרת כקצה העורפי שלו.

4. פרסום השירות באמצעות PSC: יוצרים קובץ מצורף עם השירות Private Service Connect שמפנה ישירות לכלל ההעברה של מאזן העומסים. הפעולה הזו יוצרת URI ייחודי של Service Attachment (לדוגמה, projects/.../regions/.../serviceAttachments/...).

5. יצירת תוסף Producer: משתמשים ב-URI שנוצר כדי ליצור מופע של המשאב ProducerExtension.

6. קישור עומסי עבודה של צרכנים: הצרכנים יכולים עכשיו לקשר את השערים שלהם לתוסף שלכם על ידי הפניה למזהה ה-URI של המשאב ProducerExtension.

נספח: מטא-נתונים לפי הקשר לתוספים בהתאמה אישית

כדי לעזור לתוספים בהתאמה אישית לקבל החלטות לגבי הרשאות ועיבוד בהתאם להקשר,מישורי הנתונים מעבירים את ההקשר של מחזור החיים והמשאבים ישירות לשרתי ext_proc. Cloud de Confiance

המידע הזה נכלל כמטא-נתונים לא מוקלדים בשדה metadata_context של ext_proc gRPC ProcessingRequest. המטא-נתונים האלה נמצאים במרחב השמות com.google.serviceextensions.invocation_info ומשתמשים בפורמט הסטנדרטי google.protobuf.Struct.

אתם יכולים לפענח או להמיר את המטא-נתונים האלה ל-JSON לצורך עיבוד בהמשך. דוגמה לפורמט JSON של בקשה שמטרגטת את Agent Gateway עם תנועה שמיועדת לשרת MCP:

{
 "binding_selector" : {
   "target" : "//networkservices.googleapis.com/projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME",
   "project_number" : PROJECT_NUMBER,
   "to_resource": "urn:mcp:projects-PROJECT_NUMBER:projects:PROJECT_NUMBER:locations:LOCATION:agentregistry:services:SERVER_ID"
 }
}

זו הסכימה של ה-JSON:

message ServiceExtensionsInvocationInfo {
  message ExtensionBindingSelector {
    // The target (gateway ID, etc) in fully qualified name format.
    // For example:
    // "//networkservices.googleapis.com/projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
    string target = 1;
    // Project number associated with the target.
    uint64 project_number = 2;
    // The destination resource within the Agent Registry that traffic is directed to.
    string to_resource = 3;
  }
  ExtensionBindingSelector binding_selector = 1;
}