How Agents Engineer Detection

There is a common pattern in the email security industry's adoption of AI. Whether the product was built on ML from the start or added it later, ML models are incorporated into the detection pipeline and improve detection accuracy. But the customer experience remains fundamentally the same: a verdict is delivered, the message is blocked or allowed, sometimes with a confidence score, and the system's reasoning cannot be independently verified, nor its behavior precisely shaped to a customer's environment.

This is a useful but narrow application of AI. While the models make better decisions within the existing architecture, they do not change the architecture itself or the relationship between product and security teams.

We believe there is a more consequential question: whether AI can change the structure of how detection and prevention work. Can AI provide security teams with capabilities they did not previously have, rather than incrementally better versions of existing ones? This is the shift from AI as a classifier to AI as an operator: an agent that can investigate, author detection logic, test its own changes, and improve defenses locally over time.

Through building and deploying AI agents over the past year, we've found the answer depends almost entirely on the underlying detection architecture.

3.1 Architecture as the Determining Factor

Our previous post described the Distributed Detection Model and its three customer-facing outcomes: local adaptation, fast iteration, and transparent reasoning. (It also enables a fourth, emergent property, sharable detection logic, which we will return to later.) We presented that argument on its own merits, as a better architecture for human security teams.

The architectural properties that produce those outcomes also enable AI agents to do useful detection and prevention work. While the underlying AI models matter, what determines whether an agent does useful work is the architecture it operates on.

Consider the requirements for an agent to function as a detection engineer:

• It must be able to read existing detection logic to understand current coverage and identify gaps.
• It must be able to write new detections that compose multiple signals, including ML outputs, behavioral analysis, and content inspection, into coherent detection logic.
• It must be able to test what it writes against real data.
• It must be able to present its output in a form that a human can evaluate, approve, or reject.

In a distributed detection model, each of these requirements is met. The detection language is readable, writable, and testable. The agent's output is a detection that a security engineer can review line by line, using the same criteria applicable to a detection written by a colleague. The human review is substantive rather than ceremonial, because there is a transparent artifact to evaluate.

In a centralized model, the agent encounters a structural barrier at each step. A product near the centralized end of the spectrum may expose a partial query language, but that does not change where it sits. The language operates on top of detection logic the customer can neither see nor modify; the methodology that determines what constitutes a threat remains a vendor-owned model rather than an addressable artifact the agent can read or expand. The agent cannot backtest a proposed change in isolation.

A centralized-model agent can generate recommendations that inform the vendor's detection pipeline. This is a useful capability, but it is categorically different from an agent that directly authors detection coverage.

One might argue that a vendor could simply use agents internally to improve their centralized pipeline, but this does not address the architectural constraint for three reasons:

1. The surface is not accessible to the customer or to agents acting on the customer's behalf.
2. The resulting improvements are still deployed uniformly across all customers, inheriting every structural limitation described in Part 1: high MTTC, global validation requirements, and the sensitivity ceiling.
3. The detection logic remains opaque to the security team using it.

Together, these three gaps are the architectural constraint. An agent can meaningfully engineer detection only when detection logic is per-tenant, transparent, and customer-accessible. Even centralized products that provide per-tenant behavioral adaptation do not satisfy these conditions, because the adaptation surface is not accessible to the customer or to agents acting on their behalf.

This distinction sets the ceiling for what AI agents can accomplish in a security product. The remainder of this post examines what agents on a distributed architecture can actually do, with Sublime's two production agents as the case studies.

3.2 ADÉ: Autonomous Detection Engineer

The relationship between architecture and agent capability is most clearly illustrated by examining how Sublime's Autonomous Detection Engineer (ADÉ) operates in practice.

The problem ADÉ addresses is well-defined: Every detection system has coverage gaps. New attack techniques emerge, existing techniques mutate, and some attacks are sufficiently specific to a particular organization that no vendor's default coverage would detect them. In a centralized model, many of these gaps are not merely slow to close but structurally resistant to closure. A detection generalized enough to catch the attacker behavior would produce unacceptable false positives elsewhere in the customer base, and the vendor is thus constrained from shipping it. A detection specific enough to catch the particular variant is ineffective elsewhere. Gaps that can be closed are closed on the vendor's MTTC, typically weeks, months, or even years. In a distributed model without agents, it requires a human detection engineer to write a new detection, which is faster but depends on specialized skill and available bandwidth.

