Sophos AI Defense: identifiera och kontrollera AI-användning

Sophos AI Defense synliggör användningen av AI-applikationer och styr vilka tjänster som tillåts, får en varning eller blockeras. Det avgiftsbelagda tillägget för kvalificerande Sophos EDR-, XDR- och MDR-miljöer är allmänt tillgängligt sedan den 13 oktober 2026. Det hanteras i Sophos Fusion och använder befintliga Sophos-sensorer. En licens, en synlig panel eller en slutförd assistent bevisar dock inte i sig att insamlingen är fullständig eller att policyerna tillämpas effektivt.

Vid införandet rekommenderas följande ordning: klargör licens och Fusion-status, inventera datakällor och befintliga policyer, uppfyll sensorkraven på ett kontrollerat sätt och testa först därefter en snävt avgränsad policy. Granskning av promptinnehåll är inte en garanterad aktuell skyddsfunktion: tillverkarens kommunikation är motsägelsefull på den punkten. Den omfattning som går att planera säkert utifrån denna artikel är insyn, åtkomstpolicyer för appar och rapportering, med granskningsdatum 20 oktober 2026.

Vad Shadow AI betyder och vilket problem AI Defense löser

Shadow AI är AI-användning utanför de avsedda godkännande- och kontrollprocesserna. En medarbetare kanske använder ytterligare en webbchatt, en utvecklare installerar en kodassistent eller en befintlig applikation får en ny AI-funktion. Tjänsten kan vara användbar samtidigt som reglerna för uppladdade dokument, källkod, träningsanvändning eller datalagringsplatser är oklara.

AI Defense förenar tre frågor: vilka AI-applikationer används, vilken risk tilldelas de och vilken åtkomstpolicy ska gälla? Produktöversikten nämner webbläsarbaserade språkmodeller som ChatGPT, Claude.ai och Copilot samt nyare kodnings-, dator- och agentapplikationer som Claude Code, Cursor och OpenClaw. Exemplen är ingen garanti för att varje variant, API-anslutning eller aktivitet på varje enhet kan identifieras och kontrolleras. Den konkreta sensorn och den faktiskt observerade täckningen är fortfarande avgörande.

I analyserna betyder Unsanctioned att en använd app inte uttryckligen är tillåten av någon policy. Det är i första hand en godkännandestatus, inte bevis på skadlig kod eller dataläckage. Omvänt gör en tillåten tjänst inte automatiskt varje användningssätt tillåtet. Organisationens regler för vilka data som får användas i vilken tjänst behövs fortfarande.

AI Defense är inte heller Sophos AI Assistant eller AI Search för XDR-utredningar. Där hjälper AI analytikerna i deras arbete. AI Defense kontrollerar organisationens AI-användning. Varken namnet Fusion eller befintliga Assistant-funktioner aktiverar tillägget automatiskt.

Klargör licens, Fusion och sensorer i förväg

Olika förutsättningar behöver kontrolleras före beställning respektive konfiguration:

Köpbehörighet: AI Defense är ett avgiftsbelagt tillägg för kvalificerande Sophos EDR-, XDR- och MDR-kunder. Sophos anger dessutom att Sophos EDR Endpoint Protection måste användas. Enbart en Sophos Endpoint-licens eller en fristående Sophos Firewall är därför inte tillräckligt som bevis på behörighet. Kontrollera den konkreta avtalsomfattningen enligt Aktivera och kontrollera licenser.
Teknisk åtkomst: Den dokumenterade konfigurationen kräver ett Sophos Fusion-konto som har uppgraderats till den nya plattformen med Security Operations. Kontrollen inför Fusion-övergången skiljer portalnamn från faktisk produktuppgradering.
Taegis-undantag vid inköp: Berättigade Taegis-kunder kan köpa tillägget redan vid allmän tillgänglighet utan att invänta sin Fusion-migrering. Det är inget dokumenterat undantag från de tekniska konfigurationskraven. Före införandet måste behörighet, driftsättningsväg och uppgraderingsstatus klargöras med ansvarig kontaktperson hos Sophos.
Lämpliga sensorer: Konfigurationsassistenten erbjuder för närvarande Sophos Endpoint, Sophos Firewall och Sophos Linux Server. Den allmänna produktöversikten nämner dessutom DNS Protection, Protected Browser och Sophos Data Lake som datakällor. Den bredare arkitekturbeskrivningen får inte tolkas som en identisk urvalslista eller som att alla komponenter har samma förmåga att genomdriva policyer.

