Sophos AI Defense : détecter et contrôler l'utilisation de l'IA

Sophos AI Defense rend visible l’utilisation des applications d’IA et détermine quels services sont autorisés, accompagnés d’un avertissement ou bloqués. Ce module complémentaire payant pour les environnements Sophos EDR, XDR et MDR éligibles est disponible de manière générale depuis le 13 octobre 2026. Il se gère dans Sophos Fusion et utilise les capteurs Sophos existants. Toutefois, une licence, une tuile visible ou un assistant terminé ne prouvent pas à eux seuls que la collecte soit complète ou que les règles soient effectivement appliquées.

Pour le déploiement, suivez cet ordre : clarifier la licence et l’état de Fusion, recenser les sources de données et les stratégies existantes, mettre en œuvre les prérequis des capteurs de manière contrôlée, puis seulement tester une stratégie au périmètre très limité. L’inspection du contenu des prompts n’est pas une fonction de protection actuelle garantie : la communication du fabricant est contradictoire sur ce point. Le périmètre sur lequel cet article permet de planifier de façon fiable comprend la visibilité, les stratégies d’accès aux applications et les rapports, selon les vérifications du 20 octobre 2026.

Ce que signifie Shadow AI et le problème auquel répond AI Defense

La Shadow AI désigne l’utilisation de l’IA en dehors des processus de validation et de contrôle prévus. Par exemple, une collaboratrice utilise un nouveau chat web, un développeur installe un assistant de programmation ou une application existante reçoit une nouvelle fonction d’IA. Le service peut être utile, tout en laissant ouvertes les règles relatives aux documents transférés, au code source, à l’utilisation des données pour l’entraînement ou à leur localisation.

AI Defense réunit trois questions : quelles applications d’IA sont utilisées, quel risque leur est attribué et quelle stratégie d’accès doit s’appliquer ? La présentation produit cite des modèles de langage accessibles par navigateur tels que ChatGPT, Claude.ai et Copilot, ainsi que des applications plus récentes de programmation, de bureau et d’agents comme Claude Code, Cursor et OpenClaw. Ces exemples ne garantissent pas la détection et le contrôle de chaque variante, connexion API ou activité sur chaque appareil. Le capteur concerné et la couverture réellement observée restent déterminants.

Dans les analyses, Unsanctioned signifie qu’aucune stratégie n’autorise expressément une application utilisée. Il s’agit d’abord d’un statut d’approbation, et non d’une preuve de malware ou de fuite de données. À l’inverse, l’autorisation d’un service ne rend pas automatiquement tous ses usages acceptables. Une règle organisationnelle définissant quelles données peuvent être transmises à quel service reste nécessaire.

AI Defense n’est pas non plus Sophos AI Assistant ou AI Search pour les investigations XDR. Ces fonctions utilisent l’IA pour aider les analystes dans leur travail. AI Defense contrôle l’utilisation de l’IA au sein de l’organisation. Ni le nom Fusion ni les fonctions Assistant existantes n’activent automatiquement ce module complémentaire.

Clarifier au préalable les licences, Fusion et les capteurs

Avant la commande et avant la configuration, vérifiez des prérequis distincts :

Éligibilité à l’achat : AI Defense est un module complémentaire payant pour les clients Sophos EDR, XDR et MDR éligibles. Sophos indique également l’utilisation de Sophos EDR Endpoint Protection comme prérequis. Une simple licence Sophos Endpoint ou un Sophos Firewall seul ne suffit donc pas à prouver l’éligibilité. Vérifiez le périmètre contractuel précis en suivant Activer et contrôler les licences.
Accès technique : la configuration documentée nécessite un compte Sophos Fusion mis à niveau vers la nouvelle plateforme avec Security Operations. Le contrôle de transition Fusion distingue le nom du portail de la mise à niveau effective du produit.
Exception Taegis pour l’achat : les clients Taegis éligibles peuvent acheter le module dès sa disponibilité générale sans attendre leur migration Fusion. Il ne s’agit pas d’une exception documentée aux prérequis techniques de configuration. Avant le déploiement, clarifiez l’éligibilité, le mode de mise à disposition et l’état de la mise à niveau avec votre interlocuteur Sophos.
Capteurs adaptés : l’assistant de configuration propose actuellement Sophos Endpoint, Sophos Firewall et Sophos Linux Server. La présentation générale du produit cite également DNS Protection, Protected Browser et Sophos Data Lake comme sources de données. Cette liste d’architecture plus large ne doit pas être interprétée comme une liste de sélection identique ni comme une capacité d’application des règles équivalente pour tous les composants.

