The Centralized Detection Model and Its Limits

Over the past two years, the economics of offensive cyber operations have fundamentally changed. Large language models let attackers produce convincing, personalized social engineering at scale and spin up infrastructure on demand, collapsing the old tradeoff where an attacker could have volume or sophistication but rarely both. Vendors have improved too, but incrementally: better models, richer signals, all layered onto the same architecture the industry has relied on for years. This series uses email, the most common initial access vector, as a running example, but the argument generalizes to detection and prevention broadly.

That widening gap is the reason for this series. We think the deciding factor is not whose models are better, but the detection architecture underneath: who owns the detection logic, who can see it, and how fast it can change. Specifically, we think the industry is shifting from centralized detection, owned end to end by the vendor and deployed uniformly, to distributed detection that is transparent and adapts to each organization's environment. And that shift, more than any single model, is what decides whether AI shows up as one more classifier bolted onto the old design, or as an operator that can genuinely investigate, engineer, and improve a program's defenses.

We make that case across four parts:

• Part 1: the centralized model most products share, and the limits that follow from it.
• Part 2: distributed detection as an alternative, and what it takes to build.
• Part 3: why that architecture, not the underlying models, sets the ceiling for what AI agents can do.
• Part 4: where this leads, from a changed threat landscape to security teams working alongside systems of agents, and why the same pattern applies across security domains beyond email.

These are written as an argument the industry can weigh on its merits rather than a product pitch. We build in this space, so we hold a view, and we'd rather have it stress-tested than politely agreed with. If it holds up, the architecture beneath these systems will shape the future of security more than any single model will.

1.0 The Centralized Detection Model and Its Limits

The detection and prevention industry has invested heavily in better technology over the past decade, and email security is no exception. ML models have become more sophisticated and threat research teams have grown. Yet the complaints from security teams have remained remarkably stable: attacks that get through (false negatives), false positives that can't be resolved without creating new blind spots, and weeks or months-long waits for vendor updates.

We believe the reason is architectural. Nearly every email security product on the market, despite significant differences in technology and approach, follows the same structural pattern. The vendor builds and maintains a detection pipeline and deploys it uniformly across their full customer base. We refer to this approach as the Centralized Detection Model (CDM).

CDM is understandably the dominant architecture. It is operationally efficient for the vendor: one pipeline to build, one set of metrics to optimize, one QA process before each update ships. It scales predictably. But the operational efficiency that benefits the vendor comes at the cost of detection effectiveness for the customer. We believe there are structural limitations inherent to the centralized approach that become more pronounced as attack sophistication increases and as organizations' email environments diverge. These limitations are not implementation failures. They are predictable consequences of requiring a single detection system to perform well across all customer environments simultaneously.

To illustrate the dynamics at play, consider a scenario that most security teams will recognize. A Business Email Compromise (BEC) variant that the organization hasn't encountered before lands in an executive's inbox. An employee reports it, the security team investigates, confirms it's malicious, and reports it to their email security vendor. A few days later the vendor acknowledges the report. Weeks (or sometimes months) after that, they push an update. In the meantime, the same campaign has hit several more employees, and the stopgap mail flow rule the team wrote to contain the damage (probably a sender blocklist entry) was either too narrow and missing the campaign’s variants, or too broad and blocking legitimate email. By the time the vendor's update ships, it addresses yesterday's problem, not today's.

The speed of the fix tracks the breadth of the attack. A technique that hits many organizations at once is identified and patched relatively quickly; one that hits only a handful moves down the queue; and an attack tailored to a single organization may never warrant a dedicated update at all. The more targeted the attack, the longer the customer waits.

This sequence is not evidence of vendor negligence. The vendor's ML models may be state-of-the-art and their threat research team may be highly capable. The issue is that the architecture underneath constrains their response in ways that are difficult to overcome regardless of investment in those areas. When a detection system must be validated across thousands of tenant environments before it can be updated, fix timelines can stretch to weeks or months, not hours or days. When the same detection logic must work for a 50-employee school district and a 50,000-employee financial institution, sensitivity thresholds are necessarily a tradeoff.

