שליטה בעומסי עבודה אג'נטיים באמצעות Agent Gateway בפלטפורמת הסוכנים של Gemini Enterprise

1. מבוא

Gemini Enterprise Agent Platform היא פלטפורמה פתוחה ליצירה, להרחבה, לניהול ולאופטימיזציה של סוכני AI ברמה שמתאימה לארגונים, שמבוססים על הנתונים שלכם.

Agent Runtime מספק סביבת ביצוע מנוהלת להפעלת סוכנים, כמו אלה שנבנו באמצעות הערכה לפיתוח סוכנים (ADK) בקוד פתוח, בצורה מאובטחת ב-Google Cloud.

ב-Codelab הזה נסביר איך להשתמש באבני הבניין האלה כדי לשלוט בסוכן שהופעל על ידי משתמש ב-Gemini Enterprise, בזמן שהוא פונה בצורה מאובטחת לכלים פנימיים.

מידע על Agent Gateway

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

היא מאפשרת שתי דרכים עיקריות לגישה מבוקרת:

  • לקוח לסוכן (כניסה): מאבטח את התקשורת בין לקוחות חיצוניים (כמו Cursor או Gemini CLI) לבין הסוכנים שלכם.
  • Agent-to-Anywhere (יציאה): מאבטח את התקשורת בין סוכנים שפועלים ב-Google Cloud לבין שרתים, כלים או ממשקי API שפועלים בכל מקום.

ב-Codelab הזה נתמקד במצב Agent-to-Anywhere (יציאה).

בקרת גישה באמצעות Agent Gateway

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

  • Agent Registry: ספרייה מרכזית של סוכנים וכלים מאושרים (כולל שרתי MCP של צד שלישי).
  • זהות הסוכן: לכל סוכן יש פרסונה ייחודית שאפשר לעקוב אחריה, והיא מאובטחת אוטומטית באמצעות mTLS מקצה לקצה.
  • Identity-Aware Proxy (IAP) & IAM: שכבת האכיפה שמוגדרת כברירת מחדל ומאמתת את הזהות של הסוכן מול הרשאות IAM מפורטות לפני שהיא מאפשרת לבצע קריאות לכלים ספציפיים.
  • הגנה מוגברת על המודל: אמצעי הגנה מבוסס-AI שמשולב באמצעות Service Extensions כדי לנקות תוכן ולהגן מפני מתקפות שבהן מחדירים הנחיות או מפני דליפת נתונים.

מצבי פריסה (רשת ציבורית לעומת רשת פרטית ב-Cloud Run)

כדי להפוך את שיעור ה-Codelab הזה לנגיש, אתם יכולים לבחור בין שני נתיבי רשת לכלים הפנימיים (שרתי MCP) שפרסתם ב-Cloud Run:

  1. ברירת מחדל (כניסה ציבורית): שרתי ה-MCP נפרסים ב-Cloud Run עם שמות מארחים ציבוריים (ingress=all). התעבורה מנותבת מהסוכן אל הכלים באמצעות כתובות URL רגילות של *.run.app. לא נדרשים דומיינים של DNS בהתאמה אישית, וזו הדרך הכי מהירה ללמוד את מושגי השליטה.
  2. מאובטח (רשת פרטית): ארכיטקטורה אופציונלית ופרטית לחלוטין. הגישה לשרתי ה-MCP מוגבלת (ingress=internal-and-cloud-load-balancing) והם נחשפים דרך מאזן עומסים פנימי של אפליקציות עם Serverless NEG. כדי להקצות אישור שמנוהל על ידי Google, צריך להיות בבעלותכם דומיין DNS ציבורי.

תצטרכו לבחור את הנתיב המועדף כשמגדירים את Terraform.

כדי לקבל מידע נוסף על תעבורת נתונים נכנסת של נקודות קצה ברשת ל-Cloud Run, קראו את המסמכים שלנו.

