Sophos AI Defense: KI-Nutzung erkennen und kontrollieren

Sophos AI Defense macht die Nutzung von KI-Anwendungen sichtbar und steuert, welche Dienste erlaubt, mit einer Warnung versehen oder blockiert werden. Das kostenpflichtige Add-on für qualifizierende Sophos-EDR-, XDR- und MDR-Umgebungen ist seit 13. Oktober 2026 allgemein verfügbar. Es wird in Sophos Fusion verwaltet und nutzt vorhandene Sophos-Sensoren. Eine Lizenz, eine sichtbare Kachel oder ein abgeschlossener Assistent allein beweisen aber noch keine vollständige Erfassung oder wirksame Durchsetzung.

Für eine Einführung empfiehlt sich diese Reihenfolge: Lizenz und Fusion-Zustand klären, Datenquellen und bestehende Richtlinien erfassen, die Sensorvoraussetzungen kontrolliert umsetzen und erst danach eine eng begrenzte Policy testen. Prompt-Inhaltsprüfung ist dabei keine zugesicherte aktuelle Schutzfunktion: Die Herstellerkommunikation ist hierzu widersprüchlich. Der sicher planbare Umfang dieses Artikels sind Sichtbarkeit, App-Zugriffspolicies und Reporting mit Prüfstand 20. Oktober 2026.

Was Shadow AI bedeutet und welches Problem AI Defense löst

Shadow AI ist KI-Nutzung, die ausserhalb der vorgesehenen Freigabe- und Kontrollprozesse stattfindet. Beispielsweise verwendet eine Mitarbeiterin einen zusätzlichen Web-Chat, ein Entwickler installiert einen Coding-Assistenten oder eine bestehende Anwendung erhält eine neue KI-Funktion. Der Dienst kann nützlich sein und trotzdem ungeklärte Regeln für hochgeladene Dokumente, Quellcode, Trainingsnutzung oder Datenstandorte haben.

AI Defense bringt dafür drei Fragen zusammen: Welche KI-Anwendungen werden verwendet, welches Risiko wird ihnen zugeordnet und welche Zugriffspolitik soll gelten? Die Produktübersicht nennt browserbasierte Sprachmodelle wie ChatGPT, Claude.ai und Copilot sowie neuere Coding-, Desktop- und Agentenanwendungen wie Claude Code, Cursor und OpenClaw. Diese Beispiele sind keine Garantie, jede Variante, API-Verbindung oder Aktivität auf jedem Gerät zu erkennen und zu kontrollieren. Entscheidend bleiben der konkrete Sensor und die tatsächlich beobachtete Abdeckung.

In den Auswertungen bedeutet Unsanctioned, dass eine verwendete App durch keine Policy ausdrücklich erlaubt ist. Das ist zunächst ein Freigabestatus, kein Beweis für Malware oder einen Datenabfluss. Umgekehrt macht ein erlaubter Dienst nicht automatisch jede Verwendung zulässig. Die organisatorische Regel, welche Daten in welchen Dienst dürfen, bleibt notwendig.

AI Defense ist zudem nicht der Sophos AI Assistant oder AI Search für XDR-Untersuchungen. Dort unterstützt KI die Arbeit der Analysten. AI Defense kontrolliert die KI-Nutzung in der Organisation. Weder der Name Fusion noch vorhandene Assistant-Funktionen schalten das Add-on automatisch frei.

Lizenz, Fusion und Sensoren vorab klären

Vor einer Bestellung und vor dem Setup sind unterschiedliche Voraussetzungen zu prüfen:

