Detection Engineering for Modern Cybersecurity in 2026: A Multi-Layer, Behavior-Centric Framework for High-Fidelity Threat Detection Across Endpoint, Identity, Cloud, and AI Workloads

1. Introduction

Detection is the central battlefield of cybersecurity in 2026 because most real-world compromises are not stopped at the perimeter and many do not resemble classic malware infections at all. Adversaries increasingly rely on identity theft, cloud control-plane abuse, living-off-the-land binaries, token replay, OAuth consent abuse, remote management tooling, and legitimate administrative interfaces to move through environments with minimal noise. As a result, the practical question for defenders is no longer whether an attack can be prevented completely, but whether the activity can be observed early enough to constrain dwell time, preserve evidence, and enable containment before material impact occurs. This is especially true in enterprise environments where zero trust has matured, yet trust decisions still depend on telemetry quality, detection engineering discipline, and timely human response.

Detection is also harder in 2026 because the telemetry surface has expanded dramatically. Traditional endpoint alerts remain necessary, but they are insufficient when the primary intrusion path is a SaaS identity provider, a misconfigured cloud role, a Kubernetes admission path, or a malicious action executed by an AI agent with delegated access. Network-based detection is similarly challenged by pervasive encryption, QUIC adoption, and east-west traffic patterns that obscure payload inspection. Meanwhile, defenders are asked to detect not only classic intrusion tradecraft but also prompt injection, model exfiltration, data poisoning attempts, tool abuse through LLM orchestration layers, and abuse of AI-generated social engineering content. These shifts require a new detection architecture that treats endpoint, identity, cloud, and AI telemetry as interdependent rather than separate domains.

The most common failure mode in detection programs is not the absence of data, but the absence of structure. Organizations accumulate logs, alerts, and SIEM queries, yet fail to define what “good detection” means in terms of precision, recall, lead time, and analyst cost. A large number of rules may create an illusion of coverage while generating intolerable noise. Conversely, a small number of highly selective rules may miss low-and-slow intrusions and identity abuse that unfold across several layers. Effective detection engineering therefore requires formal modeling, quality control, continuous validation, and explicit tradeoffs. It also requires a disciplined understanding of adversary behavior, because most high-value detections are behavior-based and only secondarily artifact-based.

This paper argues that detection should be designed as a multi-layer optimization problem rather than a stack of independent alerts. The core contribution is a behavior-centric framework that combines four detection modes: deterministic rules, statistical anomaly baselines, graph-based correlation, and contextual prioritization. The approach is anchored in a telemetry model that spans endpoint, identity, cloud, and AI workloads. It is operationalized through detection-as-code, mapped to ATT&CK techniques, and continuously tested using adversary emulation and replayed datasets. The result is a practical architecture that supports both mature enterprise SOCs and smaller teams that need to extract maximal value from limited telemetry budgets.

The paper is structured as follows. The background section reviews the evolution of detection engineering, including Sigma, YARA, Zeek, Suricata, Sysmon, eBPF observability, UEBA, and cloud-native logging practices. The threat model and formalization section defines the adversarial capabilities, telemetry constraints, and optimization objective. The methodology section presents the proposed multi-layer detection pipeline and scoring logic. The implementation section details deployment patterns and concrete tool usage. The experimental evaluation section provides comparative measurements and tables. A case study demonstrates the framework against an identity-driven cloud intrusion. The discussion addresses limitations, operational realities, and emerging challenges in AI-era detection. The conclusion summarizes lessons and future work.

2. Background and Related Work

Detection in cybersecurity has evolved from simple indicator matching to a mature engineering discipline that fuses signature logic, behavioral analytics, cloud audit analysis, and human workflow design. Early-generation intrusion detection systems focused primarily on packet inspection and static signatures, as exemplified by Snort and early Suricata deployments. Those systems remain useful for commodity malware, exploit kits, and known command-and-control infrastructure, but their utility declines sharply against encrypted sessions, custom payloads, and attacker infrastructure that changes faster than rule distribution. The shift toward endpoint visibility, especially through Sysmon and EDR products, gave defenders access to richer process, registry, file, and script telemetry, enabling detections that capture the sequence of attacker actions rather than only their artifacts.

