Application card: Microsoft Sentinel SIEM

What is an application card?

Microsoft's application and platform cards are intended to help you understand how our AI technology works, the choices application owners can make that influence application performance and behavior, and the importance of considering the whole application, including the technology, the people, and the environment. Application cards are created for AI applications and platform cards are created for AI platform services. These resources can support the development or deployment of your own applications and can be shared with users or stakeholders impacted by them.

As part of its commitment to responsible AI, Microsoft adheres to six core principles: fairness, reliability and safety, privacy and security, inclusiveness, transparency, and accountability. These principles are embedded in the Responsible AI Standard, which guides teams in designing, building, and testing AI applications. Application and platform cards play a key role in operationalizing these principles by offering transparency around capabilities, intended uses, and limitations. For further insight, readers are encouraged to explore Microsoft's Responsible AI Transparency Report and Code of Conduct, which outline how enterprise customers and individuals can engage with AI responsibly.

Overview

Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) solution and unified security platform for agentic defense, where automation and AI assist analysts while humans remain responsible for decisions and actions. It delivers scalable, cost-efficient security in multicloud and multiplatform environments. By combining AI capabilities, automation, and threat intelligence, Microsoft Sentinel supports threat detection, investigation, response, and proactive hunting, empowering security analysts to anticipate and stop attacks faster and with greater precision. Microsoft Sentinel's architecture and intelligent analytics allow it to make sense of massive volumes of security data and orchestrate appropriate responses, while keeping customer analysts at the center of all critical decisions.

This application card provides transparency into Microsoft Sentinel SIEM's AI-driven capabilities, explaining how they work, their intended uses and limitations, and the measures Microsoft has implemented to ensure they align with our responsible AI principles.

For more information, see What is Microsoft Sentinel? and Microsoft Sentinel in the Microsoft Defender portal.

Key terms

The following table defines key terms relevant to Microsoft Sentinel's AI-enhanced features.

Term Description
Behavior A structured record of activity produced by the Microsoft Sentinel UEBA (User and Entity Behavior Analytics) behaviors layer. A behavior captures a series of related security events consolidated into a single narrative (for example, "User X accessed 25 resources in 10 minutes") with additional context like the involved entities and relevant MITRE ATT&CK tactic labels.
Playbook An automated workflow in Microsoft Sentinel that performs a sequence of actions (such as alert triage or incident response tasks). Traditional Sentinel playbooks are built using Azure Logic Apps, whereas playbooks generated by the AI-assisted playbook generator (preview) are provided as code-based (Python) scripts running in a managed environment within Microsoft Sentinel.
Security orchestration The coordination of multiple automated tasks and responses in security systems. In Microsoft Sentinel, orchestration refers to combining various actions (for example, sending an alert, quarantining a device, and notifying a team) into a coherent, automated playbook that can be triggered by security incidents or alerts.

Key features or capabilities

The key features and capabilities in the following table describe what Microsoft Sentinel SIEM is designed to do and how it performs in supported tasks.

Feature Description
UEBA behaviors layer An AI-powered analytics layer that automatically aggregates and contextualizes security events. As logs are ingested, this feature groups related events from multiple sources into cohesive behavior entries. Each behavior provides an enriched summary of the activity—identifying the key actor(s) and target(s), labeling the relevant MITRE ATT&CK tactics, and describing in plain language what occurred. For example, instead of an analyst manually correlating dozens of logon attempts and file access events, the behaviors layer might output a single behavior like "User A attempted 10 logins from different IPs and accessed sensitive files in a short timeframe (Technique: Valid Accounts; Tactic: Credential Access)." By presenting many raw events as a single intelligible pattern, this capability reduces noise and helps analysts quickly focus on potentially unusual or noteworthy activities.

For more information, see User and Entity Behavior Analytics (UEBA) behaviors layer.
SOAR playbook generator (preview) An AI-assisted playbook authoring feature that uses a large language model (LLM) to create automation workflows from natural-language descriptions. Security teams can interact with an embedded AI coding assistant in the Microsoft Defender portal, providing a plain English description of a security process they want to automate. The system then generates a Python-based Sentinel playbook implementing that workflow, complete with documentation and a visual flow diagram. For instance, an analyst might describe, "If an incident is high severity, gather host information and notify the on-call engineer," and the playbook generator produces a script to perform exactly those steps. The generated playbook is integrated into Sentinel's automation library, where it can be reviewed, tested on sample incidents, and then activated by the user to run on actual alerts or incidents. By enabling code-free automation development, this feature accelerates the creation of custom response playbooks and broadens the range of team members who can contribute to security automation.

