Sophos AI Defense: Discover and control AI usage

Sophos AI Defense makes AI application usage visible and controls which services are allowed, trigger a warning, or are blocked. This paid add-on for qualifying Sophos EDR, XDR, and MDR environments has been generally available since October 13, 2026. It is managed in Sophos Fusion and uses existing Sophos sensors. However, a license, a visible tile, or a completed wizard alone does not prove complete coverage or effective enforcement.

For deployment, follow this sequence: clarify licensing and the Fusion upgrade state, inventory data sources and existing policies, implement sensor prerequisites in a controlled manner, and only then test a narrowly scoped policy. Prompt content inspection is not a guaranteed current protection capability: the vendor’s communications conflict on this point. The scope that can safely be planned for in this article is visibility, application access policies, and reporting, reviewed as of October 20, 2026.

What Shadow AI means and which problem AI Defense addresses

Shadow AI is AI usage outside the intended approval and control processes. For example, an employee uses an additional web chat, a developer installs a coding assistant, or an existing application gains a new AI feature. The service may be useful while rules for uploaded documents, source code, use of data for training, or data locations remain unresolved.

AI Defense brings together three questions: which AI applications are being used, what risk is assigned to them, and which access policy should apply? The product overview lists browser-based language models such as ChatGPT, Claude.ai, and Copilot, as well as newer coding, desktop, and agent applications such as Claude Code, Cursor, and OpenClaw. These examples do not guarantee detection and control of every variant, API connection, or activity on every device. The specific sensor and the coverage actually observed remain decisive.

In the analysis views, Unsanctioned means that no policy explicitly allows an app in use. This is initially an approval status, not evidence of malware or data leakage. Conversely, allowing a service does not automatically make every use of it permissible. Organizational rules about which data may be sent to which service are still necessary.

AI Defense is also not the Sophos AI Assistant or AI Search for XDR investigations. Those tools use AI to support analysts’ work. AI Defense controls AI usage within the organization. Neither the Fusion name nor existing Assistant capabilities automatically enable this add-on.

Clarify licensing, Fusion, and sensors first

Different prerequisites need to be checked before ordering and before setup:

• Purchase eligibility: AI Defense is a paid add-on for qualifying Sophos EDR, XDR, and MDR customers. Sophos also requires customers to run Sophos EDR Endpoint Protection. A Sophos Endpoint license alone or a standalone Sophos Firewall therefore does not establish eligibility. Check the actual contractual scope using Activate and verify licenses.
• Technical access: The documented setup requires a Sophos Fusion account upgraded to the new platform with Security Operations. The Fusion transition check distinguishes portal names from the actual product upgrade.
• Taegis purchase exception: Eligible Taegis customers can buy the add-on at general availability without waiting for their Fusion migration. This is not a documented exception to the technical setup prerequisites. Before deployment, clarify eligibility, the provisioning route, and the upgrade state with the responsible Sophos contact.
• Suitable sensors: The setup wizard currently offers Sophos Endpoint, Sophos Firewall, and Sophos Linux Server. The general product overview additionally lists DNS Protection, Protected Browser, and Sophos Data Lake as data sources. This broader architectural list must not be interpreted as an identical selection list or as equal enforcement capabilities across all components.

Before making changes, document affected users, devices, and networks, previous policy values, responsible administrators, and a rollback path. Data uploads and HTTPS decryption affect privacy and existing applications. Approval is required before enabling them, not just during subsequent analysis. Use an approved test user on a managed test device for the pilot; necessary changes to shared policies must not inadvertently affect the entire organization.

Prepare sensors and complete onboarding

Open Sophos Fusion, then My Products > AI Defense > Get started. The wizard asks about your admin role, experience with AI tools, user count, and industry. Under Choose your sensors, select the sensors actually in use. You must then confirm their requirements. A checkbox confirms your own checks; it does not replace evidence of effectiveness.

Sophos Endpoint

Sophos documents the following settings for the Endpoint sensor:

1. Under Endpoint > Policies > Data Collection and Investigation, enable Upload to the Data Lake in the relevant policy and select Process Data, HTTP Data, DNS Data, and Network Data.
2. Under Endpoint > Policies > Threat Protection, enable SSL/TLS decryption of HTTPS websites and Block QUIC browser connections. The documented data collection requires this configuration; do not assume equivalent visibility without checking. HTTPS decryption and QUIC blocking can affect applications. Pilot changes in a controlled manner and do not remove existing exceptions indiscriminately.
3. Under Global Settings > Protection and Remediation > Web Settings > Web Filtering Profiles, create a web profile. Under Endpoint > Policies > Web Control, assign it to new or existing policies for the intended users and devices. The same profile does not have to be used everywhere.
4. Under Endpoint > Policies > Application Control, enable Detect controlled applications when users access them and select Block the detected application. Check existing application assignments and their effects before making the change; Endpoint Application Control explains the existing configuration.

Take me to settings opens the relevant configuration. After implementation, check the actual assignment to the test device again, and only then confirm the requirements in the wizard.