• Kaufberechtigung: AI Defense ist ein kostenpflichtiges Add-on für qualifizierende Sophos EDR-, XDR- und MDR-Kunden. Sophos nennt zusätzlich den Betrieb von Sophos EDR Endpoint Protection als Voraussetzung. Eine reine Sophos-Endpoint-Lizenz oder eine alleinstehende Sophos Firewall reicht daher nicht als Nachweis der Berechtigung. Den konkreten Vertragsumfang prüft man nach Lizenzen aktivieren und kontrollieren.
• Technischer Zugang: Das dokumentierte Setup verlangt einen auf die neue Plattform mit Security Operations aktualisierten Sophos-Fusion-Account. Der Fusion-Übergangscheck trennt Portalnamen und tatsächliches Produktupgrade.
• Taegis-Ausnahme beim Kauf: Berechtigte Taegis-Kunden können das Add-on bereits zur allgemeinen Verfügbarkeit kaufen, ohne ihre Fusion-Migration abzuwarten. Das ist keine dokumentierte Ausnahme von den technischen Setup-Voraussetzungen. Vor einer Einführung müssen Berechtigung, Bereitstellungsweg und Upgrade-Zustand mit dem zuständigen Sophos-Ansprechpartner geklärt werden.
• Passende Sensoren: Der Setup-Assistent bietet aktuell Sophos Endpoint, Sophos Firewall und Sophos Linux Server an. Die allgemeine Produktübersicht nennt zusätzlich DNS Protection, Protected Browser und Sophos Data Lake als Datenquellen. Diese breitere Architekturaufzählung darf nicht als identische Auswahlliste oder als gleiche Durchsetzungsfähigkeit aller Komponenten verstanden werden.

Vor Änderungen dokumentiert man betroffene Benutzer, Geräte und Netze, die bisherigen Policy-Werte, verantwortliche Admins und einen Rückweg. Daten-Uploads und HTTPS-Entschlüsselung berühren Datenschutz und bestehende Anwendungen. Ihre Freigabe gehört vor das Einschalten, nicht erst zur späteren Auswertung. Für den Pilot verwendet man einen freigegebenen Testbenutzer auf einem verwalteten Testgerät; notwendige Änderungen an gemeinsam genutzten Policies dürfen nicht unbeabsichtigt die ganze Organisation betreffen.

Sensoren vorbereiten und Onboarding durchführen

Man öffnet Sophos Fusion und danach My Products > AI Defense > Get started. Der Assistent fragt nach Adminrolle, Erfahrung mit KI-Werkzeugen, Benutzerzahl und Branche. Unter Choose your sensors wählt man die tatsächlich eingesetzten Sensoren aus. Danach sind deren Anforderungen zu bestätigen. Eine Checkbox bestätigt die eigene Prüfung; sie ersetzt keinen Nachweis der Wirkung.

Sophos Endpoint

Für den Endpoint-Sensor dokumentiert Sophos folgende Einstellungen:

1. Unter Endpoint > Policies > Data Collection and Investigation in der zutreffenden Policy Upload to the Data Lake einschalten und Process Data, HTTP Data, DNS Data sowie Network Data auswählen.
2. Unter Endpoint > Policies > Threat Protection die Einstellungen SSL/TLS decryption of HTTPS websites und Block QUIC browser connections einschalten. Die dokumentierte Erfassung setzt diese Konfiguration voraus; ohne Prüfung darf man nicht von gleichwertiger Sichtbarkeit ausgehen. HTTPS-Entschlüsselung und QUIC-Blockierung können Anwendungen beeinflussen. Änderungen deshalb kontrolliert pilotieren und bestehende Ausnahmen nicht pauschal entfernen.
3. Unter Global Settings > Protection and Remediation > Web Settings > Web Filtering Profiles ein Webprofil erstellen. Dieses unter Endpoint > Policies > Web Control den neuen oder bestehenden Policies für die vorgesehenen Benutzer und Geräte zuordnen. Es muss nicht überall dasselbe Profil verwendet werden.
4. Unter Endpoint > Policies > Application Control Detect controlled applications when users access them einschalten und Block the detected application auswählen. Vorhandene App-Zuordnungen und deren Wirkung vor der Änderung prüfen; den Bestand erklärt Endpoint Application Control.

Über Take me to settings gelangt man zur jeweiligen Konfiguration. Nach der Umsetzung kontrolliert man nochmals die tatsächliche Zuweisung zum Testgerät und bestätigt erst dann die Anforderungen im Assistenten.

Sophos Firewall und Linux Server