We propose that these tradeoffs exist on a spectrum. On one end, the Centralized Detection Model, where detection logic is owned and operated entirely by the vendor, deployed uniformly, with limited customer visibility or participation. On the other end, what we call the Distributed Detection Model (DDM), where detection logic is transparent, composable, and adaptable per organization, with the vendor providing both a platform and comprehensive default coverage. Adaptation is available to organizations that want it, not required of those that don't.

This is not a binary classification, and we want to be precise about that. In principle, any vendor could sit anywhere along this spectrum. Some products do adapt their behavioral models per tenant. But the detection methodology itself, the logic that determines what constitutes a threat and why, remains centralized in virtually every product on the market. Customers may see vendor-provided explanations of why a specific detection fired, but the reasoning cannot be independently verified, signal composition cannot be modified, and environment-specific gaps cannot be closed outside the vendor's global update cycle.

We focus on detection because, in email security, prevention follows directly from it: the detection verdict is what determines whether a message is delivered, quarantined, or blocked, so the architectural limits on one are the architectural limits on the other.

The remainder of this post examines four structural limitations that follow from centralized detection architectures, and how they interact to create compounding effects over time.

1.1 Structural Limitations of Centralized Detection

The limitations described below follow from the architectural constraints of centralized detection itself, not from any particular vendor's implementation. A system that must deploy uniform detection coverage across all customer environments will exhibit these properties to varying degrees, regardless of the sophistication of its underlying models.

1.1.1 Detection sensitivity ceiling

In a centralized architecture, the underlying detection logic must perform acceptably across the vendor's entire customer base. Detection mechanisms that would be too aggressive in some environments must be tuned conservatively to avoid false positives multiplied across thousands of tenants. The cost of a noisy detection at scale is, from the vendor's perspective, significantly higher than the cost of a missed attack at the few customers where it would have been valuable.

The most common form of adaptation centralized vendors offer is also the shallowest: a sensitivity threshold on a global verdict score that a customer can dial up or down. Some go further with per-tenant behavioral baselines, which calibrate thresholds against each customer's observed traffic. Either way, the underlying detection logic remains globally trained; only the thresholds vary by environment.

The deeper constraint is that some environments need fundamentally different detection logic, not just different thresholds on the same logic. A financial services firm facing specific ACH fraud patterns, or a healthcare provider with HIPAA-targeted impersonation concerns, gets a globally-trained model with their behavioral data layered on top. They never get detection logic built specifically for their environment and threat model.

The underlying constraint is straightforward: a globally-trained detection layer, even with per-tenant calibration, cannot be optimal for every organization.

1.1.2 False positives and global allowlisting

When a centralized detection fires incorrectly, the customer's primary mechanism for resolution is the allowlist: marking a sender, domain, or IP address as globally safe. Allowlists are inherently coarse instruments. They do not express "this sender is safe in the context of this specific detection." They express "this sender is safe across all detections." This bluntness is not unique to allowlists: most of the controls a centralized system exposes to customers (a global sensitivity threshold, a sender or domain allowlist, a category toggle) act on broad inputs rather than on the specific detection or decision that misfired.

Broad allowlisting progressively widens the attack surface. The most concerning failure mode is what might be called the allowlisting spiral: a domain is allowlisted because it triggered a false positive, that domain is later compromised, and the attacker's messages bypass all detection because the domain is globally trusted.

The architectural constraint here is the absence of addressable detection units. In a centralized system where detection logic is not exposed as discrete, identifiable detections, there is no mechanism for scoping an exception to a specific detection. The customer can either trust the sender globally or tolerate the false positive. More precise resolution requires either detection logic decomposed into addressable components, or an equivalent mechanism for scoping exceptions at the level of individual decisions.

1.1.3 Mean Time to Coverage (MTTC)

