Netskope AI SecOps can deliver Cases, User Risk, and AI Risk events to Microsoft Sentinel in near real time through Outbound Webhooks and the Azure Monitor Logs Ingestion API. This article walks through the full setup: the Azure resources, the identity, the webhook configuration, and the queries to work with the data. Everything is copy-paste ready — replace the <angle-bracket> placeholders with your own values.

What you will build

Prerequisites

• An Azure subscription with an existing Log Analytics workspace (Sentinel-enabled or plain Log Analytics both work).
• Permission to deploy resources into a resource group, create a Microsoft Entra app registration, and assign Azure roles.
• Azure CLI. Azure Cloud Shell works well; all commands below are single-line and run in PowerShell or bash.
• A Netskope AI SecOps tenant with the Outbound Webhooks feature.

Values you will collect along the way

Step 1 — Deploy the table, DCE, and DCR

Save the ARM template below as netskope-aisecops-dce-dcr.json. It creates three resources: the custom table NetskopeAISecOps_CL inside your workspace, a Data Collection Endpoint, and a Data Collection Rule wired to both. The workspace may live in a different resource group than the DCE and DCR; the template asks for both values. The DCE and DCR must be created in the workspace’s region — the deploy snippet below fetches it with one command and passes it in. The deployment is idempotent — re-running it updates in place.

Deploy it. If you omit --parameters, the CLI prompts for the workspace name and its resource group:

https://github.com/netskopeoss/Netskope_Web_Transactions_Azure_Sentinel/blob/main/Netskope-AI-SecOps-AzureSentinel/netskope-aisecops-dce-dcr.json

$loc = az monitor log-analytics workspace show --resource-group <workspace-resource-group> --workspace-name <workspace-name> --query location -o tsv

 

az deployment group create --resource-group <resource-group> --name aisecops-webhook --template-file netskope-aisecops-dce-dcr.json --parameters workspaceName=<workspace-name> workspaceResourceGroup=<workspace-resource-group> location=$loc

 

az deployment group show --resource-group <resource-group> --name aisecops-webhook --query properties.outputs

 Record four outputs: dceLogsIngestionEndpoint, dcrImmutableId, dcrResourceIdForRoleAssignment, and destinationUrl (the last is useful for the optional curl test in Step 5).

Step 2 — Create the Microsoft Entra identity

The webhook authenticates with OAuth2 client credentials. Create an app registration, generate a secret, and grant it write access on the DCR:

az ad app create --display-name "netskope-aisecops-webhook" --query appId -o tsv

az ad sp create --id <client-id>

az ad app credential reset --id <client-id> --append --years 1

az role assignment create --assignee <client-id> --role "Monitoring Metrics Publisher" --scope <dcr-resource-id>

az account show --query tenantId -o tsv

Four things to know:

1. The first command prints the Application (client) ID — that is your <client-id>. It is unique to the app you just created in your own Entra tenant. There is no shared or Netskope-provided client ID for this integration; values copied from another environment or from screenshots will not work in yours.
2. The credential reset output shows the client secret once in its password field. Copy the secret Value into a secret store immediately. Do not confuse it with the Secret ID: the Value contains special characters like ~ and dots and is what authenticates; the Secret ID is a plain GUID used only for managing the credential.
3. The Monitoring Metrics Publisher role sits on the DCR itself, so a single assignment covers the integration. If the role command returns "principal not found", the service principal has not replicated yet — wait a minute and re-run just that command.
4. The last command prints your Entra tenant ID. You will use it in Step 4 to build the Token URL: https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token. Like the client ID, it is specific to your tenant.

Portal alternative: Microsoft Entra ID → App registrations → New registration, then Certificates & secrets → New client secret. Copy the Value column right after creation.

Step 3 — Create the parser function

Save the query below as NetskopeAISecOpsEvents.kql and register it as a workspace function:

https://github.com/netskopeoss/Netskope_Web_Transactions_Azure_Sentinel/blob/main/Netskope-AI-SecOps-AzureSentinel/NetskopeAISecOpsEvents.kql

$parser = Get-Content ./NetskopeAISecOpsEvents.kql -Raw

az monitor log-analytics workspace saved-search create --resource-group <workspace-resource-group> --workspace-name <workspace-name> --name NetskopeAISecOpsEvents --category Netskope --display-name "NetskopeAISecOpsEvents" --saved-query $parser --func-alias NetskopeAISecOpsEvents

NetskopeAISecOps_CL is the table — where the data is stored. 

Step 4 — Configure the webhook in AI SecOps

In your Netskope tenant, open AI SecOps → Configuration → Integrations → Outbound webhooks and create a webhook.

Connection tab

Azure Government note: use https://login.microsoftonline.us/<tenant-id>/oauth2/v2.0/token as the Token URL and https://monitor.azure.us/.default as the Scope.

Events tab

Select the event types to deliver. All Cases, User Risk, and AI Risk types can share this single webhook — the table and parser handle every type.

Payload tab

Review & test tab

Step 5 — Test and verify

From Review & test, pick a real event type such as case.created and send a test. Prefer real event types over webhook.test: the synthetic test event carries no business fields and lands as a mostly empty row.

Allow a few minutes. Two timing behaviors are normal on a fresh setup: the first records into a new table take longer to appear, and DCR configuration changes take several minutes to reach the ingestion pipeline. Then query:

NetskopeAISecOps_CL

How the data is structured

Each webhook delivery is a JSON array. Each element is an envelope with delivery metadata at the top level and the actual event under data:

[

  {

    "id": "evt_...",

    "timestamp": "2026-07-02T19:30:00Z",

    "tenant_id": "1234",

    "region": "us-west-2",

    "api_version": "2026-08-01",

    "type": "case.created",

    "data": { "case_id": "case_01HXYZ", "severity": "high", "...": "..." }

  }

]

The table stores the envelope in five typed columns and the event whole in Data:

Columns marked * stay dynamic. Reach inside them with dot notation: FileLineage.files[0].md5, DataConfidence.score, RiskIndicators.policy_alerts. Fields not present on a given event type are null — filter with isnotempty().

Troubleshooting

Maintenance

The client secret expires on the date set at creation (one year in the commands above). Rotate it before expiry: create a new secret with az ad app credential reset --id <client-id> --append --years 1, update the webhook’s Client secret field, verify a test delivery, then remove the old credential in Entra. An expired secret stops deliveries without any error visible on the Azure side.