From Distributed Detection to Agentic Systems

The first three posts in this series developed a structural argument. A Centralized Detection Model (CDM) imposes structural limits on sensitivity, precision, Mean Time to Coverage (MTTC), and transparency. The Distributed Detection Model (DDM) resolves those limits by delivering three outcomes (local adaptation, fast iteration, and transparent reasoning) plus an emergent fourth, sharable detection logic. That architecture turns out to be the foundation for AI agents capable of genuinely useful work, driving the shift from AI as a classifier to AI as an operator, as demonstrated by ADÉ and ASA.

Those two agents handle detection engineering and triage/investigation, and they demonstrate what becomes possible on this architecture. But they are only the beginning.

This final post examines where we believe this is heading.

4.1 A Changed Threat Landscape

For most of the history of email security, the economics of attacks were constrained by human limitations. Crafting a convincing BEC email required a skilled operator who had studied their target. Building phishing infrastructure required technical knowledge and sustained effort. Running campaigns at scale required coordination and resources. These constraints imposed a tradeoff: attackers could pursue volume or sophistication, but rarely both at scale. Defense architectures were designed against that reality, since sophisticated attacks were comparatively rare and high-volume attacks were comparatively crude.

Those constraints have weakened significantly. Large language models enable convincing, personalized social engineering at scale, collapsing the tradeoff between volume and sophistication. Phishing kits that previously required genuine development effort can now be produced on demand. Campaigns that were once artisanal are becoming industrial.

Defenses have not adapted to this new landscape. Most email security products, whether built on ML from inception or retrofitted with it later, continue to operate on the same fundamental architecture: centralized detection, vendor-mediated reasoning, and high Mean Time to Coverage. Products have become incrementally better at detecting current attack patterns. But offense has made a categorical leap while defense has made incremental improvements, and the gap is widening. This asymmetry is unlikely to close through incremental vendor effort. For a product whose engineering, operations, and pricing are all built around centralized deployment, moving to a distributed model is not a feature addition, it is a different architecture end to end.

It is worth addressing a counterargument: if AI capabilities continue to advance, won't sophisticated AI-on-everything eventually close the architectural gap? We do not believe it will. AI improves capability on both sides at once; it raises the absolute level of attack and defense without shifting the relative advantage between them. Anthropic's Claude Mythos Preview is a live example. Used by roughly 50 partner organizations under Project Glasswing, Anthropic reports it has surfaced more than 10,000 high- or critical-severity vulnerabilities in widely-used software, over 90% independently validated as true positives, including a flaw in wolfSSL, a cryptography library used by billions of devices, that would have let an attacker forge certificates to impersonate a bank or email provider. Anthropic frames the effort explicitly as a race to secure critical infrastructure before comparably capable models can be turned against it, an acknowledgment that the same capability class cuts both ways. It does not, on its own, shift the advantage. That advantage comes from what AI does not give both sides equally: deep, per-organization knowledge and adaptation at the granularity of individual decisions. What ultimately separates the two sides is the feedback loop: which side can observe, learn, adapt, and act on its own environment fastest. A centralized model has no per-organization feedback loop.

This is what makes tailorability the architectural variable that matters. In CDM, tailoring happens at the threshold or baseline level. In DDM, tailoring is atomic: per decision, per exclusion, per agent instruction, per environment. As AI improves on both sides, this asymmetry sharpens, not flattens.

We believe this asymmetry will become increasingly untenable as AI continues to evolve. Defending against the escalation with a centralized model places security teams at a structural disadvantage: high MTTC, vendor-mediated reasoning, and no surface for agents to engineer coverage per-organization.

This pressure is sharpest against AI-generated spear phishing. Highly personalized, low-volume messages crafted for a specific target are precisely what a globally tuned model is weakest against: each one is rare in aggregate, generates little cross-tenant signal, and seldom crosses thresholds calibrated to population-level noise. The attacks that most depend on per-organization context are the ones a centralized model is least equipped to catch.

The required response is architectural rather than incremental. The industry needs a detection architecture that agents can engineer on: one that adapts per organization, produces verifiable reasoning, and can close coverage gaps in hours rather than weeks or months.

4.2 A Team of Specialized Agents

ADÉ and ASA demonstrate what agents can do on a distributed detection architecture. They address two of the highest-impact workflows in email security, but the same architectural properties apply to many others.

The following describes how we think about the agents that come next.

Proactive threat hunting. Threat hunting is something most security teams value but cannot perform as often as they would like, given competing operational demands. Most threat intelligence remains focused on post-detonation indicators: C2 IP addresses, malware hashes, post-click URLs. In email security, however, detection occurs left of boom. The email itself is the evidentiary artifact, and the indicators that matter are native to the message: sending infrastructure fingerprints, authentication patterns, display name templates, HTML structural signatures, URL path patterns. Individual indicators are rarely discriminative on their own, but combinations form durable campaign fingerprints that persist across infrastructure rotation. A threat hunting agent could operate continuously, clustering these signals across an organization's message history, identifying campaign patterns that no individual detection would surface, feeding findings to ADÉ for targeted detection creation, and initiating incident-response workflows where warranted.

Metrics and reporting. Security teams spend a disproportionate amount of time extracting data from their tools for reporting purposes. The industry standard response is a static reporting dashboard, but reporting has a long tail: different organizations, teams, and executives have different questions, and no fixed dashboard can cover all of them. Questions such as "show me BEC attempts targeting employees who joined in the last 90 days," "compare detection volume before and after we deployed our new DMARC policy," or "what percentage of user reports from the engineering org turned out to be malicious versus graymail" typically require manual data exports and spreadsheet analysis.

