The Configuration section of AISecOps contains all tenant-level settings that control how cases are created, investigated, and managed. This section allows you to fine-tune AI behavior and connect AISecOps to external services like Slack and ServiceNow.
Access these settings from the left navigation bar under the Settings icon.
Preferences

Preferences control three AI-driven automation behaviors. Each can be independently toggled and tuned to match your organization’s needs.
Auto-Assignment

Automatically assigns new cases to analysts based on historical similarity.
- Similarity Threshold: Higher values require closer matches before assigning.
- Min Similar Cases: Minimum matches required before the system triggers an assignment.
- Lookback Days: How far back to search for historical assignment data.
Auto-Investigation

Prevents redundant work by skipping AI investigations if very similar recent cases were flagged as “low-risk.”
- Low Risk Skip Threshold: The fraction of similar cases that must be low-risk for the skip logic to activate.
Auto-investigation is now enabled by default for new tenants. New tenants start with a 7-day priming window at a reduced quota cap of 10%, allowing AISecOps to validate signal quality before full quota consumption begins.
Auto-investigations are capped at 70% of the weekly quota by default. You can change this value from 0-100%.
Rate Limit Info
A read-only view displaying the platform-set case creation limits per day.
Case Rules

This is the central hub for managing detection rules that drive DLP case creation.
- Rule Lifecycle: New rules start as Disabled by default to allow for review. Every update increments the Version Number.
- Optimistic Locking: If another user updates the rule first, you will receive a
409 Conflicterror. - Format: Rules use the V3 Pipe Query format.
- Example:
filter incident.dlp_incident_severity = 'High' | create_case group_by incident.user when group.evidence_count >= 1
- Example:
- Author Attribution: User-created Case Rules now display the creator’s email on the rule card, replacing the previous “Created by Netskope” label.
- The rule editor now prompts you to confirm before canceling a form with unsaved changes.
DLP Incident Pre-Filtering
This section allows you to suppress specific DLP incident patterns known to be “noise.”
- Views: Organized by DLP Profile or DLP Policy.
- The Matrix: Expand any row to see a matrix of Severity × Action. You can exclude specific combinations (e.g., exclude all “Low” severity incidents that resulted in an “Alert”).
- Auto-Tuning: Automatically suppresses low-signal combinations based on observed patterns. Auto-tuning is now enabled by default for new tenants, with a minimum-volume floor in place to prevent over-filtering on low-volume tenants.
- Sample Incidents: Review real events within the tuning UI to ensure you aren’t accidentally suppressing critical signals.
Agent Memory

Agent Memory provides persistent context and instructions that the AI Worker reviews before every investigation.
| Type | Purpose | Sample Content |
|---|---|---|
| Instruction | Directives on how the AI should reason. | “Treat all Finance folder access by contractors as high-risk.” |
| Configuration | Structured key-value pairs/lists. | List of trusted domains or sensitive project codenames. |
- Validation: Memories are validated against Bedrock Guardrails to prevent unsafe content.
- Immediate Effect: Changes take effect on the very next investigation—no service restart required.
Usage

The Usage page provides insight into your current usage. Here you can view a breakdown of the average case investigation on a weekly or daily basis.
Auto-investigations are capped at 10% of the weekly quota by default. This can be changed.
Failed investigations don’t count against the quota.
Manual investigations and auto-investigations always consume quota.
The quota resets every Monday at 00:00 UTC with no rollover.
Integrations
The Integrations page allows you to connect AISecOps to external services for case management, notifications, and endpoint enrichment. To access this page, navigate to AISecOps > Configuration > Integrations.
The following integrations are available:
- Slack
- ServiceNow
- Microsoft Entra ID
- EDR Integrations (CrowdStrike Falcon, SentinelOne Singularity, Microsoft Defender for Endpoint)