Sophos Firewall and Linux Server

For Sophos Firewall, the intended firewalls must be included in group management under Firewall Management > Firewalls. Firewalls outside group management do not receive AI Defense enforcement rules. Logging is also required in every relevant web policy: open the firewall’s web administration through its three-dot menu, select the relevant policy under Web, and enable its logging. Without this logging, the activity required for detection is missing. Check group membership and existing group rules before making a change so that onboarding does not silently alter other firewall settings.

For Sophos Linux Server, setup requires Upload to the Data Lake to be enabled with Network Data under Server > Policies > Data Collection and Investigation. This does not mean that Linux Server enforces the same application access controls as Endpoint or Firewall. The policy preview later shows which product the specific rule applies to.

If the wizard cannot verify the sensor status, it offers Refresh. If verification still fails, it allows you to continue. This is not a successful sensor test: the discrepancy remains unresolved and must be investigated before accepting the protection as effective.

Do not treat the Base Policy as a nonbinding draft

Under Define your base protection, a Base Policy is created if one does not already exist. It applies to everyone in the organization. The Generative AI category default sets Block, Warn, or Allow for apps without their own rule. App-specific rules take precedence over this default. The wizard shows apps from the past 30 days for this purpose; that is not a statement about general data retention.

Create base policy and finish creates the Base Policy. You can also skip this step. If a Base Policy already exists, onboarding does not change it; Finish and take me to the policy opens the existing configuration. Review a policy prepared by a partner first rather than replacing it as a precaution. Settings > Restart onboarding restarts the wizard; this is not a documented reset or rollback of existing policies.

For a limited trial, do not create an organization-wide blocking rule speculatively. First clarify which global default has business approval. Then create the pilot policy with an explicitly limited scope.

Build AI Defense policies safely

Under My Products > AI Defense > Policies > Create policy, give the new policy a name of your choice, such as AI-Pilot-Freigegebene-Dienste. Its description records the purpose, responsible person, and planned review date. The policy consists of Rules and Scope.

Rules and priorities

Both the policy list and the rules within a policy are evaluated from top to bottom: the first matching entry decides. A correct rule below an earlier matching rule may therefore have no effect.

A new additional policy contains a rule that blocks all AI apps by default. Sophos recommends leaving it at the bottom and adding specific allowances above it. For the pilot, this catch-all rule must affect only the approved test scope. Carelessly enabling it for all users could also block previously permitted workflows.

Use Add Rule to select the Action, and Add Filter to choose a Dimension and its Value. Supported dimensions include, for example, application, risk level, and the compliance properties offered in the interface. Under Application, select specific apps from the list. Use only values actually available; a risk rating does not replace your own review of the service and the contract purchased.

• Allow: Matching application usage is allowed.
• Warn: Users receive a notice but may continue using the service. This is not a substitute for blocking.
• Block: Matching application usage is intended to be blocked through the supported product. The pilot must establish whether this works for the intended access path.

A suitable test example is an explicitly allowed app above the blocking catch-all rule and a second app approved for the test but without its own allow rule. This lets you verify the intended exception logic without using real confidential content. The organization determines the app names and approves their use; the product examples above are not usage recommendations.

Scope and activation

Under Scope, limit the policy to the intended users, groups, or networks, for example by selecting an existing test group through Specific Users and Groups. The page shows whether the policy applies to Sophos Endpoint or Sophos Firewall. Under What will happen, the rules, scope, and product effect must match before you confirm I’ve reviewed the rules and scope above.

Save saves the additional policy without enabling it. This lets you check its position in the list first. By contrast, Save & Enable enables it immediately with the highest priority. For the prepared pilot, use Save first; check the position and scope again before enabling it later. This documented safety-relevant difference between the buttons applies to additional policies and must not be generalized to completion of the Base Policy.

Templates under Browse templates > Use and Clone in the three-dot menu can save work. However, they already contain prefilled rules or the copied scope. Adapt both to your own environment before saving. Existing policies can be edited through their list entry, a rule’s Edit icon followed by Save Rule, and Scope > Edit.

Interpret usage, risks, and reports correctly

Under My Products > AI Defense, several views answer different questions. Always select the appropriate period using the calendar icon first:

• Dashboard: Shows overall activity, blocked activities, unique apps and users, and the distribution across Allow, Block, and Warn. It also includes frequently used apps and users, Shadow AI, risk distribution, usage flow, and trends over time. The security posture score, with a maximum of 100, considers sensor coverage, policy maturity, and usage risk. A high value does not guarantee complete protection.
• AI Defense Activity: Shows the application, Actor as a device, risk, sensor, time, action, and triggering policy. Unknown means that no verdict was recorded, not that the activity was definitely allowed. Risk levels range from Low through Medium and High to Critical. The widgets can filter, for example, for allowed activities; Export provides CSV.
• Inventory > Apps or Users: Helps you review apps and users actually observed. Unsanctioned Use indicates a lack of explicit approval, while Trains on Data shows the recorded information about the provider’s use of data for training. Application risk ratings consider factors including compliance evidence and training practices. In app usage, an activity groups a device’s use of an app into 10-minute windows. Activity counts are therefore not counts of individual prompts. Both inventory lists can be exported as CSV.
• Detections: Shows, for example, a newly detected app, risky usage, or use of an unapproved app. Threat score ranges from 0 to 10, and Severity from Info to Critical. Filters narrow results by Severity, Threat Score, or title. The detail view provides a description, affected user or host, recommended action, and the underlying data under JSON. Exports are available as formatted CSV, CSV, or JSON.