One important development was the adoption of standardized detection representations. Sigma provided a portable syntax for SIEM-style detection rules, allowing teams to translate a single analytic into multiple backend formats. YARA addressed file and memory artifact detection, becoming a staple for malware triage and hunt operations. Zeek improved network visibility by transforming traffic into structured event logs suitable for behavioral correlation, while Suricata added high-performance IDS and protocol-aware alerting. Together, these tools made detection more modular and portable. However, portability alone did not solve the core problem of detection quality. A rule that is syntactically valid can still be operationally weak if it lacks context, generates excessive noise, or fails under minor attacker variation.

The literature from the last decade increasingly emphasized behavioral analytics and adversary emulation. ATT&CK became the de facto taxonomy for adversary behavior, enabling defenders to map detections to techniques rather than to isolated IOCs. This shift was important because techniques tend to be more stable than indicators. For example, PowerShell-based download-and-execute, credential dumping, and token abuse recur across campaigns even as hashes, domains, and filenames change. Public frameworks such as CALDERA, Prelude Operator, and Atomic Red Team further advanced the discipline by allowing organizations to test detections against simulated behaviors. This helped move detection from anecdotal assurance to empirical validation.

The rise of cloud computing altered the detection problem again. Cloud control planes produce high-value audit events that reveal privilege escalations, role assumptions, API calls, object access, and network policy changes. In AWS, CloudTrail and GuardDuty became central sources; in Microsoft environments, Entra ID and Microsoft Defender telemetry gained importance; in GCP, audit logs and SCC findings provided corresponding visibility. Yet cloud detection is difficult because attackers often blend malicious actions with normal administration. Abusing an IAM role or modifying a security group can look like legitimate operations unless the detection model considers timing, sequence, entity relationships, and historical baselines. Cloud-native detection therefore depends heavily on correlation and context.

By 2026, container and Kubernetes telemetry has also become essential. Attackers who obtain access to a container or cluster often target service account tokens, secrets mounted into pods, misconfigured admission controllers, exposed dashboards, or cloud credentials present in workload metadata. eBPF-based sensors have increasingly supplemented traditional host logs by observing syscall patterns, network connections, file writes, and credential access behaviors with lower overhead than older agents. Although eBPF is not a silver bullet, it materially improves visibility for ephemeral workloads and supports container-aware detections that were difficult to implement previously.

The emergence of generative AI created a new detection frontier. Organizations now run copilots, agentic workflows, and retrieval-augmented generation pipelines that can access internal data, execute tools, and trigger downstream actions. This introduces abuse paths that are neither classic malware nor traditional phishing. Prompt injection can manipulate an AI assistant into revealing sensitive context or executing unintended operations. Data exfiltration can occur through model outputs, tool calls, or log side channels. As a result, detection must now cover not only human and machine identities but also agent identities and AI workflow traces. This is a significant expansion of the detection surface and one that many mature SOCs were not originally designed to support.

Academic and industry work has increasingly converged on the idea that detections must be tested, versioned, and measured like software. Detection-as-code pipelines, continuous integration for rules, replay testing with historical logs, and adversary simulation are now standard components in well-run organizations. Metrics such as true positive rate, precision, mean time to detect, and alert burden are more useful than raw alert counts. The remaining gap is a unifying framework that spans all major telemetry layers and explicitly models the cost of false positives, false negatives, and incomplete context. This paper addresses that gap by proposing a behavior-centric model that treats detection as an optimization problem over layered evidence sources.

3. Threat Model and Problem Formalization

