Als mein Team vor einem Jahr die KI-Kategorie in unserem Secure Web Gateway (SWG) eingeführt hat, war bereits klar: KI-gestützte Tools lassen sich nicht länger ausblenden. Unternehmen wollen wissen, welche Systeme im Einsatz sind, und diese gezielt steuern können. Bereits damals war das Risiko von Schatten-KI schon real. In den Monaten seit unserem Launch hat sich die KI-Landschaft erheblich Fahrt aufgenommen: Neue Serviceklassen, autonome Agents und engere Verzahnungen machen es immer schwieriger, eine klare Grenze zwischen Tool und handelndem System zu ziehen.

Wir gehen daher den nächsten Schritt: Wir verfeinern unsere KI-Taxonomie um zwei zusätzliche, granularere Kategorien. Und künftig erweitern wir die Kontrollmöglichkeiten sowohl auf URL-Filter- als auch auf CASB-Ebene. Unser Ziel bleibt: Organisationen helfen, Risiken vorauszusehen, ohne dabei Innovation auszubremsen.

Von einer generischen Kategorie zu einer differenzierten Sicht

Zum Start fasste die Kategorie Generische KI sämtliche KI-basierten Plattformen, APIs, Services und Anwendungen zusammen (mehr dazu in meinem Blogpost “KI-Tools sicher nutzen: Mehr Kontrolle für Unternehmen”). Dieser erste Schritt brachte Unternehmen dringend notwendige Transparenz darüber, wie viel KI tatsächlich in ihren Netzwerken unterwegs ist.

Doch die KI-Welt hat sich im vergangenen Jahr massiv verändert:

  • Generative Modelle erstellen Bilder, Videos, Audio und Code auf Knopfdruck.
  • KI-Agents agieren eigenständig und interagieren mit APIs, Drittanbieter-Services oder interne Systeme.
  • Standards und Protokolle wie das Model Context Protocol (MCP) ermöglichen KI-Systemen in Echtzeit Zugriff auf Unternehmensdatenquellen, was die Grenzen zwischen KI-Tool und Datenpipeline weiter verwischt.

Eine einzige Kategorie kann diese Vielfalt nicht mehr sinnvoll abbilden. Unterschiedliche Nutzungsformen bedeuten unterschiedliche Risiken und benötigen unterschiedliche Kontrollen.

In einer Tabelle sind Kategorien wie "KI-Agenten", "Generative KI" und "Anonymisierer" aufgeführt. Die Spalte "Block" enthält Häkchen für "KI-Agenten" und "Generative KI". Die Zeilen sind abwechselnd ausgefüllt und leer.
Abbildung 1: Neue KI-Subkategorien werden unterstützt.

Wir ergänzen deshalb zwei zusätzliche Unterkategorien:

  • Generative AI: Plattformen und Services, die KI-Technologie nutzen, um Inhalte wie Text, Bilder oder Code auf Basis von Benutzeranweisungen zu generieren. Beispiele sind ChatGPT, Gemini, Claude, Bild- und Videosynthese oder Code-Generatoren.
  • AI Agents: Autonome Systeme oder Services, die nicht nur Antworten berechnen, sondern mit ihrer Umgebung interagieren: API-Verbindungen, Entscheidungen, Aktionen, Zugriff auf externe Systeme oder Unternehmensdaten. Hierzu zählen MCP-Server, autonome Assistenten oder Agent-Orchestrierungs-Frameworks sowie Websites, die solche Agents bereitstellen oder listen.

So wird sichtbar, wie KI genutzt wird – nicht nur, dass sie genutzt wird.

Weshalb diese Differenzierung wichtig ist

1. Neue Angriffsflächen und unsichtbare Verbindungen

Generative KI hat enorme Möglichkeiten, doch die typischen Risiken sind inzwischen klar benannt: mögliche Datenabflüsse über Prompts, unklare Rechte oder Angriffe wie Prompt Injection.

KI-Agents hingegen eröffnen eine neue Risikoklasse. Da sie handeln und nicht nur reagieren, können sie Verbindungen zu Drittanbieter-APIs, internen Datenbanken und Cloud-Services initiieren, und zwar teilweise unsichtbar. Solche Interaktionen könnten bestehende Kontrollen umgehen und versteckte Kanäle für Datenabfluss, laterale Bewegung oder unautorisierte Automatisierung schaffen.

Die Folge: Sicherheitsperimeter müssen sich nicht nur an Websites orientieren, sondern an agentischem Verhalten.

2. Policies nach Risikogehalt steuern

