Wie Patronus AI-Traffic über WebSockets, SSE, gRPC, Protobuf und moderne Kodierungen erkennt

Die meisten AI-Security-Werkzeuge gehen bis heute davon aus, dass AI-Traffic wie ein einfacher JSON-Request über HTTPS aussieht.

Diese Annahme veraltet zunehmend.

Moderne AI-Systeme kommunizieren über:

• WebSockets

• Server-Sent Events (SSE)

• gRPC

• HTTP/2-Streams

• Protobuf

• MsgPack

• binär geframte Protokolle

• komprimierte Transportschichten

Je verbreiteter AI-Agents, Coding-Assistenten und MCP-basierte Systeme werden, desto weiter bewegt sich AI-Traffic weg von schlichtem JSON und hin zu Streaming und binärer Kommunikation.

Bei Patronus haben wir zuletzt viel Zeit darauf verwendet, unsere transparente Inspektionsschicht zu erweitern, um besser zu verstehen, wie sich moderne AI-Kommunikation auf der Leitung tatsächlich verhält.

Herausgekommen ist eine Abdeckungsmatrix für Protokolle und Kodierungen, die vier Dinge abbildet: Transport-Unterstützung, Erkennung von AI-Traffic, semantische Extraktion und bewusstes Fail-Closed-Verhalten.

Warum wird die Erkennung von AI-Traffic schwieriger?

Vor einigen Jahren sahen die meisten AI-Interaktionen vergleichsweise einfach aus: HTTP/1.1, REST-API, JSON-Request, JSON-Response.

Heute nutzen moderne AI-Systeme zunehmend:

• gestreamte Token-Antworten

• bidirektionale Kommunikation

• Protobuf-Serialisierung

• binäres Framing

• multiplexte HTTP/2-Streams

• dauerhafte Echtzeit-Sitzungen

Für AI-Security und AI-Observability ist das eine erhebliche Herausforderung.

Wenn eine Sicherheitsschicht nur reinen JSON-Traffic versteht, verliert sie die Sicht auf AI-Coding-Assistenten, Desktop-AI-Anwendungen, MCP-Kommunikation, lokale AI-Runtimes, Agent-Frameworks und Echtzeit-Streaming-Systeme.

Das ist einer der Gründe, warum AI-Security aus unserer Sicht zunehmend ein Problem der Protokoll- und Semantik-Sichtbarkeit wird und nicht bloß eines der API-Integration.

Welche Protokolle und Kodierungen deckt Patronus ab?

Die aktuelle Matrix umfasst mehrere Transportschichten und Serialisierungsformate, darunter HTTP/1.1, HTTP/2, WebSockets, SSE und gRPC, sowie Kodierungen wie JSON, JSONL, Protobuf, MsgPack, TLV-Binär, längenpräfixiertes Binär und mit gzip oder zstd komprimierte Varianten.

Der interessante Teil war für uns nicht der reine JSON-Traffic. Interessant war alles drumherum: unbekannte Protobuf-Carrier, Streaming-Traffic, binär geframte Payloads und transportbewusster Umgang mit Fehlalarmen.

Hier eine vereinfachte Fassung der aktuellen Matrix:

Protokoll	Kodierung / Variante	AI-Erkennung	AI-Extraktion
HTTP/1.1	JSON	ja	ja
HTTP/1.1	MsgPack	ja	ja
HTTP/1.1	bekanntes Protobuf	ja	ja
HTTP/1.1	unbekanntes Protobuf	ja	nein
HTTP/2	JSON-Multiplex	Transport	Transport
HTTP/2	MsgPack	ja	ja
WebSocket	JSON-Textframes	ja	ja
WebSocket	unbekannte Protobuf-Carrier	ja	nein
SSE	JSON-Delta-Stream	ja	ja
SSE	unbekannte Carrier	ja	nein
gRPC	bekanntes Protobuf, unär	ja	ja
gRPC	unbekannter Protobuf-Stream	ja	nein

Die vollständige Matrix enthält zusätzlich strukturelle Protobuf-Varianten, komprimierte Payload-Varianten, den Umgang mit opaken Binärdaten, Schutzmechanismen bei Payloads mit hoher Entropie und die Abdeckung der Transport-Integrität.

Warum trennen wir Erkennung von Extraktion?

Eine Sache trennen wir bewusst: die Erkennung von AI-Traffic von der semantischen Extraktion.

Diese Unterscheidung ist wichtig. Ein unbekannter Protobuf-Carrier kann starke Hinweise darauf enthalten, dass eine Verbindung AI-Interaktionen transportiert, auch wenn das genaue Protobuf-Schema nicht vorliegt.

Aber: AI-Traffic zu erkennen ist nicht dasselbe wie den vollständigen semantischen Inhalt zu verstehen. Bei Binärprotokollen und unbekannten Carriern gilt das besonders.

Statt so zu tun, als würden wir jede Payload vollständig verstehen, gehen wir bewusst in Fail-Closed, sobald die semantische Konfidenz zu niedrig wird. Traffic kann also weiterhin als AI-bezogen klassifiziert sein, während die Extraktion absichtlich deaktiviert bleibt.

Für transparente AI-Security-Systeme halten wir das für den realistischeren und sichereren Ansatz.

Warum sind Streaming-Protokolle für AI-Security relevant?

Streaming verändert das Verhalten von AI-Traffic grundlegend.

Klassische Sicherheitswerkzeuge nehmen oft an: Request kommt an, Response kommt an, Analyse ist fertig.

Moderne AI-Systeme verhalten sich zunehmend anders: Antworten kommen inkrementell, Tools werden während der Sitzung ausgeführt, Verbindungen bleiben bestehen, und der Kontext entwickelt sich fortlaufend weiter.

Besonders sichtbar wird das bei SSE-Token-Streams, WebSocket-Copilots, gRPC-Streaming und agentischen Systemen.

Je autonomer AI-Agents werden, desto wichtiger wird die Inspektion von Streaming-Traffic, für Observability, Prompt-Injection-Erkennung, den Schutz sensibler Daten, Tool-Governance und MCP-Sicherheit.

Warum transparente Sichtbarkeit zählt

Die meisten Organisationen haben bereits umfangreiche, ungesteuerte AI-Nutzung: Browser-AI-Tools, AI-Erweiterungen in der IDE, lokale LLM-Runtimes, Desktop-Copilots und Schatten-AI-Workflows.

Viele bestehende Sicherheitslösungen hängen stark an Browser-Erweiterungen, Provider-APIs oder SaaS-Integrationen. Das Problem: Moderne AI-Nutzung passiert zunehmend außerhalb dieser kontrollierten Umgebungen.

Deshalb halten wir transparente Inspektion auf dem Endpoint für zunehmend wichtig. Nicht, weil Integrationen nutzlos wären, sondern weil Integrationen allein keine vollständige Sicht mehr darauf geben, wie moderne AI-Systeme tatsächlich kommunizieren.

Wie sieht AI-Traffic in Zukunft aus?

Aus unserer Sicht wird moderner AI-Traffic zunehmend gestreamt, binär, multiplext, dauerhaft und agentengetrieben sein.

Künftige AI-Security-Systeme werden dafür protokollbewusste Inspektion, semantische Extraktions-Pipelines, Streaming-Analyse und transportagnostische Erkennungsmechanismen brauchen.

Die Ära des „einfach die JSON-Requests inspizieren" geht langsam zu Ende. AI-Security wird immer mehr zu einem Problem der Protokoll- und Semantik-Sichtbarkeit.