How to Use ChatGPT to Summarise and Triage Microsoft Sentinel Alerts

The short answer: Export the incident — its title, severity, entities and related alerts, not the raw logs — and ask ChatGPT to rank the open queue by what a human should look at first, with a plain-language summary and the next investigative step for each. That turns an unreadable queue into a ten-minute read. It must not close, isolate or clear anything on its own.

A SIEM does exactly what you bought it for, and that is the problem. Within a month of connecting your identity provider, endpoints, firewall and cloud subscriptions, Microsoft Sentinel is generating more incidents than one person can read, let alone investigate. The detection is working. The reading is what fails.

Most mid-market companies hit this wall in the same way. There is a SIEM, there is one IT manager or one security engineer who also has other work, and there is nobody at all between 18:00 and 09:00. The queue grows overnight, the morning is spent skimming it, and the honest position is that low and medium incidents are being closed on pattern recognition rather than investigation.

An AI summarisation layer helps with a specific, narrow part of that: making the queue legible and ordered before a person starts. It does not make anyone an analyst, and it does not cover 03:00. Being clear about which half it solves is what keeps this useful instead of dangerous.

Why a SIEM Makes Alert Fatigue Worse Before It Makes It Better

The first weeks after a SIEM goes live are the noisiest it will ever be, and that is expected rather than a fault.

Out-of-the-box rules do not know your environment. A scheduled backup job authenticating from a server at 02:00 every night, a developer using a VPN exit in another country, an admin running a legitimate bulk operation — each of these fires something. The rule is correct in general and wrong about you specifically.

Incidents arrive without the context that makes them judgeable. Sentinel groups related alerts into an incident and attaches entities — accounts, hosts, IP addresses, files — but whether a given account matters is a question about your organisation, and the SIEM has no view of that.

Volume defeats prioritisation. Severity is assigned by the rule that fired, not by consequence. Forty medium incidents look identical in a list, and the one that involves a finance account with privileged access looks exactly like the thirty-nine that do not.

Nobody is reading it at night. This is the real gap, and no amount of tooling on the reading side closes it — worth naming early, so the rest of this article is not mistaken for a solution to it.

The instinct at this point is to tune rules and suppress noise, which is correct and which you should do. But tuning is slow work that competes with everything else, and while it happens the queue still has to be read every morning.

Where an AI Summarisation Step Fits in the Triage Path

It fits in exactly one place: between the SIEM producing incidents and a person deciding which ones to open. Everything upstream stays as it is, and everything downstream stays human.

What Should You Send the Model — the Incident or the Raw Logs?

The incident, and not much more. Sentinel's incident record already carries what a summary needs: the title and description, the severity and status, the tactics and techniques the detection maps to, the timestamps, the alerts grouped into it, and the entities involved. That is a compact, structured object.

Raw log tables are the wrong input. They are enormous, so you pay for volume and lose the model's attention. They carry far more sensitive detail than the analysis needs. And the value is not in the logs — it is in explaining what a cluster of alerts appears to add up to.

Add one thing the incident record does not have: your environment's normal. A short block of context stating what your backup jobs do, where your staff legitimately connect from, which service accounts run unattended, and which people and systems are genuinely sensitive changes the output more than any prompt engineering will. Without it the model applies generic reasoning and flags your own scheduled tasks every night.

Pull incidents through Sentinel's API or a KQL query against the incident tables, and confirm current field names in Microsoft's documentation rather than trusting a snippet — this platform changes.

Should This Run Inside Sentinel's Automation or as an External Script?

Both are legitimate, and they suit different starting points.

Sentinel's automation rules and playbooks — built on Azure Logic Apps — can trigger on incident creation and call an external API, which is the native path and the one that keeps the workflow inside Azure where the permissions and audit trail already live. It is the better long-term home, and it is more work to stand up.

A scheduled read-only script that queries incidents from the last 24 hours, calls the model once with the whole batch, and posts a digest to email or a chat channel is the faster way to learn whether this is useful at all. It also has a property worth keeping deliberately: it runs on a read-only identity and writes nothing back to Sentinel.

Start with the script. Move it into a playbook when the prompt has stopped changing every few days and the output is something people actually read.

Microsoft also ships its own AI layer for security operations; if you are already deep in that licensing, evaluate it on its own terms first. The approach here is the one that costs an afternoon.

A Worked Example — From a Noisy Queue to a Ranked Morning Briefing

Take a company with about 400 staff, a Sentinel workspace fed by Entra ID, Defender, a firewall and two cloud subscriptions, and one security-minded IT manager.

Overnight the workspace produces 38 new incidents, mostly low and medium. A scheduled job at 07:30 queries the incidents created in the last 24 hours and pulls, for each, the title, severity, tactic, the alert names inside it, and the entities. That is a few hundred lines of structured text — a single request.

The prompt gives the model three things: the incident batch, the environment context block described above, and an explicit output format. The format is what makes the difference. Ask for one entry per incident containing a ranking, a two-sentence plain-language explanation of what the alerts appear to describe, the most likely benign explanation, the single next check a human should run, and a confidence level. Ask it to group anything it believes is the same underlying activity. Ask it to name explicitly which incidents it cannot assess from the data provided.

The briefing that lands at 08:00 typically collapses those 38 incidents into something like four clusters worth attention, a dozen it can explain as known activity with the reason stated, and a handful it flags as unassessable. The IT manager reads it in ten minutes and opens Sentinel already knowing where to start — the same order of triage as before, minus the hour of reading.

Two honest caveats. The "known activity" group still needs spot-checking, because a model confidently explaining away a real intrusion is the failure mode that matters. And the 38 incidents are still 38 incidents in Sentinel — the queue is readable, not shorter. Shortening it is what rule tuning does, and this does not replace that work. A similar shape of triage-assistance applies to service desks generally, as we covered when building an internal helpdesk triage bot.