The app details let you examine functionality, risk summary, training rules, compliance, and data usage more closely; activity details also show Data Residency. This information supports decisions but does not confirm that your specific plan, account, or individual data processing agreement has identical terms.

After investigating a detection, record a reasoned status in the detail window: True positive benign, True positive malicious, False positive, or Not actionable. Correctly detected usage can be harmless; a detection entry alone must not cause it to be classified as a successful attack.

For a report, open AI Defense > Reports > AI Risk Assessment Report > Generate, select Report period, and use Download PDF if needed. The report brings together application risks, Shadow AI exposure, and a comparison of risk reduction between reporting periods. Top-five lists are excerpts, not a complete inventory. This is a separate AI Defense report, not a promise of automatic MDR report delivery. Exports can contain user and device data and belong in access-restricted storage with agreed retention.

Validate a pilot and isolate problems

The following check is a proposed acceptance procedure, not a tenant or lab test performed by Avanet. Agree on the test window, test device, user, permitted services, and expected actions in advance. Use only approved synthetic test data, such as Nur ein Funktionstest ohne Unternehmensdaten. Do not send customer data, credentials, internal documents, or real source code to an AI service. An access-only test does not require confidential content.

1. Start with an explicitly allowed app, then test the blocking or warning rule intended for the pilot. For each attempt, record the service, device, time, and actual user experience. With Warn, continuing must remain possible; with Block, the tested access path must not be usable.
2. In AI Defense Activity, compare the application, Actor, sensor, Action, and Policy for the same period. The visible block and the corresponding entry must match the intended test. A block page alone could also come from an existing Web Control or Application Control rule.
3. In Inventory, check whether the app and expected approval status appear. Because of the 10-minute grouping, do not compare usage counts with individual inputs. Use the same period in the report. No fixed display latency is documented; do not mask missing entries by running arbitrarily many tests.
4. Cross-check a user outside the pilot group or an uninvolved device. Their approved workflows should remain unchanged. Expand the scope gradually only after documented acceptance.

The app is not visible: First check the period, the access path actually captured, and the sensor. Then check data uploads and, for Endpoint, the documented Threat Protection, Web Control, and Application Control settings. For firewall-based collection, also check web policy logging. An empty dashboard does not prove that no AI is being used.

The app appears, but the intended action does not take effect: Compare activation state, policy order, rule order, scope, and the product shown under What will happen. For firewall enforcement, also check group management. Do not try to fix this with broad organization-wide blocking or by disabling existing protection.

A business application stops working after a change: Compare the last change with the previously documented values and roll back the pilot. Do not create blanket TLS exceptions or global allow rules to conceal the problem.

If a discrepancy remains unexplained, collect sanitized events, the period with time zone, sensor, device, expected action, actual behavior, and policy order and scope. These details allow you to open a Sophos support case without sharing confidential prompts.

Rollback and protection limits

Before the pilot, record the existing rule set, order, scope, and changed sensor policies. To roll back, use the documented policy editing controls to return a disruptive pilot rule to its previous state, or restore the pilot scope to its previously approved extent. Then check the previously permitted workflow and the activity view again. A changed Base Policy must be restored specifically using its previously documented default and app exceptions. Restart onboarding does not reset it.

Sensor changes may be reverted only to their specific previous values if they were made solely for the test and no other protection or investigation tasks depend on them. In particular, do not disable Data Lake uploads, TLS decryption, or Application Control indiscriminately. Reverting policies does not automatically delete telemetry already collected or exported reports. Handle these through the agreed data protection and retention process.

Three limits remain important for planning:

• Visibility is not complete control. A central policy alone cannot protect an unmonitored personal endpoint, a different access path, or a setup missing a sensor prerequisite. App detection also does not prove that all autonomous actions of an agent are controlled.
• Application access control is not guaranteed prompt DLP. The GA press communications already describe real-time inspection of prompts and uploads as a capability. The later partner information explicitly assigns prompt inspection and protection to future releases. Until the specific functionality is reliably confirmed, do not plan to rely on its protection and, in particular, do not test it with real confidential data.
• A roadmap is not a procurement commitment. Differentiation between personal and business AI accounts and additional agent protection capabilities are also described as roadmap items, without a binding date. If you specifically need these capabilities, have them confirmed for your tenant before making a decision and accept them separately.

A sound starting point is therefore not “AI is now secured,” but a verifiable inventory, deliberately approved services, narrowly scoped policies, and repeatable evidence of their actual effects.