Dokumentera berörda användare, enheter och nätverk, tidigare policyvärden, ansvariga administratörer och en återställningsväg före ändringar. Datauppladdningar och HTTPS-dekryptering berör dataskydd och befintliga applikationer. De ska godkännas före aktivering, inte först vid senare analys. Använd en godkänd testanvändare på en hanterad testenhet för pilottestet; nödvändiga ändringar i gemensamma policyer får inte oavsiktligt påverka hela organisationen.

Förbered sensorer och genomför onboarding

Öppna Sophos Fusion och därefter My Products > AI Defense > Get started. Assistenten frågar efter administratörsroll, erfarenhet av AI-verktyg, antal användare och bransch. Välj de sensorer som faktiskt används under Choose your sensors. Bekräfta sedan deras krav. En kryssruta bekräftar din egen kontroll; den ersätter inte bevis på effekt.

Sophos Endpoint

Sophos dokumenterar följande inställningar för Endpoint-sensorn:

Aktivera Upload to the Data Lake i tillämplig policy under Endpoint > Policies > Data Collection and Investigation och välj Process Data, HTTP Data, DNS Data och Network Data.
Aktivera SSL/TLS decryption of HTTPS websites och Block QUIC browser connections under Endpoint > Policies > Threat Protection. Den dokumenterade insamlingen förutsätter denna konfiguration; anta inte likvärdig insyn utan kontroll. HTTPS-dekryptering och QUIC-blockering kan påverka applikationer. Pilottesta därför ändringarna kontrollerat och ta inte bort befintliga undantag generellt.
Skapa en webbprofil under Global Settings > Protection and Remediation > Web Settings > Web Filtering Profiles. Tilldela den sedan under Endpoint > Policies > Web Control till nya eller befintliga policyer för avsedda användare och enheter. Samma profil behöver inte användas överallt.
Aktivera Detect controlled applications when users access them och välj Block the detected application under Endpoint > Policies > Application Control. Kontrollera befintliga apptilldelningar och deras effekt före ändringen; Endpoint Application Control förklarar den befintliga funktionen.

Via Take me to settings når du respektive konfiguration. Kontrollera efter genomförandet på nytt den faktiska tilldelningen till testenheten och bekräfta först därefter kraven i assistenten.

Sophos Firewall och Linux Server

För Sophos Firewall måste de avsedda brandväggarna ingå i grupphanteringen under Firewall Management > Firewalls. Brandväggar utanför grupphanteringen får inga AI Defense-regler för policytillämpning. Dessutom krävs loggning i varje relevant webbpolicy: öppna webbadministrationen via brandväggens trepunktsmeny, välj respektive policy under Web och aktivera dess loggning. Utan denna loggning saknas den aktivitet som behövs för identifieringen. Kontrollera grupptillhörighet och befintliga gruppregler före en ändring så att onboarding inte ändrar andra brandväggsinställningar obemärkt.

För Sophos Linux Server kräver konfigurationen att Upload to the Data Lake är aktiverat med Network Data under Server > Policies > Data Collection and Investigation. Detta innebär inte att Linux Server genomdriver samma åtkomstkontroller för appar som Endpoint eller Firewall. Policyförhandsgranskningen visar senare för vilken produkt den konkreta regeln gäller.

Om assistenten inte kan verifiera sensorstatusen erbjuds Refresh. Om kontrollen fortfarande misslyckas går det att fortsätta. Det är inget godkänt sensortest: avvikelsen är fortfarande öppen och måste undersökas innan skyddet kan godkännas.

Behandla inte Base Policy som ett oförbindande utkast

Under Define your base protection skapas en Base Policy om den ännu saknas. Den gäller alla i organisationen. Generative AI category default anger Block, Warn eller Allow för appar utan egen regel. Appspecifika regler har företräde framför denna standard. Assistenten visar appar från de senaste 30 dagarna för detta; det säger inget om den allmänna datalagringstiden.