For more information, see Generate playbooks using AI in Microsoft Sentinel.

Intended uses

Microsoft Sentinel SIEM can be used in multiple scenarios in a variety of industries. Some examples of use cases include:

  • UEBA behaviors layer: Designed to improve threat visibility and investigation efficiency. SOC analysts and threat hunters use the behaviors layer to quickly understand what's happening in their environment by examining behavior summaries instead of wading through individual log events. For example, during incident triage, an analyst can look at the behaviors associated with a particular user or entity to determine if recent actions show signs of compromise (like unusual login patterns or lateral movement). Detection engineers can also use behaviors as building blocks for analytics: because behaviors abstract raw data into consistent patterns, they can form higher-fidelity detection rules (for instance, alerting if an unusual number of certain behaviors occur in a short period). The intended use is to enhance situational awareness and threat hunting capabilities by complementing existing alerting logic with richer context.

  • SOAR playbook generator: Intended to simplify and expedite the development of automation playbooks. Security engineers and SOC teams use it to create or modify playbooks for incident response and routine tasks with less manual effort. A typical scenario is when an organization wants to automate a repetitive process—such as isolating a compromised endpoint and informing relevant personnel whenever a certain type of threat is detected. Instead of writing and debugging the code manually, the team can describe what they need in natural language and let the playbook generator produce the initial playbook. After reviewing and testing, they can deploy that playbook to handle real incidents, reducing the time required to implement new automations. This feature is especially helpful for rapidly prototyping workflows and responding to emerging threats by quickly codifying response steps. It isn't intended to directly execute un-reviewed code; rather, it's a speed enabler with human validation at each step.

In all cases, these AI features act as assistive tools. Human expertise and decision-making remain essential: analysts interpret the behaviors and decide how to respond, and engineers review and approve each automatically generated playbook before it's used in production.

Models and training data

Microsoft Sentinel SIEM leverages a variety of AI models to power the experience that users see. Some examples include Azure OpenAI Service models. To learn more about the data used to train the foundation models behind Microsoft Sentinel SIEM, refer to the linked model cards to find the relevant data cards.

  • UEBA behaviors layer: This layer operates with a set of predefined logic and heuristics rather than a continuously learning model. Microsoft's security experts analyzed diverse security logs (for example, Windows events, Microsoft Entra ID sign-in logs, AWS CloudTrail) and crafted rules that identify patterns of interest. These rules define how raw events are stitched together into a behavior and what contextual information to add. Rule creation and validation occur during development and testing; behavior rules are static in production and do not learn from or adapt to customer data. Because it's rule-driven, the behaviors layer doesn't train on individual customer data or adapt itself per tenant. Instead, it applies the same curated logic to all data it processes. The development process included testing on sample datasets to ensure the rules are robust and yield meaningful results. No customer-specific model training occurs—new events are simply matched against the existing patterns.

  • SOAR playbook generator: This feature uses a large language model (LLM) provided through Azure OpenAI Service—specifically, a variant of OpenAI's GPT model—to interpret natural language and produce code. This is a foundation model pretrained on broad internet text and code (with knowledge up to its training cutoff date) and not fine-tuned on Microsoft Sentinel or any customer data. When a user describes a playbook, Microsoft Sentinel's system assembles a structured prompt for the LLM that includes relevant instructions and context. The LLM then generates Python code and documentation to implement the described logic. No data from the user's prompt or the generated code is used to train the base model. Microsoft might collect usage telemetry and anonymized quality signals (for example, success/failure indicators), depending on customer data‑sharing settings. AI processing for these features occurs within Microsoft’s cloud environment, and customer data is handled pursuant to Microsoft’s data handling commitments.

Performance

