Harnessed AI agents are the future of email security. Here’s how Sublime does it

There’s a competing narrative making the rounds in email security: rules are dead, AI has made them obsolete, just get out of the AI model’s way.

That narrative is naive. AI is changing email security, but more capable models do not make testing, visibility, or control obsolete. The question is not whether rules or AI will win. It is how to combine model capabilities with explicit detection logic in a system that can be inspected, evaluated, and corrected when it gets something wrong.

At Sublime, we use a high-speed layer of org-specific, ML-powered detections backed by harnessed AI agents. Both are essential to our architecture. This post focuses on how we build those harnesses and why their design matters.

Agent = model + harness

Capability and authority are not the same thing. An agent may be more than capable of writing a detection rule, triaging alerts, and pushing new policies. That does not mean it should be authorized to do all three. A harness defines what it can do independently, what requires approval, and what it cannot do at all.

A model can be a powerful engine for detection, but it can still produce confidently incorrect answers. It isn’t a silver bullet. A harness makes its output more trustworthy by defining what inputs the model receives, how it should approach the task, and what it can conclude.

Without the right model, harness, and architecture, email security looks like this: opaque verdicts you can’t explain to your CISO, false positives that fire repeatedly, false negatives with long dwell times, and missed detections that take too long to update coverage. This is common in black-box solutions with siloed detection layers that can’t collaborate to share and enrich signals. The right architecture makes detection explainable, correctable within hours, and tailored to your organization. At Sublime, that’s a unified architecture with three parts: a model, a harness around it, and a shared language between harnesses. This post covers each in turn.

Autopilot still needs a yoke

Flightradar24 tracked a record 153,359 commercial flights on a single day in July 2026. Consider how modern jets fly on autopilot for the vast majority of every trip. A Cranfield University study of 14,000 flights found that pilots hand-flew for just minutes. That’s not a design flaw. Automation beats humans at sustained, routine precision.

But every jet still has a yoke because automation has an edge only when it focuses on what it was built to handle. In October 2002, Northwest Airlines Flight 85 was cruising on autopilot when its lower rudder went hard over, sending the 747 into a sharp bank. The crew reverted to manual controls and adapted their techniques to counter the malfunction, regain control, and land safely. The lesson isn’t that automation is bad. It’s that resilient systems need backup controls and skilled humans or agents trained to take over.

Email security has a similar limit, and attackers look for it. In 2024, Guardio Labs uncovered a campaign that sent millions of spoofed emails impersonating brands like Disney, Nike, and IBM by relaying them through a widely used email security gateway. The messages carried valid SPF and DKIM signatures, so authentication couldn’t separate them from real mail, and researchers didn't catch the campaign until months later. The attackers didn’t need to beat a model. They found where trust signals stop being reliable.

In email security, the harness is the yoke: the structure that lets an analyst or agent see what the model relied on and take over. Yet a harness that only restricts isn’t enough. The right architecture needs a control language so analysts or agents can document what they see today, recognize what they don't, and evolve it into automated detection tomorrow, because misses happen.

What happens when it fails

Every security practitioner knows no solution catches everything. Every system produces false positives and false negatives. The question is: how is the architecture designed to close coverage, what happens after a miss, and what does it cost?

A verdict is not an audit trail. AI is imperfect, and when an agent gets something wrong, its output, even its chain-of-thought, is not enough to fully investigate a failure. You need a record of the input, any additional context it received, the tools it called, and any actions that took place. Those traces should come from the harness, not just from the model’s own account. The ability to reconstruct the failure, understand its blast radius, and determine what needs to change or rollback is table stakes.

With a transparent, controllable harness, an analyst or agent sees exactly which signals fired, edits the logic, and deploys the fix within hours. With legacy black-box solutions, the path is a support ticket, and priority decides the wait. A missed threat (false negative) may get high priority and a faster turnaround (24 hours). A false positive rarely does. It can take 7 days, sometimes up to 60, and keeps firing the whole time.

Let’s do the math on two representative cases: First, five recurring false positives, each firing daily and taking 20 minutes to review. Over a 60-day ticket window, that’s roughly 100 hours of analyst or agent time spent confirming the same non-threat. Fixing all five, by contrast, takes a few hours, once. Controls don’t create work. They move it from recurring and reactive to bounded and one-time.

Second, take a missed attack. Through a vendor ticket, coverage may take a day or more. With our harness, ADÉ drafts and backtests a rule in a couple of hours. Every hour in between is exposure: more mailboxes reached, more chances for a click. It takes an agent time to analyze it, create coverage, backtest, and design against similar future attacks. Without the proper harness, the path to coverage begins once it's identified and submitted via support tickets, potentially adding  a day or more of dwell time, plus potential data exfiltration, lateral movement, or whatever malicious actions the attacker chooses. With the right harness, an agent can generate coverage automatically, reducing exposure to hours and potentially preventing significant remediation work and losses from longer exposure. Again, the harness controls aren’t making work; they’re preventing more work and mitigating losses.

