The Strategic Problem Is Not Query Generation
Security teams have spent years improving the speed of search, correlation, and alerting. Agent assistance can now reduce another source of friction by helping analysts formulate queries, summarize evidence, and draft detection logic. The strategic risk is to treat that acceleration as the whole operating model. Faster query creation does not resolve weak telemetry, ambiguous behavior, noisy rules, unclear ownership, or a production workflow that cannot learn from investigations.
Microsoft’s current custom-detections overview places detection logic inside a broader operational capability that includes rules, schedules, alerts, and response context. [1] The specific implementation is Microsoft’s, but the operating lesson applies more broadly: detection engineering is not finished when a query runs. The organization has to decide what the query represents, how it will be tested, when it becomes production logic, and how its ongoing behavior will be governed.
Five Jobs Determine Whether Agent-Assisted Detection Scales
1. Frame the behavior. Describe the adversary or suspicious behavior in a way that is independent of one incident, one IOC, or one query syntax. State which evidence should exist and what benign activity could look similar.
2. Interrogate the data. Confirm that the required telemetry, fields, time range, entity context, and ingestion behavior can support the hypothesis. An agent cannot infer a missing event with the same confidence as a collected one.
3. Engineer the analytic. Translate the validated behavior into maintainable logic with an explicit log source, conditions, thresholds where needed, owner, metadata, and known limitations.
4. Validate the operating effect. Test the logic on historical or representative data, inspect both true and unexpected matches, estimate analyst workload, and verify that the detection creates useful context rather than only volume.
5. Learn from outcomes. Use investigation results, tuning changes, missed cases, telemetry changes, and incident lessons to revise or retire the logic instead of treating deployment as completion.
Performance Engineering Is Part of Detection Quality
Google Cloud documents detection-performance considerations such as windowing, latency, rule design, and testing. [2] These details are platform-specific, but they illustrate why a detection can be logically correct and still perform poorly in operation. A rule that takes too long, scans too broadly, or produces excessive volume can reduce analyst confidence and delay useful investigation.
Detection engineering should therefore include a performance question alongside a security question. What is the minimum data required? Which time window is justified? Can the logic be constrained without losing the behavior? What operational volume appears during testing? How will the team recognize when a data or rule change creates a performance problem? Agent-generated logic should be held to the same standard.
Behavior Must Be Traceable from Strategy to Analytic Logic
MITRE ATT&CK describes Detection Analytics as platform-specific detection logic that implements broader Detection Strategies. [3] That separation is useful because it prevents a team from confusing a durable detection idea with one product-specific query. A strategy might describe the suspicious behavior and evidence relationships; the analytic implements that idea for a particular telemetry source, schema, and platform.
This distinction also improves agent-assisted workflows. An agent can draft one analytic, but the team should preserve the behavior-level intent so the detection can be implemented elsewhere, compared across platforms, and reviewed when the underlying data changes. The strategic asset is the detection idea plus evidence model, not only the generated syntax.
Investigation Feedback Is the Missing Engineering Loop
Google Cloud documents investigating detections by searching related detection context and entities. [4] The specific investigation interface is product-specific, but it reinforces a broader need: rule behavior must be connected to what analysts actually learn after an alert fires. If analysts repeatedly close the same benign pattern, that is engineering input. If an incident required a manual pivot that no detection captured, that is also engineering input.
CISA’s guidance on living-off-the-land activity emphasizes baselining, retaining useful logs, and deeper threat hunting because legitimate administrative tools can overlap with adversary behavior. [5] That is exactly the type of problem that resists simplistic automation. Detection quality improves when teams can compare behavior with environment-specific context instead of relying on a generic indicator alone.
CyberTech Intelligence Hunt-to-Detection Operating Matrix
|
Operating Job |
Executive Decision |
Operational Expression |
Evidence |
|---|---|---|---|
|
Frame |
What durable behavior or threat hypothesis are we trying to observe? |
Define behavior, scope, expected evidence, benign alternatives, affected entities, and decision purpose. |
Hypothesis, behavior description, evidence map, owner, references, assumptions. |
|
Hunt |
What does current telemetry show, and where are the evidence gaps? |
Run analyst-led or agent-assisted queries, pivot across entities and time, preserve uncertainty, and record data limitations. |
Queries, prompts or task context, analyst edits, sample events, time window, telemetry gaps. |
|
Engineer |
Can the validated behavior become maintainable detection logic? |
Translate the behavior into a rule with explicit log source, conditions, metadata, owner, version, and known false-positive patterns. |
Rule logic, log source, metadata, version, severity rationale, owner, known limitations. |
|
Validate |
Does the rule behave correctly and usefully on representative data? |
Test expected and unexpected matches, performance, operational volume, context, and response workflow before promotion. |
Test result, sample matches, tuning record, performance notes, approval decision. |
|
Operate |
What does production behavior teach us? |
Review alert quality, investigation outcomes, missed signals, execution health, telemetry changes, and tune, retire, or replace the rule as evidence changes. |
Alert and investigation outcomes, tuning history, rule-health evidence, next review, retirement/replacement decision. |
CyberTech Intelligence Perspective
Agent assistance changes the economics of query and rule creation, but it does not remove the need for engineering discipline. The most scalable operating model is one in which behavior definitions, telemetry, hunts, rules, tests, production outcomes, and analyst feedback share the same evidence chain. That gives automation a bounded role: accelerate work that remains explainable, testable, reviewable, and reversible.
Strategic Recommendations
• Manage detection ideas separately from platform-specific syntax so durable behavior can be re-implemented as tools and data sources change.
• Require a minimum validation record for every production rule, whether the logic was written by a human, generated by an agent, or adapted from external content.
• Treat rule performance, alert volume, analyst workload, and investigation usefulness as engineering evidence, not only operational aftereffects.
• Use investigation outcomes as a formal input to tuning and new hunting hypotheses; closed alerts should teach the detection program.
• Maintain enough version history to compare the original hunt, the promoted detection, subsequent tuning, and the reason for retirement or replacement.
Use the Hunt-to-Detection Operating Matrix
Choose one production detection that originated from a hunt or analyst query. Reconstruct the behavior definition, original evidence, test record, production approval, current alert behavior, and recent investigation outcomes. If the team cannot explain one of those transitions, use the matrix to assign the missing owner and evidence before expanding agent-assisted authoring.
About CyberTech Intelligence
CyberTech Intelligence provides research-led cybersecurity intelligence, executive content, and market engagement programs. This publication is vendor-neutral and intended for education, decision support, and claim-safe GTM planning.
Evidence and Citation Note
External sources are used only within their stated scope. Standards and public guidance are treated as evidence for the controls or practices they describe; vendor documentation is treated as evidence of the named platform’s capabilities and workflow. CyberTech Intelligence does not infer that a named organization has a detection gap, active compromise, weak telemetry, an autonomous-hunting program, a buying project, budget, or security outcome without direct evidence.
References
- Microsoft Learn, “Custom detections overview.” Last updated July 6, 2026. Relevance: Microsoft describes custom detections and current detection-as-code capabilities within Microsoft Defender. https://learn.microsoft.com/en-us/defender-xdr/custom-detections-overview (Accessed October 6, 2026.)
- Google Cloud, “Optimize detection and reporting performance.” Current documentation. Relevance: Google describes detection latency, rule performance considerations, testing, and the effect of windows and query design. https://docs.cloud.google.com/chronicle/docs/detection/optimize-detection-and-reporting-performance (Accessed October 6, 2026.)
- MITRE ATT&CK, “Detection Analytics.” Current ATT&CK content. Relevance: MITRE defines platform-specific detection logic that implements detection strategies. https://attack.mitre.org/analytics/ (Accessed October 6, 2026.)
- Google Cloud, “Investigate detections in Search.” Current documentation. Relevance: Google documents investigating detections by querying and filtering detection context and related entities. https://docs.cloud.google.com/chronicle/docs/investigation/investigate-detections-in-search (Accessed October 6, 2026.)
- CISA, “Identifying and Mitigating Living Off the Land Techniques.” March 2025. Relevance: CISA and partners emphasize baselining, sufficient log retention, deeper threat hunting, and behavior-focused detection for living-off-the-land activity. https://www.cisa.gov/sites/default/files/2025-03/Joint-Guidance-Identifying-and-Mitigating-LOTL508.pdf (Accessed October 6, 2026.)
