שילוב של הגנה מוגברת על המודל עם Agent Gateway

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

כש-Model Armor מזהה הפרות של מדיניות בתוכן שעובר דרך Agent Gateway, אפשר להגדיר אותו כך שיתעד את האירועים האלה. אפשר לראות את הממצאים האלה בדף הגנה מוגברת על המודל במסוף Google Cloud (כניסה להגנה מוגברת על המודל). הממצאים האלה מוצגים גם ב-Security Command Center. מידע נוסף זמין במאמר בדיקת הממצאים במסוףGoogle Cloud .

כשמשתמשים במצב סטרימינג בזמן אמת, Model Armor תומך בטוקנים ללא הגבלה בסטרימינג, ולכן הוא מתאים לאינטראקציות ארוכות ולתשובות של מודלים.

מגבלות

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

  • תמיכה בהעברה בסטרימינג לסוכנים: Model Armor תומך רק בהעברה בסטרימינג של חיטוי באמצעות השיטה streamQuery לסוכנים שנבנו באמצעות ערכת פיתוח הסוכנים (ADK).
  • שימוש בתבנית בפרויקטים שונים: כשמשתמשים בתבנית של Model Armor בפרויקט אחד כדי לנקות בקשות לשירות, כמו Agent Gateway, בפרויקט אחר, מכסת ה-API של Model Armor צריכה להיות מספיקה גם בפרויקט שמארח את התבנית וגם בפרויקט שמארח את שירות הקריאה. איך מנהלים את המכסות
  • התאמה אזורית: צריך לפרוס את הגנה מוגברת על המודל ואת השירותים שהוא משתלב איתם באותו אזור Google Cloud . אין תמיכה בשיחות חוצות אזורים אל Model Armor.
  • תאימות לשילוב יציאה: ההגנה המובנית של Model Armor על תעבורת נתונים יוצאת מוגבלת לשילובים עם שרתי MCP, שירותים שפועלים לפי הפורמט של OpenAI ו-A2A דרך Agent Gateway.
  • תאימות לשילוב Ingress: הגנה מוטמעת על Ingress באמצעות Model Armor נתמכת רק בסוכנים שנוצרו באמצעות ADK.
  • אין תמיכה במסמכים: אי אפשר להשתמש באינטגרציה הזו כדי לנקות הנחיות ותשובות שמכילות מסמכים או קבצים שהועלו (כמו קובצי PDF). כדי לסרוק מסמכים, קוראים ישירות ל-Model Armor REST API.
  • מטען ייעודי (payload) נתמך: רשימת המטענים הייעודיים הנתמכים מופיעה במאמר הזה.

הגדרת הגנה מוגברת על המודל בשער

כדי להגדיר את Model Armor בשער, מבצעים את השלבים הבאים:

  1. מפעילים את Model Armor API בפרויקט שבו רוצים ליצור את תבניות Model Armor.

  2. יוצרים תבנית אחת או יותר של הגנה מוגברת על המודל באותו אזור שבו מתכננים להוסיף את השער. אפשר להשתמש באותה תבנית גם לתעבורת נתונים נכנסת (ingress) וגם לתעבורת נתונים יוצאת (egress).

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

  3. מגדירים את Agent Gateway באותו אזור שבו מאוחסנות תבניות הגנה מוגברת על המודל. בשביל השער Client-to-Agent (ingress) ‎, מציינים את התבניות של Model Armor שיצרתם לתנועת נכנסת. בשדה Agent-to-Anywhere (egress) gateway (שער יציאה של סוכן), מציינים את תבניות Model Armor שיצרתם לתעבורת יציאה. אפשר להשתמש באותו תבנית לשני סוגי התנועה.

  4. מקצים את תפקידי ה-IAM הנדרשים לסוכני השירות המתאימים:

    • מלקוח לסוכן (כניסה): מעניקים לסוכן השירות AI Platform Reasoning Engine Service Agent את התפקידים הבאים:

      • התפקיד Model Armor Callout User (roles/modelarmor.calloutUser) בפרויקט שמכיל את סוכן ה-AI.

      • התפקיד Model Armor User (roles/modelarmor.user) בפרויקט שמכיל את תבנית Model Armor.

      gcloud projects add-iam-policy-binding AGENT_RUNTIME_PROJECT_ID \
    --member=serviceAccount:service-AGENT_RUNTIME_PROJECT_NUMBER@gcp-sa-aiplatform-re.iam.gserviceaccount.com \
    --role=roles/modelarmor.calloutUser