ADÉ performs this work through a five-step workflow:

1. Input: a concrete coverage gap. A malicious message is identified that existing detection coverage did not catch. The identification may come from a user report, an analyst's investigation, or from Sublime's Autonomous Security Analyst (ASA), discussed in the next section.

2. Attack analysis. ADÉ analyzes the attack to identify the signals that characterize it: the techniques it employs, what distinguishes it from legitimate email, and its behavioral and structural properties. It then reviews the organization's existing detection coverage to determine why the attack was not caught. This review may reveal that an existing detection came close but lacked a necessary condition, or that the attack represents a genuinely novel pattern with no existing coverage.

3. Detection authoring. ADÉ writes a new MQL detection, drawing on a domain-specific knowledge base (attack techniques, detection patterns, MQL itself) and a set of tools (enrichment functions, historical-data queries, an MQL validator) that ground each detection in real signals. Because MQL exposes ML as composable functions, ADÉ combines NLU intent classification, computer vision, link analysis, sender behavioral signals, and structural checks in a single coherent artifact, comparable to what a senior detection engineer would produce.

4. Backtest and iteration. ADÉ tests the new detection against the organization's historical message data. Does it catch the original attack? Does it catch similar variants? Does it produce false positives against the legitimate mail the organization actually receives? If the false positive rate exceeds acceptable thresholds, ADÉ iterates: adjusting conditions, refining thresholds, adding specificity. Multiple write-backtest-refine cycles may occur before the result meets the required efficacy standard.

5. Activation. ADÉ's autonomy is policy-controlled: the organization, not the vendor, sets the rules for what it may do without a human in the loop. New coverage is auto-activated when it clears a configurable efficacy threshold. Security teams can optionally require human review before activation, in which case the detection is presented together with backtest results and explanatory comments. In either case, the detection logic is transparent, the full audit trail is available for review at any time, and the organization retains control over its detection posture.

Three properties of this workflow merit emphasis.

Speed. The cycle from identified coverage gap to deployed detection can complete in hours. This is not because ADÉ performs the same process as a centralized vendor more quickly. It is because the architecture supports a fundamentally different process. There is no global validation step. The new detection is written for one organization, tested against that organization's data, and deployed to that organization's environment.

Transparency. ADÉ does not modify model weights. It produces a human-readable detection that can be inspected, evaluated, and (if desired) modified by the security team. The optional human-in-the-loop is a genuine review of a concrete artifact, which is what makes this workflow trustworthy enough to operate autonomously at scale.

Capacity. ADÉ delivers the output of a skilled detection engineer to organizations that lack the headcount or specialized expertise to do this work themselves. Detection engineering, historically a scarce and senior skill, becomes available to any team without adding staff.

A detection ADÉ writes need not stay local. Because the output is a portable, readable artifact rather than a model weight, an effective detection can be vetted and syndicated to other organizations, each backtesting it against its own data before adoption. Coverage developed in one environment strengthens the community without sacrificing local verification.

3.3 ASA: Autonomous Security Analyst

Detection engineering is half of the security workflow. The other half is investigation, triage, and disposition after a message is flagged.

This operational work constitutes a significant portion of most security teams' daily effort. Users report suspicious messages. Detections fire and require review. Each incident demands some combination of link inspection, attachment analysis, sender reputation assessment, historical pattern review, and a judgment about whether the message is genuinely malicious. The work is important, but it is repetitive and volume-dependent. Most teams face a persistent tension between thoroughness and throughput.

ASA, Sublime's Autonomous Security Analyst, performs this investigative work. When a user-reported message or alert requires investigation, ASA conducts an analysis comparable to what a human analyst would perform, completing it in seconds rather than minutes.