Avant les modifications, documentez les utilisateurs, appareils et réseaux concernés, les valeurs actuelles des stratégies, les administrateurs responsables et une procédure de retour arrière. Les transferts de données et le déchiffrement HTTPS touchent à la protection des données et aux applications existantes. Leur approbation doit précéder l’activation, et non attendre l’analyse ultérieure. Pour le pilote, utilisez un utilisateur de test autorisé sur un appareil de test géré ; les modifications nécessaires de stratégies partagées ne doivent pas affecter involontairement toute l’organisation.

Préparer les capteurs et effectuer la configuration initiale

Ouvrez Sophos Fusion, puis My Products > AI Defense > Get started. L’assistant demande votre rôle d’administration, votre expérience des outils d’IA, le nombre d’utilisateurs et le secteur d’activité. Sous Choose your sensors, sélectionnez les capteurs réellement utilisés. Vous devez ensuite confirmer leurs prérequis. Cocher une case confirme que vous avez effectué la vérification ; cela ne remplace pas une preuve de l’effet obtenu.

Sophos Endpoint

Pour le capteur Endpoint, Sophos documente les paramètres suivants :

Sous Endpoint > Policies > Data Collection and Investigation, activez Upload to the Data Lake dans la stratégie concernée et sélectionnez Process Data, HTTP Data, DNS Data et Network Data.
Sous Endpoint > Policies > Threat Protection, activez SSL/TLS decryption of HTTPS websites et Block QUIC browser connections. La collecte documentée repose sur cette configuration ; sans vérification, ne présumez pas une visibilité équivalente. Le déchiffrement HTTPS et le blocage de QUIC peuvent affecter les applications. Testez donc les changements dans un pilote contrôlé et ne supprimez pas systématiquement les exceptions existantes.
Sous Global Settings > Protection and Remediation > Web Settings > Web Filtering Profiles, créez un profil web. Affectez-le ensuite sous Endpoint > Policies > Web Control aux stratégies nouvelles ou existantes des utilisateurs et appareils prévus. Il n’est pas nécessaire d’utiliser partout le même profil.
Sous Endpoint > Policies > Application Control, activez Detect controlled applications when users access them et sélectionnez Block the detected application. Vérifiez les affectations d’applications existantes et leurs effets avant la modification ; Endpoint Application Control explique la configuration existante.

Take me to settings ouvre la configuration correspondante. Après la mise en œuvre, vérifiez à nouveau l’affectation effective à l’appareil de test, puis seulement confirmez les prérequis dans l’assistant.

Sophos Firewall et Linux Server

Pour Sophos Firewall, les firewalls prévus doivent être intégrés à la gestion par groupes sous Firewall Management > Firewalls. Les firewalls non gérés par groupes ne reçoivent pas les règles d’application d’AI Defense. La journalisation doit également être activée dans chaque stratégie web pertinente : ouvrez l’administration web du firewall via son menu à trois points, sélectionnez la stratégie sous Web et activez sa journalisation. Sans celle-ci, l’activité nécessaire à la détection manque. Vérifiez l’appartenance aux groupes et les règles de groupe existantes avant toute modification afin que la configuration initiale ne change pas d’autres paramètres du firewall à votre insu.

Pour Sophos Linux Server, la configuration exige Upload to the Data Lake activé avec Network Data sous Server > Policies > Data Collection and Investigation. Cela ne signifie pas que Linux Server applique les mêmes contrôles d’accès aux applications qu’Endpoint ou Firewall. L’aperçu de la stratégie indique ensuite à quel produit s’applique la règle concernée.

Si l’assistant ne parvient pas à vérifier l’état des capteurs, il propose Refresh. Si la vérification échoue toujours, il permet de continuer. Cela ne constitue pas un test positif des capteurs : l’écart reste ouvert et doit être examiné avant de valider la protection.

Ne pas traiter la Base Policy comme un simple brouillon sans effet

Sous Define your base protection, une Base Policy est créée si elle n’existe pas encore. Elle s’applique à toutes les personnes de l’organisation. Generative AI category default définit Block, Warn ou Allow pour les applications sans règle spécifique. Les règles propres aux applications priment sur cette valeur par défaut. L’assistant présente les applications des 30 derniers jours ; cela ne précise pas la durée générale de conservation des données.