Med Create base policy and finish skapas Base Policy. Steget går också att hoppa över. Om en Base Policy redan finns ändrar onboarding den inte; Finish and take me to the policy öppnar den befintliga konfigurationen. Granska först en policy som partnern har förberett i stället för att byta ut den i förebyggande syfte. Via Settings > Restart onboarding går det att starta assistenten på nytt; det är ingen dokumenterad återställning eller avveckling av befintliga policyer.

Skapa inte en organisationsövergripande blockeringsregel på antaganden för ett begränsat test. Klargör först vilken global standard som är godkänd ur verksamhetssynpunkt. Skapa därefter pilotpolicyn med en uttryckligen begränsad omfattning.

Bygg upp AI Defense-policyer säkert

Under My Products > AI Defense > Policies > Create policy kan den nya policyn exempelvis få det fritt valda namnet AI-Pilot-Godkanda-Tjanster. En beskrivning dokumenterar syfte, ansvarig person och planerat granskningsdatum. Policyn består av Rules och Scope.

Regler och prioriteringar

Både policylistan och reglerna inom en policy utvärderas uppifrån och ned: den första matchande posten avgör. En korrekt regel under en tidigare matchande regel kan därför bli utan effekt.

En ny ytterligare policy innehåller som standard en regel som blockerar alla AI-appar. Sophos rekommenderar att behålla den längst ned och lägga riktade tillåtelser ovanför. I pilottestet får denna uppsamlingsregel endast påverka den godkända testomfattningen. En ogenomtänkt aktivering för alla användare kan även blockera arbetsflöden som tidigare var tillåtna.

Med Add Rule väljer du Action och via Add Filter en Dimension och dess Value. Dimensioner som stöds omfattar exempelvis applikation, risknivå och de efterlevnadsegenskaper som erbjuds i gränssnittet. Vid Application väljer du konkreta appar ur listan. Använd endast värden som faktiskt är tillgängliga; en riskklassificering ersätter inte en egen granskning av tjänsten och det tecknade avtalet.

Allow: Den matchande appanvändningen tillåts.
Warn: Användare får en varning men kan fortsätta använda tjänsten. Det ersätter inte en blockering.
Block: Den matchande appanvändningen ska blockeras via produkten som stöds. Pilottestet måste visa om detta fungerar för den planerade åtkomstvägen.

Ett lämpligt testexempel är en uttryckligen tillåten app ovanför den blockerande uppsamlingsregeln och en andra app som är godkänd för testet men saknar egen tillåtelse. Då går det att kontrollera den avsedda undantagslogiken utan att använda verkligt konfidentiellt innehåll. Organisationen bestämmer appnamnen och vilka appar som godkänns; produktexemplen ovan är inga användningsrekommendationer.

Omfattning och aktivering

Begränsa policyn till avsedda användare, grupper eller nätverk under Scope, exempelvis till en befintlig testgrupp via Specific Users and Groups. Sidan visar om policyn tillämpas på Sophos Endpoint eller Sophos Firewall. Under What will happen måste regler, omfattning och produkteffekt stämma överens innan du bekräftar I’ve reviewed the rules and scope above.

Save sparar den ytterligare policyn utan aktivering. Då går det att först kontrollera dess position i listan. Save & Enable aktiverar den däremot omedelbart med högsta prioritet. För det förberedda pilottestet rekommenderas därför först Save; kontrollera position och omfattning på nytt före en senare aktivering. Den dokumenterade säkerhetsmässiga skillnaden mellan knapparna gäller ytterligare skapade policyer och får inte överföras generellt till slutförandet av Base Policy.

Mallar under Browse templates > Use och Clone i trepunktsmenyn kan spara arbete. De innehåller dock redan ifyllda regler respektive kopierad omfattning. Båda måste anpassas till den egna miljön före sparandet. Befintliga policyer kan redigeras via sin listpost, en regels Edit-ikon med Save Rule och Scope > Edit.

Tolka användning, risker och rapporter korrekt

Under My Products > AI Defense hjälper flera vyer till att besvara olika frågor. Välj alltid först lämplig tidsperiod via kalenderikonen:

