Model Armor auf einem Gateway konfigurieren

Mit Model Armor können Sie dafür sorgen, dass Ihre KI-Agents Ihre Sicherheits- und Governance-Standards einhalten, ohne dass Sie Filterlogik direkt in die Agents implementieren müssen. Wenn Sie Model Armor mit Agent Gateway konfigurieren, wendet Model Armor die Richtlinien für die Inhaltssicherheit Ihrer Organisation an, indem alle Prompts und Antworten, die das Gateway durchlaufen, geprüft werden. Mit dieser Funktion können Sie Sicherheitsvorkehrungen für Inhalte einheitlich für alle KI-Agents durchsetzen, die vom Gateway verwaltet werden. Model Armor hilft Ihnen, Risiken wie Prompt Injection, Jailbreaking-Versuche, das Preisgeben sensibler Informationen und die Generierung schädlicher Inhalte zu minimieren. Weitere Informationen finden Sie unter Model Armor-Filter.

Model Armor-Vorlagen

Wenn Sie Model Armor für ein Gateway konfigurieren möchten, erstellen Sie Vorlagen, in denen angegeben wird, wie die Prompts und Antworten, die Ihre KI-Agents empfangen und zurückgeben, geprüft werden sollen. Die Vorlagen enthalten benutzerdefinierte Filter und Schwellenwerte für mehrere Sicherheitskategorien. Weitere Informationen finden Sie unter Model Armor-Vorlagen.

Model Armor bettet Screening-Funktionen direkt in die Kommunikationswege ein, die vom Agent Gateway verwaltet werden. Wenn Sie die Inhalte über Model Armor weiterleiten, erzwingt das Gateway die Einhaltung Ihrer Vorlagen für die Inhaltssicherheit. In Ihrer Vorlage können Sie Model Armor so konfigurieren, dass Inhalte, die gegen Ihre Vorlagen verstoßen, entfernt oder blockiert werden.

Ein- und ausgehender Traffic

Über Agent Gateway kann Model Armor die folgenden Trafficflüsse schützen.

Client zu Agent (eingehender Agententraffic)

Sie definieren Vorlagen, die von Model Armor verwendet werden, um sowohl Anfragen als auch Antworten im Client-to-Agent-Traffic zu bewerten. Sie können eine einzelne Vorlage für beide Richtungen anwenden oder für jede Richtung eine andere Vorlage konfigurieren.

Model Armor folgt den Vorlagen beim Überprüfen der folgenden Elemente:

  • Eingehende Anfragen vom Client (Endnutzer oder Anrufanwendungen) an Ihren KI-Agenten
  • Ausgehende Antworten des KI-Agents an den Kunden

Wenn ein Client einen Prompt an den Agent sendet, fängt Agent Gateway den Traffic ab und sendet die Nutzlast zur Bereinigung an Model Armor. Wenn Model Armor ein ALLOW-Ergebnis ausgibt, sendet Agent Gateway den Prompt an den KI-Agenten. Wenn Model Armor das Ergebnis BLOCK ausgibt, erhält der Client einen Fehler und der Ablauf wird beendet, bevor der KI-Agent erreicht wird.

Nachdem der KI-Agent die Anfrage verarbeitet und eine Antwort generiert hat, fängt das Agent Gateway den ausgehenden Stream ab, bevor er den Client erreicht. Model Armor bewertet die Antwort und gibt ein Urteil ab. Basierend auf dem Ergebnis lässt Agent Gateway die Antwort entweder zu oder blockiert sie vollständig.

Agent zu beliebigem Ziel (ausgehender Agententraffic)

Sie definieren Vorlagen, die Model Armor verwendet, um Anfragen und Antworten im Agent-to-Anywhere-Traffic zu bewerten. Sie können eine einzelne Vorlage für beide Richtungen anwenden oder für jede Richtung eine andere Vorlage konfigurieren.

Model Armor folgt den Vorlagen, wenn die Kommunikation zwischen Ihrem KI-Agenten und externen Systemen überprüft wird. Dazu gehören:

  • Externe Large Language Models (LLMs)
  • KI-Agents von Drittanbietern
  • MCP-Server (Model Context Protocol)

Wenn ein KI-Agent mit einem externen System kommuniziert, fängt Agent Gateway den ausgehenden Traffic ab und ruft Model Armor auf. Model Armor bewertet die Nutzlast anhand der von Ihnen festgelegten Egress-Vorlagen.

Wenn die ausgehenden Daten gegen Ihre Sicherheitsrichtlinien verstoßen, gibt Model Armor ein BLOCK-Urteil aus. Agent Gateway beendet dann die Verbindung, um zu verhindern, dass schädliche oder sensible Daten das LLM, das Tool oder den externen KI-Agenten erreichen.

Hinweis

Aktivieren Sie die Model Armor API, falls sie noch nicht aktiviert ist.