Notably, ASA's architecture does not operate as a single model producing a binary verdict. It orchestrates a rich enrichment pipeline that gathers evidence from many specialized capabilities: following link redirects and capturing screenshots, exploding attachment archives and running OCR on their contents, applying computer vision for logo detection, evaluating sender reputation and WHOIS data, reviewing historical sender patterns within the organization, and applying NLU to assess message intent. All of this evidence is passed to a reasoning step that produces a structured verdict with citations to the specific signals that contributed to it.

Some Sublime detections use a fuzzy attack score rather than precise conditions, casting a wide net to surface anomalous-looking messages for ASA to reason through. Because ASA's judgment rests on evidence rather than prior signatures, it can reach a malicious verdict on a novel technique no precise detection would catch, then hand it to ADÉ to codify as durable coverage. Broad probabilistic surfacing paired with agent reasoning is one of the mechanisms by which the system catches zero-day attacks.

The output is a verdict accompanied by structured reasoning. When ASA determines that a message is a credential phishing attempt impersonating a SaaS provider, it documents the specific findings: the sender domain was registered recently, the embedded link redirects to a page mimicking the provider's login interface, logo detection confirmed the brand impersonation, and the NLU model classified the message intent as credential harvesting. Each conclusion traces back to a specific analytical step.

The distributed architecture is directly relevant here. ASA's reasoning is grounded in the same transparent detection primitives that the rest of the system uses. The ML functions ASA invokes are the same functions available in MQL. The signals it references are the same signals available to human analysts and to ADÉ. The entire system operates on a shared, inspectable substrate.

3.4 Agent Collaboration and the Feedback Loop

ASA and ADÉ are not independent tools that happen to coexist in the same product. They function as components of a connected system in which each agent's output informs the other's work.

When ASA triages a malicious message that no existing detection caught, that finding flows directly to ADÉ as an input for new detection coverage. ADÉ analyzes the attack and writes, backtests, and deploys a new detection. Any similar attack targeting the organization is caught automatically. ASA's subsequent triage workload becomes lighter and more focused on genuinely novel threats. Each agent improves the other's effectiveness, and the organization's detection posture strengthens with each iteration.

This feedback dynamic reveals a structural difference between centralized and distributed detection that extends beyond the properties discussed in Part 2.

In a centralized model, improvements to detection occur on the vendor's timeline. A customer reports an attack, the report enters a queue alongside every other customer's, and it may or may not influence a future update. The customer has no way to verify that the gap was ever closed; they are asked to trust that it will be. Their specific experience of an attack does not feed back into their own defenses in any observable way.

In a distributed model with agents, the feedback loop is direct and per-organization. An attack arrives. ASA investigates and confirms it is malicious. ADÉ writes a new detection targeting the attack's specific characteristics, tests it against the organization's own historical data, and deploys it. The next occurrence of that technique against that organization is caught.

Each iteration of this cycle makes the system more adapted to the specific organization's threat landscape and the uniqueness of its environment. The attacks that bypass detection are analyzed. The resulting coverage gaps are closed with detections tailored to that environment, tested against that organization's actual mail patterns. Over time, the detection posture becomes increasingly precise, increasingly unique to that organization, and increasingly difficult for attackers to predict. This runs on top of, not in place of, the vendor's own default coverage, which keeps improving in parallel for every customer. The distributed layer exists for what that default coverage cannot reach: the tailored, organization-specific cases that would never justify a global rule.

This is a fundamentally different dynamic from what centralized models offer. Even with per-tenant behavioral profiles, the feedback from "this specific attack got through" to "we now have coverage for this pattern of behavior" does not exist as a discrete, traceable loop. In a distributed model, that loop is explicit, it runs per-tenant, and agents ensure it runs continuously without requiring the security team to drive it manually.

3.5 Beyond Two Agents

ASA and ADÉ address two workflows: triage/investigation, and detection engineering. The architectural properties that make them effective (a transparent detection language, composable ML signals, per-tenant adaptation, historical data for testing) apply to a broader set of security workflows such as threat hunting, incident response, security operations management, and metrics and reporting. Each of these involves work that could be performed by a specialized agent operating on the same shared substrate, collaborating with the existing agents and extending the feedback loop.

The final post in this series examines that broader vision: what a full team of specialized agents might look like, why the distributed detection architecture is a prerequisite for building it, and why we believe the implications extend beyond email security.