העברת תנועה של Agent Runtime דרך Agent Gateway

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

לפני שמתחילים

  • חשוב לוודא שאתם יודעים איך פורסים סוכנים ב-Agent Runtime.

  • מידע על Agent Gateway אתם יכולים להשתמש ב-Agent Gateway במצב Agent-to-Anywhere (יציאה) כדי לאבטח ולנהל את כל התקשורת היוצאת עם תנועה יוצאת לכלים, למודלים, לממשקי API ולנציגים אחרים. אתם משתמשים בשער במצב Client-to-Agent (ingress) כדי לקבוע אילו לקוחות יכולים לגשת לסוכנים שלכם. השער מאפשר לכם לבחור אילו מדיניות בנושא רכישות מתוך האפליקציה ותבניות של הגנה מוגברת על המודל יחולו על האינטראקציות האלה.

    מופע יחיד של זמן ריצה יכול להיות משויך בו-זמנית גם לשער Agent-to-Anywhere (יציאה) וגם לשער Client-to-Agent (כניסה).

מגבלות

  • אי אפשר לקשר שער סוכנים למנועי נימוקים של זמן ריצה שנוצרו לפני 29 באפריל 2026.

  • פרויקט ואזור יחידים יכולים לארח כמה מופעים של Agent Gateway (יציאה) מסוג Agent-to-Anywhere וכמה מופעים של Agent Gateway (כניסה) מסוג Client-to-Agent, אבל כל סוכני Agent Runtime שנפרסים באותו פרויקט ובאותו אזור חייבים להיות קשורים לאותם מופעים ספציפיים של Agent Gateway (יציאה) ו-Agent Gateway (כניסה).

    לדוגמה, אם פרויקט ואזור מכילים את egress-gateway-X ואת egress-gateway-Y, כל הסוכנים בפרויקט ובאזור האלה צריכים להיות מוגדרים לשימוש באותו שער לתעבורת נתונים יוצאת (egress). כלומר, כל הסוכנים משתמשים ב-egress-gateway-X או שכל הסוכנים משתמשים ב-egress-gateway-Y. אי אפשר להגדיר את agent-A לשימוש ב-egress-gateway-X ואת agent-B לשימוש ב-egress-gateway-Y.

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

  • שירות זיהוי האיומים של Agent Engine ב-Security Command Center לא זמין כש-Agent Gateway מופעל עבור סוכן.

  • במצב Client-to-Agent (כניסה), Agent Gateway יכול לשלוט רק בשיטות query ו-streamQuery של Agent Runtime. כדי להגן על שיטות אחרות שלא נתמכות (כמו asyncQuery), אפשר להחיל תבניות של הגנה מוגברת על המודל ישירות מהאפליקציה או מהסוכן. אפשר לעיין במאמר בנושא ניקוי הנחיות ותשובות או ב-codelab בנושא יצירת מערכת סוכנים מאובטחת באמצעות הגנה מוגברת על המודל.

  • אין תמיכה ב-VPC Service Controls עם Agent Gateway.

העברת תנועה של Agent Runtime דרך Agent Gateway