Create base policy and finish crée la Base Policy. Cette étape peut également être ignorée. Si une Base Policy existe déjà, la configuration initiale ne la modifie pas ; Finish and take me to the policy ouvre l’état existant. Une stratégie préparée par le partenaire doit d’abord être examinée, et non remplacée par précaution. Settings > Restart onboarding permet de relancer l’assistant ; ce n’est pas une réinitialisation ni un retour arrière documenté des stratégies existantes.

Pour un essai limité, ne créez pas de règle de blocage à l’échelle de l’organisation sur la base d’une supposition. Clarifiez d’abord la valeur globale par défaut approuvée par les responsables. Créez ensuite la stratégie pilote avec un périmètre expressément limité.

Construire des stratégies AI Defense en toute sécurité

Sous My Products > AI Defense > Policies > Create policy, donnez à la nouvelle stratégie un nom librement choisi, par exemple AI-Pilot-Freigegebene-Dienste. Indiquez son objectif, la personne responsable et la date de contrôle prévue dans sa description. La stratégie se compose de Rules et de Scope.

Règles et priorités

La liste des stratégies et les règles à l’intérieur d’une stratégie sont évaluées de haut en bas : la première entrée correspondante décide. Une règle correcte placée sous une règle qui correspond plus tôt peut donc rester sans effet.

Une nouvelle stratégie supplémentaire contient par défaut une règle qui bloque toutes les applications d’IA. Sophos recommande de la laisser en bas et de placer les autorisations ciblées au-dessus. Pour le pilote, cette règle de blocage par défaut ne doit concerner que le périmètre de test approuvé. Une activation irréfléchie pour tous les utilisateurs pourrait également bloquer des processus de travail jusque-là autorisés.

Avec Add Rule, choisissez l’Action, puis une Dimension et sa Value via Add Filter. Les dimensions prises en charge comprennent, par exemple, l’application, le niveau de risque et les propriétés de conformité proposées dans l’interface. Pour Application, sélectionnez des applications précises dans la liste. Utilisez uniquement les valeurs réellement disponibles ; une classification du risque ne remplace pas votre propre examen du service et du contrat souscrit.

Allow : l’utilisation de l’application correspondante est autorisée.
Warn : les utilisateurs reçoivent un avertissement, mais peuvent continuer à utiliser le service. Ce n’est pas un substitut au blocage.
Block : l’utilisation de l’application correspondante doit être bloquée via le produit pris en charge. Le pilote doit montrer si cela fonctionne pour le mode d’accès prévu.

Un exemple de test adapté consiste à placer une application expressément autorisée au-dessus de la règle de blocage par défaut et à utiliser une seconde application approuvée pour le test, mais sans autorisation spécifique dans la stratégie. Vous pouvez ainsi vérifier la logique d’exception prévue sans utiliser de véritables contenus confidentiels. L’organisation détermine les noms des applications et leur approbation ; les exemples de produits ci-dessus ne sont pas des recommandations d’utilisation.

Périmètre et activation

Sous Scope, limitez la stratégie aux utilisateurs, groupes ou réseaux prévus, par exemple à un groupe de test existant via Specific Users and Groups. La page indique si la stratégie s’applique à Sophos Endpoint ou à Sophos Firewall. Sous What will happen, les règles, le périmètre et l’effet sur le produit doivent être cohérents avant de confirmer I’ve reviewed the rules and scope above.

Save enregistre la stratégie supplémentaire sans l’activer. Vous pouvez ainsi vérifier d’abord sa position dans la liste. Save & Enable, en revanche, l’active immédiatement avec la priorité la plus élevée. Pour le pilote préparé, commencez donc de préférence par Save ; avant une activation ultérieure, vérifiez à nouveau la position et le périmètre. La différence de sécurité documentée entre ces boutons concerne les stratégies supplémentaires et ne doit pas être étendue systématiquement à la finalisation de la Base Policy.

Les modèles sous Browse templates > Use et Clone dans le menu à trois points peuvent faire gagner du temps. Ils contiennent toutefois déjà des règles préremplies ou le périmètre copié. Adaptez ces deux éléments à votre environnement avant l’enregistrement. Pour modifier les stratégies existantes, ouvrez leur entrée dans la liste, utilisez l’icône Edit d’une règle avec Save Rule, ainsi que Scope > Edit.

Interpréter correctement l’utilisation, les risques et les rapports

Sous My Products > AI Defense, plusieurs vues répondent à des questions différentes. Commencez toujours par choisir la période appropriée à l’aide de l’icône de calendrier :

