Agentischen Traffic mit Agent Gateway verwalten

Wenn Sie autonome KI-Agenten in der Google Kubernetes Engine (GKE) bereitstellen, funktionieren Ihre Arbeitslasten anders als Standard-Mikrodienste. KI-Agenten bestimmen ihre eigenen Ausführungspfade und rufen basierend auf Nutzerprompts dynamisch externe SaaS-APIs, Remote-MCP-Server (Model Context Protocol) oder andere interne KI-Agenten auf.

Da dieses Verhalten nicht deterministisch ist, können Standard-Netzwerkfirewalls der Schicht 4 Ihre KI-Umgebung nicht vollständig schützen. Um agentischen Traffic zu sichern, müssen Sie die Identität des aufrufenden KI-Agenten prüfen, genau einschränken, welche Tools er verwenden darf, und den semantischen Kontext des Prompts bereinigen, um Bedrohungen wie Prompt-Injection-Angriffe zu verhindern.

Wenn Sie Plattformadministrator, Sicherheitsingenieur oder KI-Entwickler sind, können Sie Agent Gateway verwenden, um diesen agentischen Traffic zu sichern und zu verwalten. Das Agent Gateway fungiert als zentraler Netzwerkeingangs- und ‑ausgangspunkt für Ihre in GKE gehosteten Agenten und stellt eine direkte Verbindung zur Richtlinienerzwingungsebene der Gemini Enterprise Agent Platform her.

Vorteile des KI-Agenten-Gateways für KI-Arbeitslasten

Mit dem Agent Gateway können Sie die folgenden Ziele für Ihre agentischen Anwendungen erreichen:

  • Sicherheit vom Agent-Code entkoppeln: KI-Entwickler müssen keine komplexe Authentifizierung, gegenseitige TLS (mTLS) oder Logik zur Bereinigung von Nutzlasten in ihre Agent-Frameworks einbauen. Agent Gateway übernimmt die Netzwerkverschlüsselung und die Richtlinienerzwingung auf Plattformebene.
  • Sidecar-freie Erzwingung implementieren: GKE Ambient Networking erfasst Agent-Traffic außerhalb Ihrer Pods, ohne dass Sidecars eingefügt werden müssen und ohne dass Änderungen am Agent-Code erforderlich sind. Außerdem wird der Traffic zwischen Arbeitslasten mit mTLS basierend auf der Identität der einzelnen Pods verschlüsselt, sodass Sie Zertifikate nicht selbst verwalten müssen.
  • Sicherheitsmaßnahmen für KI erzwingen: Eingehende Nutzer-Prompts und ausgehende Toolantworten werden in Echtzeit bereinigt. Agent Gateway ist direkt in Google Cloud Model Armor eingebunden, um Payloads auf Prompt-Injection-Angriffe oder schädliche Inhalte zu prüfen, bevor sie die Reasoning Engine Ihres KI-Agenten erreichen.
  • Sichere Tool-Ausführung: Prüfen Sie, ob nur autorisierte Agenten auf bestimmte MCP-Server oder APIs mit hohen Berechtigungen zugreifen können. Sie können für jeden Toolaufruf detaillierte, identitätsbasierte Zugriffssteuerungen erzwingen.
  • Multi-Agenten-Systeme überwachen: Erfassen und rufen Sie Beobachtbarkeits-Telemetriedaten für alle Agenteninteraktionen ab, um die mehrstufige Agentenlogik über verschiedene Tools und Endpunkte hinweg zu verfolgen.

Funktionsweise des Agent Gateways in GKE

Je nach Traffic-Richtung können Sie Standard-GKE-Netzwerkressourcen verwenden, um Agent Gateway so zu konfigurieren, dass die folgenden KI-Interaktionsabläufe gesteuert werden:

  • Client-zu-Agent (eingehend): Verwalten Sie, wie externe Clients (z. B. Chat-Schnittstellen oder Entwickler-CLIs) mit den in Ihrem GKE-Cluster gehosteten Agenten interagieren. Sie stellen einen regionalen Application Load Balancer mithilfe der GKE Gateway API bereit. Anschließend wenden Sie benutzerdefinierte Kubernetes-Ressourcen (GCPAgentGateway, GCPAuthzPolicy und GCPExtensionBinding) an, um identitätsbasierte Zugriffssteuerungen zu erzwingen, bestimmte MCP-Toolaufrufe einzuschränken und eingehende Prompts mit Model Armor zu prüfen, bevor die Anfrage den Agenten erreicht.
  • Agent-to-Anywhere (ausgehend): Leiten Sie ausgehende Anfragen sicher von Ihren in GKE gehosteten KI-Agenten an externe Datenspeicher, Remote-MCP-Server und APIs weiter. Sie verwenden den GKE-Ambient-Proxy, um diesen Traffic an einen Secure Web Proxy (SWP) weiterzuleiten. SWP erzwingt Ihre Sicherheitsrichtlinien, verifiziert die Identität des KI-Agenten mit Identity-Aware Proxy (IAP) und prüft ausgehende Nutzlasten mit Model Armor, bevor der Traffic Ihr Netzwerk verlässt.
  • Ost-West (innerhalb des Clusters): Steuern Sie, wie KI-Agenten mit anderen KI-Agenten, freigegebenen internen Tools oder MCP-Servern innerhalb desselben Clusters zusammenarbeiten. Sie stellen Layer-7-Ambient-Proxys pro Namespace bereit, um gegenseitiges TLS (mTLS) und detaillierte Zugriffsrichtlinien zu erzwingen, ohne Sidecar-Proxys in Ihre Agent-Pods einzufügen. Wenden Sie sich an Ihr Google Cloud-Account-Management-Team, um Zugriff auf die Vorabversion der Layer-7-Ambient-Proxys anzufordern.

Beschränkungen und Anforderungen

Damit Sie in GKE gehostete Agenten mit Agent Gateway verwalten können, muss Ihre Umgebung die folgenden grundlegenden Anforderungen erfüllen:

  • Unterstützte Arbeitslasten: Agent Gateway unterstützt Agenten, die als Standard-GKE-Pods bereitgestellt werden. Agent Substrate in GKE und Agent Sandbox in GKE werden nicht unterstützt.
  • GKE-Clusterversion: Auf Ihrem Cluster muss die GKE-Version 1.37.1-gke.1697000 oder höher ausgeführt werden.
  • Agentenidentität: Sie müssen Ihren Agentenarbeitslasten eine kryptografische SPIFFE-Identität zuweisen, damit das Gateway identitätsbasierte Richtlinien auswerten kann. Informationen zum Zuweisen dieser Identitäten zu Ihren Pods finden Sie unter Agentenidentität in GKE.
  • Agent Registry: Sie müssen Ihre Agent-Deployments registrieren, damit die Agent Registry die Arbeitslasten erkennen und ihre Metadaten synchronisieren kann. Fügen Sie Ihren Deployments das Label registry.gke.io/functional-type: "AGENT" hinzu, um sie zu registrieren. Weitere Informationen finden Sie unter Automatische Registrierung verwenden.
  • GKE-Netzwerkkomponenten:
    • Für die Ingress-Governance müssen Sie die GKE Gateway API in Ihrem Cluster aktivieren.
    • Für die Governance des ausgehenden Traffics müssen Sie Ihren Cluster für Ambient Networking vorbereiten und eine Secure Web Proxy-Instanz bereitstellen.

Für Agent Gateway for GKE gelten Einschränkungen für einzelne Projekte, bestimmte Grenzen für benutzerdefinierte Erweiterungen und regionale Verfügbarkeitslimits.

Nächste Schritte