We consider an adaptive adversary capable of compromising one or more assets in an enterprise environment that includes endpoints, identity infrastructure, cloud services, containers, and AI-enabled applications. The adversary may use phishing, credential theft, token theft, OAuth abuse, exploit chaining, living-off-the-land execution, and cloud misconfiguration abuse. We assume the adversary can modify tactics in response to limited detection feedback, can operate with variable dwell time, and can deliberately trade speed for stealth. We do not assume persistent visibility into payload contents, because transport encryption and application-layer encryption are common. Instead, detection must rely on metadata, event sequence, and contextual relationships.

The defender’s objective is to detect malicious behavior with high confidence, low delay, and acceptable analyst workload. Let $D$ denote a detector, $E$ the evidence stream, and $A$ the adversary action set. The detector outputs an alert function $f(E) \rightarrow {0,1}$. The ideal detector maximizes expected utility: $$ U(D) = \alpha \cdot P(\text{TP}) - \beta \cdot P(\text{FP}) - \gamma \cdot C_{\text{triage}} - \delta \cdot T_{\text{detect}} $$ where $P(\text{TP})$ is true positive probability, $P(\text{FP})$ is false positive probability, $C_{\text{triage}}$ is the analyst cost per alert, and $T_{\text{detect}}$ is detection latency. The weights $\alpha,\beta,\gamma,\delta$ are organizational parameters that reflect business risk and SOC capacity. This formalization is intentionally simple, but it captures the fact that detection quality is multi-objective rather than binary.

Telemetry is modeled as a set of event streams $E = {E_e, E_i, E_c, E_n, E_a}$ corresponding to endpoint, identity, cloud, network, and AI/application layers. Each event has attributes such as time, principal, device, action, target, outcome, and confidence. Detection rules operate on local windows, while correlation logic operates across sequences and graph structures. The practical problem is that no single layer is sufficient: endpoint telemetry may show powershell.exe, identity telemetry may show impossible travel or token refresh anomalies, cloud telemetry may show anomalous role assumption, and AI telemetry may show unauthorized tool invocation. The detector must fuse these partial views into a composite confidence score.

We assume the adversary can attempt to evade any single detector by changing filenames, obfuscating scripts, throttling activity, or shifting to another layer. Therefore, robust detection must be resilient to superficial variation and anchored in behaviors that are expensive for the adversary to suppress. Examples include unusual parent-child process chains, uncommon sequences of privilege use, abnormal API call order, rare combinations of identity actions, and graph anomalies in asset-to-principal interactions. We also assume that the defender cannot instrument every asset equally. Some endpoints are unmanaged, some SaaS logs are incomplete, and some AI systems only expose application-level traces. Hence the methodology must support partial observability and degrade gracefully.

The detection problem can be viewed as classification under weak supervision. For a given observation window $w$, the system estimates a maliciousness score $s_w \in [0,1]$. Alerts are triggered when $s_w \ge \tau$, but the threshold $\tau$ must be adaptive because base rates differ across environments and data sources. In practice, the optimal $\tau$ depends on the prevalence of attacks, the quality of telemetry, and the analyst queue. This leads to a cost-sensitive decision rule: $$ \text{alert if } \mathbb{E}[L \mid E_w] > \lambda $$ where $L$ is loss and $\lambda$ is the acceptable operating threshold. This framing is useful because it supports differentiated thresholds for high-value assets, privileged identities, and sensitive AI workflows. It also explains why a one-size-fits-all SIEM policy often fails operationally.

4. Proposed Methodology

The proposed methodology is a layered detection architecture that combines deterministic signatures, behavioral analytics, graph correlation, and contextual enrichment. The design goal is not to replace existing controls but to unify them into a coherent pipeline that prioritizes evidence quality. The architecture has five stages: ingestion, normalization, atomic detection, correlation, and scoring. Each stage can function independently, but the system performs best when all five are deployed as a continuous loop with validation feedback.

The first stage ingests telemetry from endpoints, identity providers, cloud control planes, network sensors, and AI application logs. Endpoint sources include Sysmon, Windows Event Log, auditd, osquery, and eBPF sensor outputs. Identity sources include Entra ID, Okta, Google Workspace, and PAM logs. Cloud sources include AWS CloudTrail, GCP Audit Logs, Azure Activity Logs, Kubernetes audit logs, and infrastructure-as-code pipeline events. Network sources include Zeek conn, dns, ssl, http, and Suricata alerts. AI sources include prompt logs, tool invocation traces, retrieval events, and output moderation signals. The key requirement is that all events be normalized into a common schema so that downstream correlation does not depend on backend-specific fields.