AI-Assisted Triage vs Detection-Rule Tuning vs a 24/7 SOC

• Time to first value — AI-assisted triage wins easily. A read-only export, a prompt and an afternoon, versus weeks of tuning or a procurement cycle.
• Reducing the number of alerts — Detection-rule tuning wins outright. It is the only one of the three that makes the queue genuinely smaller instead of easier to read.
• Explaining what an incident means — AI-assisted triage wins. Turning a cluster of technical alerts into a sentence a busy IT manager can act on is precisely what a language model is good at.
• Coverage at 03:00 — A 24/7 SOC wins, and nothing else comes close. A briefing is only read when someone reads it.
• Deciding and acting on an incident — A SOC wins. Containment during an active intrusion is a judgement and an action, not a summary.
• Evidence for an audit or an insurer — A SOC or a documented tuning programme wins. A chat transcript is not evidence of monitoring.
• Ongoing cost — AI-assisted triage is cheapest by a wide margin, and it is cheap because it does the least.

These are layers, not alternatives. The realistic sequence for a mid-market company is: use AI summarisation to survive the current queue, invest the time it frees into rule tuning so the queue shrinks, and buy monitored coverage for the hours nobody is awake.

What This Must Never Do

Three limits, and they are not negotiable.

Never auto-close an incident. A model's "this is almost certainly the backup job" is a hypothesis with no access to your traffic, your tickets or last week's context. Closing on it produces a clean queue and a false sense of coverage, which is worse than a messy queue.

Never let it isolate a host, disable an account or block an address. Response actions belong behind a human decision. An automation that can quarantine machines on a model's reading of an alert is a new outage source and, if it can be triggered, an attack surface.

Never treat "likely benign" as a verdict. Treat it as a sentence explaining where to look first. The distinction sounds pedantic until the week it matters.

And the standing position underneath all three: the model can only see what you sent it. Anything absent from the export — a suppressed rule, a data source that stopped ingesting, a log type you never connected — is invisible to it, and it will not tell you that something is missing.

Getting This Right — Log Data Governance, API Keys, and When to Bring in IT

Three decisions worth making deliberately rather than by default.

What leaves your tenant. Security telemetry is among the more sensitive data you hold: usernames, hostnames, internal addressing, your detection coverage and, by implication, your gaps. Sending it to an external API is a real decision. Make it consciously — read the data-handling and training terms for the specific product tier you use rather than assuming, since business and enterprise tiers commonly differ from consumer ones and terms change. Consider pseudonymising account and host names before export, which usually costs little analytical value. Where none of that is acceptable, the same method works against a self-hosted model, and the pattern of keeping AI work on compliant infrastructure is the same one that applies to data-residency-constrained markets.

The credential. The export identity should be read-only against Sentinel and nothing else, and the model API key belongs to a company account with its own billing and usage limits — not to whichever engineer set it up. Keep both in a secret store, give them a rotation date, and make sure someone other than the person who created them knows they exist. A departed engineer's personal API key silently running a production job is a recurring and entirely avoidable finding.

Who owns the hours nobody is awake. This is the part the article cannot solve. Detection engineering, rule tuning, and monitored coverage are exactly what a SIEM and monitoring practice exists to supply, including the tuning work that makes the queue smaller rather than only more readable. Our AI+ support practice sets up this kind of automation on governed credentials and company accounts, and our managed IT support covers the access lifecycle around it. Brocent has run managed IT and security across Asia since our founding in Beijing in 2007, with headquarters in Singapore and a Hong Kong office since 2016.

Frequently Asked Questions

Does sending security log data to an AI tool create its own risk?

Yes, and it deserves a decision rather than a habit. An incident export describes your users, your systems and your detection coverage. Reduce what you send to incident-level fields, consider pseudonymising account and host names, and check the data-handling terms of the exact tier you use. If your regulator or client contracts do not permit it, use a self-hosted model — the workflow does not depend on which model answers.

Can AI close a false positive automatically?

No. It can propose which incidents look like known activity and say why, which is genuinely useful as a reading order. Closing is a decision with consequences for your audit trail and your actual security posture, and it stays with a person.

Will this reduce our Sentinel ingestion bill?

No — this sits after ingestion and changes nothing about what you collect. Ingestion cost is a question of which sources you connect, which tables sit in analytics tiers, and how long you retain them: worth reviewing, but a separate exercise.

What happens to incidents raised at 03:00?

They sit in the queue until someone reads the briefing. That is the honest answer, and it is why this is a readability improvement rather than coverage. If out-of-hours response actually matters to your risk profile — and for most companies holding client data it does — that needs monitored coverage by people, not a better summary.

Is this a replacement for tuning detection rules?

No, and treating it as one is the main way this goes wrong. Summarisation makes an over-noisy queue survivable; tuning makes it smaller. Using the first to avoid the second means you are permanently paying a model to explain alerts that should never have fired.

How do we know the summaries are actually accurate?

Sample them. For the first few weeks, open a fixed number of incidents the model explained away and check whether its reasoning held. Keep the briefings and compare them against what investigation found. If it is confidently wrong about your environment, the fix is almost always a better context block rather than a better prompt.

Does this work with SIEMs other than Sentinel?

Yes. Nothing here is Sentinel-specific beyond the export step — any SIEM exposing incidents and entities through an API feeds the same workflow.

Where to Start

Take one week of incidents you have already triaged, export them, and write your environment-context block in ten plain sentences. Ask for the ranked briefing and compare it against what you actually found. You will learn two things quickly: whether the ordering matches your judgement, and which parts of your environment the model does not know about — a useful gap list in itself. If the queue ends up readable but still unread at night, that is a coverage problem rather than a tooling one — get in touch.