כדי להפנות תנועה של Agent Runtime דרך Agent Gateway, מבצעים את השלבים הבאים:

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

    מוודאים שהשער מוגדר בהתאם לצרכים של הפריסה. לדוגמה, אם הסוכן שלכם דורש גישה ל-LLM, צריך להגדיר את השער כך שיאפשר את הגישה הזו כדי למנוע כשלים פוטנציאליים בפריסת Agent Runtime.

  2. מגדירים את הסוכן לניתוב תנועה דרך Agent Gateway.

    • לנציגים חדשים

      מציינים את משאב השער בזמן פריסת הסוכן. לדוגמה, כדי לפרוס את הסוכן ב-Agent Runtime, משתמשים ב-client.agent_engines.create כדי להעביר את האובייקט local_agent יחד עם הגדרות אופציונליות.

      אם רוצים להשתמש בתכונות של פלטפורמת השער כמו Model Armor או Semantic Governance Policies עם הסוכן הזה, צריך להגדיר גם את agent_gateway_config וגם את identity_type=AGENT_IDENTITY בקריאת היצירה, כמו בדוגמה הזו. בלי identity_type=AGENT_IDENTITY, המופע של Runtime effectiveIdentity חוזר לחשבון השירות שמוגדר כברירת מחדל ב-Vertex AI, ומדיניות השליטה הסמנטית מסננת את הסוכן מהבורר של יצירת המדיניות בלי להציג הודעה.

      remote_agent = client.agent_engines.create(
  agent=local_agent,
  config={
      "agent_gateway_config": {
        "agent_to_anywhere_config": {"agent_gateway": projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_TO_ANYWHERE_NAME},
        # "client_to_agent_config": {"agent_gateway": projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_CLIENT_TO_AGENT_NAME}
      },
      "identity_type": types.IdentityType.AGENT_IDENTITY,
      # Other optional configuration ...
      # "requirements": requirements,
      # "gcs_dir_name": gcs_dir_name,
      # https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/agent-identity#opt-out-caa
      "env_vars": {
        "GOOGLE_API_PREVENT_AGENT_TOKEN_SHARING_FOR_GCP_SERVICES": False,
      }
  },
)

      מחליפים את AGENT_GATEWAY_TO_ANYWHERE_NAME בשם של Agent Gateway שיצרתם במצב Agent-to-Anywhere (יציאה).

      אם יצרתם Agent Gateway במצב Client-to-Agent (כניסה), צריך להשתמש בשדה client_to_agent_config במקום בשדה AGENT_GATEWAY_CLIENT_TO_AGENT_NAME ולהחליף את AGENT_GATEWAY_CLIENT_TO_AGENT_NAME בשם של Agent Gateway שיצרתם לכניסה.

    • לסוכנים קיימים

      Agent-to-Anywhere

      משתמשים בבקשת API בארכיטקטורת REST הבאה כדי לשייך סוכן קיים לשער Agent-to-Anywhere ליציאה.

      curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json; charset=utf-8" \
-d '{
  "spec": {
    "deploymentSpec": {
      "agentGatewayConfig": {
        "agentToAnywhereConfig": {
          "agentGateway": "projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_TO_ANYWHERE_NAME"
        }
      }
    }
  }
}' \
"https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID?updateMask=spec.deploymentSpec.agentGatewayConfig"

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

      • ‫PROJECT_ID: מזהה הפרויקט
      • ‫REGION: האזור שבו הסוכן נפרס
      • ‫AGENT_GATEWAY_TO_ANYWHERE_NAME: השם של Agent Gateway שיצרתם במצב Agent-to-Anywhere (יציאה)
      • ‫RESOURCE_ID: מזהה המשאב של הסוכן

      לקוח לנציג

      משתמשים בבקשת API בארכיטקטורת REST הבאה כדי לשייך סוכן קיים לשער Client-to-Agent לצורך תעבורת נתונים נכנסת.

      curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json; charset=utf-8" \
-d '{
  "spec": {
    "deploymentSpec": {
      "agentGatewayConfig": {
        "clientToAgentConfig": {
          "agentGateway": "projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_CLIENT_TO_AGENT_NAME"
        }
      }
    }
  }
}' \
"https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID?updateMask=spec.deploymentSpec.agentGatewayConfig"

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

      • ‫PROJECT_ID: מזהה הפרויקט
      • ‫REGION: האזור שבו הסוכן נפרס
      • ‫AGENT_GATEWAY_CLIENT_TO_AGENT_NAME: השם של Agent Gateway שיצרתם ב-Client-to-Agent (ingress)
      • ‫RESOURCE_ID: מזהה המשאב של הסוכן

  3. נרשמים באמצעות מופע של Agent Registry באותו פרויקט ואזור כמו הסוכן והשער.

    gcloud agent-registry services create SERVICE_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --display-name="DISPLAY_NAME" \
  --endpoint-spec-type=no-spec \
  --interfaces='[{url="https://REGION-aiplatform.mtls.googleapis.com",protocolBinding="jsonrpc"}]' \
  --format="value(registryResource)"

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

    • ‫SERVICE_NAME: השם שרוצים לתת למשאב, למשל allow-aiplatform-region-eu3.
    • ‫PROJECT_ID: מזהה הפרויקט.
    • ‫REGION: האזור של המאגר.
    • ‫DISPLAY_NAME: השם של נקודת הקצה שקריא לאנשים.

    מידע נוסף מופיע במאמר בנושא רישום סוכן.

  4. יוצרים קשר בין מדיניות IAM של סוכן לבין רישום של הסוכן.

    gcloud iap web add-iam-policy-binding \
  --resource-type=agent-registry \
  --endpoint=ENDPOINT_ID \
  --region=REGION \
  --project=PROJECT_ID \
  --member=MEMBER \
  --role=roles/iap.egressor

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

    • ‫ENDPOINT_ID: המזהה של נקודת הקצה של השירות של הסוכן הרשום. הנתון הזה מופיע בפלט של השלב הקודם.

    • ‫MEMBER: חשבון המשתמש של סוכן שרוצים להקצות לו את התפקיד. הפורמט הוא בדרך כלל: principal://TRUST_DOMAIN/resources/aiplatform/projects/PROJECT_ID/locations/REGION/reasoningEngines/ENGINE_ID.

  5. בשלב הזה, התנועה של הסוכנים תופנה דרך Agent Gateway. עם זאת, Agent Gateway מאמץ מדיניות של דחייה כברירת מחדל. כדי להפעיל פונקציות מסוימות ב-Agent Platform, צריך לוודא שהסוכן יכול לתקשר עם נקודות הקצה הבאות:

    • אם Cloud Trace מופעל, Agent Gateway צריך לאפשר תנועה לנקודת הקצה https://telemetry.googleapis.com/.

      אם משתני הסביבה GOOGLE_API_USE_CLIENT_CERTIFICATE ו-GOOGLE_API_USE_MTLS_ENDPOINT מוגדרים, צריך לוודא שהתעבורה אל https://telemetry.mtls.googleapis.com/ מותרת גם כן.

    • אם Cloud Logging מופעל, Agent Gateway צריך לאפשר תנועה לנקודת הקצה https://logging.googleapis.com/.

      אם משתני הסביבה GOOGLE_API_USE_CLIENT_CERTIFICATE ו-GOOGLE_API_USE_MTLS_ENDPOINT מוגדרים, צריך לוודא שהתעבורה אל https://logging.mtls.googleapis.com/ מותרת גם כן.

    בנוסף, אם הסוכנים שלכם מתקשרים עם מודלים גדולים של שפה (LLM) או משתמשים בתכונות כמו Sessions ו-Memory Bank, אתם צריכים לוודא שהסוכנים יכולים לתקשר עם נקודות הקצה שבהן השירותים האלה משתמשים. לדוגמה:

    • לסשנים: https://REGION-aiplatform.googleapis.com/API_VERSION/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID/sessions
    • ב-Memory Bank: https://REGION-aiplatform.googleapis.com/API_VERSION/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID/memories

    מטעמי אבטחה, מומלץ לרשום ברשימת ההיתרים רק את כתובות ה-URI הספציפיות שהסוכן ניגש אליהן. מכיוון שהשער מתאים לשמות מארחים באופן ישיר, צריך לוודא שרשמתם את כל הווריאציות שבהן נעשה שימוש ב-SDK של הסוכן. לדוגמה, בהתאם לגרסת ה-SDK, להגדרת הלקוח האזורי או לשימוש ב-mTLS, אפשר לפתור Google API באמצעות שמות המארחים של נקודות הקצה הבאות:

    • https://REGION-aiplatform.googleapis.com
    • https://REGION-aiplatform.mtls.googleapis.com
    • https://aiplatform.REGION.rep.googleapis.com

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

  6. בודקים את הגדרות הנציג.

    המסוף

    1. נכנסים לדף Deployments של Agent Platform במסוף Google Cloud .

      מעבר לדף Deployments

    2. לוחצים על השם של נציג התמיכה שהטמעתם.

    3. לוחצים על הגדרת שירות. החלונית Observability של הסוכן תיפתח.

    4. לוחצים על פרטי הפריסה. ההגדרות של תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) של Agent Gateway זמינות בשדה Deployment spec.

    gcloud

    כדי לוודא שהסוכן משויך עכשיו לשער, משתמשים בבקשת API בארכיטקטורת REST הבאה. אם הפלט שמוחזר הוא null, המשמעות היא ש-Runtime לא הצליח להתחבר לשער.

    curl -s -X GET \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID" \
  | jq '.spec.deploymentSpec.agentGatewayConfig'

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

    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫REGION: האזור שבו הסוכן נפרס
    • ‫RESOURCE_ID: מזהה המשאב של הסוכן