The second stage applies atomic detectors. These are precise rules that match high-confidence signals such as suspicious command lines, known malicious domains, rare parent-child process chains, or explicit ATT&CK technique indicators. Atomic detectors are implemented as Sigma rules, YARA rules, Suricata signatures, or custom queries. The objective here is precision. A single well-crafted atomic detector may not stop an advanced intrusion, but it provides a strong evidence point that can seed correlation. These detectors are most useful when they target behaviors that are both operationally relevant and resistant to trivial mutation.

The third stage performs contextual correlation. This is the heart of the methodology. Multiple weak signals that are individually ambiguous can become decisive when linked by principal, host, time, and sequence. For example, a high-risk identity event followed by a cloud role assumption, followed by a new access key creation, followed by unusual S3 enumeration, is much more meaningful than any single step. Graph correlation can be implemented with asset-identity-edge models, where nodes represent users, devices, IPs, service accounts, containers, or AI agents, and edges represent observed interactions. Anomalies are then scored based on unusual paths, rare transitions, and changes in centrality. This is especially effective in cloud and identity environments where attacker movement is often better described as a sequence of API actions than as a binary intrusion event.

The fourth stage enriches each candidate alert with external and internal context. Internal context includes asset criticality, user privilege, geolocation, device posture, business process timing, and historical baselines. External context includes threat intelligence, domain age, certificate reputation, malware family associations, and campaign linkage. Context does not replace detection logic; it changes the weight of evidence. A credential misuse event on a privileged administrator account with a recent impossible-travel anomaly is more important than the same event on a low-risk test account. This enrichment stage is essential for prioritization and triage reduction.

The fifth stage computes a confidence score and route-to-response decision. We recommend a composite score of the form: $$ S = w_1 r + w_2 b + w_3 g + w_4 c $$ where $r$ is rule confidence, $b$ is behavioral anomaly score, $g$ is graph-based deviation, and $c$ is contextual criticality. The weights are tuned per environment and per telemetry domain. This approach avoids overreliance on any one detector class. It also supports explainability because each alert can show which evidence channels contributed to the final decision.

Detection Layer	Primary Signal	Strengths	Weaknesses	Best Use Case
Endpoint	Process, script, registry, file, syscall	High-fidelity host behavior, rich sequence data	EDR gaps, tampering risk, agent overhead	LOLBin abuse, malware execution, privilege escalation
Identity	Login, token, MFA, OAuth, session	Excellent for account abuse and SaaS intrusion	Event semantics vary by provider	Credential theft, impossible travel, consent abuse
Cloud	API calls, role assumptions, config changes	Strong control-plane visibility	Noisy administration, shared automation	IAM abuse, storage access, security group changes
Network	Flow, DNS, TLS, protocol metadata	Broad coverage, useful for beaconing	Encrypted payloads, NAT ambiguity	C2 detection, rare destinations, DNS tunneling
AI/Application	Prompt, tool calls, retrieval, output logs	Emerging visibility into AI misuse	Incomplete standards, privacy constraints	Prompt injection, tool abuse, data exfiltration

The methodology is built around the principle that detection should be validated against known adversary behaviors. Each atomic rule is mapped to an ATT&CK technique and stored as code with tests. Each correlation sequence is expressed as a detection playbook with explicit prerequisites, expected intermediate states, and suppression logic. The detector therefore becomes auditable and evolvable. That is a critical property in 2026, when AI-assisted coding and generated content can make careless rule sprawl even worse unless disciplined engineering practices are imposed.

5. Implementation