Slack
Connect AISecOps to Slack to enable the manager approval workflow. When Slack is configured, manager approval requests are sent as Slack messages. If Slack is not configured, approval requests are sent by email instead.
ServiceNow
The ServiceNow integration bridges AISecOps with your IT service management (ITSM) workflow by creating and syncing tickets for high-risk cases.
- One-way sync: AISecOps writes data to ServiceNow; the ITSM sync worker tracks the ticket ID and status back in the AISecOps case.
- Requirements: The instance URL must be
https://*.service-now.com. - Tracking: Linked cases display the human-readable ServiceNow ticket number (e.g.,
INC0012345) and a direct link to the ticket.
Set Up the ServiceNow Integration
- Follow Step 1 on the Onboard ServiceNow page to configure ServiceNow API access.
- Follow Step 2 on the Onboard ServiceNow page to enable ServiceNow table permissions. When prompted for a table name, enter
sn_si_incident. - In the Netskope tenant, go to AISecOps > Configuration > Integrations > ServiceNow.
- Enter your Instance URL, Client ID, and Client Secret.
- Click Connect to ServiceNow.
Microsoft Entra ID
Connecting AISecOps to Microsoft Entra ID enables user attribute provisioning, including manager, department, organization, and hire date fields that the AISecOps agents use during investigations.
Set Up the Microsoft Entra ID Integration
- Follow the steps on SCIM User Provisioning with RBACv3 to create an RBACv3 token.
- Follow the steps on Integration with Entra ID for User Provisioning to connect the Netskope app in Entra ID with Netskope.
- Run the following command to enable the custom attributes required by AISecOps. Replace <tenant_url> and <token> with your values.
curl --location --request PUT 'https://<tenant_url>/api/v2/scim/Schemas/urn:ietf:params:scim:schemas:extension:tenant:2.0:User' \
--header 'accept: application/scim+json;charset=utf-8' \
--header 'Content-Type: application/scim+json;charset=utf-8' \
--header 'Authorization: Bearer <token>' \
--data '{
"name": "AISecOps Custom Attributes",
"attributes": [
{
"name": "hireDate",
"type": "dateTime",
"description": "Employee hire date",
"mutability": "readWrite",
"returned": "default",
"required": false,
"multiValued": false,
"caseExact": false,
"uniqueness": "none"
}
],
"description": "Netskope AISecOps Additional Attributes",
"id": "urn:ietf:params:scim:schemas:extension:tenant:2.0:User",
"meta": {
"location": "https://<tenant_url>/Schemas/urn:ietf:params:scim:schemas:extension:tenant:2.0:User",
"resourceType": "Schema"
}
}'
- Open the schema editor in your Azure portal:
- If you are signed in to https://portal.azure.com, open link https://portal.azure.com/?Microsoft_AAD_Connect_Provisioning_forceSchemaEditorEnabled=true
- If you are signed in to https://entra.microsoft.com, open link https://entra.microsoft.com/?Microsoft_AAD_Connect_Provisioning_forceSchemaEditorEnabled=true
- Open the Netskope app and go to the attribute mapping page.
- Add the following Netskope attributes and save:
- urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.manager (string)
- urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.department (string)
- urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.organization (string)
- urn:ietf:params:scim:schemas:extension:tenant:2.0:User.hireDate (DateTime)

- Add mappings until the final mapping configuration matches the required layout.