Die klare Trennung der Kategorien ermöglicht differenzierte Vorgaben:

  • Mitarbeitende ohne Kontakt zu sensiblen Daten können generative KI breiter nutzen.
  • Agentenbasierte Funktionen werden kontrolliert oder auf klar definierte Bereiche begrenzt.
  • Generative KI kann im Warnmodus bereitgestellt werden, um Nutzende vorab auf Datenrisiken hinzuweisen.

Gleichzeitig erhalten Security-Teams eine bessere Datenbasis:

  • Welche Abteilungen arbeiten mit KI-Agents?
  • Welche Tools setzen sich tatsächlich durch?

Präziser steuern mit URL-Filter: Allow, Block und Warn

In unserer ersten Version bestand die Steuerung aus Allow oder Deny. Dieser Ansatz war notwendig, um die neue Kategorie einzuführen, ohne operative Abläufe zu stören. Wir setzten KI standardmässig auf “erlaubt”, ausser in bestehenden Deny-all-Policies unserer Kunden, und stimmten uns eng mit unseren Technical Account Managers ab, um Erwartungen transparent zu managen und Überraschungen zu vermeiden

Jetzt kommt eine dritte Option hinzu: Warn.

  • Allow: Zugriff wird ohne Unterbruch gewährt
  • Block: Zugriff wird vollständig verhindert
  • Warn: Risiko-Hinweis für die Benutzerin oder den Benutzer, mit expliziter Bestätigung

Diese Zwischenstufe erlaubt eine sanftere Steuerung: Sichtbarkeit und Nutzeraufklärung, ohne sofort zu blockieren. Sie unterstützt einen schrittweisen, gezielten Übergang zu stärkerer Governance rund um KI-Nutzung.

Diese Policy-Aktionen stehen für alle KI-Kategorien (Generisch, Generativ, Agent) zur Verfügung. Da jede ein anderes Risikoprofil aufweist, können Administratoren passende Standardaktionen definieren.

Mehr Kontrolle in der Interaktion: CASB-Integration

URL-Filtering entscheidet, ob ein Zugriff erlaubt wird. CASB kontrolliert, wie ein Service genutzt wird.

Durch die Abbildung derselben KI-Kategorien in die CASB-Ebene können Unternehmen:
  • Shadow AI erkennen – also Dienste aufspüren, die ausserhalb des genehmigten SaaS-Portfolios genutzt werden.
  • Feingranulare Richtlinien für Benutzeraktionen durchsetzen, etwa Uploads und Downloads im Zusammenhang mit generativer KI verbieten.
  • Oder im Allgemeinen CASB-Funktionen wie Data Loss Prevention (DLP) einsetzen, um zu verhindern, dass vertrauliche Inhalte in KI-Prompts gelangen, oder um agentisches Verhalten zu erkennen und zu kontrollieren.
Ein Dashboard-Bildschirm zeigt eine "Cloud Access Security Broker Block List" mit blockierten Anwendungen, Risikobewertungen, Richtliniengruppen und Kundenreferenzen. Die Optionen zum Filtern, Exportieren und Ändern der Zeitauswahl sind oben sichtbar.
Abbildung 2: CASB Block List im Open Systems Kundenportal

CASB bedeutet klar: Zugriffskontrolle plus Interaktionskontrolle.

Konkrete Vorteile für Security und Nutzer

Diese neue KI-Taxonomie und die mehrschichtige Kontrolle ermöglichen:

  • Präzisere Analytics: Traffic nach generativer und agentischer Nutzung unterscheidbar
  • Realistische Risikobewertung: Policies nach Gefahr abgestuft
  • Mehr Nutzerbewusstsein: Warnmeldungen fördern reflektierte Datennutzung
  • Besserer Schutz sensibler Daten: Agentenkanäle lassen sich hart absichern
  • Sicher unterstützte Innovation: generative KI bleibt dort erlaubt, wo sie Mehrwert schafft

Sicherheitsteams erhalten den Überblick, den sie brauchen, und Nutzende bleiben handlungsfähig.

Innovation sicher unterstützen

Die KI-Entwicklung ist dynamisch. Neue agentische Systeme, hybride Modelle und Protokolle kommen schnell auf uns zu.

Wir investieren kontinuierlich in URL-Filter- und CASB-Funktionen, damit Unternehmen ihre Daten und Prozesse schützen können – ohne die Innovationskraft einzuschränken.

Denn im Umfeld der KI zählt es mehr denn je, ein sicherer, transparenter und agiler Enabler des Fortschritts zu sein.