Für Sophos Firewall müssen die vorgesehenen Firewalls unter Firewall Management > Firewalls in die Gruppenverwaltung aufgenommen sein. Firewalls ausserhalb der Gruppenverwaltung erhalten keine AI-Defense-Durchsetzungsregeln. Zusätzlich ist das Logging in jeder relevanten Web-Policy erforderlich: Bei der Firewall über das Dreipunktmenü die Webadministration öffnen, unter Web die jeweilige Policy auswählen und deren Logging einschalten. Ohne dieses Logging fehlt die für die Erkennung benötigte Aktivität. Gruppenzugehörigkeit und bestehende Gruppenregeln vor einer Änderung prüfen, damit das Onboarding nicht unbemerkt andere Firewall-Einstellungen verändert.

Für Sophos Linux Server verlangt das Setup unter Server > Policies > Data Collection and Investigation den aktivierten Upload to the Data Lake mit Network Data. Daraus folgt nicht, dass Linux Server dieselben App-Zugriffskontrollen wie Endpoint oder Firewall durchsetzt. Die Policy-Vorschau zeigt später, für welches Produkt die konkrete Regel gilt.

Kann der Assistent den Sensorstatus nicht verifizieren, bietet er Refresh an. Bleibt die Prüfung erfolglos, lässt er ein Fortsetzen zu. Das ist kein positiver Sensortest: Die Abweichung bleibt offen und muss vor einer Schutzabnahme untersucht werden.

Base Policy nicht als unverbindlichen Entwurf behandeln

Unter Define your base protection wird eine noch fehlende Base Policy angelegt. Sie gilt für alle in der Organisation. Der Generative AI category default legt für Apps ohne eigene Regel Block, Warn oder Allow fest. App-spezifische Regeln haben Vorrang vor diesem Standard. Der Assistent zeigt dafür Apps aus den vergangenen 30 Tagen; das ist keine Aussage zur allgemeinen Datenaufbewahrung.

Mit Create base policy and finish wird die Base Policy erstellt. Dieser Schritt lässt sich auch überspringen. Besteht bereits eine Base Policy, verändert das Onboarding sie nicht; Finish and take me to the policy öffnet den vorhandenen Stand. Eine vom Partner vorbereitete Policy ist zuerst zu prüfen, nicht vorsorglich zu ersetzen. Über Settings > Restart onboarding lässt sich der Assistent erneut starten; das ist kein dokumentierter Reset oder Rückbau bestehender Policies.

Für einen begrenzten Versuch legt man keine organisationsweite Blockierregel auf Verdacht an. Zuerst wird geklärt, welcher globale Standard fachlich freigegeben ist. Die Pilot-Policy wird anschliessend mit einem ausdrücklich begrenzten Geltungsbereich erstellt.

AI-Defense-Policies sicher aufbauen

Unter My Products > AI Defense > Policies > Create policy erhält die neue Policy beispielsweise den frei gewählten Namen AI-Pilot-Freigegebene-Dienste. Eine Beschreibung hält Zweck, verantwortliche Person und geplantes Prüfdatum fest. Die Policy besteht aus Rules und Scope.

Regeln und Prioritäten

Sowohl die Policy-Liste als auch die Regeln innerhalb einer Policy werden von oben nach unten ausgewertet: Der erste passende Eintrag entscheidet. Eine richtige Regel unter einer früher passenden Regel kann deshalb ohne Wirkung bleiben.

Bei einer neuen zusätzlichen Policy ist standardmässig eine Regel vorhanden, die alle KI-Apps blockiert. Sophos empfiehlt, sie unten zu belassen und gezielte Freigaben darüber anzulegen. Für den Pilot darf diese Auffangregel nur auf den freigegebenen Testumfang wirken. Eine unbedachte Aktivierung für alle Benutzer könnte auch bisher erlaubte Arbeitsabläufe sperren.

Mit Add Rule wählt man die Action und über Add Filter eine Dimension sowie deren Value. Unterstützte Dimensionen umfassen beispielsweise Anwendung, Risikostufe und die in der Oberfläche angebotenen Compliance-Eigenschaften. Bei Application werden konkrete Apps aus der Liste gewählt. Man übernimmt nur tatsächlich verfügbare Werte; eine Risikoeinstufung ersetzt keine eigene Prüfung des Dienstes und des gebuchten Vertrags.