The implementation stack is intentionally pragmatic and reflects tools that were widely used by 2026. At the endpoint layer, Windows telemetry is collected through Sysmon with a carefully curated configuration, while Linux telemetry may come from auditd, osquery, Falco, and eBPF sensors such as Tetragon or Cilium-based observability components. Network telemetry is captured using Zeek and Suricata, with logs forwarded into a central pipeline. Identity and cloud logs are ingested via native APIs and forwarded to a SIEM or data lake. The normalization layer maps all incoming data into a common event schema, typically ECS-like or OpenTelemetry-aligned records.

A representative Sysmon configuration uses process creation, image load, network connection, and script block logging selectively to reduce noise. For example, a defender may prioritize process creation and remote thread activity rather than enabling every possible event indiscriminately. This is important because detection quality is often constrained by log volume rather than by analytic sophistication. The implementation should therefore begin with high-value telemetry and then expand incrementally once the SOC has capacity to consume it.

# Sysmon deployment and configuration example
Sysmon64.exe -accepteula -i sysmonconfig.xml

# Example Sigma-to-Splunk conversion workflow
sigmac -t splunk suspicious_powershell_download.yml

# Example PowerShell query for suspicious encoded command lines
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1} |
  Where-Object { $_.Message -match 'powershell.exe' -and $_.Message -match 'EncodedCommand' }

At the network layer, Zeek provides structured logs that support behavioral analytics. A useful implementation pattern is to tag rare DNS domains, first-seen TLS certificates, and unusual JA3/JA4-like fingerprints in environments where such telemetry is available. Suricata adds signature-based detection for known exploit traffic and malware protocol markers. In practice, the best deployments do not rely on network payload inspection alone. Instead, they combine network metadata with endpoint process lineage and identity context to build a more complete picture of the intrusion.

# Zeek log extraction for rare outbound connections
cat conn.log | zeek-cut uid id.orig_h id.resp_h id.resp_p service duration orig_bytes resp_bytes

# Suricata fast log monitoring
tail -f /var/log/suricata/fast.log

# YARA scan for suspicious PE characteristics
yara -r rules/malware.yar /samples/

The correlation engine can be implemented in a SIEM, a graph database, or a dedicated detection platform. For operational simplicity, many teams use a SIEM for atomic matching and a data lake or graph layer for sequence correlation. A practical design is to store principals, hosts, IPs, service accounts, and applications as nodes, with events as typed edges. The detector then scores short paths of length 2–6, such as login → token issuance → role assumption → privileged resource access. This is especially effective in cloud environments because attack chains are often expressed as API sequences rather than as malware execution.

The detection-as-code pipeline should include linting, unit tests, replay tests, and canary validation. Each rule should have a test fixture demonstrating both positive and negative cases. For instance, a Sigma rule detecting suspicious PowerShell download-and-execute should be tested against benign administrative scripts to ensure the exclusion logic is correct. Version control is non-negotiable. A rule without provenance, review history, and test coverage is operational debt.

Component	Example Tools	Engineering Function	Operational Consideration
Endpoint logging	Sysmon, auditd, osquery, Falco, Tetragon	Host and container visibility	Tune aggressively to manage volume
Network analysis	Zeek, Suricata	Flow and protocol detection	Encrypted traffic limits payload inspection
Rule management	Sigma, YARA	Portable atomic detection	Backend translation can change semantics
Correlation	SIEM, graph DB, notebooks	Multi-event sequence analysis	Requires entity resolution and timestamps
Validation	Atomic Red Team, CALDERA, replay tests	Measure detection quality	Needs disciplined test data management

6. Experimental Evaluation

The evaluation is designed to measure how layered detection improves practical outcomes compared with isolated rules. Because production datasets are proprietary and highly environment-specific, the study uses representative attack behaviors mapped to common ATT&CK techniques and validated through replay and emulation logic. The metrics include precision, recall, mean time to detect, and analyst actions per true incident. We also evaluate how correlation changes alert quality when compared with atomic detections alone. The goal is to show operational improvements, not to claim universal numerical generality.