Dashboard: Visar total aktivitet, blockerade aktiviteter, unika appar och användare samt fördelningen på Allow, Block och Warn. Därtill visas vanliga appar och användare, Shadow AI, riskfördelning, användningsflöde och utveckling över tid. Security Posture-poängen upp till 100 tar hänsyn till sensortäckning, policymognad och användningsrisk. Ett högt värde är ingen garanti för fullständigt skydd.
AI Defense Activity: Visar applikation, Actor som enhet, risk, sensor, tidpunkt, åtgärd och utlösande policy. Unknown betyder att inget utfall registrerades, inte att aktiviteten säkert var tillåten. Risknivåerna går från Low via Medium och High till Critical. Via widgetarna går det exempelvis att filtrera på tillåtna aktiviteter; Export ger CSV.
Inventory > Apps respektive Users: Hjälper dig att granska faktiskt observerade appar och användare. Unsanctioned Use visar att uttryckligt godkännande saknas, Trains on Data den registrerade informationen om leverantörens användning av data för träning. Appens riskklassificering tar bland annat hänsyn till efterlevnadsunderlag och träningspraxis. För appanvändning grupperar en aktivitet en enhets användning av en app i 10-minutersfönster. Aktivitetsantal är därför inte antalet enskilda prompter. Båda inventeringslistorna kan exporteras som CSV.
Detections: Visar exempelvis en app som upptäckts för första gången, riskfylld användning eller användning av en app som inte är godkänd. Threat score går från 0 till 10, Severity från Info till Critical. Filter begränsar Severity, Threat Score eller titel. Detaljvyn erbjuder beskrivning, berörd användare eller värd, rekommenderad åtgärd och under JSON underliggande data. Export är möjlig som formaterad CSV, CSV eller JSON.

I appdetaljerna kan funktion, risksammanfattning, träningsregler, efterlevnad och dataanvändning granskas närmare; aktivitetsdetaljerna anger också Data Residency. Informationen är beslutsstöd, inte en bekräftelse på att det egna specifika abonnemanget, kontot eller ett individuellt personuppgiftsbiträdesavtal har identiska villkor.

Dokumentera efter utredning av en Detection en motiverad status i detaljfönstret: True positive benign, True positive malicious, False positive eller Not actionable. Korrekt identifierad användning kan vara ofarlig; den får inte klassificeras som ett lyckat angrepp enbart för att det finns en Detection-post.

För en rapport öppnar du AI Defense > Reports > AI Risk Assessment Report > Generate, väljer Report period och vid behov Download PDF. Rapporten sammanställer apprisker, exponering för Shadow AI och jämförelser av riskminskningen mellan rapportperioder. Topplistorna med fem poster är urval, inte fullständiga inventarier. Detta är en separat AI Defense-rapport och inget löfte om automatisk leverans av MDR-rapporter. Exporter kan innehålla användar- och enhetsdata och ska placeras i en åtkomstbegränsad lagring med överenskommen lagringstid.

Validera ett pilottest och avgränsa fel

Följande kontroll är ett föreslaget acceptansförfarande, inte ett tenant- eller laboratorietest som Avanet har genomfört. Kom överens om testfönster, testenhet, användare, tillåtna tjänster och förväntade åtgärder i förväg. Använd endast godkända, syntetiska testdata, exempelvis Endast ett funktionstest utan företagsdata. Överför inga kunddata, autentiseringsuppgifter, interna dokument eller verklig källkod till en AI-tjänst. Ett rent åtkomsttest kräver inte att konfidentiellt innehåll matas in.

Börja med en uttryckligen tillåten app och kontrollera sedan den blockerings- eller varningsregel som är avsedd för pilottestet. Notera tjänst, enhet, tidpunkt och faktiskt beteende för användaren vid varje försök. Vid Warn måste det gå att fortsätta; vid Block får den testade åtkomstvägen inte vara användbar.
Jämför applikation, Actor, sensor, Action och Policy i AI Defense Activity för samma tidsperiod. Den synliga blockeringen och den tillhörande posten måste motsvara det avsedda försöket. Enbart en blockeringssida kan också komma från en befintlig regel i Web Control eller Application Control.
Kontrollera i Inventory att appen och förväntad godkännandestatus visas. Jämför inte användningsantal med enskilda inmatningar på grund av 10-minutersgrupperingen. Använd samma tidsperiod i rapporten. Ingen fast visningsfördröjning är dokumenterad; dölj inte saknade poster med godtyckligt många tester.
Gör en motkontroll med en användare utanför pilotgruppen eller en enhet som inte berörs. Dess godkända arbetsflöden ska förbli oförändrade. Utöka omfattningen stegvis först efter dokumenterat godkännande.

