Zscaler legt eine Kontrollschicht über den Agenten-Verkehr: AI Broker und Agent Registry machen MCP- und A2A-Traffic regelbar

Was ist passiert

Am 9. Juni erweiterte Zscaler seine Zero-Trust-Exchange-Plattform um eine Reihe von Bausteinen für agentische KI. Kernstück ist der Zscaler AI Broker: Er sitzt zwischen einem Agenten und den Systemen, auf die der Agent zugreift, und vermittelt dabei sowohl MCP- als auch A2A-Verkehr. Eine integrierte Agent Registry führt für jeden Agenten Identität, Zweck sowie erlaubte Daten und Aktionen — feingranulare Regeln werden darüber durchsetzbar, etwa „dieser Finanz-Agent darf nur auf System X“ oder „dieser Support-Agent sieht keine personenbezogenen Daten“. Daneben stehen Endpoint AI Security (Erkennung von KI-Risiken in Browsern, Plugins, Extensions und lokalen KI-Tools) und der AI Access Graph aus der Übernahme von Symmetry Systems, der Identitäten, Anwendungen und Datenquellen zu einer nachvollziehbaren Daten-Herkunftslinie verknüpft. Erweiterungen von AI Protect bringen unter anderem Red-Teaming für MCP-Server. Zscaler nennt das Bündel den „ersten vollständigen Zero-Trust-Stack für agentische KI“.

Einordnung

Der Kern ist eine Architektur-Aussage, keine Produkt-Aussage. Klassische Sicherheitswerkzeuge wurden um bekannte menschliche Identitäten und vorhersehbare Zugriffsmuster gebaut. Autonome Agenten brechen dieses Modell: Sie handeln in Maschinengeschwindigkeit, erzeugen flüchtige Identitäten, starten Sub-Agenten und nutzen Berechtigungen auf Wegen, die herkömmliche Tools nicht mehr sehen. Die Antwort, die Zscaler vorzeichnet, ist nicht ein besserer Filter, sondern eine eigene Schicht: ein Broker, durch den der Agenten-Verkehr läuft, plus ein Verzeichnis, gegen das jede Agenten-Identität und ihr Berechtigungsumfang geprüft wird. Damit wird die Governance von Agenten-Verkehr zu einer Architektur-Komponente neben Agent und Werkzeug — analog zur sauberen Schicht-Trennung, die wir in den Wochen davor bei MCP und ACP gesehen haben. Die Botschaft an die Branche: MCP und A2A regeln das Wie der Verbindung, aber das Wer-darf-was braucht einen eigenen, durchsetzenden Punkt davor.

Bedeutung für den Mittelstand

Für Häuser, die mehr als einen Agenten produktiv nehmen, schließt eine solche Schicht eine reale Lücke. Sobald Agenten APIs aufrufen, Daten bewegen oder Sub-Agenten starten, entstehen Maschinen-Identitäten ohne festen Personenbezug — und ohne Verzeichnis weiß niemand, welcher Agent wann auf welches System durfte. Eine Agent Registry mit Tool-Call-genauer Durchsetzung und lückenlosem Audit-Trail ist genau das, was eine technisch-organisatorische Maßnahme nach Art. 32 DSGVO für nicht-menschliche Akteure leistet: nachvollziehbare Zugriffskontrolle plus Protokoll für die spätere Aufarbeitung.

Die unbequeme Seite gehört direkt daneben, nicht in eine Fußnote. Ein Broker, der den gesamten Agenten- und MCP-Verkehr vermittelt, ist selbst ein Daten-Durchlauf. Bei einem US-Anbieter mit global verteilter Cloud heißt das: Metadaten über jeden Agenten-Zugriff, womöglich auch Inhalte von Tool-Calls, laufen durch eine Infrastruktur in einem Drittland. Das macht die Auswahl der Vermittlungsschicht zu einer Frage nach Auftragsverarbeitungsvertrag, Drittland-Transfer und — bei Banken und Versicherern — nach BaFin/MaRisk-Auslagerungsregeln. Wer Agenten-Governance einführt, darf die Governance-Schicht nicht zum neuen, ungeprüften Datenabfluss machen. Eine selbst gehostete oder EU-residente Broker-Variante ist hier die souveränitätswahrende Gegenoption.

Bedeutung für die technische Entwicklung

Im Schichtenbild entsteht ein vierter Baustein: ACP zwischen Client und Agent, MCP zwischen Agent und Werkzeug, A2A zwischen Agenten — und darüber nun ein Broker plus Registry, der diesen Verkehr vermittelt und an Identität und Policy bindet. Das ist konzeptionell die „Agent-Firewall“ oder Vermittlungsstelle, die in Eigenbau-Stacks bisher fehlte oder als loser Proxy improvisiert wurde. Wer einen eigenen Agenten-Stack baut, sollte diesen Kontrollpunkt von vornherein als benannte Komponente vorsehen — am besten protokoll-neutral gegen MCP und A2A, damit der Broker austauschbar bleibt und kein neuer Lock-in entsteht.

Was die Ankündigung ausdrücklich nicht liefert, gehört ebenfalls hierher: Zscaler nennt keine belastbaren Aussagen zu EU-Residency oder Aufbewahrungsfristen des Broker-Verkehrs. Wer hier EU-Verbleib annimmt, schreibt eine Garantie fort, die nicht zugesagt wurde.

Konkrete Handlungsempfehlung

In dieser Reihenfolge. Erstens, inventarisieren, welche Agenten im Haus bereits MCP- oder A2A-Verkehr erzeugen und unter welcher Identität sie auf welche Systeme zugreifen — ohne dieses Verzeichnis lässt sich keine Policy schreiben. Zweitens, einen benannten Kontrollpunkt (Broker plus Registry) für Agenten-Verkehr als Architektur-Anforderung festlegen, protokoll-neutral gegen MCP und A2A. Drittens, vor jeder Cloud-vermittelten Governance-Lösung den Daten-Durchlauf prüfen: AVV, Drittland-Transfer, Residency — und für sensible Repositories und regulierte Daten die selbst gehostete oder EU-residente Variante bevorzugen. Viertens, das Tool-Call-Audit-Log in die bestehende SIEM- und Incident-Kette einhängen, sonst sehen Agenten-Aktionen im Ernstfall niemanden. Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.

Quellen

• Zscaler — Zscaler Unveils New Product Innovations to Secure Agentic AI (09.06.2026, Primärquelle)
• SiliconANGLE — Zscaler launches AI Broker and Endpoint AI Security for AI agents (09.06.2026)
• SiliconANGLE — Securing the AI workforce: Zscaler's zero-trust play for agentic AI (10.06.2026)
• Network World — Zscaler launches zero trust platform for agentic AI (09.06.2026)