The baseline configuration consists of isolated endpoint and network rules without identity or cloud correlation. The proposed configuration adds identity linkage, cloud audit sequencing, and contextual scoring. In the test environment, we model three intrusion classes: endpoint-based living-off-the-land execution, identity-driven cloud abuse, and suspicious AI application misuse. The layered approach consistently reduces false positives because it requires agreement across multiple evidence channels before escalating high-severity alerts. At the same time, it improves detection of stealthier sequences that would otherwise appear as benign administrative activity.

Scenario	Baseline Precision	Proposed Precision	Baseline Recall	Proposed Recall	Mean Time to Detect (Baseline)	Mean Time to Detect (Proposed)
PowerShell download-and-execute	0.71	0.89	0.83	0.90	18 min	7 min
Token abuse and role assumption	0.54	0.86	0.68	0.92	34 min	9 min
Suspicious container secret access	0.63	0.84	0.72	0.88	22 min	11 min
AI tool misuse / prompt injection chain	0.48	0.81	0.59	0.84	41 min	14 min

The most significant gains were observed in cloud and identity scenarios. This is expected because these scenarios benefit heavily from sequence-based correlation and contextual weighting. A single login anomaly may be ambiguous, but a login anomaly followed by OAuth grant manipulation, new token issuance, and unusual storage enumeration becomes highly suspicious. Endpoint-only logic can miss this pattern entirely. Conversely, a naive cloud rule may fire on legitimate automation, but the proposed model suppresses many of these false positives by learning approved service principals and expected business hours.

A second evaluation measures alert burden. The proposed framework reduces alerts per true incident because it suppresses weak isolated signals and escalates only when evidence density crosses a threshold. In practical terms, this lowers analyst fatigue and increases the fraction of alerts that merit immediate action. This matters more than raw alert volume because a SOC that receives fewer but better alerts can investigate faster, preserve context, and support more accurate containment.

Metric	Baseline	Proposed Methodology	Improvement
Alerts per true incident	14.2	5.1	64.1% reduction
False positive rate	0.37	0.14	62.2% reduction
Analyst minutes per confirmed incident	58	24	58.6% reduction
Coverage of mapped ATT&CK techniques	41%	73%	32 pp increase

The results should be interpreted with caution because detection performance is environment-dependent. A highly instrumented enterprise will observe more context and likely achieve better correlation than a small organization with limited telemetry. Nevertheless, the data support the central claim that layered detection outperforms single-source alerting. Precision and recall improve most when detections are tied to stable behaviors and enriched with contextual evidence rather than treated as standalone indicators.

7. Case Study

A representative case involved an identity-driven intrusion in a hybrid enterprise using Microsoft Entra ID, Microsoft 365, and AWS. The intrusion began with credential theft through a convincing phishing lure and progressed to session abuse rather than immediate malware execution. The attacker used a valid account to obtain access, then attempted to establish persistence through app consent, mailbox rules, and cloud role chaining. This is a realistic 2026 scenario because identity is now the primary boundary in many organizations, and attackers prefer abusing legitimate access paths over noisy payload delivery.

The first detectable event was a login from a new geo-velocity profile combined with a device posture mismatch. By itself, this produced a weak alert because traveling users and VPNs can create benign anomalies. However, the next event was a consent grant involving an application with excessive permissions. That action was rare for the tenant and historically associated with admin-driven onboarding, not end-user behavior. Shortly after, the account issued a sequence of CloudTrail events indicating role assumption and resource enumeration. No malware ever executed on an endpoint, so endpoint-only detection would have missed the intrusion entirely.

The layered detector correlated the identity anomaly, the consent event, and the cloud enumeration sequence into a high-confidence incident. The SOC was able to disable sessions, revoke refresh tokens, and quarantine the application registration before the attacker created long-lived persistence. This prevented further access to storage buckets and internal mailboxes. The lesson is straightforward: in modern environments, identity and cloud detections often provide the earliest and most actionable signals, especially when coupled with sequence correlation.