Each AI feature is designed to perform reliably and to improve the efficiency of security operations:

  • UEBA behaviors layer: Behavior generation runs inline as events are ingested into Microsoft Sentinel. It's built to scale to high event volumes and produce results in near real-time. For supported log sources, behaviors are typically available within moments of data ingestion, allowing them to be immediately used in detection rules or investigations. By summarizing many events into one object, the behaviors layer can significantly reduce the number of logs or alerts an analyst needs to review. Internal testing and feedback indicate that the behaviors layer can shorten certain investigation tasks markedly—for example, correlating events from multiple systems that might take an analyst an hour manually can often be understood in minutes via a single behavior summary. Additionally, because it uses static, expert-defined rules, its output is consistent and predictable for the scenarios it covers, and it doesn't degrade in accuracy as data scale increases (provided the logs are within the supported patterns).

  • SOAR playbook generator: This feature dramatically accelerates the development phase of automation workflows. In practice, generating a new playbook through the AI usually takes only a minute or two from description to code output, compared to potentially hours of manual coding. The underlying LLM is optimized for quick inference, so the majority of requests result in a workable playbook on the first attempt. From a runtime perspective, once a generated playbook is deployed and triggered by an incident, it executes as a cloud-hosted Python function with performance comparable to built-in playbooks (generally sub-minute execution for typical sequences of actions, depending on external API calls). Thus, the key performance benefit is the reduced turnaround time for creating and deploying robust automations, which in turn can improve the SOC's overall response times.

Localization considerations: Currently, these AI features are optimized for English. The behaviors layer produces English-language descriptions. The playbook generator also expects instructions in English for optimal results. Non-English logs can still generate behavior objects (the structure and context tags would appear, but the textual summary might not capture details as clearly). Microsoft might extend language support in the future, but as of now using the features in English ensures the best performance.

Limitations

Understanding Microsoft Sentinel SIEM's limitations is crucial to determine if it's used within safe and effective boundaries. While we encourage customers to leverage Microsoft Sentinel SIEM in their innovative solutions or applications, it's important to note that Microsoft Sentinel SIEM wasn't designed for every possible scenario. We encourage users to refer to either the Microsoft Enterprise AI Services Code of Conduct (for organizations) or the Code of Conduct section in the Microsoft Services Agreement (for individuals) as well as the following considerations when choosing a use case:

  • UEBA behaviors layer: This capability is limited to specific data source types. Initially, it supports selected telemetry sources (for example, CommonSecurityLog for various firewall and appliance logs, AWS CloudTrail for AWS events, and similar schemas). If your environment generates logs outside these supported types, the behaviors layer doesn't process them; those events remain available as raw logs as usual. Additionally, the behaviors layer's outputs are only as good as the inputs: if the data is incomplete or lacks context, the resulting behavior might be less insightful. For instance, if user identifiers are inconsistent in different systems, the behaviors layer might not always link events that belong to the same user. It's also possible that in highly complex scenarios (with very long chains of events), a behavior summary simplifies details to keep the overview concise. Users should be aware that behaviors don't replace detailed logs—they highlight patterns, and if deeper specifics are needed, analysts might still need to refer to the raw events.

  • SOAR playbook generator: This feature, while powerful, has boundaries. It currently generates playbooks only in Python, focusing on incident-driven triggers. If you need a playbook integrated with a trigger outside of Microsoft Sentinel's incident automation (such as a manually initiated run or a scheduled job), those scenarios aren't directly covered yet by the generated playbooks—you would have to adapt them or use standard Azure Logic Apps for those cases. Furthermore, the quality of the initial code output depends on the clarity and detail of the user's description. If a natural-language input is ambiguous or extremely complex, the system might produce a playbook that requires further tweaking or might indicate it can't fulfill the request. Essentially, the playbook generator excels at standard or moderately complex workflows, but edge-case or highly specialized logic might need additional manual refinement. Another limitation: no direct output is returned when these playbooks run; they perform actions without generating a result payload for the UI, by design, to keep the focus on action automation rather than data retrieval.

Evaluations

Performance and safety evaluations assess whether AI applications are operating reliably and securely by examining factors like groundedness, relevance, and coherence while identifying the risks of generating harmful content. The following evaluations were conducted with safety components already in place, which are also described in Safety components and mitigations.

Performance and quality evaluations

Performance evaluations for AI applications are essential to improving their reliability in real-world applications. Metrics like groundedness, relevance, and coherence help assess the accuracy and consistency of AI-generated outputs, so that they are factually supported in grounded content scenarios, contextually appropriate, and logically structured. For Microsoft Sentinel SIEM, we conducted performance evaluations for the following metrics, which are available through Microsoft Foundry:

  • Groundedness
  • Coherence
  • Fluency
  • Similarity

Performance and quality evaluation methods