Email Manager Approval Workflow
After connecting Netskope with Entra ID and configuring the manager email integration, AISecOps enables the email manager approval workflow.
When an agent determines that a case requires manager input to assess risk, the investigation pauses to allow an analyst to intervene. The analyst has two options:
- Bypass or continue: Skip the email request or force-continue the investigation if the manager does not respond in time.
- Request manager input: Trigger an automated email to the manager. The manager can authorize or flag the activity directly from the email. The investigation remains paused for up to six hours or until the manager responds.
EDR Integrations
Beta feature notice This feature is in Beta. Contact your Sales Representative or Netskope Support to enable this feature.
EDR integrations allow you to connect your organization’s Endpoint Detection and Response (EDR) tools directly to AISecOps. When an EDR integration is configured, the Insider Threat Agent automatically enriches user investigations with endpoint signals — device risk, recent detections, and device hygiene — alongside Netskope-native signals such as User Confidence Index (UCI), Data Loss Prevention (DLP) incidents, and behavioral anomalies.
EDR integrations connect directly to your vendor’s APIs. Netskope Cloud Exchange is not required and is not used in this integration path.
The following EDR vendors are supported:
- CrowdStrike Falcon
- SentinelOne Singularity
- Microsoft Defender for Endpoint
You can configure one, two, or all three vendors simultaneously. Multi-vendor configurations are supported for organizations running a mixed or migrating EDR estate.
Data Handling
EDR integrations transmit device-identifying data outside the Netskope environment to enable device lookups at the configured vendor. Review this section, along with your organization’s own data protection obligations, before enabling an EDR integration.
When an EDR integration is triggered during an Insider Threat investigation, Netskope’s AI Worker service queries the vendor’s cloud API to look up the investigated user’s enrolled devices. All calls are read-only — Netskope does not write or modify data in the vendor’s system.
Data Transmitted Per Vendor
The specific device identifier and API endpoint used varies by vendor, as shown below:
- CrowdStrike Falcon: Device serial numbers, sent as a Falcon Query Language (FQL) filter to the Devices API. Serial numbers are sourced from Netskope’s own event logs for the investigated user.
- Data Not transmitted: email address, username, UPN, or any other user identifier.
- SentinelOne Singularity: Device serial numbers, sent as a query parameter to the Agents API. Serial numbers are sourced from Netskope’s own event logs.
- Data Not transmitted: username, email address, UPN, file hashes, or any other user identifier.
- Microsoft Defender for Endpoint: Device hostnames, sent in a KQL query to the Advanced Hunting API. Hostnames are sourced from Netskope’s own event logs.
- Data Not transmitted: email address, UPN, username, or file hashes.
Note: Device hostnames sent to Microsoft Defender may contain or imply a username, depending on your organization’s device naming convention (for example, a hostname like `JTAYLOR-WIN10`). Serial numbers sent to CrowdStrike and SentinelOne do not carry this risk.
Third-party Data Transmission
Looking up a user’s devices sends the identifiers above across Netskope’s environment boundary to the configured vendor’s cloud API (CrowdStrike, SentinelOne, or Microsoft Defender). The vendor returns device and risk data in response, which AISecOps uses to enrich the investigation.
Retention
Netskope does not maintain a separate cache of EDR vendor API responses. Data returned from the vendor is stored as part of the investigation record and retained according to the tenant’s configured AISecOps data retention period.
Customer Responsibility
By enabling an EDR integration, the tenant administrator authorizes Netskope to transmit the device identifiers listed above to the configured vendor’s cloud API during Insider Threat investigations. Customers are responsible for ensuring this transmission is permitted under their own privacy policies, applicable data protection regulations (e.g., GDPR, CCPA), and end-user agreements.
Prerequisites
Before you configure an EDR integration, ensure that:
- You have a tenant administrator role for AISecOps.
- Your organization is entitled to the Insider Threat AISecOps Agent.
- You have the OAuth credentials or API token for the EDR vendor you are connecting.
- For Microsoft Defender for Endpoint: you have completed an Azure Active Directory (Azure AD) app registration with the required Graph Security and Defender API permissions.
Configure a SentinelOne Singularity Integration
SentinelOne Singularity enriches Insider Threat investigations with per-user identity risk, device risk scores, threat detections with MITRE technique tags, and privilege-change events.
- Go to AISecOps > Configuration > Integrations > SentinelOne Singularity.
- Enter your SentinelOne API token.
- Enter your SentinelOne console URL.
- (Optional) Enter a site or scope filter to limit enrichment to a specific SentinelOne site.
- Click Test Connection to validate each read scope independently. The test result shows a success or failure status per capability category: device risk, detections, and hygiene.
- Click Save.
The integration card updates to show the connection status and the last successful sync per capability category.
Configure a CrowdStrike Falcon Integration
CrowdStrike Falcon enriches Insider Threat investigations with Falcon Identity Protection user risk, Falcon ZTA and Spotlight device risk, recent detections with MITRE technique tags, device hygiene, and indicators of compromise (IOC) sightings on the user’s devices.
- Go to AISecOps > Configuration > Integrations > CrowdStrike Falcon.
- Enter your CrowdStrike OAuth2 client ID and client secret.
- Select your CrowdStrike cloud region.
- Certain scopes are mandatory for this integration and must be added to the corresponding client ID directly in the CrowdStrike Falcon console (Support and Resources > API Clients and Keys). Enable the following read-only scopes: hosts (device lookup), zero-trust-assessment (device risk score), alerts (detections with MITRE ATT&CK mapping), and iocs-indicators-of-compromise/ioc-management (IOC sightings). Do not grant any write permissions.
- Click Test Connection to validate each read scope independently.
- Click Save.
Configure a Microsoft Defender for Endpoint Integration
Microsoft Defender for Endpoint enriches Insider Threat investigations with Defender for Identity user risk, Defender for Endpoint machine risk scores, Graph Security alerts with MITRE technique tags, device sensor health, and IOC sightings.
Note: This integration requires an Azure AD app registration with admin-consented Microsoft Graph Security and Defender for Endpoint API permissions, specifically Machine.ReadWrite.All (device hygiene), Alert.ReadWrite.All (detections), and AdvancedQuery.Read.All (Advanced Hunting device lookup).
- Go to AISecOps > Configuration > Integrations > Microsoft Defender for Endpoint.
- Enter your Azure AD tenant ID.
- Enter your Azure AD application (client) ID and client secret.
- Click Test Connection to validate each read scope independently.
- Click Save.
Note: If your organization does not have a Microsoft Defender for Identity license, Defender for Endpoint computes user risk by aggregating risk scores across the user’s devices. The integration health page indicates when this degraded path is active.
Disconnect an EDR Integration
You can disconnect an EDR integration when it’s no longer needed. Disconnecting an integration deletes its configuration and credentials.
- On the Integrations page, click the integration you want to disconnect.
- Click Disconnect.
To reconnect, configure the integration again from the beginning.
View EDR Integration Health
On the Integrations page, each EDR integration card shows an icon, label, name, and subtitle. Cards in the list are not badged. Click a card to open its detail page, which shows a Connected or Connection error badge in the header, the “Connected on” date, and a Test Connection action. There is no periodic health polling and no per-capability sync-time tracking. If credentials become invalid, the badge turns red and the surfaced error message describes the failure. Re-entering credentials in the integration form and clicking Save restores the connection.
How EDR Enrichment Appears in Investigations
When an EDR integration is configured and a user is investigated by the Insider Threat Agent, the user detail panel includes an Endpoint Detection & Response section containing:
- Max device risk score — the highest per-device risk score across the user’s devices.
- Detections by severity — a bar chart showing critical, high, medium, low, and info counts.
- Device Health overview cards — Critical, Warning, Healthy, and Unknown counts.
- A Device Health Table with columns for Last seen, Hostname, Health, Risk, Detections, OS/Platform, and Vendors. Each row expands to show a detections sub-table with Date, Severity, Title, Vendor, MITRE techniques, and Status. Detections are sorted by severity, then timestamp.
- Vendor attribution, shown as a plain text list next to the section title. Configured vendors that returned no data are listed with a “No data returned” suffix.
An EDR Detections tile, showing the total detection count, appears in the risk indicator strip alongside UCI Score, Anomalies, DLP, Malware, and Malsite, but only when EDR enrichment returned data. - If EDR enrichment fails or is not configured, the section and the tile are omitted. Enrichment status appears within the AI Summary. If enrichment partially succeeds, a “Some data is incomplete” notice also appears on top of the Endpoint Detection & Response card.

