push connector · logs ingestion api

Wytness for Microsoft Sentinel

Push Wytness anomalies into a custom Sentinel table you own. Your SOC sees them next to everything else they investigate.

what it does

Where your alerts land

Sentinel is where your SOC already lives. Wytness sends every anomaly to a custom Log Analytics table that you provision and own, via the Logs Ingestion API. Your detection rules, workbooks, and Logic Apps run against Wytness records the same way they run against any other source.

setup

From nothing to first delivery

In your Azure tenant, create a Data Collection Endpoint (DCE) and a Data Collection Rule (DCR) with a custom stream declaration for Wytness anomalies, flowing to a custom table in your Log Analytics workspace.

Create an App Registration with a client secret; grant its service principal the Monitoring Metrics Publisher role on the DCR (allow a few minutes for the role to propagate).

In the Wytness app, go to Integrations → Connectors → Add connection → Microsoft Sentinel and enter the tenant ID, client ID, client secret, DCE endpoint, DCR immutable ID, and stream name. The delivery URL is derived for you.

Click Test connection. A test record should appear in your custom table within a few minutes (Log Analytics ingestion lag, not Wytness).

Save. Anomalies dispatch within about 30 seconds of detection.

azure cli · service-principal provisioning

terminal

1# After creating the DCE + DCR + custom table (portal or template),
2# register the Entra app and grant the role:
3 
4$ az ad app create --display-name "Wytness Logs Ingestion" \
5    --sign-in-audience AzureADMyOrg
6$ az ad app credential reset --id <APP_ID> --append --years 1
7$ az ad sp create --id <APP_ID>
8$ az role assignment create \
9    --assignee <SP_OBJECT_ID> \
10    --role "Monitoring Metrics Publisher" \
11    --scope <DCR_RESOURCE_ID>

The DCE, DCR, and custom table can be provisioned in the portal or by template — the /docs/connectors setup guide walks through the exact pieces and the six wizard values.

the payload

What arrives in your custom table

Every anomaly POSTs to {dce}/dataCollectionRules/{dcr-id}/streams/{stream-name} as a list-of-one record matching your DCR streamDeclaration. Field names stay stable so your KQL keeps working as the connector evolves.

sentinel_payload.json

1[
2  {
3    "TimeGenerated": "2026-05-23T14:23:41Z",
4    "AlertId":     "9f2d1c34-8a7b-4e2d-b1a0-5c6d7e8f9a0b",
5    "AgentId":     "payments-reconciler-v3",
6    "RuleName":    "off_hours_activity",
7    "Severity":    "high",
8    "Description": "Tool invocation outside business hours window (08:00-18:00 AEST).",
9    "Source":      "Wytness",
10    "WytnessUrl":  "https://app.wytness.ai/anomalies?alert_id=9f2d1c34-8a7b-4e2d-b1a0-5c6d7e8f9a0b"
11  }
12]

prove it landed

Verify end to end

Run this in your Log Analytics workspace after firing a Wytness test record. One row in the last hour means the pipeline is wired correctly end-to-end.

verify.kql

1// Confirm Wytness records are landing — replace Wytness_CL with the
2// custom-table name you chose in your DCR streamDeclaration.
3Wytness_CL
4| where TimeGenerated > ago(1h)
5| where Source == "Wytness"
6| project TimeGenerated, AgentId, RuleName, Severity, AlertId
7| order by TimeGenerated desc
8| take 50

the boundary

What flows and what doesn't

Writes

Anomaly records to one custom `*_CL` table you control

Auth

OAuth2 client-credentials against Entra ID; tokens cached and refreshed automatically

Reads

Nothing. We never query your workspace.

Other tables

Not touched. Scoped to the single DCR stream you provision.

Network

No change on your side — deliveries are outbound from Wytness to Azure's Logs Ingestion API. Wytness source IPs are not fixed; the Entra service principal is the authentication.

what you need

Required permissions

✓Monitoring Metrics Publisher on the target Data Collection Rule
✓App Registration with a client secret (or federated credential)
✓Tenant ID, Client ID, DCE endpoint, DCR immutable ID, stream name

stated plainly

Limitations

—

Latency

Wytness dispatches within about 30 seconds of detection; Log Analytics then applies its own ingestion lag — typically a couple of minutes before records are queryable.

—

Ingestion costs

Logs Ingestion API records count against your workspace ingestion. Wytness sends one record per anomaly, not per event; at launch volumes this is measured in MB per month, not GB.

—

PII pseudonymisation

Anomalies sent to Sentinel are already pseudonymised on the way in. Raw PII never reaches your workspace; Sentinel sees the same EMAIL_a3f9b1c4 pseudonym shape your auditor sees in the Evidence Pack.

Keep reading

/docs/connectors

Connector setup guide

The full integrator contract — network requirements, delivery semantics, and every wizard field. Read the guide.

/connectors

All connectors

Sentinel, Splunk, ServiceNow, Slack, and the generic webhook. See the index.

tier

Tier availability

Business plan or higher.

One DCR. One custom table. Anomalies land in your SOC.

Start recording Ask a question