הפעולות שתבצעו:

  • הקצאת משאבים של מחסנית תשתית הליבה באמצעות Terraform
  • פיתוח ופריסה של כלים פנימיים כשרתי MCP ב-Cloud Run
  • פריסת סוכן ADK ל-Agent Runtime באמצעות יציאה מממשק PSC
  • הגדרת תוספים לשירות Agent Gateway לגישה מבוססת-זהות (IAM) ולסינון תוכן (Model Armor)
  • מעקב אחר הביצוע המאובטח מקצה לקצה של הסוכן ואימותו

הדרישות

  • דפדפן אינטרנט כמו Chrome
  • פרויקט ב-Google Cloud שהחיוב בו מופעל ושיש לו גישת בעלים
  • הרשאות IAM ברמת הארגון (ה-codelab מעניק תפקידים בהיקף הארגון)
  • דומיין שאתם שולטים בו, שהוקצה ל-Cloud DNS (לצורך אישור מנוהל ציבורי)
  • היכרות עם Terraform,‏ gcloud ועם רשתות בסיסיות ב-Google Cloud

טופולוגיית Codelab

ארכיטקטורה מקצה לקצה: Gemini Enterprise ל-Agent Runtime ל-Agent Gateway לשרתי MCP ב-Cloud Run

ב-Codelab הזה תפרסו סוכן חיתום משכנתאות מקצה לקצה שמתקשר בצורה מאובטחת עם שלושה כלים פנימיים.

תתחילו בהקצאת משאבים לרשת הבסיסית, כולל VPC ומאזן עומסים של אפליקציות (ALB) פנימי שהוגדר כ-Agent Gateway. לאחר מכן, תפרסו שלושה שרתים של Model Context Protocol‏ (MCP) ב-Cloud Run. הכלים האלה משמשים ככלים פנימיים קנייניים:

  • ניהול מסמכים (legacy-dms)
  • אימייל ארגוני (corporate-email)
  • אימות הכנסה (income-verification)

אחרי שתגדירו את הכלים, תפרסו את עוזר המשכנתאות (mortgage-agent) שנבנה באמצעות ADK ב-Agent Runtime. תגדירו את הסוכן הזה כך שישתמש בממשק PSC לתעבורת נתונים יוצאת פרטית, ותפעילו את האפשרות לאיתור כלי בזמן ריצה באמצעות Agent Registry.

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

לבסוף, תרשמו את הסוכן ב-Gemini Enterprise, תפעילו משימת חיתום משכנתא כמשתמשי קצה ותאמתו את הביצוע המאובטח והמבוקר באמצעות Cloud Trace.

ה-Codelab הזה מיועד למהנדסי פלטפורמה ואבטחה בכל הרמות. השלמת התהליך צפויה להימשך כ-100 דקות.

‫2. לפני שמתחילים

יצירת פרויקט ואימות

יוצרים פרויקט חדש ב-GCP (או משתמשים בפרויקט קיים) עם חיוב מופעל, ואז מאמתים את Cloud Shell או את המחשב המקומי:

gcloud auth login
gcloud auth application-default login
gcloud config set project <your-project-id>

הפעלת ממשקי API של bootstrap

מודול הבסיס של Terraform מאפשר להשתמש ב-30 ממשקי API בערך בהפעלה הראשונה, אבל נדרש סט קטן של אתחול ל-terraform init ולמאגר המידע של GCS:

gcloud services enable \
  compute.googleapis.com \
  serviceusage.googleapis.com \
  cloudresourcemanager.googleapis.com \
  iam.googleapis.com \
  storage.googleapis.com \
  dns.googleapis.com

התקנת הכלים הנדרשים

מתקינים את ערכת הכלים. ב-Cloud Shell, רוב הפקודות האלה כבר קיימות. בתחנת עבודה:

# uv (Python package manager)
curl -LsSf https://astral.sh/uv/install.sh | sh

# skaffold
curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64 && \
  sudo install skaffold /usr/local/bin/

# envsubst (gettext)
sudo apt-get install -y gettext-base

צריך גם Terraform >= 1.12.2,‏ Python 3.12+‎ ו-Google Cloud SDK ‏ (gcloud).

הגדרה של משתני סביבה

בהמשך ה-codelab מניחים שהקבצים האלה מיוצאים למעטפת.

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
export ORG_ID=$(gcloud projects get-ancestors $PROJECT_ID | awk '$2 == "organization" {print $1}')
export REGION="us-central1"

