שילוב של הגנה מוגברת על המודל עם 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, אפשר להגדיר שהאירועים האלה יתועדו ביומן. אפשר לראות את הממצאים האלה בדף Model Armor במסוף Google Cloud (כניסה לדף Model Armor). הממצאים האלה מוצגים גם ב-Security Command Center. מידע נוסף זמין במאמר בדיקת הממצאים במסוףGoogle Cloud .

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

מגבלות

כשמשלבים את Model Armor עם Agent Gateway, חשוב לזכור את המגבלות הבאות:

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

הגדרת Model Armor בשער

כדי להגדיר את Model Armor בשער:

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

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

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

    אם אתם יוצרים את התבניות של Model Armor בפרויקט שונה מהפרויקט שמכיל את סוכן ה-AI או את Agent Gateway, ואתם משתמשים ב-VPC Service Controls, שני הפרויקטים צריכים להיות באותם גבולות גזרה לשירות של VPC Service Controls.

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

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

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

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

      • התפקיד "משתמש ב-Model Armor"‏ (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: מזהה הפרויקט שמכיל את התבנית של Model Armor.

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

      • התפקידים Model Armor Callout User‏ (roles/modelarmor.calloutUser) ו-Service Usage Consumer‏ (roles/serviceusage.serviceUsageConsumer) בפרויקט שמכיל את השער.
      • התפקיד "משתמש ב-Model Armor"‏ (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.

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

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

תנועה נכנסת ויוצאת

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

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

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

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

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

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

זרימת התנועה מלקוח לסוכן

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

הגנה על נתונים שיוצאים מהסוכן (egress)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    דוגמת הקוד הבאה מראה איך להעביר מזהה מעקב בהתאמה אישית בבקשה ל-method‏ 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, במיוחד לסשנים של סטרימינג נכנס. מידע נוסף זמין במאמר התאמה בין יומנים לאירועים קשורים.

מטענים ייעודיים נתמכים ולא נתמכים

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

תנועה מהלקוח לסוכן (נכנסת)

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

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

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

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

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

הגנה מוגברת על המודל מסירה תוכן זדוני או רגיש רק מהמטענים הייעודיים הבאים של פרוטוקול A2A בגרסה 1:

הגנה מוגברת על המודל מאפשרת את המטענים הייעודיים הבאים של A2A בלי הסרת תוכן זדוני או רגיש:

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

‫Model Armor מסיר תוכן זדוני או רגיש רק מהמטענים הייעודיים הבאים של MCP:

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

הגנה מוגברת על המודל מאפשרת את המטענים הייעודיים הבאים ללא הסרת תוכן זדוני או רגיש:

  • tools/list
  • resources/*
  • notifications/*
  • ‫Streamable HTTP/SSE ל-MCP
  • שגיאות בפרוטוקול MCP (לדוגמה, כל השגיאות חוץ משגיאות בהפעלת הכלים)

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

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