הגדרת סוכנים של קונטיינר בהתאמה אישית (BYOC) ב-Agent Gateway

אם רוצים לנתב תנועה יוצאת דרך שער של סוכן לכל מקום (יציאה) עבור סוכן שנפרס עם תמונת קונטיינר מותאמת אישית (Bring Your Own Container / BYOC), צריך להטמיע את אישור CA של רשות אישורי הבסיס של השער בחנות האישורים של תמונת הקונטיינר המותאמת אישית.

מכיוון ש-Agent Gateway מבצע פענוח ובדיקה של TLS בתקשורת של נציגים יוצאים, פריסות של נציגים שאינן BYOC (מבוססות מקור) מזריקות באופן אוטומטי את האישור של רשות האישורים במהלך יצירת התמונה. במקרה של תמונות קונטיינר מותאמות אישית, צריך לאחזר באופן מפורש את אישור ה-CA של השער, להתקין אותו במאגר האישורים המהימנים של ה-CA במערכת בתוך Dockerfile ולהגדיר את משתני הסביבה של חבילת האישורים שנדרשים על ידי ערכות ה-SDK של Python, ספריות לקוח HTTP ו-gRPC.

כדי להגדיר קובץ אימג' של קונטיינר BYOC לתעבורת נתונים יוצאת (egress) מ-Agent Gateway, פועלים לפי השלבים הבאים:

  1. אחזור אישורי הבסיס ממקור Agent Gateway.

    מייצאים את מחרוזת ה-PEM של אישור הבסיס של הרשות שמנפיקה את האישורים (CA) ישירות מהשדה agentGatewayCard.rootCertificates של משאב Agent Gateway:

    export AGW_CERT=$(gcloud network-services agent-gateways describe AGENT_GATEWAY_NAME \
   --location=REGION \
   --project=PROJECT_ID \
   --format="value[delimiter=\\n](agentGatewayCard.rootCertificates)")

    לחלופין, אפשר להשתמש ב-API בארכיטקטורת REST כדי לאחזר את משאב השער:

    curl -s -X GET \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   "https://networkservices.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME" \
   | jq -r '.agentGatewayCard.rootCertificates[]'

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

    • ‫AGENT_GATEWAY_NAME: השם של Agent Gateway ליציאה
    • ‫REGION: האזור שבו שער הרשת נפרס
    • ‫PROJECT_ID: מזהה הפרויקט

  2. כדי לתת אמון באישור ה-CA, צריך לעדכן את Dockerfile.

    מוסיפים את AGENT_GATEWAY_ROOT_CERTIFICATES build argument אל Dockerfile. פקודות ה-build מפצלות את האישורים לקבצים נפרדים, מתקינות אותם באמצעות update-ca-certificates ומגדירות משתני סביבה כדי ש-OpenSSL, ספריות לקוח של Python HTTP ‏ (requests, httpx) ו-gRPC יזהו את רשות האישורים המותאמת אישית:

    # Install root certificates under root user