# Only required if using the secure private networking path
export DOMAIN_NAME="agw.example.com" 

מוודאים שכל המשתנים מאוכלסים בצורה נכונה. אמורים להיות שלושה ערכים שמוחזרים.

echo $PROJECT_ID  
echo $PROJECT_NUMBER
echo $ORG_ID

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

gcloud organizations list
export ORG_ID=ID_FROM_OUTPUT

3. שכפול המאגר

git clone https://github.com/GoogleCloudPlatform/cloud-networking-solutions.git
cd cloud-networking-solutions
cd demos/agent-gateway

סיור מהיר בתיקיית ההדגמה:

src/                MCP servers (legacy-dms, corporate-email, income-verification-api) + mortgage-agent
terraform/          Root Terraform config + modules (foundation, networking, agent-gateway, model-armor, ...)
cloudrun/           Cloud Run service definitions (rendered from .yaml.tmpl via envsubst)
scripts/            grant_agent_mcp_egress.sh — per-MCP IAP egressor binding
skaffold.yaml.tmpl  Skaffold pipeline that builds + deploys all three MCP services to Cloud Run

4. יצירת קטגוריית אחסון של מצב Terraform והגדרת הקצה העורפי

יוצרים קטגוריה ב-GCS לאחסון המצב במיקום מרוחק, ואז מעתיקים את תבנית ה-backend:

gcloud storage buckets create gs://${PROJECT_ID}-tfstate \
  --location=${REGION} \
  --uniform-bucket-level-access

cp terraform/example.backend.conf terraform/backend.conf

עורכים את terraform/backend.conf עם הערכים שלכם:

bucket = "<your-project-id>-tfstate"
prefix = "agent-gateway"

5. (אופציונלי) יצירת תחום ציבורי ב-Cloud DNS

כברירת מחדל, במעבדה הזו, הגדרת הכניסה של Cloud Run מוגדרת ל-all, ו-Agent Registry רושם כל שרת MCP בכתובת ה-URL הציבורית שלו *.run.app – לא נדרשים DNS, אישורים או מאזן עומסים נוספים. אם רוצים לעבור לרשת פרטית (Cloud Run עם ingress = internal-and-cloud-load-balancing מאחורי איזון עומסים פנימי של אפליקציות), צריך גם תחום DNS ציבורי ב-Cloud DNS כדי ש-Certificate Manager יוכל לאמת את אישור איזון העומסים.

תרשים זרימה ברמה גבוהה של רשתות פרטיות

תרשים זרימה ברמה גבוהה של אפשרות הרשת הפרטית

כדי להשתמש בגישה לרשת פרטית:

  1. יוצרים את תחום ה-DNS הציבורי של Cloud DNS – Certificate Manager מאמת את האישור האזורי המנוהל על ידי כתיבת רשומות CNAME לתוכו:
gcloud dns managed-zones create agw-example-com \
  --dns-name="${DOMAIN_NAME}." \
  --description="Public zone for ${DOMAIN_NAME}" \
  --visibility=public

אזור פרטי תואם ל-mcp.${DOMAIN_NAME} (שמשמש את איזון העומסים הפנימי של MCP ואת ה-DNS peering מ-Agent Runtime) נוצר באופן אוטומטי על ידי Terraform – אין צורך ליצור אותו באופן ידני. אם הרשת הפרטית מושבתת, לא מוקצים אזורים ציבוריים או פרטיים.

6. הגדרת משתני Terraform

מעתיקים את הקובץ לדוגמה tfvars ועורכים אותו:

cp terraform/example.tfvars terraform/terraform.tfvars

יש שתי דרכים להגיע להדגמה, והן מוגבלות על ידי enable_cloud_run_private_networking.

נתיב ברירת מחדל: Cloud Run עם תעבורת נתונים נכנסת ציבורית

ההגדרה הכי פשוטה: בנתיב ברירת המחדל צריך לערוך רק שלושה ערכים ב-terraform.tfvars. לכל שאר המשתנים בקובץ כבר יש ערך ברירת מחדל שמתאים להדגמה.

