canonical: https://jentic.com/apis/azure.com/azure-security-insights # Microsoft Azure Security Insights Jentic publishes the only available OpenAPI specification for Security Insights, keeping it validated and agent-ready. The Azure Security Insights API exposes the Microsoft.SecurityInsights resource provider that powers Microsoft Sentinel, the Azure-native SIEM. It lets agents manage scheduled and Microsoft-source alert rules, attach automated actions to those rules, and connect telemetry data sources such as Office 365, AAD, AWS CloudTrail, and threat intelligence feeds into a Log Analytics workspace. The API is workspace-scoped and is the same control plane the Microsoft Sentinel portal uses under the hood. ## For AI agents Manage Microsoft Sentinel alert rules, automated rule actions, and data connectors that bring telemetry into a Log Analytics workspace. ## Scope Does not query raw log data, manage incidents, or run hunting queries - use for Sentinel alert rule, action, and data connector configuration only. ## Capabilities - Create scheduled alert rules that run KQL queries against Sentinel workspace data - Attach automated actions such as logic app playbooks to alert rules - Onboard data connectors for Office 365, Azure AD, AWS CloudTrail, and threat intelligence feeds - List the available Microsoft.SecurityInsights operations exposed in a region - Disable or re-enable a Sentinel alert rule without deleting it - Inspect the configuration of a connected data source attached to a workspace - Tune detection logic by updating an alert rule's query, severity, or trigger threshold ## Use cases ### Detection-as-Code Deployment Security engineering teams version-control their Sentinel detections and push them through CI rather than editing rules in the portal. The alertRules endpoint accepts the full rule definition - KQL query, query frequency, period, severity, and trigger threshold - so a pipeline or agent can deploy a catalogue of detections to one or many workspaces deterministically and roll forward when the query logic changes. Example prompt: Create a scheduled alertRule in the workspace with a KQL query for repeated failed Azure AD sign-ins, severity High, query frequency PT5M, and triggerThreshold 5 ### SOAR Playbook Wiring Security operations teams automate response by attaching Logic Apps to detections so that when a rule fires, an incident is enriched, a user disabled, or an analyst paged. The alertRules/{ruleId}/actions endpoint links a Logic App resource ID to a rule and lets an agent rotate or replace the playbook without touching the detection logic itself. Example prompt: Create an action under alertRules/{ruleId}/actions that wires a Logic App resource ID to fire when the rule triggers ### Multi-Tenant Connector Audit MSSPs and central security teams audit which data sources are flowing into each customer or business unit workspace. The dataConnectors list endpoint returns every configured connector with its kind (Office365, AzureActiveDirectory, AmazonWebServicesCloudTrail, ThreatIntelligence, and others) so an agent can build a coverage report and flag workspaces missing critical telemetry. Example prompt: List dataConnectors for the workspace and return the kind and dataTypes state for each connector ### AI Agent SOC Triage An agent built on Jentic uses Security Insights to inspect and tune detections during incident response. The agent can read the rule that fired, lower or raise its threshold, disable it during a known false-positive storm, and re-enable it once the underlying noise is fixed - all without an analyst opening the Sentinel UI. Example prompt: Search Jentic for disable a sentinel alert rule, load the schema, and PATCH the rule to set enabled false for the next 24 hours ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/providers/Microsoft.SecurityInsights/alertRules | List all alert rules in a Sentinel workspace | | PUT | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/providers/Microsoft.SecurityInsights/alertRules/{ruleId} | Create or update a Sentinel alert rule | | DELETE | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/providers/Microsoft.SecurityInsights/alertRules/{ruleId} | Delete a Sentinel alert rule | | PUT | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/providers/Microsoft.SecurityInsights/alertRules/{ruleId}/actions/{actionId} | Attach a Logic App playbook action to a rule | | GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/providers/Microsoft.SecurityInsights/dataConnectors | List configured data connectors for a workspace | | PUT | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/providers/Microsoft.SecurityInsights/dataConnectors/{dataConnectorId} | Onboard or update a data connector | ## Key resources - **alertRules** — Create, list, update, and delete scheduled and Microsoft-source detection rules in a Sentinel workspace - **alertRules/actions** — Attach and manage Logic App playbook actions on a specific alert rule - **dataConnectors** — Onboard and inspect data sources such as Office 365, Azure AD, AWS CloudTrail, and threat intelligence - **operations** — List the operations exposed by the Microsoft.SecurityInsights resource provider ## Why Jentic - **Setup:** Wiring the Security Insights API by hand means registering an Azure AD app, running the OAuth2 azure_auth implicit flow with the user_impersonation scope against management.azure.com, and building the deeply nested Log Analytics workspace path that every Sentinel operation sits under. Through Jentic you install once, import Security Insights from the API Directory, store the Azure service principal credential once, and your agent calls it. - **Permission scoping:** Security Insights puts the workspace and rule identifiers in the URL path (.../workspaces/{workspaceName}/providers/Microsoft.SecurityInsights/alertRules/{ruleId}), so a rule can pin your agent to one Sentinel workspace. You choose the operations it may call, so destructive ones like deleting an alert rule are not included unless you add them. - **Credential handling:** Your Azure service principal credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'create a Microsoft Sentinel alert rule' or 'onboard a Sentinel data connector', and Jentic returns the matching Microsoft.SecurityInsights operation with its input schema, ready to execute. ## Related APIs - **Azure Security Center** — CSPM controls and Defender plans that feed alerts into Sentinel - **Amazon GuardDuty** — AWS-native threat detection service - **AWS Security Hub** — AWS-native findings aggregator across security services ## FAQ ### Why is there no official OpenAPI spec for Security Insights? Microsoft Azure does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Security Insights via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the Security Insights API use? Security Insights uses Azure AD OAuth 2.0 with the implicit flow against https://login.microsoftonline.com/common/oauth2/authorize and the user_impersonation scope. When called through Jentic, your service principal credentials sit in your Jentic One instance and the agent only ever sees a short-lived bearer token scoped to the subscription it is acting on. ### Can I create Microsoft Sentinel alert rules with this API? Yes. PUT /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/providers/Microsoft.SecurityInsights/alertRules/{ruleId} accepts the rule kind (Scheduled or MicrosoftSecurityIncidentCreation), KQL query, query frequency, severity, and triggerThreshold. The same path supports DELETE to remove a rule. ### How do I attach a Logic App playbook to an alert rule? Use PUT /subscriptions/{subscriptionId}/.../alertRules/{ruleId}/actions/{actionId} with the Logic App resource ID and the trigger URI. The action becomes part of the rule and runs when the detection fires; you can replace it later by PUT-ing the same actionId with a different Logic App. ### What are the rate limits for the Security Insights API? Azure Resource Manager applies subscription-level throttling for both reads (around 12,000 per hour) and writes (around 1,200 per hour) per principal, surfaced in the x-ms-ratelimit-remaining-subscription-reads and x-ms-ratelimit-remaining-subscription-writes response headers. Jentic returns those headers so an agent can pace itself before hitting the cap. ### How do I onboard a data connector through Jentic? Search Jentic for onboard sentinel data connector, load the schema for PUT /.../dataConnectors/{dataConnectorId}, and execute it with the connector kind (for example AzureActiveDirectory or AmazonWebServicesCloudTrail) and the dataTypes block enabled. The full search, load, and execute flow ships in the Jentic Python SDK after pip install jentic. ### Does this API let me read raw security events? No - this API manages the Sentinel control plane (rules, actions, connectors). To query events you run KQL against the Log Analytics workspace through the Azure Monitor Logs query API. Use Security Insights to configure detections and use the Log Analytics query API to read what they produce. ### Can I limit what my agent is allowed to do with the Microsoft Azure Sentinel API? Yes. Because Jentic One is self-hosted, you set the rules that decide which Security Insights operations and which Azure service principal credential your agent may use. Since the workspace and rule identifiers live in the URL path (.../workspaces/{workspaceName}/providers/Microsoft.SecurityInsights/alertRules/{ruleId}), you can pin the agent to a single Sentinel workspace. You also choose the exact operations it can call, so destructive ones like deleting an alert rule stay out of reach unless you explicitly add them.