Appen syns inte: Kontrollera först tidsperiod, den åtkomstväg som faktiskt fångas upp och sensor. Kontrollera därefter datauppladdningar och för Endpoint de dokumenterade inställningarna i Threat Protection, Web Control och Application Control. Kontrollera även webbpolicyloggning vid insamling via Firewall. En tom dashboard bevisar inte att ingen AI används.

Appen visas men önskad åtgärd får ingen effekt: Jämför aktiveringsstatus, policyordning, regelordning, omfattning och produktvisning i What will happen. Kontrollera även grupphanteringen vid policytillämpning via Firewall. Försök inte rätta till detta genom en bred organisationsövergripande blockering eller genom att stänga av befintliga skyddsfunktioner.

En arbetsapplikation slutar fungera efter en ändring: Jämför den senaste ändringen med de tidigare dokumenterade värdena och återställ pilottestets ändringar. Skapa inga generella TLS-undantag eller globala Allow-regler för att dölja felet.

Om en avvikelse förblir oförklarad samlar du händelser rensade från känsliga uppgifter, tidsperiod med tidszon, sensor, enhet, förväntad åtgärd, faktisk reaktion samt policyordning och omfattning. Med dessa uppgifter går det att öppna ett Sophos-supportärende utan att vidarebefordra konfidentiella prompter.

Återställningsväg och skyddets begränsningar

Dokumentera befintlig regeluppsättning, ordning, omfattning och ändrade sensorpolicyer före pilottestet. För att återställa läget återförs en störande pilotregel till sitt tidigare tillstånd via den dokumenterade policyredigeringen, eller så återställs pilotomfattningen till den tidigare godkända omfattningen. Kontrollera sedan det tidigare tillåtna arbetsflödet och aktivitetsvisningen igen. En ändrad Base Policy måste återställas riktat utifrån dess tidigare dokumenterade standard och appundantag. Restart onboarding återställer den inte.

Sensorändringar får endast återföras till de konkreta tidigare värdena om de gjordes särskilt för testet och inga andra skydds- eller utredningsuppgifter är beroende av dem. Stäng i synnerhet inte av Data Lake-uppladdningar, TLS-dekryptering eller Application Control generellt. Redan insamlad telemetri eller exporterade rapporter raderas inte automatiskt när policyändringarna återställs. För dem gäller den överenskomna dataskydds- och lagringsprocessen.

Tre begränsningar är fortsatt viktiga för planeringen:

Insyn är inte fullständig kontroll. En privat endpoint som inte omfattas av insamlingen, en annan åtkomstväg eller ett ouppfyllt sensorkrav kan inte säkras enbart genom en central policy. Appidentifiering bevisar inte heller att alla autonoma åtgärder från en agent kontrolleras.
Åtkomstkontroll för appar är inte garanterad prompt-DLP. Pressinformationen vid GA beskriver redan realtidsgranskning av prompter och uppladdningar som en funktion. Den senare partnerinformationen placerar uttryckligen granskning och skydd av prompter i framtida versioner. Så länge den konkreta funktionsomfattningen inte har bekräftats tillförlitligt ska ingen skyddseffekt planeras för detta, och den ska i synnerhet inte testas med verkligt konfidentiella data.
En färdplan är inget inköpslöfte. Även åtskillnaden mellan privata AI-konton och företagskonton samt ytterligare skyddsfunktioner för agenter beskrivs som färdplan, utan bindande datum. Den som behöver just dessa funktioner måste få dem bekräftade för den egna tenanten före ett beslut och godkänna dem separat.

En hållbar start är därför inte ”nu är AI säkrat”, utan ett verifierbart inventarium, medvetet godkända tjänster, avgränsade policyer och ett upprepningsbart bevis på deras faktiska effekt.