Rollen, die zum Aktivieren von APIs erforderlich sind

Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Rolle „Inhaber“ (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen

API aktivieren

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Model Armor Admin (roles/modelarmor.admin) für das Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen von Model Armor-Vorlagen benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Informationen zu den Rollen, die für die Arbeit mit Agent Gateway erforderlich sind, finden Sie in der Agent Gateway-Dokumentation unter Erforderliche Rollen.

Informationen zu unterstützten und nicht unterstützten Nutzlasten, die das Gateway durchlaufen, finden Sie in diesem Dokument unter Unterstützte und nicht unterstützte Nutzlasten.

Model Armor auf einem Gateway konfigurieren

So konfigurieren Sie Model Armor für ein Gateway:

  1. Aktivieren Sie die Model Armor API in dem Projekt, in dem Sie die Model Armor-Vorlagen erstellen möchten.

  2. Erstellen Sie eine oder mehrere Model Armor-Vorlagen in derselben Region, in der Sie das Gateway hinzufügen möchten. Sie können dieselbe Vorlage sowohl für eingehenden als auch für ausgehenden Traffic verwenden.

    Notieren Sie sich die Namen der Vorlagen. Wenn Sie den Namen einer Vorlage in derCloud de Confiance Console kopieren möchten, rufen Sie die Details der Vorlage auf und klicken Sie neben dem Namen der Vorlage auf  In die Zwischenablage kopieren.

  3. Richten Sie das Agent Gateway in derselben Region ein, in der die Model Armor-Vorlagen gespeichert sind. Geben Sie für das Client-to-Agent-Gateway (Ingress) die Model Armor-Vorlagen an, die Sie für eingehenden Traffic erstellt haben. Geben Sie für das Agent-to-Anywhere (Egress)-Gateway die Model Armor-Vorlagen an, die Sie für Egress-Traffic erstellt haben. Sie können dieselbe Vorlage für beide Traffic-Flows verwenden.

  4. Weisen Sie den entsprechenden Dienst-Agents die erforderlichen IAM-Rollen zu:

    • Client zu Agent (eingehender Traffic): Weisen Sie dem Dienst-Agent AI Platform Reasoning Engine Service Agent die folgenden Rollen zu:

      • Die Rolle „Model Armor Callout User“ (roles/modelarmor.calloutUser) im Projekt, das den KI-Agenten enthält.

      • Die Rolle „Model Armor User“ (roles/modelarmor.user) im Projekt, das die Model Armor-Vorlage enthält.

      gcloud projects add-iam-policy-binding AGENT_RUNTIME_PROJECT_ID \
    --member=serviceAccount:service-AGENT_RUNTIME_PROJECT_NUMBER@gcp-sa-aiplatform-re.s3ns-system.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.s3ns-system.iam.gserviceaccount.com \
    --role=roles/modelarmor.user

      Ersetzen Sie Folgendes:

      • AGENT_RUNTIME_PROJECT_ID: Die Projekt-ID des Projekts, in dem Sie den Agent erstellt haben.
      • AGENT_RUNTIME_PROJECT_NUMBER: Die Projektnummer des Projekts, in dem Sie den Agent erstellt haben.
      • MODEL_ARMOR_PROJECT_ID: Die Projekt-ID des Projekts, das die Model Armor-Vorlage enthält.

    • Agent-to-Anywhere (Egress): Gewähren Sie dem Dienst-Agenten für Dienst-Erweiterungen die folgenden Rollen:

      • Die Rollen „Model Armor Callout User“ (roles/modelarmor.calloutUser) und „Service Usage Consumer“ (roles/serviceusage.serviceUsageConsumer) im Projekt, das das Gateway enthält.
      • Die Rolle „Model Armor User“ (roles/modelarmor.user) im Projekt, das die Model Armor-Vorlage enthält.
      gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.s3ns-system.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.s3ns-system.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.s3ns-system.iam.gserviceaccount.com \
    --role=roles/modelarmor.user

      Ersetzen Sie Folgendes:

      • GATEWAY_PROJECT_ID: Die Projekt-ID des Projekts, in dem Sie das Gateway erstellt haben.
      • GATEWAY_PROJECT_NUMBER: Die Projektnummer des Projekts, in dem Sie das Gateway erstellt haben.
      • MODEL_ARMOR_PROJECT_ID: Die Projekt-ID des Projekts, das die Model Armor-Vorlage enthält.

      Eine Anleitung finden Sie unter Autorisierung an Model Armor delegieren.

    Allgemeine Informationen zum Zuweisen einer Rolle finden Sie unter Einzelne IAM-Rolle zuweisen.

Optional: Vorabprüfung der Vorlage vor der Bereitstellung

Bevor Sie Ihre Vorlagen auf einem Gateway bereitstellen, können Sie eine Vorabprüfung durchführen, um zu prüfen, ob Ihre Vorlagenkonfiguration Ihre Sicherheitsrichtlinien korrekt erzwingt.

Sie können Ihre Vorlage validieren, indem Sie die Methode sanitizeUserPrompt direkt mit einer Reihe von Testprompts abfragen. Weitere Informationen zum Ausführen dieser Prüfung vor der Bereitstellung und eine Liste der geprüften Testprompts finden Sie unter Vorlagenkonfiguration validieren.

Sensible Daten aus Anfragen und Antworten entfernen

Sie können Model Armor anweisen, vertrauliche Daten wie Personalausweisnummern und Telefonnummern aus Nutzlasten zu entfernen. So verwenden Sie diese Funktion:

Wenn Sie den Erzwingungstyp INSPECT_AND_BLOCK verwenden, tritt einer der folgenden Fälle ein:

  • Wenn eine Nutzlast nur gegen den Sensitive Data Protection-Detektor verstößt, schwärzt Model Armor die Nutzlast gemäß Ihren erweiterten Sensitive Data Protection-Einstellungen und der De-Identifikationsvorlage.

  • Wenn eine Nutzlast gegen mehrere Detektoren verstößt, wird sie von Model Armor nicht unkenntlich gemacht, sondern vollständig blockiert.

Wenn Sie den Erzwingungstyp INSPECT_ONLY anstelle von INSPECT_AND_BLOCK verwenden, wird die Nutzlast von Model Armor nicht unkenntlich gemacht.

Unabhängig von Ihrem Erzwingungstyp (INSPECT_ONLY oder INSPECT_AND_BLOCK) werden Model Armor-Protokolle gemäß Ihren erweiterten Sensitive Data Protection-Einstellungen und der Vorlage für die De-Identifizierung unkenntlich gemacht.

Eine vollständige Liste der Model Armor-Detektoren (auch Filter genannt) finden Sie unter Model Armor-Filter.

Unterstützte und nicht unterstützte Nutzlasten

In diesem Abschnitt werden die Arten von Nutzlasten aufgeführt, die von Model Armor bereinigt werden.

Client-zu-Agent-Traffic (eingehend)

Bei Client-to-Agent-Traffic (Ingress) mit dem ADK-Protokoll bereinigt Model Armor nur reasoningEngines.streamQuery-Anfragen und -Antworten für Agenten, die mit dem Agent Development Kit (ADK) erstellt wurden und in der Vertex AI Agent Engine ausgeführt werden.

Alle anderen ReasoningEngine-Nutzlasten und ReasoningEngine-Fehlerantworten werden nicht an Model Armor gesendet. Nicht-ADK-Nutzlasten (z. B. Langchain-Nutzlasten) werden ebenfalls nicht an Model Armor gesendet.

Agent-zu-beliebigem-Ziel-Traffic (ausgehend)

Für Agent-to-Anywhere-Traffic (Egress) werden die folgenden Nutzlasten unterstützt.

A2A-Nutzlasten

Model Armor bereinigt nur die folgenden Nutzlasten des A2A v1-Protokolls:

Model Armor erlaubt die folgenden A2A-Nutzlasten ohne Bereinigung:

MCP-Nutzlasten

Model Armor bereinigt nur die folgenden MCP-Nutzlasten:

Model Armor lässt die folgenden Nutzlasten ohne Bereinigung zu:

  • tools/list
  • resources/*
  • notifications/*
  • Streamable HTTP/SSE for MCP
  • MCP-Protokollfehler (z. B. alle Fehler außer Tool-Ausführungsfehlern)

Externe LLM-Nutzlasten

Model Armor bereinigt nur die folgenden Nutzlasten des OpenAI API-Protokolls (Egress), einschließlich GPT-Modelle auf openai.com sowie aller anderen Modelle über OpenAI API-kompatible LLM-Server (z. B. vLLM). Payloads, die hier nicht aufgeführt sind, sind ohne Bereinigung zulässig.

Dokumentenprüfung

Das Bereinigen von Prompts und Antworten, die Dokumente oder Dateiuploads (z. B. PDFs) enthalten, wird in dieser Integration nicht unterstützt. Wenn Sie Dokumente prüfen möchten, rufen Sie die Model Armor REST API direkt auf. Weitere Informationen finden Sie in der Model Armor-Dokumentation unter Document screening.

Kontingente und Systemlimits

Das Kontingent wird in dem Projekt verbraucht, in dem sich die Model Armor-Vorlagen befinden. Wenn sich das Gateway in einem anderen Projekt befindet, wird das ExternalProcessor-Kontingent auch im Gateway-Projekt verbraucht.

Weitere Informationen zu Kontingenten, die gelten, wenn Sie Model Armor mit anderen Diensten verwenden, finden Sie unter Kontingente verwalten.

Allgemeine Informationen zu Model Armor-Kontingenten und Systemlimits, einschließlich der Eingabegröße und Tokenlimits, finden Sie in der Model Armor-Dokumentation unter Kontingente und Systemlimits.

Nächste Schritte