For the UEBA behaviors layer, Microsoft tested it extensively with real and synthetic log data to ensure that the generated behaviors accurately represent underlying events and add value to security analysis. Evaluations focused on confirming that behaviors meet criteria such as:

  • Accuracy: The behavior summaries correctly describe the events (who did what to whom, where, and when).
  • Relevance: The behaviors capture significant security-relevant patterns without overloading analysts with trivial combinations.
  • Consistency: Given similar input patterns, the output behaviors are consistently structured, enabling reliable use in detection rules.

Scenarios from known attack techniques were run through the system, and security analysts verified that the behaviors captured those scenarios correctly. For example, a series of privilege escalation attempts in logs should result in a behavior that clearly indicates multiple privilege escalation attempts by the same account. The team also ensured that false positives are minimized: the system is tuned to ignore very common, benign sequences to avoid inundating users with non-actionable information.

For the SOAR playbook generator, evaluation involved scenario testing with a broad set of automation tasks. Microsoft's security and engineering teams created sample requests for various use cases (like malware containment, phishing response, log enrichment tasks) and reviewed the generated playbooks for correctness, readability, and safety. They ensured that the code is coherent, follows best practices, and matches the requested logic. They also tested the playbooks end-to-end in lab environments to verify they perform as expected (for example, does a "quarantine device" playbook actually isolate a machine when triggered by a test incident? Does a "notify team" playbook send the right information to the right channel?). These quality checks helped calibrate the system to produce reliable automations under typical usage patterns.

Risk and safety evaluations

Evaluating potential risks associated with AI-generated content is essential for safeguarding against content risks with varying degrees of severity. This includes evaluating an AI application's predisposition towards generating harmful content or testing vulnerabilities to jailbreak attacks. For Microsoft Sentinel SIEM, we conducted risk and safety evaluations for the following metrics available through Microsoft Foundry:

  • Hate and unfairness
  • Violence
  • Self-harm
  • Indirect jailbreak
  • Direct jailbreak
  • Ungrounded attributes

Risk and safety evaluation methods

Microsoft examined potential risks and unintended behaviors of these AI features and implemented safeguards accordingly:

  • Behavior neutrality and privacy: Evaluators checked that behavior summaries remain factual and free of bias or unsupported judgment. Unlike an anomaly detection system that might label something as "suspicious," the behaviors layer simply describes activities; this avoids introducing bias or misclassification. The content of behaviors is confined to what's present in logs (governed by the user's own data collection policies), so the system doesn't introduce new privacy-sensitive data. These factors were part of the responsible AI assessment to ensure fairness and privacy principles are upheld.

  • Playbook generation safety: One risk scenario considered was if an AI-generated playbook inadvertently performed an unintended or harmful action. To mitigate this:

    • The model is guided through prompt engineering to focus on generating safe and relevant code. The team tested for undesirable outputs, and the system is more likely to respond with an error or request clarification than to produce something overtly dangerous if given a confusing or inappropriate request.
    • The generator doesn't have the ability to run a playbook immediately on its own. Human review is mandatory—the playbook is saved but remains inactive until an authorized user enables it.

Additionally, the team considered misuse—for example, could someone misuse the generator to create a playbook that intentionally exfiltrates data or causes disruption? The primary protections are access control and user oversight. Only users with specific roles (like Sentinel Contributor and Automation/Detection Tuning roles) can use the generator, and those individuals are typically trusted, trained personnel. And since the output code is fully visible to these users before activation, any malicious intent would likely be caught during review. This layered approach - gating the capability to appropriate roles and requiring activation - mitigates the risk of feature abuse by ensuring an audit trail exists and requiring authorized personnel involvement.

No evidence of disparate impact or demographic bias is present for these features, as they operate on technical data and user-driven inputs, not on attributes of individuals. Behavior summaries and playbooks treat all inputs equally without preferential or prejudicial differences.

Evaluation data for quality and safety

Our evaluation data is custom-built to assess AI application performance in key areas of safety and quality, simulating real-world scenarios and risks. We begin by identifying relevant evaluation aspects of concern based on multi-disciplinary research and expert input. These concerns are translated into targeted evaluation objectives and guide formulation of evaluation metrics. For safety, we create adversarial prompts to elicit undesirable or edge-case responses, which are then scored using AI-assisted annotators trained to assess alignment with Microsoft's safety standards. For quality, we craft rubric-based prompts relevant to scenarios including evaluating retrieval-augmented generation (RAG) applications and agents. Datasets are curated from diverse sources including synthetic and public datasets to simulate real-world user scenarios. Using the curated datasets, both evaluations undergo iterative refinement and human alignment to improve metric efficacy and reliability. This methodology forms the foundation of repeatable, rigorous assessments that reflect how customers use evaluations to build better and safer AI.