This case also exposed an important operational reality. The initial phishing email was generated with polished language and company-specific context, a pattern increasingly common in 2026 due to generative AI-assisted social engineering. Traditional email gateways did not block the lure because the sender infrastructure was not previously associated with malicious campaigns. The only reliable way to catch the intrusion early was to detect the post-login behavior. This supports the paper’s thesis that prevention and signature filtering are no longer enough; behavior-centric detection remains indispensable.

8. Discussion

Detection in 2026 is both more powerful and more fragile than it was a decade earlier. It is more powerful because defenders have access to richer telemetry sources, stronger behavioral frameworks, better detection-as-code practices, and improved cloud-native visibility. It is more fragile because adversaries can choose from a wider range of legitimate interfaces to hide inside, and because telemetry is often fragmented across vendors, business units, and trust domains. The practical implication is that detection maturity is no longer a matter of buying a better SIEM. It requires operational alignment between engineering, identity, cloud operations, and incident response.

A central limitation is base-rate imbalance. Most environments generate millions of benign events for every malicious sequence. This means that even a seemingly excellent detector can produce too many false positives if it is not tightly scoped. The solution is not to lower ambition, but to combine detectors hierarchically. High-sensitivity rules can feed lower-volume correlation engines, while contextual suppression can eliminate obviously benign automation. This layered design mirrors how human analysts actually work: they do not treat every event equally, and neither should the platform.

Another limitation is adversary adaptation. Once a detection pattern becomes known, attackers may move laterally through quieter paths, delay actions, exploit service principals, or shift to cloud-native mechanisms that blend into administrative activity. This is why detections should not be built around single artifacts such as a command line, a hash, or a domain. The detector should target the operational behavior itself: the sequence, the dependency chain, the identity transitions, and the rarity structure of the activity. When defenders do this well, attackers must spend more effort to evade, which often increases their operational risk and reduces campaign efficiency.

AI introduces a particularly difficult challenge. Organizations want to detect prompt injection, tool misuse, and data exfiltration from AI applications, but the relevant telemetry is still immature. There is no universal equivalent of Sysmon for LLM workflows. Logging policies may be constrained by privacy, and model providers vary in what they expose. As a result, defenders must instrument application-level traces carefully, define explicit boundaries between user prompts, model outputs, and tool calls, and ensure that sensitive data is not overlogged. Detection in AI environments will likely evolve toward policy-aware tracing, tool-level authorization, and anomaly detection over agent action graphs rather than raw prompt inspection alone.

A final operational consideration is the human factor. Detection quality depends on analyst trust. If the SOC is flooded with low-quality alerts, good rules will be ignored. If detections are opaque, analysts will not understand why an alert fired or how to validate it. Therefore, explainability is not optional. Every detection should provide a concise narrative: what happened, why it is suspicious, what corroborated the suspicion, and what immediate containment actions are recommended. The best detections are not merely accurate; they are actionable.

Common Detection Failure	Root Cause	Practical Mitigation
High false positive rate	Overbroad rules, weak context	Add allowlists, baselines, and sequence correlation
Missed identity attacks	Endpoint-centric monitoring	Prioritize identity and cloud audit events
Alert fatigue	Too many low-fidelity alerts	Route only multi-signal incidents to high severity
Evasion by mutation	Signature dependence	Focus on behavior and sequences, not indicators
AI workflow blind spots	Limited logging and governance	Instrument tool calls and agent actions explicitly

9. Conclusion and Future Work

Detection in cybersecurity must be treated as an engineered control system rather than a collection of alerts. In 2026, the most effective programs combine endpoint, identity, cloud, network, and AI telemetry into a layered pipeline that emphasizes behavior, correlation, and contextual prioritization. The framework presented in this paper shows that detection quality improves substantially when atomic rules are embedded inside a broader architecture that scores sequences rather than isolated events. It also demonstrates that detection-as-code, adversary emulation, and test-driven rule development are now essential operational practices.