• Allow: Die passende App-Nutzung wird erlaubt.
• Warn: Benutzer erhalten einen Hinweis, dürfen den Dienst aber weiterverwenden. Das ist kein Ersatz für eine Sperre.
• Block: Die passende App-Nutzung soll über das unterstützte Produkt blockiert werden. Ob dies für den geplanten Zugriffsweg funktioniert, muss der Pilot zeigen.

Ein geeignetes Testbeispiel ist eine ausdrücklich erlaubte App oberhalb der Blockier-Auffangregel und eine zweite, für den Versuch freigegebene App ohne eigene Freigabe. So lässt sich die beabsichtigte Ausnahmelogik prüfen, ohne echte vertrauliche Inhalte zu verwenden. Die App-Namen und deren Freigabe bestimmt die Organisation; die Produktbeispiele oben sind keine Nutzungsempfehlung.

Geltungsbereich und Aktivierung

Unter Scope begrenzt man die Policy auf die vorgesehenen Benutzer, Gruppen oder Netze, beispielsweise über Specific Users and Groups auf eine vorhandene Testgruppe. Die Seite zeigt, ob die Policy auf Sophos Endpoint oder Sophos Firewall angewendet wird. Unter What will happen müssen Regeln, Scope und Produktwirkung vor der Bestätigung I’ve reviewed the rules and scope above zusammenpassen.

Save speichert die zusätzliche Policy ohne Aktivierung. So lässt sich zuerst ihre Position in der Liste prüfen. Save & Enable aktiviert sie dagegen sofort mit höchster Priorität. Für den vorbereiteten Pilot empfiehlt sich deshalb zunächst Save; vor einer späteren Aktivierung werden Position und Scope erneut geprüft. Der dokumentierte sichere Unterschied zwischen den Schaltflächen gilt für zusätzlich erstellte Policies und darf nicht pauschal auf den Base-Policy-Abschluss übertragen werden.

Vorlagen unter Browse templates > Use und Clone im Dreipunktmenü können Arbeit sparen. Sie liefern aber bereits vorausgefüllte Regeln beziehungsweise den kopierten Scope. Beides muss vor dem Speichern auf die eigene Umgebung angepasst werden. Bestehende Policies lassen sich über ihren Listeneintrag, das Edit-Symbol einer Regel mit Save Rule und Scope > Edit bearbeiten.

Nutzung, Risiken und Reports richtig lesen

Unter My Products > AI Defense helfen mehrere Ansichten bei unterschiedlichen Fragen. Immer zuerst über das Kalendersymbol den passenden Zeitraum wählen:

• Dashboard: Zeigt Gesamtaktivität, blockierte Aktivitäten, eindeutige Apps und Benutzer sowie die Verteilung auf Allow, Block und Warn. Dazu kommen häufige Apps und Benutzer, Shadow AI, Risikoverteilung, Nutzungsfluss und zeitlicher Verlauf. Der Security-Posture-Score bis 100 berücksichtigt Sensorabdeckung, Policy-Reife und Nutzungsrisiko. Ein hoher Wert ist keine Garantie für vollständigen Schutz.
• AI Defense Activity: Zeigt Anwendung, Actor als Gerät, Risiko, Sensor, Zeitpunkt, Aktion und auslösende Policy. Unknown bedeutet, dass kein Urteil erfasst wurde, nicht dass die Aktivität sicher erlaubt war. Die Risikostufen reichen von Low über Medium und High bis Critical. Über die Widgets lässt sich beispielsweise nach erlaubten Aktivitäten filtern; Export liefert CSV.
• Inventory > Apps beziehungsweise Users: Hilft, tatsächlich beobachtete Apps und Nutzer zu prüfen. Unsanctioned Use zeigt fehlende ausdrückliche Freigabe, Trains on Data die erfasste Information zur Trainingsnutzung des Anbieters. Die App-Risikoeinstufung berücksichtigt unter anderem Compliance-Nachweise und Trainingspraktiken. In der App-Nutzung gruppiert eine Aktivität die Verwendung einer App durch ein Gerät in 10-Minuten-Fenster. Aktivitätszahlen sind deshalb keine Anzahl einzelner Prompts. Beide Inventarlisten lassen sich als CSV exportieren.
• Detections: Zeigt etwa eine erstmals erkannte App, risikoreiche Nutzung oder die Verwendung einer nicht freigegebenen App. Threat score reicht von 0 bis 10, Severity von Info bis Critical. Filter grenzen Severity, Threat Score oder Titel ein. Die Detailansicht bietet Beschreibung, betroffenen Benutzer oder Host, empfohlene Aktion und unter JSON die zugrunde liegenden Daten. Exporte sind als formatiertes CSV, CSV oder JSON möglich.