Custom evaluations

There were no per-customer customizations of the underlying models. However, Microsoft continuously monitors feature usage and feedback at a macro level, performing ongoing evaluations. For example, if multiple customers report that a certain behavior pattern is missing or mislabeled, Microsoft's engineers might refine the rules and deploy an updated logic set. Similarly, if the playbook generator is observed (via opt-in telemetry) to consistently struggle with a particular type of request, the team might adjust the LLM prompt or add new guidance to improve outputs. These improvements are rolled out to all users in service updates, ensuring that evaluation and learning are part of the lifecycle but without any custom model per individual tenant.

Safety components and mitigations

Microsoft has implemented several measures to ensure these AI features remain safe, reliable, and under user control:

  • Human oversight and control: Customer security analysts are the ultimate decision-makers in how these features are used. The UEBA behaviors layer provides rich context but doesn't autonomously act on it; it's up to analysts or detection rules (configured by analysts) to decide if a behavior indicates malicious activity requiring response. The playbook generator yields code that is always presented to the user for review and approval before any execution occurs. Generated playbooks are stored in an inactive state and only run if a user with appropriate privileges explicitly enables and triggers them. This human-in-the-loop design ensures that no automated actions are taken without direct customer oversight.

  • Transparency and explainability: Both features are built with transparency in mind. The behaviors layer's output includes clear descriptions and tags that explain each behavior and why certain events were grouped together. Analysts can click on a behavior to see the underlying events for verification. The playbook generator produces detailed documentation for each playbook, including a step-by-step explanation of the logic and a visual flowchart. This makes it easy for a security team to understand what an AI-generated playbook does, and adjust or augment it if needed. Transparency is crucial for trust—users should feel confident that they understand the AI's outputs before relying on them in their workflows.

  • Access and permissions: Access to AI features is controlled through existing security roles. By requiring roles like Microsoft Sentinel Contributor or Automation Contributor, Microsoft ensures that only qualified personnel can use the playbook generator. This reduces the risk of inexperienced users generating playbooks without proper oversight. Similarly, the behaviors layer is automatically available only to those who have access to relevant logs and analytics results, meaning it's used by those who already handle sensitive security data.

  • Data security and privacy: All processing for these features happens within the Microsoft Azure environment, under the same compliance standards as the rest of Microsoft Sentinel. The behaviors layer processes data entirely within the SIEM's analytics pipeline—it doesn't send log data outside the service. For the playbook generator, the user's prompt and context are handled by an Azure OpenAI instance tied to the customer's Security Copilot tenant (which enforces data handling policies consistent with enterprise requirements). No long-term retention of prompt data occurs beyond what's needed to generate the output (unless the customer opts in to allow Microsoft to use it for product improvement under strict controls). These measures ensure that using these AI features doesn't expose or store sensitive customer data inappropriately.

  • Testing and iteration support: Microsoft provides avenues within the tools themselves to help users adopt them safely. For example, the playbook generator interface allows users to run the new playbook on a sample alert (typically a sanitized incident) to see what actions it would take, verifying outcomes before deployment. The behaviors layer outputs can be compared against known sequences of events to confirm they align with expectations. Microsoft's documentation encourages such testing and outlines best practices for validating AI outputs (such as performing dry runs or starting in a lab environment). This approach helps organizations integrate the AI features gradually and with confidence.

Best practices for deploying and adopting Microsoft Sentinel's AI capabilities

Responsible AI is a shared commitment between Microsoft and its customers. While Microsoft builds AI applications with safety, fairness, and transparency at the core, customers play a critical role in deploying and using these technologies responsibly within their own contexts. To support this partnership, we offer the following best practices for deployers and end users to help customers implement responsible AI effectively.

