The Distributed Detection Model

The previous post examined four structural limitations of centralized email detection: a sensitivity ceiling imposed by the need to deploy uniformly, false positives resolvable only through coarse global allowlisting, high Mean Time to Coverage (MTTC) gated on global validation, and decision-making that customers cannot independently verify or modify. We argued that these limitations are architectural rather than implementational, and that resolving them requires a different design.

This post describes that design, which we call the Distributed Detection Model (DDM).

2.1 Design Requirements

If one were designing an email detection system with the goal of avoiding the centralized limitations described in Part 1, the requirements would be reasonably clear. They are properties of the customer experience, not implementation details:

• Adaptation should be local and atomic. Two of the Part 1 limitations share a root: the sensitivity ceiling (uniform logic is never optimal for every environment) and global allowlisting (the only exception mechanism is coarse). Both dissolve when each organization's defenses can be shaped to its environment at the granularity of individual decisions, without waiting on the vendor.
• Iteration should be fast. Time to Coverage (new techniques left uncovered for weeks or months while an update is validated globally) only improves when new coverage and adjustments can be deployed in minutes or hours.
• Reasoning should be transparent. The fourth limitation was that customers consume a vendor-mediated view they cannot independently verify. The corresponding requirement: practitioners can understand why specific decisions were made and verify the reasoning holds in their environment.

No single requirement defines distributed detection on its own; some centralized vendors satisfy individual outcomes (per-tenant behavioral baselines, for example, partially address local adaptation). The combination is what matters. Multiple architectures could satisfy all four outcomes together. The remainder of this post describes the architecture we built at Sublime as one such implementation.

2.2 MQL as Reference Implementation

Sublime's architecture combines a domain-specific language, called Message Query Language (MQL), with composable ML, agent-based reasoning (covered in Part 3), and per-tenant adaptation. This section walks through MQL as one of those mechanisms, with the others addressed later in the series. MQL provides the transparent, composable layer for expressing detection logic; reasoning about novel, never-before-seen techniques is the role of the agents covered in Part 3.

Structured data model. Email in its raw form is difficult to work with programmatically: nested MIME parts, encoded headers, attachments within attachments. MQL operates on the Message Data Model (MDM), a clean, typed, queryable schema that the system produces by parsing raw email. Fields such as sender, subject, body content, attachments, and headers are normalized into a consistent structure regardless of the email provider. This normalization is what makes it possible to write detection logic that works identically across Microsoft 365 and Google Workspace.

Readable syntax. The language uses plain English operators (and, or, not, any, all) and supports dot notation for nested field access. This is a deliberate design choice. The barrier to reading and writing detection logic should be low enough that security analysts who are not software developers can participate meaningfully. Readability is not a cosmetic property, it's what makes transparency operationally useful rather than merely theoretical.

ML as composable functions. This is the most architecturally significant design decision. In MQL, ML model outputs are exposed as functions callable within the language. NLU (Natural Language Understanding) intent classification, computer vision, link analysis, logo detection, and OCR are not black boxes running in a separate pipeline. They are functions that return structured data, and that data is composed with other signals directly within the detection.

A concrete example illustrates how these properties work together. The following MQL rule detects callback phishing, an attack in which a document is designed to trick the recipient into calling a fraudulent support number:

type.inbound
and any(attachments, .file_extension == "zip"
  and any(file.explode(.),
    .file_extension in~ ("pdf", "jpg", "jpeg", "png")
    and any(ml.nlu_classifier(.scan.ocr.raw).intents,
      .name == "callback_scam"
      and .confidence == "high")))

Reading through it: the detection checks for an inbound message, identifies a ZIP attachment, extracts the archive contents, locates an image or PDF within it, applies OCR to extract text, and then runs an NLU classifier on the extracted text. If the classifier identifies callback scam intent with high confidence, the detection fires.

This is eight lines of readable code. Every signal is named. Every condition is visible. The ML model's output (callback scam intent classification) is composed with structural checks (ZIP archive containing an image, OCR text extraction) in a single auditable artifact. In a centralized architecture, this same signal composition occurs inside vendor code that no customer can inspect.

The analogy we find useful is what SQL accomplished for databases: a declarative language that allows practitioners to express what they are looking for without specifying the execution details. A detection DSL serves a similar function for security, with the critical addition that ML capabilities are first-class language features rather than opaque backend services. The result is detection logic that is transparent, inspectable, and fast to iterate on.

2.3 How DDM Resolves the Centralized Limitations

Each of the four limitations described in Part 1 maps to a specific architectural property of the distributed model.

2.3.1 Raising the detection sensitivity ceiling

In a distributed architecture, different organizations can run fundamentally different detection logic, not just different thresholds on the same underlying logic. The vendor maintains comprehensive default coverage, and individual organizations can extend it with detections that may have no parallel in any other environment. A detection written for a specific firm's financial fraud patterns or a specific healthcare org's HIPAA-related impersonation concerns can exist in DDM and have no equivalent for any other customer.

Centralized models cannot do this. Per-tenant behavioral baselines, the most common form of CDM customization, calibrate thresholds against a globally-trained model. The model itself is universal. A customer never gets detection logic built specifically for their environment; they get a globally-trained model with their behavioral data layered on top.

This is the architectural difference that raises the sensitivity ceiling. A detection that would produce unacceptable noise across thousands of customers may work perfectly in one organization where the relevant signals are unambiguous. The architecture allows the vendor to ship more precisely targeted coverage because the consequences of a misfire are contained to one organization. For organizations that wish to go further, custom coverage and direct tuning are available, but they are not a prerequisite for benefiting from the higher ceiling.

