שילוב של הגנה מוגברת על המודל עם 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, חשוב להביא בחשבון את המגבלות הבאות:

  • תמיכה בסטרימינג לסוכנים: הגנה מוגברת על המודל תומך רק בחיטוי סטרימינג באמצעות השיטה 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.

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

כדי להגדיר את 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.

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

      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: מזהה הפרויקט שמכיל את תבנית הגנה מוגברת על המודל.

    • סוכן לכל מקום (יציאה): מקצים לסוכן השירות של 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: מזהה הפרויקט שמכיל את תבנית הגנה מוגברת על המודל.

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

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

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

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

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

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

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

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

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

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

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

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

  1. לקוח שולח הנחיה לסוכן. הבקשה מיוּרטת על ידי Agent Gateway והמטען הייעודי (payload) נשלח אל Model Armor.
  2. הבקשה נבדקת על ידי Model Armor. אם החסימה מתבצעת, הלקוח מקבל שגיאה.
  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, במיוחד עבור הפעלות של סטרימינג של תעבורת נתונים נכנסת. מידע נוסף זמין במאמר הצלבת נתונים מיומנים ומאירועים קשורים.