USER root

ARG AGENT_GATEWAY_ROOT_CERTIFICATES
RUN if [ -n "$AGENT_GATEWAY_ROOT_CERTIFICATES" ]; then \
     echo "Installing Agent Gateway root certificates..."; \
     printf "%b" "$AGENT_GATEWAY_ROOT_CERTIFICATES" | awk 'BEGIN {c=0} /BEGIN CERTIFICATE/ {c++} c > 0 { print > "/usr/local/share/ca-certificates/agw-" c ".crt" }'; \
     update-ca-certificates; \
   fi

# Configure SSL/TLS trust paths for Python HTTP libraries, OpenSSL, and gRPC
ENV GRPC_DEFAULT_SSL_ROOTS_FILE_PATH=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt}
ENV REQUESTS_CA_BUNDLE=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt}
ENV SSL_CERT_FILE=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt}
ENV AGENT_GATEWAY_ROOT_CERT_302034098528=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt}

# Switch back to application execution user
USER 1000

  3. יוצרים את קובץ האימג' של הקונטיינר באמצעות Cloud Build.

    יוצרים קובץ cloudbuild.yaml כדי להעביר את מחרוזת אישור הבסיס ל-Cloud Build באמצעות החלפות:

    steps:
- name: 'gcr.io/cloud-builders/docker'
  args:
  - 'build'
  - '--build-arg'
  - 'AGENT_GATEWAY_ROOT_CERTIFICATES=${_AGW_CERT}'
  - '-t'
  - '$_IMAGE_URI'
  - '.'