# GCP project ID where all resources will be created.
project_id = "my-gcp-project-id"

# GCP organization ID (numeric).
organization_id = "123456789012"

# Members granted demo-wide roles
platform_admin_members = ["user:admin@example.com"]

# IAP Enforcement Mode ("DRY_RUN" or null)
agent_gateway_iap_iam_enforcement_mode = "DRY_RUN"

רשת פרטית (אופציונלי)

מגדירים את enable_cloud_run_private_networking = true ומוסיפים את המשתנים הבאים כדי להקצות את מחסנית האבטחה המלאה:

  • מאזן עומסים פנימי של אפליקציות (ALB)
  • אישור שמנוהל על ידי Google
  • ‫Cloud Run עם ingress = internal-and-cloud-load-balancing
  • קישור DNS בין רשתות שכנות (peering) של Agent Gateway.
enable_cloud_run_private_networking = true

# DNS — must end with a trailing dot, must match a Cloud DNS zone you own
dns_zone_domain            = "agw.example.com."
enable_certificate_manager = true

# mcp_internal_dns_zone.domain MUST be a real subdomain of dns_zone_domain so
# Certificate Manager can issue a Google-managed cert.
mcp_internal_dns_zone = {
  name   = "mcp-server-internal"
  domain = "mcp.agw.example.com."
}

# Must match mcp_internal_dns_zone.domain so Agent Engine resolves MCP
# hostnames over the PSC interface peering.
psc_interface_dns_zone = {
  name   = "mcp-server-internal"
  domain = "mcp.agw.example.com."
}

mcp_lb_protocol = "HTTPS"

7. פריסת תשתית באמצעות Terraform

אתחול, בדיקה והחלה:

cd terraform
terraform init -backend-config=backend.conf
terraform plan -out=tfplan
terraform apply tfplan