In den App-Details lassen sich Funktion, Risikozusammenfassung, Trainingsregeln, Compliance und Datennutzung näher betrachten; die Aktivitätsdetails nennen auch Data Residency. Diese Informationen sind Entscheidungshilfen, aber keine Bestätigung, dass der eigene konkrete Tarif, Account oder eine individuelle Auftragsbearbeitungsvereinbarung identische Bedingungen hat.

Nach der Untersuchung einer Detection dokumentiert man im Detailfenster einen begründeten Status: True positive benign, True positive malicious, False positive oder Not actionable. Eine korrekt erkannte Nutzung kann harmlos sein; sie darf nicht allein wegen des Detection-Eintrags als erfolgreicher Angriff eingestuft werden.

Für einen Bericht öffnet man AI Defense > Reports > AI Risk Assessment Report > Generate, wählt Report period und bei Bedarf Download PDF. Der Bericht bündelt App-Risiken, Shadow-AI-Exposition und den Vergleich der Risikominderung zwischen Berichtszeiträumen. Die Top-Five-Listen sind Ausschnitte, kein vollständiges Inventar. Das ist ein eigener AI-Defense-Bericht und keine Zusage zur automatischen Zustellung von MDR-Berichten. Exporte können Benutzer- und Gerätedaten enthalten und gehören in eine zugriffsbeschränkte Ablage mit vereinbarter Aufbewahrung.

Einen Pilot validieren und Fehler eingrenzen

Die folgende Prüfung ist ein vorgeschlagener Abnahmeablauf, kein von Avanet ausgeführter Tenant- oder Labortest. Man vereinbart Testfenster, Testgerät, Benutzer, erlaubte Dienste und erwartete Aktionen vorab. Es werden nur freigegebene, synthetische Testdaten verwendet, beispielsweise Nur ein Funktionstest ohne Unternehmensdaten. Keine Kundendaten, Zugangsdaten, internen Dokumente oder echter Quellcode werden an einen KI-Dienst übertragen. Für einen reinen Zugriffstest ist keine Eingabe vertraulicher Inhalte erforderlich.

1. Mit einer ausdrücklich erlaubten App beginnen und dann die für den Pilot vorgesehene Blockier- oder Warnregel prüfen. Je Versuch Dienst, Gerät, Zeitpunkt und tatsächliche Benutzerreaktion notieren. Bei Warn muss eine Fortsetzung möglich bleiben; bei Block darf der getestete Zugriffsweg nicht nutzbar sein.
2. In AI Defense Activity für denselben Zeitraum Anwendung, Actor, Sensor, Action und Policy abgleichen. Die sichtbare Sperre und der zugehörige Eintrag müssen zum beabsichtigten Versuch passen. Eine Sperrseite allein könnte auch von einer bisherigen Web- oder Application-Control-Regel stammen.
3. In Inventory kontrollieren, ob die App und der erwartete Freigabestatus erscheinen. Nutzungszahlen wegen der 10-Minuten-Gruppierung nicht mit einzelnen Eingaben vergleichen. Im Bericht denselben Zeitraum verwenden. Es ist keine feste Anzeigelatenz dokumentiert; fehlende Einträge nicht mit beliebig vielen Tests kaschieren.
4. Einen nicht zur Pilotgruppe gehörenden Benutzer beziehungsweise ein unbeteiligtes Gerät gegenprüfen. Dessen freigegebene Arbeitsabläufe sollen unverändert bleiben. Erst nach dokumentierter Abnahme wird der Scope schrittweise erweitert.

App wird nicht sichtbar: Zuerst Zeitraum, tatsächlich erfassten Zugriffsweg und Sensor prüfen. Danach die Daten-Uploads und beim Endpoint die dokumentierten Threat-, Web- und Application-Control-Einstellungen kontrollieren. Bei Firewall-Erfassung zusätzlich Web-Policy-Logging prüfen. Ein leeres Dashboard beweist nicht, dass keine KI verwendet wird.