images:
- '$_IMAGE_URI'

    שולחים את יצירת קובץ האימג' של הקונטיינר ל-Cloud Build:

    export IMAGE_URI="REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME:latest"

gcloud builds submit \
   --project=PROJECT_ID \
   --region=REGION \
   --config=cloudbuild.yaml \
   --substitutions=_IMAGE_URI="$IMAGE_URI",_AGW_CERT="$AGW_CERT" \
   .

    מחליפים את REPOSITORY_NAME ואת IMAGE_NAME בשמות המאגר והאימג' שלכם ב-Artifact Registry.

  4. פריסת הסוכן שמוכל ב-container.

    מציינים את ה-URI של קובץ האימג' של הקונטיינר שנוצר יחד עם ההגדרה של Agent Gateway בבקשת הפריסה (באמצעות agent_gateway_config בקטע spec.deploymentSpec או באמצעות קריאות לפריסת SDK).

הגבלת Agent Runtime ל-Agent Gateways מאושרים

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

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

בדוגמה הזו נוצרות אילוצים מותאמים אישית שמאפשרים תנועה רק אל רשימה שאושרה מראש של שערים וממנה.

Agent-to-Anywhere

  1. כדי להגדיר אילוץ מותאם אישית למצב Agent-to-Anywhere (יציאה), יוצרים קובץ בשם constraint-agent-gateway-egress.yaml.

    בדוגמה הבאה, השדה condition מציין שהפעולה מותרת רק אם צוין משאב של Agent Gateway (השדה קיים ולא ריק) ואם השער שצוין נמצא ברשימה שאושרה מראש.

    name: organizations/ORGANIZATION_ID/customConstraints/custom.allowlistedEgressAgentGatewaysForAgentEngine
resource_types:
- aiplatform.googleapis.com/ReasoningEngine
condition: >-
has(resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway) &&
resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway != '' &&
(resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway in [
  'projects/AGENT_PROJECT_ID_1/locations/REGION_1/agentGateways/AGENT_GATEWAY_ID_1',
  'projects/AGENT_PROJECT_ID_2/locations/REGION_2/agentGateways/AGENT_GATEWAY_ID_2',
])
method_types:
- CREATE
- UPDATE
action_type: ALLOW
display_name: Restrict Reasoning Engine Egress to Approved Agent Gateways
description: Reasoning Engines can only be bound to a pre-approved list of
Agent Gateway instances. Binding to any other gateway is denied.

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

    • ‫ORGANIZATION_ID: מזהה הארגון.
    • AGENT_PROJECT_ID: מזהה הפרויקט.
    • ‫REGION: האזור שבו נוצר שער.
    • ‫AGENT_GATEWAY_ID: מזהה השער.

  2. החלת האילוץ המותאם אישית.

    gcloud org-policies set-custom-constraint EGRESS_CONSTRAINT_PATH

    מחליפים את EGRESS_CONSTRAINT_PATH בנתיב המלא לקובץ האילוצים המותאמים אישית שנוצר בשלב הקודם.

  3. יוצרים את מדיניות הארגון כדי לאכוף את האילוץ. כדי להגדיר את מדיניות הארגון, יוצרים קובץ YAML של מדיניות בשם policy-agent-gateway-egress.yaml. בדוגמה הזו אנחנו אוכפים את האילוץ הזה ברמת הפרויקט, אבל אפשר גם להגדיר אותו ברמת הארגון או התיקייה.

    name: projects/AGENT_PROJECT_ID/policies/custom.allowlistedEgressAgentGatewaysForAgentEngine