terraform apply מספקת כ-40 משאבים בנתיב ברירת המחדל, והתהליך נמשך 8-10 דקות בפרויקט חדש (כ-60 משאבים / 15-20 דקות כש-enable_cloud_run_private_networking = true). היא יוצרת:

  • הבסיס של הפרויקט (ממשקי API, זהויות שירות, מכסות)
  • VPC, רשתות משנה (ראשיות, proxy-only, ‏ PSC, ‏ PSC-Interface, ‏ Agent Gateway co-location), ‏ Cloud NAT, כללים של חומת אש
  • מאגר Artifact Registry לתמונות Cloud Run
  • שלושה שירותי Cloud Run + חשבונות שירות של זמן ריצה לכל שירות (תעבורת כניסה = all כברירת מחדל; internal-and-cloud-load-balancing כשמופעלת רשת פרטית)
  • תבנית של הגנה מוגברת על המודל + IAM
  • ‫Agent Gateway, ‏ PSC-I network attachment, ‏ IAP ו-Model Armor extensions, ‏ both authorization policies, ‏ and the project-level roles/iap.egressor grant
  • נקודות קצה של Agent Registry ‏ (Vertex AI, ‏ IAP, ‏ Discovery Engine וכו') בתוספת שלושת שרתי ה-MCP (שנרשמים ב-*.run.app/mcp כברירת מחדל, וב-./mcp כשהרשת הפרטית מופעלת)

רק כשenable_cloud_run_private_networking = true:

  • מאזן עומסים אזורי פנימי של אפליקציות עם NEG ללא שרת (ניתוב של מיסוך כתובות URL) + רשומות DNS פרטיות מסוג A
  • תחום DNS פרטי של MCP ‏ (mcp..) שמצורף ל-VPC
  • מודול של תחום DNS ציבורי (הרשאות DNS ב-Certificate Manager) + אישור אזורי שמנוהל על ידי Google
  • תחום DNS של ממשק PSC (יתום כשאין שמות מארחים פרטיים לפענוח, ולכן הוא מוגבל גם על ידי דגל האב)
  • Agent Gateway DNS peering for mcp.. (auto-prepended)

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

‫Agent Registry הוא קטלוג של שירותים (ממשקי Google API ושרתי MCP משלכם) שסוכן מגלה בזמן ריצה. הקטלוג הזה הוא ספציפי לכל פרויקט. סוכן המשכנתאות קורא את הקובץ הזה בהפעלה ומקשר כלים באופן דינמי – כתובות ה-URL של MCP לא מוטמעות בקוד של הסוכן או בפקודת הפריסה שלו.

נקודות קצה

מה Terraform הפעיל בשמכם – לכל Google API ב-agent_registry_google_apis, הוא רשם חמש גרסאות (גלובלית, גלובלית mTLS, אזורית, אזורית mTLS, אזורית REP). לדוגמה, עבור aiplatform:

gcloud alpha agent-registry services create aiplatform \
  --project=${PROJECT_ID} --location=${REGION} \
  --display-name="Vertex AI Platform" \
  --endpoint-spec-type=no-spec \
  --interfaces="url=https://aiplatform.googleapis.com,protocolBinding=JSONRPC"

gcloud alpha agent-registry services create aiplatform-mtls \
  --project=${PROJECT_ID} --location=${REGION} \
  --display-name="Vertex AI Platform mTLS" \
  --endpoint-spec-type=no-spec \
  --interfaces="url=https://aiplatform.mtls.googleapis.com,protocolBinding=JSONRPC"

gcloud alpha agent-registry services create ${REGION}-aiplatform \
  --project=${PROJECT_ID} --location=${REGION} \
  --display-name="Vertex AI Platform Locational" \
  --endpoint-spec-type=no-spec \
  --interfaces="url=https://${REGION}-aiplatform.googleapis.com,protocolBinding=JSONRPC"

gcloud alpha agent-registry services create aiplatform-${REGION}-rep \
  --project=${PROJECT_ID} --location=${REGION} \
  --display-name="Vertex AI Platform Regional (REP)" \
  --endpoint-spec-type=no-spec \
  --interfaces="url=https://aiplatform.${REGION}.rep.googleapis.com,protocolBinding=JSONRPC"

שרתי MCP

בנוסף, Terraform רושם בשבילכם את 3 שרתי ה-MCP. כדי לרשום שרתי MCP אחרים, אפשר לפעול לפי השלבים במסמכי התיעוד.

gcloud alpha agent-registry services create legacy-dms \
--project=${PROJECT_ID} \
--location=${REGION} \
--display-name="Legacy DMS" \
--mcp-server-spec-type=tool-spec \
--mcp-server-spec-content=src/legacy-dms/toolspec.json \
--interfaces=url=https://dms.${DOMAIN_NAME}/mcp,protocolBinding=JSONRPC

מאמתים את נקודות הקצה ואת שרתי ה-MCP הרשומים.

gcloud alpha agent-registry services list \
  --project=${PROJECT_ID} --location=${REGION} \
  --format="value(displayName,name)"

gcloud alpha agent-registry mcp-servers list \
  --project=${PROJECT_ID} --location=${REGION} \
  --format="value(displayName,name)"

מקור: terraform/modules/agent-registry-endpoints/scripts/register_endpoints.sh.tpl

9. בדיקת ההגדרה של שער הסוכן

Agent Gateway הוא מישור ניהול שמנוהל על ידי Google בין Agent Runtime לבין הכלים שלכם. במצב AGENT_TO_ANYWHERE הוא קשור ל-Agent Registry של הפרויקט, והתעבורה היוצאת שלו עוברת דרך ממשק PSC בבעלות הלקוח, כדי שיוכל להגיע לשרתי MCP פרטיים ב-VPC שלכם.

אם היית מייבא את שער התשלומים הזה באופן ידני, קובץ ה-YAML היה נראה כך:

# agent-gateway.yaml  for reference only, Terraform already created this
name: agent-gateway
protocols: [MCP]
googleManaged:
  governedAccessPath: AGENT_TO_ANYWHERE
registries:
  - "//agentregistry.googleapis.com/projects/${PROJECT_ID}/locations/${REGION}"
networkConfig:
  egress:
    networkAttachment: projects/${PROJECT_ID}/regions/${REGION}/networkAttachments/agent-gateway-na
  dnsPeeringConfig:
    domains:
      - mcp.${DOMAIN_NAME}.
    targetProject: ${PROJECT_ID}
    targetNetwork: projects/${PROJECT_ID}/global/networks/gateway-vpc
gcloud alpha network-services agent-gateways import agent-gateway \
  --source=agent-gateway.yaml \
  --location=${REGION}

בודקים את השער שנוצר על ידי Terraform:

gcloud alpha network-services agent-gateways describe agent-gateway \
  --location=${REGION}

10. בדיקת הרשאות ב-IAP וב-הגנה מוגברת על המודל

Agent Gateway מעביר את ההרשאה לתוספי שירות. שני פרופילי מדיניות מכסים את ההדגמה:

  • REQUEST_AUTHZ – מוערך פעם אחת לכל בקשה בשלב הכותרות. הפרמטר הזה משמש כאן כדי לקרוא ל-IAP, שבודק אם לזהות של הסוכן המבצע את הקריאה יש את ההרשאה roles/iap.egressor בשרת היעד של MCP.
  • CONTENT_AUTHZ – מעביר אירועים של גוף הזרם לתוסף לצורך ניקוי התוכן. הוא משמש כאן לקריאה ל-Model Armor, שמסנן החדרת הנחיות, פריצות, הפרות של RAI ו(אופציונלית) פרטים אישיים מזהים (PII) באמצעות Sensitive Data Protection (הגנה על מידע אישי רגיש, SDP).

תוסף IAP REQUEST_AUTHZ

cat > iap-authz-extension.yaml <<EOF
name: agent-gateway-iap-authz
service: iap.googleapis.com
failOpen: true
timeout: 1s
EOF

gcloud beta service-extensions authz-extensions import agent-gateway-iap-authz \
  --source=iap-authz-extension.yaml \
  --location=${REGION} \
  --project=${PROJECT_ID}

מקשרים אותו ל-Agent Gateway באמצעות מדיניות REQUEST_AUTHZ:

curl -fsS -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -X POST "https://networksecurity.googleapis.com/v1alpha1/projects/${PROJECT_ID}/locations/${REGION}/authzPolicies?authz_policy_id=agent-gateway-iap-policy" \
  -d '{
    "name": "agent-gateway-iap-policy",
    "policyProfile": "REQUEST_AUTHZ",
    "action": "CUSTOM",
    "target": {
      "resources": [
        "projects/'"${PROJECT_ID}"'/locations/'"${REGION}"'/agentGateways/agent-gateway"
      ]
    },
    "customProvider": {
      "authzExtension": {
        "resources": [
          "projects/'"${PROJECT_ID}"'/locations/'"${REGION}"'/authzExtensions/agent-gateway-iap-authz"
        ]
      }
    }
  }'