Dashboard : affiche l’activité totale, les activités bloquées, les applications et utilisateurs uniques ainsi que la répartition entre Allow, Block et Warn. S’y ajoutent les applications et utilisateurs les plus fréquents, la Shadow AI, la répartition des risques, les flux d’utilisation et l’évolution dans le temps. Le score de posture de sécurité, jusqu’à 100, tient compte de la couverture des capteurs, de la maturité des stratégies et du risque d’utilisation. Une valeur élevée ne garantit pas une protection complète.
AI Defense Activity : affiche l’application, Actor sous la forme d’un appareil, le risque, le capteur, l’heure, l’action et la stratégie à l’origine de celle-ci. Unknown signifie qu’aucun verdict n’a été enregistré, et non que l’activité était assurément autorisée. Les niveaux de risque vont de Low à Critical, en passant par Medium et High. Les widgets permettent, par exemple, de filtrer les activités autorisées ; Export fournit un fichier CSV.
Inventory > Apps ou Users : permet de vérifier les applications et utilisateurs réellement observés. Unsanctioned Use indique l’absence d’autorisation explicite, et Trains on Data l’information enregistrée sur l’utilisation des données par le fournisseur pour l’entraînement. La classification du risque de l’application tient notamment compte des justificatifs de conformité et des pratiques d’entraînement. Dans l’utilisation des applications, une activité regroupe l’usage d’une application par un appareil dans des fenêtres de 10 minutes. Le nombre d’activités ne correspond donc pas au nombre de prompts individuels. Les deux listes d’inventaire sont exportables en CSV.
Detections : affiche notamment une application détectée pour la première fois, une utilisation à risque ou l’utilisation d’une application non approuvée. Threat score va de 0 à 10, et Severity d’Info à Critical. Les filtres permettent de restreindre les résultats selon Severity, Threat Score ou le titre. La vue détaillée fournit une description, l’utilisateur ou l’hôte concerné, l’action recommandée et, sous JSON, les données sous-jacentes. Les exports sont possibles en CSV formaté, CSV ou JSON.

Les détails des applications permettent d’examiner leur fonction, le résumé des risques, les règles d’entraînement, la conformité et l’utilisation des données ; les détails de l’activité indiquent aussi Data Residency. Ces informations aident à la décision, mais ne confirment pas que votre offre, votre compte ou un accord individuel de traitement des données soient soumis à des conditions identiques.

Après l’investigation d’une Detection, consignez un statut justifié dans la fenêtre détaillée : True positive benign, True positive malicious, False positive ou Not actionable. Une utilisation correctement détectée peut être bénigne ; la seule présence d’une Detection ne permet pas de la classer comme une attaque réussie.

Pour produire un rapport, ouvrez AI Defense > Reports > AI Risk Assessment Report > Generate, sélectionnez Report period et, si nécessaire, Download PDF. Le rapport regroupe les risques des applications, l’exposition à la Shadow AI et la comparaison de la réduction des risques entre les périodes de rapport. Les listes des cinq premiers éléments ne sont que des extraits, et non un inventaire complet. Il s’agit d’un rapport propre à AI Defense, pas d’une promesse d’envoi automatique de rapports MDR. Les exports peuvent contenir des données d’utilisateurs et d’appareils ; stockez-les dans un emplacement à accès restreint, avec une durée de conservation convenue.

Valider un pilote et diagnostiquer les écarts

La vérification suivante est une procédure de validation proposée, pas un test de tenant ou de laboratoire effectué par Avanet. Définissez au préalable la fenêtre de test, l’appareil, l’utilisateur, les services autorisés et les actions attendues. Utilisez uniquement des données de test synthétiques approuvées, par exemple Nur ein Funktionstest ohne Unternehmensdaten, c’est-à-dire un simple test fonctionnel sans données d’entreprise. Ne transmettez à un service d’IA aucune donnée client, aucun identifiant, document interne ou véritable code source. Un simple test d’accès ne nécessite pas de saisir des contenus confidentiels.

Commencez par une application expressément autorisée, puis vérifiez la règle de blocage ou d’avertissement prévue pour le pilote. Pour chaque essai, notez le service, l’appareil, l’heure et le comportement réellement observé côté utilisateur. Avec Warn, il doit rester possible de continuer ; avec Block, le mode d’accès testé ne doit pas être utilisable.
Dans AI Defense Activity, comparez l’application, Actor, le capteur, Action et Policy pour la même période. Le blocage visible et l’entrée associée doivent correspondre à l’essai prévu. Une page de blocage seule pourrait aussi provenir d’une règle Web Control ou Application Control existante.
Dans Inventory, vérifiez que l’application et le statut d’approbation attendu apparaissent. Ne comparez pas les nombres d’utilisations à des saisies individuelles, compte tenu du regroupement par fenêtres de 10 minutes. Utilisez la même période dans le rapport. Aucun délai fixe d’affichage n’est documenté ; ne masquez pas les entrées manquantes en multipliant indéfiniment les tests.
Effectuez une contre-vérification avec un utilisateur hors du groupe pilote ou un appareil non concerné. Ses processus de travail autorisés doivent rester inchangés. N’élargissez progressivement le périmètre qu’après une validation documentée.