Deployers and end-users should:

  • Exercise caution and evaluate outcomes when using Microsoft Sentinel SIEM for consequential decisions or in sensitive domains: Consequential decisions are those that might have a legal or significant impact on a person's access to education, employment, financial platforms, government benefits, healthcare, housing, insurance, legal platforms, or that could result in physical, psychological, or financial harm. Sensitive domains—such as financial platforms, healthcare, and housing—require particular care due to the potential for disproportionate impact on different groups of people. When using AI for decisions in these areas, make sure that impacted stakeholders can understand how decisions are made, appeal decisions, and update any relevant input data.

  • Evaluate legal and regulatory considerations: Customers need to evaluate potential specific legal and regulatory obligations when using any AI platforms and solutions, which might not be appropriate for use in every industry or scenario. Additionally, AI platforms or solutions aren't designed for and might not be used in ways prohibited in applicable terms of service and relevant codes of conduct.

End-users should:

  • Exercise human oversight when appropriate: Human oversight is an important safeguard when interacting with AI applications. While we continuously improve our AI applications, AI might still make mistakes. The outputs generated might be inaccurate, incomplete, biased, misaligned, or irrelevant to your intended goals. This could happen due to various reasons, such as ambiguity in the inputs or limitations of the underlying models. As such, users should review the responses generated by Microsoft Sentinel SIEM and verify that they match their expectations and requirements.

  • Be aware of the risk of overreliance: Overreliance on AI happens when users accept incorrect or incomplete AI outputs, mainly because mistakes in AI outputs might be hard to detect. In the context of Microsoft Sentinel SIEM, overreliance might lead analysts to treat a neutral behavior observation as a confirmed threat without further investigation, or to assume that the absence of a behavior means no suspicious activity occurred.

  • Exercise caution when designing agentic AI in sensitive domains: Users should exercise caution when designing and/or deploying agentic AI applications in sensitive domains where agent actions are irreversible or highly consequential. Additional precautions should also be taken when creating autonomous agentic AI as described further in either the Microsoft Enterprise AI Services Code of Conduct (for organizations) or the Code of Conduct section in the Microsoft Services Agreement (for individuals).

  • Ensure relevant data and prerequisites: For the behaviors layer, connect the supported data sources (such as network logs or cloud audit logs) so you get the most out of the feature. More complete and high-quality data in Sentinel leads to more comprehensive behaviors. For the playbook generator, verify you've met all prerequisites (such as enabling Microsoft Security Copilot in your tenant and having the appropriate user roles) before use.

  • Start with human oversight and small scope: Initially, treat AI outputs as suggestions or prototypes. For instance, use the playbook generator to create a new playbook and then walk through the code line by line with your team before trusting it on live incidents. You might deploy it in a monitoring-only mode (for example, logging actions but not taking irreversible steps) at first. Similarly, when you enable the behaviors layer, start by observing how it represents known benign vs. known malicious sequences in your logs to gauge its accuracy, and then gradually incorporate behaviors into detection rules or workflows.

  • Maintain a feedback loop: Encourage your analysts and engineers to track their experiences with the AI features—what works well, what needs adjustment—and share that feedback internally and with Microsoft if appropriate. This helps your own team refine their usage (for instance, developing prompt phrasings that yield the best playbook results, or identifying new detection opportunities using behaviors). It also contributes to Microsoft's ongoing improvement of these features via updates.

Deployers should:

  • Stay updated on feature changes: Responsible AI features like these can evolve quickly. Check Microsoft's official documentation and release notes periodically for updates about expanded support (for example, new data connectors that the behaviors layer can analyze, or new trigger types for playbooks) and plan to incorporate those enhancements. Microsoft might also publish updated guidance, examples, or templates that can help you apply these tools more effectively—taking advantage of those resources can improve your outcomes.

  • Integrate into your processes securely: Make sure usage of these AI features aligns with your internal protocols for change management and incident response. For instance, treat an AI-generated playbook the same way you'd treat a new script from a team member: put it through a peer review, test it in a lab or staging environment if possible, and get formal approval before letting it run automatically on incidents. Document when and where you've enabled behavior outputs in detection rules, so colleagues are aware that some detections rely on AI-derived data. This fosters transparency and trust in how AI is being used within your security operations program.

  • Test in controlled environments before broad adoption: Enable the behaviors layer and test with representative data before relying on it for production security operations. Validate that behavior outputs meet your organization's accuracy and performance standards, and that detection rules based on behaviors produce expected results.

Learn more about Microsoft Sentinel SIEM

For additional guidance or to learn more about the responsible use of Microsoft Sentinel SIEM, we recommend reviewing the following documentation:

Learn more about responsible AI

  • Last updated on