תוסף הגנה מוגברת על המודל CONTENT_AUTHZ

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

cat > ma-extension.yaml <<EOF
name: agent-gateway-ma-authz
service: modelarmor.${REGION}.rep.googleapis.com
failOpen: true
timeout: 1s
metadata:
  model_armor_settings: '[
    {
      "request_template_id":  "projects/${PROJECT_ID}/locations/${REGION}/templates/agw-request-template",
      "response_template_id": "projects/${PROJECT_ID}/locations/${REGION}/templates/agw-response-template"
    }
  ]'
EOF

gcloud beta service-extensions authz-extensions import agent-gateway-ma-authz \
  --source=ma-extension.yaml \
  --location=${REGION} \
  --project=${PROJECT_ID}
curl -fsS -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -X POST "https://networksecurity.googleapis.com/v1alpha1/projects/${PROJECT_ID}/locations/${REGION}/authzPolicies?authz_policy_id=agent-gateway-ma-policy" \
  -d '{
    "name": "agent-gateway-ma-policy",
    "policyProfile": "CONTENT_AUTHZ",
    "action": "CUSTOM",
    "target": {
      "resources": [
        "projects/'"${PROJECT_ID}"'/locations/'"${REGION}"'/agentGateways/agent-gateway"
      ]
    },
    "customProvider": {
      "authzExtension":