AI agents investigate every alert, add context, and prepare cases for response, on a full-stack SecOps platform that captures and correlates all your security data.
Cloud-based SIEM platform providing visibility across all your data sources
Every alert investigated, with a verdict and the evidence behind it
Manage your external footprint, publicly available data, and Dark Web leaks
Log management and threat detection across any of your log sources
Get ultimate assurance that your environment is free from threat actors
Fully featured distrubuted NDR for on-premises and public cloud environments
A SecOps platform purpose-built for industrial and OT environments
Integrated endpoint agent providing deep visibility, response and forensics
Deploy honeypots and honeytokens and stay ahead of threat actors
24x7 security operations from our Australian SOC. AI investigates every alert, and experienced analysts validate findings and contain threats around the clock.
24x7 managed detection and response across endpoint, network, cloud, identity, and log sources
AI investigations and 24x7 MDR on the Microsoft Sentinel you already own
Eyes-on-glass SOC and continuous threat hunting
Expert hunters and AI agents find attacker activity your alerts missed
Quickly recover from cyber attacks and breaches
ThreatDefence is the only SecOps as a Service company providing broad coverage across your entire technology stack with evidence-based security.
We provide security teams with full-stack SecOps infrastructure – you get deep visibility from day one, gain control over your security data, and get access to a comprehensive set of ready-to-use tools, detections, workflows, playbooks and scenarios.
24x7 SOC, Continuous Monitoring, Threat Containment and Incident Response
Visibility and actionable insights for all IT assets
Leverage our Cyber Range to train defenders based on real-world scenarios and simulations
OT and industrial cyber security services for critical infrastructure
Monitoring, evidence and a 24x7 SOC in one platform
Compliance monitoring, evidence and board reporting
Privacy Act reform impacts, obligations, and practical security considerations
Monitoring and compliance support for critical infrastructure environments
A practical guide to securing critical infrastructure with continuous monitoring
A practical buyer’s guide for schools evaluating SIEM and SOC services
A practical guide to selecting the right SIEM and SOC service for local government
Articles on security operations, AI and compliance
Events, awards and company news
Read what our customers say about us
Solution briefs and datasheets
How we keep your data secure
Technical support and knowledge base
Guides, case studies, and advisories in one place
How AI agents investigate alerts and run security operations
Free ebook: a practical guide to adopting an AI SOC platform
A practical guide to incident response and digital forensics
Where SOAR playbooks fit and where AI agents take over
Free ebook: modern security operations with Microsoft Sentinel
How the framework is structured and what changes from the Essential Eight
November 13, 2026
November 10, 2026
November 6, 2026
We provide end-to-end SecOps solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs).
Find out how you can become a ThreatDefence partner.
Protect your entire technology stack and build your SecOps on your own pace
White-labeled AI SOC for every client tenant, co-managed with our SOC team
Launch your SOC business without any upfront investment
Embed security operations, threat intelligence and exposure data in your product
Sovereign SOC for Australian MSPs and MSSPs, with onshore analysts and client data
Set the rules for closing alerts automatically, with evidence checks and review
How MSPs deliver branded security monitoring with a SOC partner
ThreatDefence was an official partner of the Cyber Resilience Summit NSW, 29 October 2026 at Hilton Sydney.
Our team was back at BSides Canberra, and our cyber quiz was a hit again.
Two days in Perth with our partner Ever Nimble, on security operations and cyber resilience.
Sponsors of the AUSCERT Cyber Security Conference on the Gold Coast.
Sponsors of the Gartner Security & Risk Management Summit in March.
Sponsors of the Cyber Security for Critical Assets Summit in Perth, February 2026.
Expert conversations with speakers and attendees at CyberCon Melbourne 2025.
An agentic SOC adds AI investigation and coordinated response to the Microsoft Sentinel environment you already run.
Agents take work from the incident queue, gather evidence across connected systems, and prepare findings and actions for analysts to review. Approved workflows can also close incidents or execute specific response actions within defined limits.
Start with the work and the people responsible for it. An agentic SOC needs clear ownership of investigations, escalations, response, and quality, even when agents carry out much of the routine work.
Decide what should change for the team. Your first goal might be to remove repetitive evidence gathering, shorten overnight investigation delays, or give analysts completed assessments for a frequent alert class.
Define the responsibilities alongside that goal:
Gather and assess evidence, document findings, and prepare the permitted next steps.
Resolve uncertainty, challenge conclusions, direct further work, and handle decisions requiring judgment.
Maintain integrations, investigation skills, detections, and execution controls.
Approve the scope, acceptance criteria, and authority granted to each workflow.
An agentic SOC can grow beyond triage into hunting, detection engineering, and reporting. Those workflows should share evidence and established methods, with responsibility assigned for their outputs.
For the wider operating model, see What Is an Agentic SOC?.
Build around one workflow first, then increase its scope and authority separately. Adding another alert class needs investigation testing; allowing an action to run without approval needs its own execution testing.
These are practical checkpoints, rather than a requirement to automate every stage. An approved-response workflow can remain human-approved indefinitely. Automatic closure and containment are separate permissions, and neither should be enabled across the whole queue at once.
Begin with a limited set of incidents and a named analyst responsible for review. Keep the existing monitoring and response process running while you compare results. Define how unfinished work returns to that process if the agent fails, reaches a limit, or is suspended.
Closure-policy testing is covered in Autonomous Alert Triage.
Microsoft Sentinel can remain your SIEM and incident source. The agent layer connects its data and tools to a managed investigation process, while analysts retain visibility and control.
The following capabilities need to work together, whether supplied by Microsoft, an adopted platform, or your own implementation.
An MCP connection supplies tools. It does not, by itself, supply queue ownership, case handling, approval procedures, or service monitoring. Include those in the design from the beginning.
Keep the investigation state outside a single model conversation. If a run stops, an analyst or another run needs to know what completed, what remains unresolved, and whether an action already executed.
Building an agentic SOC does not require writing every component yourself. Choose the combination that fits your workflows and the engineering capacity available to maintain them.
These approaches can coexist. A native phishing agent may handle an eligible scenario while another workflow investigates custom Microsoft Sentinel incidents or follows evidence into an independent business application.
Microsoft provides several distinct capabilities:
Email and collaboration triage, including supported phishing alerts, is generally available. Cloud and identity expansion remains documented as preview. Check the supported alert list and product prerequisites.
Looks for missed threats across Defender and Microsoft Sentinel signals and generates dynamic alerts. Its dedicated documentation currently labels it public preview.
Provides on-demand analysis over supported Defender, Microsoft Sentinel, or lake data. Its documentation is prerelease, and it is configured per user.
Supports interactive hunting, query generation, interpretation, and follow-up investigation.
These capabilities do not all process the same queue or have the same authority. Use the current product documentation and your tenant configuration to establish what each one will actually do.
Microsoft’s integration is strongest across its own stack, but an incident may require other evidence to reach a conclusion. Broader coverage assessment is covered in Augmenting Microsoft Sentinel.
Choose a workflow that is frequent enough to matter, familiar enough to review, and supported by the evidence already available. Examples include a particular identity alert, reported phishing, or an endpoint rule that repeatedly needs the same contextual checks.
Avoid starting with every incident type at once. Different classes need different sources, legitimate explanations, and escalation criteria.
Write a short workflow specification before configuring the agent:
This specification becomes the basis for the agent instructions, tool design, and acceptance tests. It also gives analysts a consistent way to review the result.
Test the workflow using the identity the agent will actually run under. A successful query in an administrator’s session does not establish that the deployed agent can retrieve the same evidence.
Confirm that the required sources cover the relevant accounts, devices, event categories, and investigation period. A recent record proves some delivery, not complete coverage.
Validate account, host, IP address, and application mappings. Prefer stable directory and device identifiers where available. Application client IDs, application object IDs, and service principal object IDs are different identifiers and must be resolved correctly.
Add the context needed to interpret the activity: asset importance, privileged accounts, application owners, approved tools, and change windows. Give exceptions an owner and review date.
For a custom integration, grant the query permissions needed and add incident-update permissions only when required. Log Analytics Reader and Microsoft Sentinel Responder serve different purposes. A read-only investigator does not need incident write authority.
Defender response and Microsoft Graph actions require separate permissions. Access to a workspace does not authorize endpoint isolation, session revocation, or directory changes.
Security Copilot roles also do not replace underlying data permissions. Its agent setup can use a dedicated supported agent identity or, for some scenarios, a user account. Avoid making a shared administrator account the dependency for unattended work.
Record the allowed tenants and workspaces in the execution configuration. Do not let an account name or instruction inside an alert choose the authorization scope.
The agent needs tools that can retrieve the evidence required by the investigation. Use supported APIs, query interfaces, and Microsoft Sentinel MCP collections according to the operation.
Start with a small tool set:
Keep tenant, workspace, incident, and source identifiers in the results. Preserve the distinct identifiers used by Microsoft Sentinel and Defender when records are synchronized.
A tool should state what it returns and the inputs it accepts. A sign-in tool might accept one identity and a bounded time range, then return matching records, the searched scope, and completion status.
Return errors, partial results, pagination, and truncation explicitly. The agent must be able to distinguish no matches from an incomplete search.
For common checks, reviewed parameterized queries can reduce query-writing variation. They still need tests for the selected identifier, supplied parameters, and interpretation of the result.
Microsoft Sentinel provides hosted MCP tool collections using Entra authentication. Collection capabilities and permissions differ.
The triage collection works in the home tenant, without guest or delegated access, cannot select a workspace, and does not query the lake. Its capabilities have preview documentation. Do not assume it supplies the same access path as a custom integration using Azure Lighthouse.
Data exploration tools support lake exploration and entity analysis. Entity analyzer can assess supported users or URLs, consumes SCUs, and can incur underlying query charges. Graph-related capabilities have their own availability and preview limits.
Custom MCP tools, currently in preview, can expose saved advanced hunting and lake queries with parameters. Documented creation roles include Security Operator, Security Administrator, and Global Administrator; invocation supports Security Reader and Global Reader. A default workspace hint is not an authorization boundary.
For an external agent host, verify where retrieved evidence and model requests are processed. The Microsoft Sentinel workspace region does not establish the processing location of every connected service.
The workflow should let the agent adapt its questions while keeping the required checks and boundaries clear.
Use an appropriate supported trigger, integration, or polling process. Select the intended alert class and retrieve the original incident and entities.
Use a stable run key incorporating the tenant, workspace, and incident identity. An incident update or retried notification should not start another independent investigation by accident. Also prevent the agent’s own comments or tags from repeatedly retriggering the workflow.
Confirm the investigation window and required sources. Check whether the evidence is accessible and whether important collection gaps exist.
If a required source is unavailable, record the reason and follow the workflow’s escalation rule. Do not silently replace a failed query with an assumption that nothing happened.
Run the required checks, then pursue relevant findings. A suspicious sign-in may lead to authentication changes, application grants, mailbox access, or activity on an endpoint.
Test legitimate explanations too. A new application credential can be an approved rotation; an unusual administrative tool can be part of maintenance. Use the supporting records and owner context to establish which explanation fits.
Separate established facts, interpretation, and unresolved questions. Reference the records supporting important conclusions and retain the query text, scope, and execution outcome.
An inconclusive assessment is appropriate when missing evidence could change the decision. It should explain what an analyst needs to resolve, with the completed work available for review.
Route the case to the responsible analyst or prepare the permitted response plan. Keep action preparation separate from authorization to execute.
A plan should identify the target, reason, scope, expected impact, and recovery procedure. Its status should distinguish proposed, approved, submitted, completed, and failed actions.
The underlying agent components are explained further in AI SOC Agents.
Reusable skills capture the team’s investigation methods. They should define the questions to answer, mandatory checks, useful tools, evidence requirements, and circumstances requiring escalation.
Keep skills versioned alongside tool definitions and policies. Record the deployed version with each investigation so results can be traced after a change.
Context should have a source and an age. Approved activity, privileged identities, application ownership, and earlier cases can improve an assessment, but stale or unrelated context can also produce a wrong conclusion.
Historical records and graph relationships support further investigation. A graph edge shows a relationship, not proof that an attacker used it. A thirty-day baseline is meaningful only if the required evidence exists for that period.
Confirm the query route for older lake records rather than assuming every advanced hunting query searches the entire retention period.
Feedback needs review before becoming general guidance. Microsoft’s documented feedback learning for the triage agent currently applies to email and collaboration alerts; do not assume every agent automatically learns from every correction.
Agents and playbooks perform complementary work. An agent can decide which evidence to check next, while an established workflow carries out routing, notification, approvals, and response steps.
Microsoft’s AI playbook generator, generally available since May 2026, can help create Python-based playbooks through conversation. Generated workflows still need testing and access review.
Use the same execution checks whether a request comes from an agent or a person. The wider comparison is covered in AI SOC vs SOAR.
An agent can investigate independently while still requiring approval to close an incident or change a production system. Configure those permissions separately.
Useful operating levels are:
The agent investigates and proposes the outcome. A person decides and acts.
The agent prepares a specific action for an authorized person to approve.
A defined action can run when its eligibility and policy conditions are satisfied.
These describe the operating design, not one universal Microsoft setting. Implement the corresponding boundaries across the agent identity, tools, runtime, and response workflow.
Approval should apply to the specific target and plan presented. Recheck the current state before execution, suppress duplicate requests, and verify the outcome afterward. An accepted API request is not the same as completed containment.
Test stop controls too. Disabling the agent may not cancel a running playbook or revoke an action identity. Operators need to know how to stop pending work and return affected cases to manual handling.
Do not use a confidence number alone as authority to close or contain. The evidence requirements, target eligibility, and execution policy still need to be satisfied.
Plan for investigation demand, tool limits, and the people handling exceptions. Capacity is part of the service design rather than a check after deployment.
Security Copilot uses Security Compute Units, or SCUs. Eligible Microsoft 365 E5 and E7 tenants receive 400 monthly SCUs per 1,000 paid user licenses, scaled for smaller tenants, up to 10,000 monthly SCUs. The allowance is shared across Copilot experiences and agents, with no rollover. Confirm tenant provisioning.
Purchased provisioned capacity follows a different model: hourly billing and refresh in fixed clock-hour blocks, with unused capacity expiring. Configured overage can cover additional consumption within its limit. Microsoft’s inclusion documentation describes future throttling and optional pay-as-you-go arrangements; verify the rules active for the tenant.
For illustration, 2,000 eligible licenses provide 800 monthly SCUs. Dividing that across 4,000 alerts leaves 0.2 SCU per alert before other use. This is budget arithmetic, not a per-investigation benchmark.
Measure completed investigations, failures, retries, and analyst follow-up alongside usage. Reserve capacity for complex cases and demand spikes. Include separate lake queries, graph operations, Logic Apps, and agent-specific commercial charges.
For supported delegated Security Copilot scenarios, Lighthouse uses partner capacity, while GDAP and B2B use client capacity. Access and workload support differ.
Set query, runtime, and concurrency limits around the tools actually used. When a limit prevents completion, the case needs a visible referral or retry state. Detailed data pricing is covered in Microsoft Sentinel Cost Optimization.
Test the complete workflow, not just whether the model gives a plausible answer. It needs to select appropriate tools, retrieve valid evidence, reach a supportable assessment, and respect execution boundaries.
Include confirmed attacks, convincing benign activity, reopened incidents, and cases analysts disputed. Review the labels rather than treating every old closure as ground truth.
Hide closing notes and later events that reveal the answer. Give the agent the evidence available at the point being tested, and keep a separate set outside tuning.
Define the facts the agent must establish and the unsupported conclusions it must avoid. A correct label based on invented evidence fails the test.
Test expired credentials, missing tables, permission denials, delayed records, partial results, and throttling. Confirm that these conditions cannot silently produce a benign closure.
Place harmless instruction attempts in attacker-controlled fields and tool results. Verify that they cannot change permissions, bypass approval, or redirect evidence.
Validate targets, exclusions, approval scope, retries, outcome checks, and recovery on controlled assets.
Repeat important cases to expose variation between runs. Re-run the test set after changes to models, skills, tools, permissions, or schemas.
Microsoft’s custom-agent testing experience helps inspect execution and tool behavior. Build-time validation and tuning scores do not replace security acceptance testing.
Report results by workflow and include sample sizes. High agreement across a largely benign queue can hide missed attacks, while escalating everything can deliver little useful automation.
Consider an incident where a new client secret is added to an application with permission to read mail across the tenant. The workflow must establish who added it, whether it was used, and whether the activity was authorized.
The following starter queries illustrate evidence tools an agent could use. They require local validation and do not establish compromise by themselves. The IP addresses are documentation examples.
Retrieve the original audit record. Confirm the actor, operation, timestamp, target type, and changed credential metadata. Resolve the application and its service principal before moving between tables.
Keep the application client ID, application object ID, and service principal object ID distinct. A wrong identifier can produce an empty query that looks reassuring.
This query connects successful credential-management activity with preceding risky sign-ins by a user account.
// Starting point: credentials added to apps or service principals // by a user who had a risky sign-in in the previous 24 hours. let lookback = 7d; let riskySignIns = SigninLogs | where TimeGenerated > ago(lookback) | where RiskLevelDuringSignIn in ("medium", "high") | project RiskyTime = TimeGenerated, UserPrincipalName, RiskyIP = IPAddress, RiskLevelDuringSignIn; AuditLogs | where TimeGenerated > ago(lookback) | where OperationName has_any ("Add service principal credentials", "Certificates and secrets management") | where Result == "success" | extend Actor = tostring(InitiatedBy.user.userPrincipalName) | extend TargetName = tostring(TargetResources[0].displayName), TargetId = tostring(TargetResources[0].id) | where isnotempty(Actor) | join kind=inner riskySignIns on $left.Actor == $right.UserPrincipalName | where TimeGenerated between (RiskyTime .. (RiskyTime + 24h)) | project TimeGenerated, Actor, OperationName, TargetName, TargetId, RiskyTime, RiskyIP, RiskLevelDuringSignIn
Suppose it returns a medium-risk sign-in forty minutes before the change. Check the original events and establish separately whether the address is new for that user.
The query can join several sign-ins to one change, inspects the first target resource, and excludes non-user actors. Validate audit operation names and review approved changes, authentication details, and the administrator’s responsibilities.
Use the service principal object ID to look for activity from unfamiliar source addresses.
// Starting point: service principal sign-ins in the last day // from IP addresses it did not use in the previous 30 days. let spId = "00000000-0000-0000-0000-000000000000"; // object ID from the incident let knownIPs = AADServicePrincipalSignInLogs | where TimeGenerated between (ago(30d) .. ago(1d)) | where ServicePrincipalId == spId | distinct IPAddress; AADServicePrincipalSignInLogs | where TimeGenerated > ago(1d) | where ServicePrincipalId == spId | where IPAddress !in (knownIPs) | summarize SignIns = count(), Resources = make_set(ResourceDisplayName), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by IPAddress, ResultType, Location
This includes successful and failed sign-ins and does not identify which credential was used. Its baseline describes the available records in the selected period, not every address the application has ever used.
Inspect original outcomes and, where populated, ServicePrincipalCredentialKeyId. Establish whether the new credential was used, then review the resource and subsequent activity. A Graph sign-in alone does not prove that mail was read.
ServicePrincipalCredentialKeyId
Review relevant workstation process and logon evidence, using network records for connection questions. No match in DeviceProcessEvents or DeviceLogonEvents does not establish the absence of network activity or prove token theft.
DeviceProcessEvents
DeviceLogonEvents
Confirm the change with the application owner. An unapproved credential, successful use of the matching key, and corroborating abusive activity provide a stronger basis for a malicious verdict. Keep the case open or escalate when those questions remain unresolved.
The record below assumes corroborating checks beyond the two starter queries. It demonstrates a compact output format, not the complete evidence required for its conclusions.
incident New client secret on mail-reading app verdict malicious, confidence high technique T1098.001 Additional Cloud Credentials evidence AuditLogs: secret added by the admin account at 09:42 UTC SigninLogs: medium-risk sign-in from 203.0.113.45 at 09:02 UTC, first seen for this user AADServicePrincipalSignInLogs: Graph sign-in from 198.51.100.23 at 09:47 UTC, first seen in 30 days DeviceLogonEvents: no link from the admin workstation to either IP queries 4 run, each stored with its text, time range, and row count gaps none, all required tables reported within the last 15 minutes actions revoke user sessions: done (act within limits) remove new client secret: awaiting approval reset user password: awaiting approval review Graph activity by the app: recommended review analyst accepted the verdict and approved the secret removal
The no-gap claim requires validation of event categories, relevant assets, and the full search window. Recent table activity alone is insufficient. The device observation is supporting context, not proof of credential theft.
Session revocation is explicitly pre-authorized in this example, while credential removal requires approval. Revoking the user’s sessions does not invalidate an application secret. Contain the application credential separately, preserve its metadata, and check the application’s wider access.
Production monitoring needs to show whether investigations remain accurate and useful, not only whether the agent is available.
For every workflow, retain enough information to review:
Check claims against captured results. Re-running an ago() query later changes its time window, and source records can change or expire. Preserve the original evidence needed to evaluate the conclusion.
ago()
Compare closure and escalation outcomes by alert class, source coverage, and deployed version. Investigate changes before treating a higher closure rate as an improvement.
Alert content, emails, logs, filenames, and retrieved records are untrusted evidence. Instructions found in them must not determine authorization or execution policy.
The query below can identify some instruction-like text for review. It is a heuristic, not a prompt-injection detector or a control that makes an agent safe.
// Starting point: instruction-like text in fields attackers control. // Run in Defender advanced hunting; extend the phrase list for your environment. let phrases = dynamic(["ignore previous instructions", "ignore all prior", "mark as benign", "classify as false positive", "close this incident", "system prompt"]); union isfuzzy=true (EmailEvents | where Timestamp > ago(7d) | where Subject has_any (phrases) | project Timestamp, Field = "EmailEvents.Subject", Value = Subject, Entity = RecipientEmailAddress), (SigninLogs | where TimeGenerated > ago(7d) | where UserAgent has_any (phrases) | project Timestamp = TimeGenerated, Field = "SigninLogs.UserAgent", Value = UserAgent, Entity = UserPrincipalName), (DeviceProcessEvents | where Timestamp > ago(7d) | where ProcessCommandLine has_any (phrases) | project Timestamp, Field = "DeviceProcessEvents.ProcessCommandLine", Value = ProcessCommandLine, Entity = DeviceName) | sort by Timestamp desc
Legitimate security discussions can match, while many injection attempts will not. Check table availability and query warnings: union isfuzzy=true can return results from available sources while others remain unresolved.
union isfuzzy=true
Monitor source and context freshness, query failures, timeouts, budget exhaustion, and waiting cases. Failed searches must not be recorded as no matches.
Tool-specific limits also matter. Entity analyzer has documented hourly, daily, and concurrency limits; triage tools inherit relevant API quotas. Give unfinished work an owner and a clear next step.
Review a random sample of closures alongside a separate targeted sample of high-risk or uncertain cases. Record how the samples were selected and avoid treating a targeted sample as an estimate of the whole queue’s error rate.
Track time to a usable assessment, analyst effort, escalation delay, incorrect closures, missed escalations, and action failures. Include unfinished investigations in reporting rather than measuring only successful runs.
Assign an owner to pause affected automation when required evidence fails or quality drops below agreed criteria. Review pending cases and validate the corrective change before restoring the workflow.
Once the pilot is reliable, add the next alert class or evidence source while retaining the same review process. Reuse validated tools and skills, then adapt the required checks and escalation rules to the new workflow. Test again after changes to a model, source schema, or execution policy.
Expand into hunting, detection proposals, and reporting as the team gains experience. These workflows can use the same evidence and shared methods while keeping their own permissions and acceptance criteria. Detection engineers review proposed rules, hunters assess findings, and incident responders direct material containment.
Track whether the expansion reduces backlogs, improves investigation coverage, and gives analysts more time for difficult cases. Increase autonomy only where the results support it, and reduce it when quality or operational conditions change.
ThreatDefence runs AI agents on your Microsoft Sentinel and Defender incidents, alongside your existing Microsoft tools, with a 24x7 SOC behind them. Access uses a service principal with Log Analytics Reader and Microsoft Sentinel Responder, assigned by your Owner or User Access Administrator.
Agents investigate Microsoft and non-Microsoft sources in the same case, close known-benign alert classes under your policies, and escalate the rest with the investigation completed. You choose the autonomy level for each response action, from session revocation to host isolation. Telemetry is treated as untrusted evidence, so instructions planted in alerts or logs do not grant agents additional authority. Data and AI processing stay in your region.
In one example, an agent covered six sources in eight steps and reached a verdict in 38 seconds, for about two cents and about 90 seconds of analyst review. These figures describe that example, rather than a guaranteed investigation time or Security Copilot SCU rate.
A free Microsoft Sentinel cost and coverage review identifies suitable agent workflows, coverage gaps, and opportunities to reduce data costs, typically by 50 to 70% in most environments.
Macro in invoice.docm launched encoded PowerShell, which resolved a domain first seen today and opened SMB to a database server. Same pattern on no other host.
Explore Microsoft Sentinel MDR
CountryAustraliaUnited StatesNew ZealandUnited KingdomCanadaSingaporeOtherI'm an MSP, MSSP, or reseller
Δ
No. Microsoft’s Security Copilot agents use its capacity, but an approved external runtime can use Microsoft Sentinel APIs, query interfaces, and supported MCP tools. Individual tools may still consume SCUs or incur other charges. Check the complete workflow.
Eligible E5 and E7 tenants receive included capacity through Microsoft’s rollout. This does not automatically activate every agent or supply every workload license. Phishing triage, for example, requires Defender for Office 365 Plan 2. Confirm tenant provisioning and agent prerequisites.
Agents can draft rules where their tools support it. Review the logic, source dependencies, and test results before authorizing deployment. Production rule creation requires separately controlled write access.
No. Agents can investigate and prepare a response while playbooks execute established procedures. Keep permissions and approvals enforced in the execution path.
Grant the roles its tools require at the narrowest practical scope. A custom integration may need Log Analytics Reader for queries and Microsoft Sentinel Responder for incident updates. Defender, Graph, Copilot, and MCP permissions require separate assessment.
Yes, using supported query interfaces and data exploration tools with the required access. Confirm the available tables, historical window, query limits, and charges. Do not assume every advanced hunting query searches older lake records.
Support depends on the collection and access path. The triage collection is restricted to the home tenant without guest or delegated access. This differs from supported Security Copilot scenarios using Azure Lighthouse. Validate the proposed tools and identities directly.
There is no universal figure. Measure usage by workflow, including retries and complex investigations, through Security Copilot’s usage records. Budget separately for underlying queries and supporting services.
AI SOC Agents
Autonomous Alert Triage
AI SOC vs SOAR