What a harness looks like in practice at Sublime

“Agentic AI” gets talked about as if the model is the product. In practice, it’s the smaller part of what ships. A harness is software engineering, not prompt engineering, and it comes down to five components:

• Runner: the entry point that orchestrates each call
• Prompts and templates: the system-level instructions, framing, and output shape
• Knowledge base: the domain-specific documents the model reads at inference time
• Tools: what “access” the agent has to non-LLM code, data/APIs, and subagents.
• Eval and CI gates: a standardized test to measure the impact of change to the harness or model.

Prompts and the runner shape how it reasons, the knowledge base and tools set what it sees and can do, the output schema limits what it can conclude, and eval gates check the result.

An instruction is not an enforced boundary. Prompting an agent not to take specific actions is vastly different from preventing it from accessing or executing certain tools. In email security, that distinction is critical because an agent may examine attack-controlled inputs. These instructions are designed to manipulate model decision-making and cause the agent to take unwanted actions. Therefore, the harness is necessary to enforce permissions and approval gates outside of the model itself. The last thing we want is a mistaken verdict or a manipulated response that grants the agent authority it was never explicitly given.

We build ours on that skeleton, in two different shapes today. ASA, our Autonomous Security Analyst, is a classification harness. A message goes in, and a verdict comes out. It’s single-shot and stateless, with a compact knowledge base built around a labeling guide and known false-positive patterns. Any change to the code, templates, the model, or those documents triggers a benchmark run against held-out data, and a regression beyond a set threshold blocks the change.

ADÉ, our Autonomous Detection Engineer, is a generation harness. It takes an ASA report, runs a multi-turn loop with tools and subagents, and iteratively refines a detection rule. Its knowledge base is much larger because the agent has to write in a domain language, and we evaluate it by comparing generated rules against human-authored references.

Different agents, same scaffolding. That symmetry is deliberate: once you have a pattern, you can stamp out more harnesses.

MQL: the contract between harnesses

A single-agent harness works alone. Multi-agent systems can solve harder problems, but only if the handoff between agents is reliable. If ASA handed ADÉ a paragraph of English, ADÉ would have to re-interpret intent, errors would compound, and you’d lose the ability to audit or tweak anything along the way.

That's the job of MQL, our Message Query Language. It’s a domain-specific language built for email detection, and it serves as the shared protocol between our harnesses. ASA’s findings flow to ADÉ, and ADÉ’s output is an MQL rule: transparent, readable, deterministic, and durable. A deterministic output schema lets one harness hand off to another cleanly, in a way that’s maintained, auditable, and not subject to drift or misinterpretation.

In fact, industry has already voted on this. CrowdStrike, Microsoft, Palo Alto Networks, Splunk, and Elastic all built specialized languages, giving their products explainability and analyst controls, because opaque AI wasn’t operationally sufficient.

Evaluate the system, not just the model

Model accuracy is table stakes. The more difficult  question is whether the agent completes its task reliably when conditions change. Recognizing an attack in a benchmark is different from handling an unfamiliar variant in production or a failed tool call. Evals need to test the complete workflow under those conditions, not just score the model’s final answer.

Evaluation therefore has to go beyond correct answers.

• Does performance hold across different messages and over time?
• Can attacker-written content manipulate the verdict or trigger an unauthorized action?
• When the agent makes a mistake, do safeguards contain the impact or allow the error to propagate?

The more consequential the action we delegate, the stronger the evidence we need.

Learning makes this harder. A harness can incorporate analyst corrections without a full retraining cycle, but adapting is not the same as improving. We need to measure whether a correction fixes the intended failure without degrading performance elsewhere. We’ve done research on exactly this question. If you want to learn more, check out our blogs.

What a harness unlocks for AI agents

Put a well-built harness and a deterministic contract together, and a few things become possible:

• Agents can compose without ambiguity. One agent’s output is the next agent’s input, with no re-interpretation in between.
• New models can be evaluated honestly. When a frontier provider ships a new model, we don’t guess whether it’s better for your task. We run it through the harness, score the output against the benchmark, and let the CI gate tell you. Same knowledge base, same eval set, different model. The deterministic output contract is what makes that comparison apples-to-apples.
• New agents plug into the same pipe. A new harness that speaks MQL can join the pipeline.
• Humans can read and tweak agent output directly. An MQL rule isn’t a black-box verdict. It’s logic an analyst can inspect and edit.

The model is the easy part. The harness is the engineering. The contract between harnesses is the architecture. Sublime’s bet is to invest in all three.