gcloud projects add-iam-policy-binding MODEL_ARMOR_PROJECT_ID \
    --member=serviceAccount:service-AGENT_RUNTIME_PROJECT_NUMBER@gcp-sa-aiplatform-re.iam.gserviceaccount.com \
    --role=roles/modelarmor.user

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

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

    • Agent-to-Anywhere (יציאה): מקצים לסוכן השירות Service Extensions את התפקידים הבאים:

      • התפקידים Model Armor Callout User ‏ (roles/modelarmor.calloutUser) ו-Service Usage Consumer ‏ (roles/serviceusage.serviceUsageConsumer) בפרויקט שמכיל את השער.
      • התפקיד Model Armor User (roles/modelarmor.user) בפרויקט שמכיל את תבנית Model Armor.
      gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/modelarmor.calloutUser
gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/serviceusage.serviceUsageConsumer
gcloud projects add-iam-policy-binding MODEL_ARMOR_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/modelarmor.user

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

      • ‫GATEWAY_PROJECT_ID: מזהה הפרויקט שבו יצרתם את שער הגישה.
      • ‫GATEWAY_PROJECT_NUMBER: מספר הפרויקט שבו יצרתם את שער הנתונים.
      • ‫MODEL_ARMOR_PROJECT_ID: מזהה הפרויקט שמכיל את תבנית הגנה מוגברת על המודל.

      הוראות מפורטות מופיעות במאמר בנושא העברת הרשאה ל-Model Armor.

    מידע כללי על הקצאת תפקידים מופיע במאמר הקצאת תפקיד יחיד ב-IAM.

תעבורת נתונים נכנסת (ingress) ויוצאת (egress)

בהקשר של שילוב Agent Gateway ו-Model Armor, המונחים כניסה ויציאה מתייחסים לאינטראקציות של סוכן ה-AI:

  • תנועת נכנסת (מלקוח לסוכן): מתייחסת לזרימת התקשורת בין לקוח לסוכן. התכונה Model Armor יכולה להגן גם על הבקשות הנכנסות מהלקוח לסוכן וגם על התשובות היוצאות מהסוכן בחזרה ללקוח.
  • תעבורת נתונים יוצאת (egress) (מהסוכן לכל מקום): מתייחסת לזרימת התקשורת בין הסוכן למערכת חיצונית. ‫הגנה מוגברת על המודל יכולה להגן גם על הבקשות היוצאות מהסוכן למערכת החיצונית וגם על התשובות הנכנסות מהמערכת החיצונית בחזרה לסוכן.

הגנה על תעבורה מלקוח לסוכן (ingress)

אתם מגדירים תבניות שמשמשות את Model Armor להערכה של:

  • בקשות נכנסות מהלקוח (משתמשי קצה או אפליקציות שמתקשרות) לסוכן ה-AI.
  • תשובות יוצאות מסוכן ה-AI בחזרה ללקוח.

אפשר להחיל תבנית אחת על שני הכיוונים או להגדיר תבניות שונות לכל כיוון.

זרימת התנועה מלקוח לנציג

  1. לקוח שולח הנחיה לסוכן. הסוכן Agent Gateway מיירט את הבקשה ושולח את המטען הייעודי (payload) אל Model Armor.
  2. ההגנה המוגברת על המודל בודקת את הבקשה. אם החסימה מתבצעת, הלקוח מקבל שגיאה.
  3. אם הבקשה מורשית, היא מגיעה לסוכן ה-AI.
  4. סוכן ה-AI יוצר תשובה. Agent Gateway מיירט את התגובה הזו לפני שהיא מגיעה ללקוח.
  5. ‫Model Armor בודק את התגובה, ו-Agent Gateway מאשר או חוסם אותה בהתאם לתוצאות הבדיקה.

הגנה על תעבורה מסוכנים לכל מקום (יציאה)

אתם מגדירים תבניות שמשמשות את Model Armor להערכה של:

  • בקשות יוצאות מסוכן ה-AI שלכם למערכות חיצוניות.
  • תשובות נכנסות ממערכות חיצוניות לסוכן ה-AI.

ההגנה הזו חלה על תקשורת עם מערכות, כולל:

  • מודלים גדולים של שפה (LLM) חיצוניים וסוכני AI של צד שלישי
  • שרתים של Model Context Protocol‏ (MCP)
  • סוכני AI אחרים

זרימת התנועה ב-Agent-to-Anywhere

  1. סוכן ה-AI יוזם בקשה למערכת חיצונית. Agent Gateway מיירט את התנועה היוצאת.
  2. ההגנה המוגברת על המודל סורקת את המטען הייעודי (payload) היוצא. אם החיבור חסום, הוא מופסק.
  3. אם הבקשה מורשית, היא נשלחת למערכת החיצונית.
  4. המערכת החיצונית שולחת תגובה. ‫Agent Gateway מיירט את התגובה הנכנסת.
  5. ‫Model Armor בודק את מטען התשובה, ו-Agent Gateway מאפשר לו להגיע לסוכן או חוסם אותו.

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

מעקב אחרי בקשות סטרימינג וניפוי באגים

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

שימוש במזהה מעקב