A reporting agent could address this long tail in two ways. Reactively, it could provide a conversational interface to the organization's email security data, answering natural language queries with structured visualizations, tables, and exportable data. Proactively, it could surface significant findings without being asked: a spike in credential phishing targeting a specific department, a previously unseen sender domain generating unusual flagging volume, shifts in the threat posture that security managers should be aware of. It could also deliver regular reports to stakeholders automatically. This capability addresses a real source of operational friction, particularly for security managers who must regularly communicate program effectiveness to organizational leadership.

Autonomous operations management. A distributed detection architecture works well out of the box, with the vendor providing comprehensive default coverage. Beyond that baseline, an operations management agent can continuously refine the deployment on the customer's behalf: tuning detection thresholds to the environment, promoting high-precision detections to automated enforcement, consolidating overlapping detections, and adjusting agent configurations over time. It would begin in advisory mode, surfacing recommendations with evidence, and organizations could extend its autonomy as they build confidence in its judgment. These gains accrue automatically rather than requiring ongoing manual effort.

The significance of these agents lies not in any individual capability but in how they function as a coordinated team. A threat hunting agent identifies a campaign pattern emerging across the threat landscape. ADÉ proactively writes new detections targeting its techniques. When an instance of the attack arrives, ASA triages it with context from the threat hunt. As the attack evolves, ADÉ iterates on those detections. The operations management agent monitors their performance and optimizes them as empirical data accumulates. Each agent improves the effectiveness of the others, and each cycle of the feedback loop makes the organization's defenses more precise.

The human security team's role in this model expands. Rather than spending the majority of their time on repetitive operational work, they can focus on the higher-judgment tasks that drew them to security in the first place: investigating novel threats, making strategic decisions about risk tolerance, and ensuring the system reflects their expertise and priorities. The human does not become less important. Rather, a small team working with a system of specialized agents gains the detection engineering and response capacity of a team many times its size.

4.3 Applicability Beyond Email

The argument presented across this series is specific to email security, but the analytical framework is not. The CDM/DDM spectrum applies to any domain in which detection and prevention exist. Our direct experience is in email, so the observations below are offered with appropriate humility about our depth in adjacent domains.

Endpoint detection has moved partway along the CDM/DDM spectrum. Major EDR vendors offer query languages for customer-written custom detections: KQL in Microsoft Defender XDR, FQL in CrowdStrike Falcon, STAR in SentinelOne. This supports per-organization adaptation in a way centralized email security has not. But the vendor's proprietary detection methodology remains centralized, and the customer cannot independently verify or modify the underlying reasoning. The full set of DDM outcomes has yet to emerge in EDR.

Cloud security shows a similar partial pattern. CSPM and CNAPP vendors typically offer custom policy languages that let organizations define environment-specific policies, but the vendor's proprietary detection and risk-scoring logic remains centralized and opaque. Security Information and Event Management (SIEM) platforms sit further along the spectrum already: query languages like Splunk's SPL or Microsoft Sentinel's KQL let security teams write, test, and version fully custom detection logic, closer to DDM's outcomes than most native email security products achieve. But the underlying platform's built-in detection content, and how transparently its logic is exposed, still varies by vendor.

When evaluating detection and prevention products in any domain, these are the diagnostic questions worth asking:

• Can the reasoning behind decisions be independently verified, or is the customer dependent on what the vendor exposes?
• Can the system's behavior be adapted per organization at the granularity of individual decisions, or only at the threshold or baseline level?
• Can new coverage be deployed in hours, or only on the vendor's update cycle?
• Is detection knowledge sharable across the security community, or locked inside the vendor?

The vendors in each domain that move toward transparent, composable detection languages will be the ones where agents produce the most value. A more sophisticated AI model improves the quality of what an agent can produce, but the architecture determines the kinds of work possible at all. Vendors that remain centralized and opaque will find that agents are limited to describing problems rather than solving them.

This is not a projection about a distant future. The enabling technologies exist today. The architectural patterns are proven in production environments. The question is which vendors and which domains will adopt them first.

4.4 Conclusion

We began building Sublime with a specific conviction: that email security needed to be transparent, composable, and adaptable per organization. That conviction led to MQL, the Message Data Model, and the distributed detection architecture described across this series.

What we did not fully anticipate was how that architecture would become the foundation for something considerably larger. When we designed MQL, we were thinking about human detection engineers. It turned out we were also building the substrate for AI agents to perform detection engineering, security analysis, threat hunting, and operations management.

The transition from centralized to distributed detection is not merely a change in how a security product functions. It is a change in what a security product can be. In a centralized model, the product is a service to be consumed. In a distributed model with agents, the product is a team that works alongside the security organization: adapting to its environment, strengthening its defenses continuously, and remaining transparent and inspectable throughout.

We believe every detection and prevention domain will eventually make this transition. The architectural advantages are too significant, and the agent capabilities they enable are too valuable, for the industry to remain where it is. The vendors and practitioners who move first will accumulate a compounding advantage that grows with each iteration of the feedback loop.

Detection architecture is the quietest variable in the security industry, and the one with the most leverage. The products built on transparent, composable, per-organization foundations will become genuine partners to the teams using them: agents that engineer detection, investigate threats, hunt proactively, and explain their reasoning. The products built on centralized, opaque foundations will continue to produce verdicts. That is the distinction we have spent four posts describing. We believe it is the distinction that will define the next decade of detection and prevention.