The security industry measures Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR) for individual incidents. But there is no standard metric for the interval between a new attack technique emerging and the detection system being updated to cover it. We refer to this as Mean Time to Coverage (MTTC).

When a novel attack technique emerges, the centralized response path involves several sequential steps: the vendor identifies the technique, develops a detection or model update, validates that it  will not produce false positives across a diverse set of customer environments, validates that it will not introduce regressions to existing coverage, iterates as necessary, and finally deploys the update. This process typically requires days, weeks, or even months, because the vendor is deploying a single update to all customers and must be conservative about unintended effects. MTTC is unacceptably high.

The resulting asymmetry favors the attacker. An attacker needs only to identify a pattern that bypasses the current centralized coverage. Once identified, that pattern is effective against other customers simultaneously, and remains effective until the vendor completes their update cycle. The vendor's MTTC becomes the attacker's window of opportunity.

It is worth noting that this latency is not primarily a resourcing problem. Even a well-staffed vendor with excellent threat research capabilities faces the same constraint: global deployment requires global validation, and global validation takes time and iteration.

1.1.4 Reasoning the customer cannot independently verify or modify

In most centralized products, 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 these are explanations, not provenance. The customer is consuming what the vendor has chosen to expose, not an auditable record of the evidence, model outputs, and decision logic that produced the verdict.

This creates two related problems:

• Security teams cannot independently verify that detections behave as expected in their specific environment. They can review what the vendor surfaces, but they cannot trace any decision back to its full set of inputs without the vendor's cooperation.
• When a decision is incorrect, teams cannot diagnose or remediate it independently. The available remediation is a support ticket and a wait for the vendor to investigate, or a global allowlist that weakens detection elsewhere.

ML-driven detection pipelines have shaped this dynamic in subtle ways. Some make significant effort to surface explanations: contribution weights, similar past decisions, natural-language summaries. But the explanation, however thorough, is still a vendor-mediated view of a process the customer cannot inspect, audit, or change. The customer's relationship with the system remains passive.

This is not a deliberate choice by vendors. It is a structural property of architectures where the entire detection layer is owned and operated by the vendor and treated as a trade secret. The customer can only see and act on what the vendor exposes. Because the customer cannot see which component of the reasoning failed, they cannot correct that component. They can only suppress the outcome it produced, a blunt instrument that trades one error for another.

1.2 Compounding effects

These four limitations do not operate independently. They interact in ways that create a reinforcing cycle.

The detection sensitivity ceiling means that some attacks will bypass the system. High Mean Time to Coverage (MTTC) means those attacks will continue to bypass the system for days or weeks while the vendor develops and validates an update. During that window, security teams compensate by creating broad allowlist entries to contain the immediate threat, which erodes the detection surface and introduces new blind spots. Those blind spots effectively lower the detection ceiling further. And because the customer's view into how decisions are made is vendor-mediated, the compounding cycle is hard to diagnose.

This compounding dynamic may explain a pattern that many security practitioners have observed: switching from one CDM vendor to another often produces a different set of specific gaps but the same categories of frustration. The particular attacks that get through will differ. The particular false positives will differ. But the structural failure modes (sensitivity compromises, coarse exception handling, response delays, and limited visibility) persist because the architecture that produces them is the same.

1.3 Looking forward

The limitations described in this post are not quality problems that can be improved incrementally. A more sophisticated ML model does not resolve the sensitivity ceiling, because the ceiling is imposed by the requirement to deploy uniformly. A larger threat research team does not resolve response latency, because the latency is imposed by the requirement to validate globally. Better explanations from the vendor do not change the customer's passive position; the customer is still consuming a vendor-mediated view of a process they cannot inspect or modify.

Resolving these limitations requires a different architecture: one where the system can be adapted to each environment beyond what the vendor ships globally, false positives can be resolved with precision scoped to individual detections rather than applied globally, response time is decoupled from the vendor's global update cycle, and customers can independently verify the reasoning behind decisions.

The next post in this series describes that architecture in detail: the Distributed Detection Model (DDM), and the design choices that make it work in practice.

‍