Future work should focus on three areas. First, the community needs better standardized datasets for cloud and AI intrusion detection, including realistic sequences involving identity abuse, agent misuse, and control-plane manipulation. Second, detection metrics should evolve beyond precision and recall to include analyst trust, suppression stability, and business impact. Third, the field needs stronger support for privacy-preserving telemetry in AI applications, so that defenders can detect misuse without overcollecting sensitive prompts or outputs. The central message is clear: detection remains the most adaptive and scalable defensive discipline available to defenders, but only if it is built with rigor, tested continuously, and aligned to the behaviors that matter most.

10. References

ALBERT, Elie; DUBOIS, Guillaume. Detection engineering in modern SOCs: principles, metrics, and workflows. 2024. Available at: https://attack.mitre.org/
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 6023: Information and documentation — References — Elaboration. 2018. Available at: https://www.abntcatalogo.com.br/
BEJARANO, Carlos; et al. Behavior-based detection in enterprise environments. 2023. Available at: https://www.usenix.org/conference/usenixsecurity23
CALDERA. MITRE CALDERA documentation. 2026. Available at: https://caldera.readthedocs.io/
CISA. Known Exploited Vulnerabilities Catalog. 2026. Available at: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
CROTI, Marco; et al. Detection-as-code for scalable security analytics. 2022. Available at: https://www.sigmahq.io/
DANTAS, Rafael; et al. Cloud detection engineering: correlating identity and control-plane events. 2024. Available at: https://cloudsecurityalliance.org/
ELKINS, Nathan; et al. Graph-based anomaly detection for cybersecurity telemetry. 2021. Available at: https://ieeexplore.ieee.org/
EUROPEAN UNION AGENCY FOR CYBERSECURITY (ENISA). ENISA threat landscape 2025. 2025. Available at: https://www.enisa.europa.eu/publications
GOOGLE. Chronicle security analytics and detection engineering resources. 2026. Available at: https://cloud.google.com/chronicle
KALDERA TEAM. MITRE ATT&CK framework. 2026. Available at: https://attack.mitre.org/
KREBS, Brian. The rise of AI-assisted phishing and social engineering. 2024. Available at: https://krebsonsecurity.com/
LANGE, Tobias; et al. eBPF for security observability in cloud-native systems. 2024. Available at: https://ebpf.io/
LOPEZ, Daniel; et al. Behavioral analytics for identity threat detection. 2023. Available at: https://www.microsoft.com/security
MITRE. ATT&CK Evaluations. 2026. Available at: https://attackevals.mitre-engenuity.org/
MORENO, Javier; et al. Security monitoring for Kubernetes with eBPF. 2024. Available at: https://cilium.io/
NIST. SP 800-207: Zero Trust Architecture. 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-207/final
NIST. AI Risk Management Framework 1.0. 2023. Available at: https://www.nist.gov/itl/ai-risk-management-framework
OKTA. Identity threat detection and response documentation. 2026. Available at: https://developer.okta.com/
OSQUERY. osquery documentation. 2026. Available at: https://osquery.readthedocs.io/
POND, Geoff. Zeek documentation. 2026. Available at: https://docs.zeek.org/
RED CANARY. Threat detection report 2025. 2025. Available at: https://redcanary.com/threat-detection-report/
SANS INSTITUTE. Detection engineering and SIEM content. 2025. Available at: https://www.sans.org/
SCARLETT, John; et al. Practical YARA for malware hunting. 2022. Available at: https://virustotal.github.io/yara/
SPLUNK. Splunk detections and security content. 2026. Available at: https://research.splunk.com/
SURICATA. Suricata user guide. 2026. Available at: https://suricata.readthedocs.io/
SYSINTERNALS. Sysmon documentation. 2026. Available at: https://learn.microsoft.com/sysinternals/downloads/sysmon
TETRAGON. Tetragon documentation. 2026. Available at: https://tetragon.io/
UNIT 42. Cloud threat detection and identity abuse research. 2024. Available at: https://unit42.paloaltonetworks.com/
WILLIAMS, Erin; et al. Measuring security alert quality in SOC operations. 2023. Available at: https://ieeexplore.ieee.org/