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

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

תבניות של Model Armor

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

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

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

באמצעות Agent Gateway, אפשר להשתמש ב-Model Armor כדי להגן על תנועת הנתונים הבאה.

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

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

התבניות של Model Armor משמשות לסינון של:

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

כשלקוח שולח הנחיה לסוכן, Agent Gateway מיירט את התנועה ושולח את המטען הייעודי (payload) ל-Model Armor כדי להסיר תוכן זדוני או רגיש. אם Model Armor מחזיר את התוצאה ALLOW, ‏Agent Gateway שולח את ההנחיה לסוכן ה-AI. אם Model Armor מנפיק פסיקה של BLOCK, הלקוח מקבל שגיאה והתהליך מסתיים לפני שהוא מגיע לסוכן ה-AI.

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

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

אתם מגדירים תבניות שבהן Model Armor משתמש כדי להעריך בקשות ותשובות בתנועה מסוג Agent-to-Anywhere. אפשר להחיל תבנית אחת על שני הכיוונים או להגדיר תבניות שונות לכל כיוון.

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

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

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

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

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

מפעילים את Model Armor API, אם הוא עדיין לא מופעל.

התפקידים שנדרשים כדי להפעיל ממשקי API

כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם אתם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, אתם יכולים לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים?

להפעלת ה-API

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות ליצירת תבניות של Model Armor, בקשו מהאדמין להקצות לכם את התפקיד אדמין של Model Armor (roles/modelarmor.admin) ב-IAM בפרויקט. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

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

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

הגדרת 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 יחיד.

אופציונלי: בדיקת אימות של התבנית לפני הפריסה

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

כדי לאמת את התבנית, אתם יכולים לשלוח שאילתה ל-method‏ sanitizeUserPrompt ישירות באמצעות קבוצה של הנחיות לבדיקה. במאמר בדיקת תבנית של Model Armor מוסבר איך מריצים את הבדיקה הזו לפני הפריסה, ויש בו רשימה של הנחיות לבדיקה.

צנזור מידע רגיש מבקשות ומתשובות

אתם יכולים להורות ל-Model Armor לצנזר מידע אישי רגיש, כמו מספרי תעודות זהות ומספרי טלפון, מהמטען הייעודי (payload). כדי להשתמש בתכונה הזו:

אם משתמשים בסוג האכיפה INSPECT_AND_BLOCK, קורה אחד מהמקרים הבאים:

  • אם המטען הייעודי (payload) מפר רק את הגלאי של Sensitive Data Protection, המערכת מצנזרת את המטען הייעודי (payload) בהתאם להגדרות המתקדמות של Sensitive Data Protection ולתבנית להסרת פרטי הזיהוי.

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

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

לא משנה מה סוג האכיפה (INSPECT_ONLY או INSPECT_AND_BLOCK), היומנים של Model Armor מצונזרים בהתאם להגדרות המתקדמות של Sensitive Data Protection ולתבנית להסרת פרטי הזיהוי.

רשימה מלאה של גלאי Model Armor (שנקראים גם מסננים) מופיעה במאמר מסנני Model Armor.

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

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

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

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

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

בדיקת מסמכים

השילוב הזה לא תומך בהסרת תוכן זדוני או רגיש מהנחיות ומתשובות שמכילות מסמכים או קבצים שהועלו (כמו קובצי PDF). כדי לסנן מסמכים, צריך לשלוח קריאה ישירות ל-Model Armor REST API. מידע נוסף מופיע במאמר סינון מסמכים במרכז העזרה של Model Armor.

מכסות ומגבלות מערכת

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

מידע נוסף על המכסות שחלות כשמשתמשים ב-Model Armor עם שירותים אחרים זמין במאמר ניהול מכסות.

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

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