מזהה מעקב מקשר בין כל האירועים של בקשה יחידה כשהיא עוברת בין כמה שירותים במערכת מבוזרת. זה כולל את אמצעי האבטחה ש-Model Armor מחיל בנתיב הבקשה של משאב Agent Gateway.

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

יש שני סוגים של מזהי מעקב:

  • אוטומטי: כש-Google Cloud Observability מופעל, Agent Gateway יוצר באופן אוטומטי מזהה מעקב ומפיץ אותו במערכת.

  • פרטים שהמשתמשים סיפקו: אתם יכולים לשנות את מזהה העקבות שנוצר על ידי המערכת על ידי אספקת מזהה משלכם באמצעות כותרת ה-HTTP של traceparent בבקשות.

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

    curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -H "traceparent: 00-98adffecc8dd095968a06c44216190f6-5b565a8342378cd7-01" \
  "https://LOCATION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/reasoningEngines/REASONING_ENGINE_ID:streamQuery?alt=sse"

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

    • ‫LOCATION: האזור שבו ממוקם מנוע הנימוקים.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫REASONING_ENGINE_ID: המזהה של מנוע הנימוקים.

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

כדי לראות את היומנים של פעולות הסרת מידע אישי עבור מזהה מעקב ספציפי, משתמשים בשאילתה הבאה ב-Logs Explorer:

jsonPayload.@type="type.googleapis.com/google.cloud.modelarmor.logging.v1.SanitizeOperationLogEntry"
trace:TRACE_ID

מחליפים את TRACE_ID במזהה המעקב של הבקשה.

שימוש במזהה קורלציה

מזהה קורלציה מקשר בין כל הרשומות ביומן ב-Cloud Logging שקשורות לסשן יחיד של ניקוי נתונים בסטרימינג, מהבקשה הראשונית ועד לתגובה הסופית. זהו מזהה פנימי שמשמש בעיקר ביומנים של Model Armor, במיוחד עבור הפעלות של סטרימינג של תעבורת נתונים נכנסת. מידע נוסף זמין במאמר הצלבת נתונים מיומנים ומאירועים קשורים.

מטען ייעודי (payload) נתמך ומטען ייעודי לא נתמך

בקטע הזה מפורטים סוגי המטענים הייעודיים (payloads) ש-Model Armor מנקה.

תנועת גולשים (ingress) מלקוח לנציג

בתנועה מלקוח לסוכן (ingress) באמצעות פרוטוקול ADK,‏ הגנה מוגברת על המודל מבצע סניטציה רק של בקשות ותשובות של reasoningEngines.streamQuery לסוכנים שנוצרו באמצעות ערכה לפיתוח סוכנים (ADK) ופועלים ב-Agent Runtime.

כל שאר המטענים הייעודיים (payloads) של ReasoningEngine ותגובות השגיאה של ReasoningEngine לא נשלחים אל Model Armor. גם מטען ייעודי (payload) שאינו ADK (כמו מטען ייעודי של Langchain) לא נשלח להגנה מוגברת על המודל.

תעבורת נתונים (יוצאת) מסוכן לכל מקום

במקרה של תנועה מ-Agent-to-Anywhere (יציאה), המטענים הייעודיים (payloads) הבאים נתמכים.

מטענים ייעודיים (payloads) של A2A

‫Model Armor מנקה רק את המטענים הייעודיים (payloads) הבאים של פרוטוקול A2A v1:

‫Model Armor מאפשר את המטענים הייעודיים (payloads) הבאים של A2A ללא ניקוי:

מטענים ייעודיים (payloads) של MCP

‫Model Armor מנקה רק את מטען הנתונים (payload) הבא של MCP:

  • בקשת tools/call ותגובה
  • בקשת prompts/get ותגובה
  • שגיאות בהרצת כלי ה-MCP (יעד להחדרת הנחיות על ידי יוצרים זדוניים של כלי MCP)

התכונה הגנה מוגברת על המודל מאפשרת את מטען הייעודי (payload) הבא ללא ניקוי:

  • tools/list
  • resources/*
  • notifications/*
  • ‫HTTP/SSE שניתן להזרמה עבור MCP
  • שגיאות בפרוטוקול MCP (לדוגמה, כל השגיאות מלבד שגיאות בהרצת כלי)

מטענים ייעודיים (payloads) של מודלים חיצוניים של שפה גדולה (LLM)

‫הגנה מוגברת על המודל מנקה רק את המטענים הייעודיים (payloads) הבאים של פרוטוקול OpenAI API (תעבורת נתונים יוצאת), שכולל מודלים של GPT ב-openai.com וגם מודלים אחרים דרך שרתי LLM שתואמים ל-OpenAI API (כמו vLLM). מותר להשתמש במטענים ייעודיים (payloads) שלא מופיעים כאן בלי לבצע בהם ניקוי.