The current wave of AI coding assistants and agentic orchestration platforms is giving the age-old build vs buy decision a new twist.
Prototyping agentic workflows for detection engineering is more accessible than ever, but sustaining high-performance detection systems demands a more systemic approach. For a consistent advantage against AI-enabled adversaries, you need detection expertise, operational feedback loops, and adaptive intelligence encoded into a system designed to mature alongside changing environments and adversary behaviors.
That’s what we’ve built with the CardinalOps Detection Engineering Foundation, the intelligence layer guiding our Agentic Fleet’s actions.
The Foundation is a continuously evolving system of in-depth practitioner expertise, environment-specific context, and adaptive threat-informed learning, designed to enable our agents to operate like real detection engineers with extensive experience in enterprise environments.
It encodes CardinalOps core detection engineering philosophies across three main sources: detection engineering expertise, customer-specific context, and broader world context.
CardinalOps Detection Engineering Expertise
The Foundation starts with our team’s decades of cumulative detection engineering experience. It incorporates best practices across security research and detection engineering, including a wide variety of detection logic patterns, adversary mapping methodologies, and SIEM-specific syntax knowledge. Drawing from CardinalOps’ extensive detection library, the Foundation’s knowledge base includes over 8,000 production-ready detection rules across a very wide range of threat detection use cases, for all major enterprise SIEMs.
The Foundation also embeds self-check mechanisms into each agent, so they validate their own detection logic before surfacing recommendations. This mechanism ensures agents will always validate generated detections before suggesting them to an end user. If necessary, they’ll proactively identify and fix syntax issues, logic flaws, or implementation inconsistencies.
Immutable Artifacts
One of our core principles for resilient detections is anchoring rule logic on immutable artifacts: behaviors or attacker dependencies that are significantly harder for adversaries to modify without disrupting the attack itself. By reducing dependence on brittle indicators that attackers can easily mask or change, CardinalOps detections identify immutable artifacts so they remain resilient over longer periods.
For example, to detect service creation in Windows, you might think to look for Event ID 4697 in the Security log, or Event ID 7045 in the System log, but shifting your focus to immutable artifacts anchors your detections on behaviors that must occur regardless of the tool or method. And when detecting service creation, no matter the tool — PowerShell, sc.exe, WinRM, or a custom binary — every one of them will generate the appropriate registry key as an immutable artifact. And that’s what our detections will always look to identify.
Tuning Workflows
The Foundation incorporates extensive real-world engineering experience tuning detections across enterprise environments. Through countless customer engagements, lab research exercises, detection scenarios, and alerting workflows, CardinalOps has developed deep intelligence around common false positive root causes, unstable telemetry behaviors, and noisy alert patterns to develop effective exclusion strategies across a range of styles and preferences. All of that knowledge is represented in the Foundation, directly informing how the Fleet approaches detection tuning and signal optimization.
Collective, Adaptive Intelligence
The Foundation continuously evolves, with every tuning recommendation, coverage gap analysis, investigation outcome, and detection refinement contributing additional context that helps improve future decisions. Human detection engineers and threat researchers stay in the loop, reviewing and refining the system’s ongoing evolution.
This learning extends beyond any single deployment. The Foundation draws from aggregated operational patterns observed across enterprise environments, security platforms, and detection workflows. As the system encounters new telemetry behaviors, false positive trends, and attacker techniques, those insights help strengthen the Fleet’s broader detection engineering capabilities. The result is a continuously maturing body of detection intelligence that compounds over time.
Anonymization for Privacy & Data Protection
At the same time, customer-sensitive information remains protected. Learning is derived from aggregated and anonymized insights, like a generalized false-positive root cause. For example, a class of PowerShell detections may start generating false positives after a customer deploys an endpoint update. Investigations reveal that a legitimate administrative process spawned PowerShell commands during scheduled software inventory scans. This establishes a learned pattern on which general fields of telemetry reliably distinguish between benign administrative activity from malicious execution, so the system can quickly recognize similar conditions next time.
But the details of the organization’s telemetry–their specific Powershell activity logs, detection rule logic, and any downstream alert triage or investigation data–never leaves their environment, remaining under their control.
This allows organizations to benefit from collective experience without exposing proprietary, sensitive data. With this adaptive intelligence layer, detection effectiveness strengthens continuously while maintaining the privacy and control requirements expected in enterprise security environments.
Customer-Specific Context
Each organization has its operational idiosyncrasies: how rules are written, how exclusions are incorporated into the logic, how alerts are enriched, what types of sources exist in the environment, and many other “facts” about their unique environment. Things like “we rely on our EDR for endpoint detections, so any endpoint-related detection should not be in the SIEM”, or “we don’t have an office, so network-related rules must use endpoint-based agents rather than network appliances.”
The Foundation includes mechanisms to identify these types of preferential patterns over time while reasoning over operational outcomes inside the customer’s own environment. By integrating with SIEMs, SOARs, AI SOC platforms, and related datasets, the system can observe SIEM rule logic and evaluate alert history, investigation outcomes, and false-positive-to-true-positive ratios across detections.
This allows the agents to identify recurring patterns, prioritize noisy detections, and recommend tuning strategies grounded in observed behavior rather than static assumptions.
Detection Styles
The Foundation adapts to each customer’s own detection methodology. Different organizations structure detections differently: some rely heavily on data models, others prefer source types and indexes, and documentation practices vary widely between teams. The Foundation has mechanisms to learn these styles, then instruct the Fleet’s agents to use those implementation patterns and generate detections in forms that align more naturally with the customer’s operational style.
Tuning & Exclusion Preferences
Different organizations approach tuning differently. For example, a detection engineer may want to start with broader visibility across their environment. For them, starting with minimal exclusions and gradually adding more to tighten the logic over time works better. Others may work with analysts already drowning in alert floods, so they’ll prefer starting with more aggressive exclusions that suppress noise. These preferences are integrated as context for the model, which helps agents better understand how the organization approaches tuning workflows in practice.
The Foundation applies these tuning preferences when generating recommendations, helping ensure tuning strategies align with how the SOC prefers to balance signal quality, operational overhead, and investigative visibility.
Feedback Loops
While early actions and recommendations are based on the strong principles discussed above, the system’s initial understanding of the customer’s operational preferences is limited. Context develops quickly through interaction with the organization’s infrastructure, workflows, and preferred detection strategies and tactics. The Foundation is designed to accelerate learning processes through continuous human feedback loops.
Teams provide direct feedback on the quality of detections, tuning decisions, exclusions, and operational outcomes. For example, a detection engineer may repeatedly modify generated detections to anchor on process lineage and parent-child execution behavior instead of command-line string matching, because their environment experiences frequent noise from administrative scripting activity. The Foundation incorporates those decisions as additional context, helping the agents better understand the organization’s detection methodology and generate future recommendations that align with the team’s actual detection practices.
The system works to match the customer’s operational preferences and environment-specific realities. The agents become more familiar with telemetry patterns, detection methodologies, tuning philosophies, and implementation styles unique to the organization. Instead of static automation workflows, the agents mature alongside the detection program itself.
Broader World Context
Detection strategy and the customer environment don’t exist in a vacuum. The world they operate in grounds the Foundation in reality. This is where the broader threat landscape and emerging threat actors come in. The Foundation has proven techniques for quickly parsing new threat actors and APTs and applying threat intelligence to detection strategy.
The Foundation codifies a strategic high-level approach to maintaining a threat-informed detection posture. When new CVEs or attack techniques appear in the wild, the system knows to proactively generate specific detection tactics and rule templates designed to identify those emerging threats in context–not just the infrastructure directly relevant to a CVE, but also the upstream and downstream attack surfaces likely to be affected by an attack chain exploiting that CVE.
For example, following disclosure and active exploitation of CVE-2026-0300 affecting Palo Alto Networks PAN-OS GlobalProtect gateways, the Foundation would anticipate downstream attacker behaviors commonly associated with compromised perimeter infrastructure. That includes suspicious authentication activity originating from GlobalProtect-connected users, anomalous use of administrative accounts, unexpected lateral movement from VPN subnets, PowerShell or PsExec execution on internal Windows systems shortly after VPN logins, and privilege escalation from newly established remote sessions. By reasoning from both the vulnerability context and known adversary tradecraft and attack paths, the Foundation helps organizations operationalize relevant detections rapidly as exploitation activity emerges in the wild.
How the Foundation and Fleet Interact
Think of the Foundation as the knowledge layer, and the Fleet as the action layer.
Agents have the Foundation’s detection engineering expertise embedded within their core.
They also know how to quickly gather, process, and operationalize relevant context from the broader world. But just like a new team member, they will have to learn the customer organization’s specific context during their onboarding, ongoing training and throughout their work.
The Foundation has embedded important initial questions to ask to gather environmental context. Some can be completed automatically, like looking at the customer’s existing rules to infer their style based, using some key questions we guide it with. For other things, the agents learn from customer feedback on the agents’ activities (as discussed in the feedback loops section above).
Want a live look at how the Foundation and Fleet work together to defeat adversaries? Request a demo today.