I occasionally have a conversation with a customer about how quickly their security monitoring systems generate alerts. Sometimes they are evaluating Microsoft’s first-party alerting. Other times they are integrating Microsoft security services with a third-party ticket management system and trying to understand why it takes so long for something to arrive in the queue.
These conversations become more interesting as we talk about AI accelerating attacks. We want security teams to investigate and respond at machine speed. We want an AI agent that can pick up an incident immediately, understand what happened, and intervene.
But what if that incident describes activity that started 10, 15, or 20 minutes ago?
An AI agent could respond immediately when the incident arrives and still be responding long after the attacker accomplished their goal. Ten minutes is a lifetime for an automated attack.
To understand that problem, we need to look at the entire journey from the activity occurring to someone, or something, responding. Some of that delay comes from moving and processing data. Some of it is deliberately engineered into how we detect suspicious behavior and present it to humans.
And despite what we sometimes say about wanting immediate notifications, there are legitimate reasons we do not want every event to become an immediate alert.
Everything starts at the source
A device or application records activity. A process starts or stops. A user signs in. Someone uses or changes permissions. A file is accessed, a registry key is modified, software is installed, or an application communicates with an IP address.
What gets recorded depends on the code and configuration of that source. The developer decides which activities the application can write to its logs. The configuration determines which of those details it actually produces.
It is common to have different logging levels. Turn on verbose logging, and the application might tell you just about everything it knows. Turn it down, and you might get only significant errors. In practice, we often settle somewhere in the middle: enough information to be useful without being too loud.
There are practical reasons for that balance. Generating and collecting telemetry consumes compute, memory, bandwidth, and storage. Collecting more information also increases the cost of retaining and analyzing it. We want visibility, but we have historically needed to keep the volume manageable.
There is a human consideration, too. Extremely detailed logs can be difficult to interpret. The information might be there, but finding the useful part can feel like searching for a needle in a warehouse full of needles.
AI could change how we evaluate that information. A log that seems too verbose or cryptic for a human might still be useful to an automated analysis system. We may need to reconsider some of the telemetry we previously dismissed, filtered, or disabled.
That does not make collection free. It changes the calculation of what might be worth collecting and where we should analyze it.
Immediate intervention happens close to the activity
The source is also where we have the best opportunity to intervene quickly.
Endpoint and antivirus protection already follows this pattern. Microsoft Defender’s endpoint protections can inspect activity when a file is opened, a process executes, or a network connection is attempted. Local protection does not need to wait for a log to reach a centralized database before taking action.
If we need an immediate response, that is the kind of placement we should be thinking about. The protection is right there when the activity happens.
The same principle applies to AI. If an AI service is supposed to intervene immediately, it needs to operate as close to the activity as possible, whether that is on the device, within the application, or at a control point through which the action must pass.
And the response does not have to be agentic. A traditional, deterministic control can be faster and cheaper when we already know what should be blocked. AI adds value where interpretation and adaptability are useful, but we do not need an agent to deliberate over every known bad action.
The question is where the decision can happen soon enough to matter.
Then we move the data
When detection does not happen at the source, the information generally needs to travel to a central location, such as a security service, database, or security information and event management system, or SIEM.
There can already be delays in writing or buffering the logs. Collection introduces another clock. A service might stream events, transmit them in batches, or retrieve them periodically. The data may pass through collectors, proxies, or a transport service such as Azure Event Hubs.
Once it reaches the destination, it may still need parsing, normalization, enrichment, deduplication, and indexing before it becomes available for analysis.
All of that happens before our detection logic gets its opportunity to evaluate the information.
Microsoft’s guidance on handling ingestion delay in Sentinel explains why detection rules need to account for the time between an activity occurring and its data becoming available. The rule needs to look far enough back to include information that arrived late, while avoiding repeatedly alerting on the same activity.
That brings us to another part of the timeline: how often the detection runs and how much history it examines when it does.
Now we wait for the detection
Detection logic often runs on a schedule, and sometimes it needs to collect evidence over a long period before it can make a determination.
It might check once a minute, once every five minutes, or once every 24 hours for a pattern that matches its detection logic. When it performs that check, it looks back over a period of time. That might be an hour, a day, a week, or a month, looking for a pattern across many days or log entries.
How often a detection runs and how far back it looks are two different settings. A rule might run every five minutes while examining the previous week of activity. We may need to wait for its next execution, and we may also need enough evidence to accumulate before the pattern becomes recognizable.
For the kinds of behavioral detections we are discussing, a single log entry is rarely the whole story.
A single failed sign-in usually does not warrant an investigation. Someone probably mistyped their password. A connection attempt to a blocked network port is not particularly surprising either. Repeated attempts across many ports or systems start to tell a different story.
We are often detecting a pattern of behavior rather than a single occurrence.
There is also an operational choice here. We might decide that the first hint of smoke is too ambiguous to send to a human. We wait for stronger evidence that something is burning.
If we asked our security operations team to investigate every hint of smoke, they would spend their day chasing things that never became a fire.
One last consideration here is that, in some cases, an alert or an incident is a notification of an automated block, disablement, or containment activity that disrupted suspected malicious behavior. In these cases, the response has already occurred, and this is asking a human or automated process for confirmation and root cause analysis.
We deliberately shape what humans see
A significant part of traditional alert engineering is about protecting human attention.
We use thresholds, suppression, aggregation, and correlation to reduce low-value noise. We try to bring the most consequential and likely true-positive activity to the front of the queue. Lower-confidence activity may be held for more context, grouped with related activity, or never presented as a separate investigation.
Most of those mechanisms delay an alert. Others prevent one from being generated at all.
These are reasonable decisions when people have a finite amount of time. A million alerts in a day would be more than most teams could meaningfully investigate. Sending everything immediately would bury the important activity in a mountain of noise.
So when someone says, “I want to be notified immediately when something happens,” I usually want to unpack what they mean.
Do they want every event? Every suspicious signal? Or do they want a reasonably confident investigation that deserves their attention?
Those are very different requirements, and they produce different timelines.
A fingerprint is not the whole investigation
Once an alert is generated, there is still the question of what it means in the broader attack.
Think about investigating a break-in. You might find fingerprints, a damaged lock, and camera footage. Each is useful evidence, but each requires different processing and interpretation. You usually cannot explain the entire crime with a single fingerprint.
Security alerts work much the same way. One identifies suspicious process execution. Another identifies unusual authentication. A third identifies access to sensitive information. Together, they may describe an attack that would be difficult to understand by examining each alert independently.
Microsoft Defender correlates related alerts into incidents to assemble that larger story. An incident can appear with initial evidence and continue evolving as more information becomes available.
That correlation also changes how we think about volume. A thousand fingerprints associated with one investigation are a different workload from a thousand separate investigations. The evidence still matters, but the responder has one connected case to work.
This is why the distinction between alerts and incidents is so important, especially when another ticketing system enters the picture.
The queue adds another human delay
Once an incident reaches the queue, someone still needs to take ownership.
It could be the middle of the night, a weekend, or a holiday. The analyst might be working on something more urgent, sitting in a meeting, or simply away from their desk. Even with response SLAs, there can be a meaningful gap between an incident appearing and a person actually examining it.
AI can serve an important role here. An agent could begin evaluating the incident as soon as it arrives, gather context, and take an authorized response action. Deterministic logic and traditional automation workflows can also play a role at this stage, handling known scenarios without waiting for a person or requiring an AI agent to make the decision.
But by then, the incident may already describe activity from 10, 15, or 20 minutes earlier. The attacker could have accomplished their objective and moved on before the AI or automation ever had an opportunity to intervene.
Automating the queue addresses a real problem. We also need to examine everything that happened before the queue.
A third-party system can extend the journey
This becomes more complicated when an external ticket management system or SIEM is involved.
There are two different scenarios. We might forward an existing Microsoft incident and its associated alerts into another system for investigation management. Or we might export raw telemetry to another analytics platform, where that platform performs its own detections.
The second scenario adds more processing. We need to export the data, transport it, ingest it into the destination, and potentially parse, normalize, and index it again. Then we wait for that platform’s detection logic to evaluate it.
The main point here is that there are so many inherent delays in the system to begin with. If you add another ticketing system on top of your primary ticketing system, like Defender, you’re adding considerable delays to the response process.
Preserve the investigation Microsoft already built
One common mistake is creating a separate external ticket for every alert without preserving the first-party incident correlation.
We have already done the work of connecting related evidence. If the integration pulls those alerts apart and presents them as unrelated tickets, we lose much of that value and increase the workload for the responder.
For investigation management, my recommendation is to use the incident as the primary record and retain the associated alerts as evidence.
The integration also needs to follow changes. An incident evolves as new evidence arrives, classifications change, and responders add information. Copying it once and never checking again leaves the external system working from an increasingly incomplete version of the investigation.
Another question is whether we need to recreate the detection in the external system at all.
Independent analytics can have a valid purpose. But copying the same telemetry elsewhere to reproduce an existing detection adds another path, another cost, and more opportunities for delay.
The closer we can place detection to the relevant activity and data, the more opportunities we have to shorten that journey.
Revisit why the third-party system is there
Many organizations use a third-party ticket management system because that is what they have always done. They may have been unhappy with the incident response capabilities Microsoft originally provided. The third-party product brought a capability they needed, or it offered a workflow their team already knew.
Those were reasonable reasons to make that investment. But the capabilities available today may be very different from what existed when that decision was made.
There are several legitimate reasons for using a third-party ticketing system. A managed service provider supporting dozens of customers across AWS, Google Cloud, and Microsoft may benefit considerably from a centralized incident response tool. An organization managing security across multiple clouds and dissimilar tenants may have the same need. Bringing those investigations into one operational system can be valuable.
If that is not your situation, it is worth considering the delays, complexity, and confusion the additional system introduces. Could your team manage those investigations directly in the Microsoft Defender portal? Doing so brings operations closer to the detections and prepares the team to take advantage of the continued AI evolution within that portal.
I do not think this recommendation is necessarily Microsoft-specific. Your organization might have most of its investment in AWS or Google Cloud. My preference is to use the security platform closest to the bulk of your technology investment and the detections it produces, provided its incident management capabilities meet your needs.
That determination deserves periodic review. A third-party solution may still be the best fit, but we should revisit the decision as the platforms evolve. Working closer to where detections occur can simplify operations, lower expenses, reduce the number of tools people need to learn, and help speed response.
AI gives us a reason to rethink the design
As agentic systems take on more investigation work, I think we have an opportunity to reconsider some of the assumptions behind this process.
We may be able to evaluate more low-confidence signals without immediately involving a person. We may find value in more detailed telemetry. We may move lightweight analysis closer to the source and reserve centralized systems for broader correlation and investigation.
We might shift towards more optimal data collection methods that abandon human-readable forms of data, relying on code or an AI service to read and explain that low-latency data pattern. Much of the size and cost of the data that we use today is because we have to keep it or convert it into a human-readable format.
Human alert fatigue may become less of a constraint, but the volume still has a cost. More signals can mean more compute, more tokens, repeated investigations, and unnecessary response actions. We will still need filtering and correlation. We may simply optimize them for different reasons.
AI could also help make those optimization decisions. Instead of relying entirely on a person to tune ingestion channels or choose between high-fidelity and low-fidelity data sources, an AI solution could recommend changes or, within its authorized scope, make those adjustments. It could help determine which information contributes to useful detections and where we are spending resources without gaining meaningful visibility.
The questions become: Which delays are unavoidable and inherently part of the system, and do we understand what those delays are? Which have we accepted or imposed on ourselves because of the human factor? Which could we eliminate to speed response, either through better design or because AI can process this activity differently?
I think the long-term opportunity is a rethinking of how we collect data, where we evaluate it, and when we permit a response. Some decisions need the context of a centralized investigation. Others need to happen at the source, while the activity is still occurring.
An AI agent can respond immediately to the incident it receives. We also need to ask how much time passed before it ever got there.