App erscheint, aber die gewünschte Aktion greift nicht: Aktivierungszustand, Policy-Reihenfolge, Regelreihenfolge, Scope und Produktanzeige in What will happen vergleichen. Bei Firewall-Durchsetzung auch die Gruppenverwaltung prüfen. Nicht durch eine breite organisationsweite Sperre oder das Abschalten bestehender Schutzfunktionen nachbessern.

Nach einer Änderung funktioniert eine Arbeitsanwendung nicht mehr: Den letzten Change mit den vorher dokumentierten Werten vergleichen und den Pilot zurücknehmen. Keine pauschalen TLS-Ausnahmen oder globalen Allow-Regeln anlegen, um den Fehler zu verdecken.

Bleibt eine Abweichung ungeklärt, werden bereinigte Ereignisse, Zeitraum mit Zeitzone, Sensor, Gerät, erwartete Aktion, tatsächliche Reaktion sowie Policy-Reihenfolge und Scope gesammelt. Mit diesen Angaben lässt sich ein Sophos-Supportfall eröffnen, ohne vertrauliche Prompts weiterzugeben.

Rückweg und Grenzen des Schutzes

Vor dem Pilot hält man den bisherigen Regelsatz, die Reihenfolge, den Scope und die geänderten Sensor-Policies fest. Für einen Rückweg wird eine störende Pilotregel über die dokumentierte Policy-Bearbeitung auf ihren vorherigen Stand gebracht oder der Pilot-Scope auf den vorher freigegebenen Umfang zurückgesetzt. Anschliessend werden der zuvor erlaubte Arbeitsablauf und die Aktivitätsanzeige erneut geprüft. Eine veränderte Base Policy muss anhand ihres vorher dokumentierten Standards und ihrer App-Ausnahmen gezielt wiederhergestellt werden. Restart onboarding setzt sie nicht zurück.

Sensoränderungen dürfen nur auf die konkret vorherigen Werte zurückgenommen werden, wenn sie eigens für den Versuch geändert wurden und keine anderen Schutz- oder Untersuchungsaufgaben davon abhängen. Insbesondere Data-Lake-Uploads, TLS-Entschlüsselung oder Application Control nicht pauschal abschalten. Schon erfasste Telemetrie oder exportierte Berichte werden durch den Policy-Rückbau nicht automatisch gelöscht. Für deren Behandlung gilt der vereinbarte Datenschutz- und Aufbewahrungsprozess.

Für die Planung bleiben drei Grenzen wichtig:

• Sichtbarkeit ist keine lückenlose Kontrolle. Ein nicht erfasster privater Endpoint, ein anderer Zugriffsweg oder eine fehlende Sensorvoraussetzung lässt sich durch eine zentrale Policy allein nicht absichern. App-Erkennung beweist auch nicht, dass alle autonomen Aktionen eines Agenten kontrolliert werden.
• App-Zugriffskontrolle ist keine zugesicherte Prompt-DLP. Die GA-Pressekommunikation beschreibt die Echtzeitprüfung von Prompts und Uploads bereits als Funktion. Die spätere Partnerinformation ordnet Promptprüfung und -schutz ausdrücklich künftigen Releases zu. Solange der konkrete Funktionsumfang nicht belastbar bestätigt ist, plant man dafür keine Schutzwirkung ein und testet sie insbesondere nicht mit echten vertraulichen Daten.
• Roadmap ist kein Beschaffungsversprechen. Auch die Unterscheidung privater und geschäftlicher KI-Accounts sowie zusätzliche Agentenschutzfunktionen sind als Roadmap beschrieben, ohne verbindlichen Termin. Wer genau diese Funktionen benötigt, muss sie vor einer Entscheidung für den eigenen Tenant bestätigen lassen und separat abnehmen.

Der tragfähige Einstieg ist deshalb nicht «KI ist jetzt abgesichert», sondern ein überprüfbares Inventar, bewusst freigegebene Dienste, begrenzte Policies und ein wiederholbarer Nachweis ihrer tatsächlichen Wirkung.