2.3.2 From global allowlisting to granular exclusions

When a detection fires incorrectly in a distributed model, the resolution mechanism is fundamentally different from the allowlist. A scoped exclusion can be added to a specific decision, for a specific sender, domain, or recipient, and the rest of the detection layer continues to function as before. The exception is precisely scoped rather than globally applied.

A detection layer composed of discrete, addressable elements (as in MQL) supports this deterministically: a scoped exclusion is guaranteed to behave exactly as specified. Agent-based approaches can also handle scoped exceptions, by including instructions in their context window ("don't flag this kind of message for this customer"), though the behavior is probabilistic rather than guaranteed. The DDM property is atomicity, the granularity at which exceptions can be expressed and applied. Deterministic detection logic is one path to that property; agent-based memory is another.

In a centralized architecture where the detection layer is a set of trained models or an opaque pipeline, there is nothing granular to attach an exception to. The only available exception mechanism is to broadly trust a sender or domain across all decisions.

2.3.3 Reducing Time to Coverage (MTTC)

In Part 1, we introduced Mean Time to Coverage (MTTC) as the interval between a new attack technique emerging and the detection system being updated to cover it. In a centralized model, MTTC commonly runs from days to weeks, and can stretch to months. In a distributed model, the response path is structurally different, compressing MTTC to minutes or hours.

A detection engineer, or an AI agent acting as one, can encode new coverage for the specific pattern (e.g., writing a detection, or sketching a lesson for the agent layer) then test it against the organization's historical message data to verify efficacy and false positive rates, and deploy it.

The new detection does not require validation across every customer environment. It needs to work for one organization, verified against that organization's own data. And unlike in a centralized model, none of this requires the vendor's involvement: an agent acting as a detection engineer can identify, test, and deploy the fix without a support ticket ever reaching the vendor. If the detection produces unexpected results, the blast radius is contained to a single tenant, and that tenant can adjust or disable it immediately.

This changes the MTTC equation by orders of magnitude. New coverage no longer requires validation across the vendor's entire customer base; it can be authored and tested against a single environment's own data, which is what compresses the timeline from weeks to hours, whether by writing a detection or sketching a lesson for the agent layer.

2.3.4 Making decisions verifiable

This is the deepest architectural difference between the two models, and the one that most directly shapes the customer's relationship with the system.

In a centralized product, the chain of reasoning that produces a verdict is owned by the vendor. Some vendors surface partial visibility: the signals that contributed to a risk score, an LLM-generated explanation, or a confidence breakdown. But the customer is consuming what the vendor has chosen to expose, not independently verifying the reasoning.

In a distributed model, the customer can verify the reasoning directly. Detection logic written in MQL is readable line by line. Agent-produced verdicts (covered in Part 3) cite the specific signals and detections that contributed. The customer can audit any decision back to its constituent inputs, and modify how those inputs are combined when the default composition does not suit their environment. Centralized products can provide explanations. Distributed systems can provide provenance. The difference is whether the customer can trace, test, and modify the decision path.

Transparency in a distributed model is a structural property, not a feature. It emerges from making the decision chain inspectable end-to-end, whether through readable detection logic, explainable agent reasoning, or both.

2.4 Collaborative Detection Development

The vendor maintains comprehensive default coverage that every customer receives out of the box. On top of that baseline, a distributed architecture makes something possible that has no analog in the centralized model: detection logic that can be shared, reviewed, and improved across organizations, the same way source code is.

In a centralized model, none of this is possible. There is no mechanism for a customer to contribute to a vendor's compiled model; the detection development process is closed by design, and the vendor is the sole entity that can improve coverage. In a distributed model, a detection written for one environment can be vetted and shared with others, each backtesting it against their own data before adopting it. Sublime's core feed includes detections that originated this way.

This is a structural capability, not a claim about how much of it happens today. It means the detection surface can grow through more than the vendor's own investment, something centralized architectures cannot replicate regardless of the size of their internal research teams.

2.5 Implications for AI Agents

The architectural properties that produce these outcomes for human security teams also enable AI agents to do useful work in detection and prevention.

This was not something we fully anticipated when we began building the distributed architecture. When we designed MQL (before the advent of ChatGPT and Claude), we were thinking about human detection engineers. In practice, though, writing and validating detection logic well enough to trust in production is hard, and most practitioners never used composable features to their full potential, in our product or others'. Agents close that gap: the same transparency and composability that make detection logic legible to a human also let an agent write, test, and iterate on it rigorously, at a speed and scale no human team can sustain. That is what turns the architecture's theoretical benefits into ones organizations actually realize.

Sublime's Autonomous Detection Engineer (ADÉ) demonstrates this concretely. ADÉ analyzes attacks that bypass existing coverage, writes new detections targeting their specific patterns, backtests them against the organization's historical data, iterates until efficacy and false positive thresholds are met, and either deploys them automatically (when they clear an efficacy threshold) or presents them for human review. The per-organization adaptation that DDM makes possible does not require the customer to write detections themselves. An agent can perform this work continuously, for every customer, tuned to each environment's unique threat landscape.

This capability depends on the same architectural properties. Without transparent reasoning, an agent's output cannot be reviewed. Without atomic adaptation, an agent cannot meaningfully tailor coverage to a specific environment. Without fast iteration, an agent has no feedback loop.

The next post examines this relationship in detail: how the distributed detection model serves as a foundation for AI agents, what those agents look like in practice, and why the architecture determines the ceiling for what agents can accomplish.