spec:
  rules:
  - enforce: true

    מחליפים את AGENT_PROJECT_ID במזהה הפרויקט.

  4. אוכפים את מדיניות הארגון.

    gcloud org-policies set-policy EGRESS_POLICY_PATH

    מחליפים את EGRESS_POLICY_PATH בנתיב המלא לקובץ ה-YAML של מדיניות הארגון שנוצר בשלב הקודם. יכולות לעבור עד 15 דקות עד שהמדיניות תיכנס לתוקף.

לקוח לנציג

  1. כדי להגדיר אילוץ מותאם אישית למצב 'לקוח לסוכן' (ingress), יוצרים קובץ בשם constraint-agent-gateway-ingress.yaml.

    בדוגמה הבאה, השדה condition מציין שהפעולה מותרת רק אם צוין משאב של Agent Gateway (השדה קיים ולא ריק) ואם השער שצוין נמצא ברשימה שאושרה מראש.

    name: organizations/ORGANIZATION_ID/customConstraints/custom.allowlistedIngressAgentGatewaysForAgentEngine
resource_types:
- aiplatform.googleapis.com/ReasoningEngine
condition: >-
has(resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway) &&
resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway != '' &&
(resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway in [
  'projects/AGENT_PROJECT_ID_1/locations/REGION_1/agentGateways/AGENT_GATEWAY_ID_1',
  'projects/AGENT_PROJECT_ID_2/locations/REGION_2/agentGateways/AGENT_GATEWAY_ID_2',
])
method_types:
- CREATE
- UPDATE
action_type: ALLOW
display_name: Restrict Reasoning Engine Ingress to Approved Agent Gateways
description: Reasoning Engines can only be bound to a pre-approved list of
Agent Gateway instances. Binding to any other gateway is denied.

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

    • ‫ORGANIZATION_ID: מזהה הארגון.
    • AGENT_PROJECT_ID: מזהה הפרויקט.
    • ‫REGION: האזור שבו נוצר שער.
    • ‫AGENT_GATEWAY_ID: מזהה השער.

  2. החלת האילוץ המותאם אישית.

    gcloud org-policies set-custom-constraint INGRESS_CONSTRAINT_PATH

    מחליפים את INGRESS_CONSTRAINT_PATH בנתיב המלא לקובץ האילוצים המותאמים אישית שנוצר בשלב הקודם.

  3. יוצרים את מדיניות הארגון כדי לאכוף את האילוץ. כדי להגדיר את מדיניות הארגון, יוצרים קובץ YAML של מדיניות בשם policy-agent-gateway-ingress.yaml. בדוגמה הזו אנחנו אוכפים את האילוץ הזה ברמת הפרויקט, אבל אפשר גם להגדיר אותו ברמת הארגון או התיקייה.

    name: projects/AGENT_PROJECT_ID/policies/custom.allowlistedIngressAgentGatewaysForAgentEngine
spec:
  rules:
  - enforce: true

    מחליפים את AGENT_PROJECT_ID במזהה הפרויקט.

  4. אוכפים את מדיניות הארגון.

    gcloud org-policies set-policy INGRESS_POLICY_PATH

    מחליפים את INGRESS_POLICY_PATH בנתיב המלא לקובץ ה-YAML של מדיניות הארגון שנוצר בשלב הקודם. יכולות לעבור עד 15 דקות עד שהמדיניות תיכנס לתוקף.

מידע נוסף על שימוש באילוצים מותאמים אישית של מדיניות הארגון זמין במאמר יצירת אילוצים מותאמים אישית.

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

Codelab

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

מדריך

כאן מוסבר איך להאציל הרשאה ל-Agent Gateway ל-IAP, להגנה מוגברת על המודל או לשירות הרשאות מותאם אישית משלכם.

מדריך

איך עוקבים אחרי Agent Gateway

פתרון בעיות

כאן אפשר לקרוא על פתרון בעיות בקישוריות של Agent Gateway.