L’application n’apparaît pas : vérifiez d’abord la période, le mode d’accès réellement couvert et le capteur. Contrôlez ensuite les transferts de données et, pour Endpoint, les paramètres documentés de Threat Protection, Web Control et Application Control. Pour une collecte via Firewall, vérifiez également la journalisation de la stratégie web. Un tableau de bord vide ne prouve pas qu’aucune IA n’est utilisée.

L’application apparaît, mais l’action souhaitée ne s’applique pas : comparez l’état d’activation, l’ordre des stratégies, l’ordre des règles, le périmètre et le produit indiqué sous What will happen. Pour l’application des règles via Firewall, vérifiez aussi la gestion par groupes. Ne tentez pas de corriger la situation par un blocage étendu à toute l’organisation ou en désactivant des protections existantes.

Une application métier ne fonctionne plus après une modification : comparez le dernier changement aux valeurs documentées auparavant et annulez le pilote. Ne créez pas d’exceptions TLS générales ni de règles Allow globales pour masquer le problème.

Si un écart reste inexpliqué, rassemblez les événements expurgés, la période avec le fuseau horaire, le capteur, l’appareil, l’action attendue, le comportement réel ainsi que l’ordre et le périmètre des stratégies. Ces éléments permettent d’ouvrir un dossier Sophos Support sans transmettre de prompts confidentiels.

Retour arrière et limites de la protection

Avant le pilote, consignez les règles existantes, leur ordre, leur périmètre et les stratégies de capteurs modifiées. Pour revenir en arrière, rétablissez l’état antérieur d’une règle pilote perturbatrice via l’édition documentée des stratégies, ou ramenez le périmètre pilote au périmètre précédemment approuvé. Vérifiez ensuite à nouveau le processus de travail auparavant autorisé et l’affichage des activités. Une Base Policy modifiée doit être restaurée de façon ciblée à partir de sa valeur par défaut et de ses exceptions applicatives documentées avant le changement. Restart onboarding ne la réinitialise pas.

Les modifications des capteurs ne peuvent être ramenées à leurs valeurs antérieures précises que si elles ont été effectuées spécialement pour l’essai et qu’aucune autre fonction de protection ou d’investigation n’en dépend. En particulier, ne désactivez pas systématiquement les transferts vers le Data Lake, le déchiffrement TLS ou Application Control. Le retour arrière des stratégies ne supprime pas automatiquement la télémétrie déjà collectée ni les rapports exportés. Leur traitement relève du processus convenu de protection et de conservation des données.

Trois limites restent importantes pour la planification :

La visibilité ne garantit pas un contrôle exhaustif. Une stratégie centrale ne suffit pas à sécuriser un endpoint privé non couvert, un autre mode d’accès ou un capteur dont un prérequis manque. La détection d’une application ne prouve pas non plus que toutes les actions autonomes d’un agent soient contrôlées.
Le contrôle d’accès aux applications n’est pas une DLP garantie sur les prompts. La communication de presse lors de la disponibilité générale présente déjà l’inspection en temps réel des prompts et des transferts de fichiers comme une fonction disponible. Les informations ultérieures destinées aux partenaires attribuent expressément l’inspection et la protection des prompts à de futures versions. Tant que le périmètre fonctionnel concret n’est pas confirmé de manière fiable, ne prévoyez aucune protection à ce titre et ne la testez surtout pas avec de véritables données confidentielles.
Une feuille de route n’est pas un engagement d’achat. La distinction entre comptes d’IA privés et professionnels ainsi que les fonctions supplémentaires de protection des agents figurent également sur la feuille de route, sans date contraignante. Si vous avez précisément besoin de ces fonctions, faites-les confirmer pour votre tenant avant toute décision et validez-les séparément.

Un démarrage solide ne consiste donc pas à affirmer que « l’IA est désormais sécurisée », mais à disposer d’un inventaire vérifiable, de services délibérément approuvés, de stratégies limitées et d’une preuve reproductible de leurs effets réels.