Does your programme see what attackers see?

Most security programmes are stronger on discovery than validation. The Exposure Maturity Model identifies exactly which dimension is holding your programme back.

No items found.
Threat Trends
-
7
mins read
-
July 7, 2026

Forget the Frontier Model: The Harness Is Where the Product Lives

Muneeb Zafar
-
Solutions Architect
- -
Forget the Frontier Model: The Harness Is Where the Product Lives

Earlier this year I gave a talk at Infosecurity Europe 2026 about human-guided AI adversaries and what it takes to safely put a capable model to work in offensive security. Twenty minutes was enough to make the argument, but nowhere near enough to unpack the engineering underneath it. This is the version I would have given with another half hour: less stagecraft, more detail, and a closer look at where the durable value in agentic systems actually sits.

The timing since the talk has been almost suspiciously neat! Cloudflare published the architecture behind its own vulnerability harness. Anthropic released research on how people actually use coding agents. Source-level analyses of production agents showed that the visible model loop is a thin sliver of the whole system. Then Fable 5 launched, vanished under a US government export control directive, and came back on 1 July 2026 with new safeguards. Each of those points the same way.

Frontier capability in cyber has crossed a practical threshold. Models can now do enough reconnaissance, code analysis, vulnerability discovery and exploit reasoning that the bottleneck has moved elsewhere: controlling what the model is allowed to do, holding context across long-running work, verifying what it claims to have found, and knowing when to hand a decision back to a person. That surrounding system is the harness. It is where the product lives, and I increasingly think the moat lives there too.

The bottleneck has already moved

A lot of security teams still discuss AI as though the main question is whether a model can find vulnerabilities. In its first update on Project Glasswing, Anthropic said roughly fifty partners had used Claude Mythos Preview to identify more than ten thousand high or critical severity vulnerabilities across important software. Its own scan of more than one thousand open-source projects flagged an estimated 6,202 high or critical issues, and of the 1,752 findings later assessed by independent security firms, 90.6 per cent proved to be valid true positives.

The line that matters the most within the first update is as follows: 

progress on software security used to be limited by how quickly we could find new vulnerabilities, and is now limited by how quickly we can verify, disclose, and patch them. — Anthropic, 2026

That is the verification crisis in a sentence. More findings do not automatically make software safer. They can make the backlog worse, because unverified output is cheap to produce and expensive to disprove. Some open-source maintainers, already buried under low-quality AI bug reports, asked Anthropic to slow down disclosures because they could not triage them fast enough.

A few weeks later, Anthropic expanded Glasswing to about 150 more organisations across more than fifteen countries in its second phase. Many of these participants are tied to critical infrastructure, with access gated by strict security requirements and US government approval. In this phase, the emphasis moves downstream from finding weaknesses towards verifying them, writing fixes and shipping patches.

OpenAI is heading the same way from the policy side. Cybersecurity in the Intelligence Age frames the next phase around widening access to AI-powered defence while keeping control of frontier cyber capability, and Trusted Access for Cyber is more direct still: vet the defender, then lower the classifier refusals that otherwise block legitimate work like vulnerability research. This is a more mature conversation than which model scored highest this week. It is about access, evidence, safe execution, telemetry, patching capacity, and who is accountable when the system gets something wrong.

This is a thread I have been pulling on for a while now. In Beyond EPSS I argued that exposure management has spent years getting better at listing things that might matter, when the harder problem is proving which ones actually matter in the environment you are defending. In From MCP to Secure MCP and The Authority Layer I followed what happens once models can reach tools, identities and shared state. AI accelerates both sides of the equation. It makes discovery cheaper, and it makes unverified output cheaper too.

Fable 5 made model dependency impossible to ignore

Fable 5 and Mythos 5 are the same underlying model. The difference is the operating envelope around it. Fable 5 launched for general use with safety classifiers, fallback routing and a stricter envelope around cyber, biology and model distillation, with flagged requests routed to Opus 4.8 instead. Mythos 5 exposed more of the underlying cyber capability to a small set of trusted Glasswing defenders.

Then, on 12 June 2026, the US Commerce Department issued an export control directive requiring Anthropic to cut off access for any foreign national, anywhere. Because you cannot verify nationality in real time across every cloud, Anthropic disabled both models for everyone, whilst every other Claude model stayed up.

We should focus on the trigger here, because as per Anthropic's own account, this stemmed from a report from Amazon researchers who bypassed a Fable 5 safeguard by prompting it to identify software vulnerabilities, and in one case got it to produce code demonstrating exploitation. Anthropic's testing then found that weaker, widely available models could do the same. Opus 4.8, GPT-5.5 and Kimi K2.7 identified the same vulnerabilities, and every model tested, including Haiku 4.5, reproduced the single exploit demonstration. The reported technique exposed no unique Mythos-level capability. It was a borderline case for a deliberately cautious classifier, and the behaviour behind it was routine defensive work.

On 30 June 2026 the controls were lifted. Fable 5 returned globally on 1 July 2026 with a retrained classifier that blocks the reported technique in more than 99 per cent of cases, and Mythos 5 access was restored to a set of US organisations after government approval on 26 June 2026. Anthropic is also working with Amazon, Microsoft, Google and other Glasswing partners on a shared framework for rating jailbreak severity, scored on capability gain, breadth, ease of weaponisation, and how quickly a bypass could become a real-world problem.

Whilst the outage is over, we still need to recognise the lesson behind it. The model did not change across those three weeks whilst everything around it did: access policy, regulatory treatment, classifiers, fallback behaviour, and availability twice over. A product welded to that one model would have inherited every disruption. A product built around a model abstraction could route work elsewhere, degrade gracefully, hold its state, and move the task back when access returned. Those starting their journey in harness engineering can already spot the difference.

The government is now part of the model supply chain

As with every good story, the Fable episode was not a one-off. On 2 June 2026 the White House issued Executive Order 14409, setting up a voluntary framework in which developers can give the government access to a "covered frontier model" for up to thirty days before releasing it to trusted partners, and can coordinate on which defenders get early access. The order is explicit that this is not a mandatory licensing regime. Even so, government evaluation, export controls and national security review have plainly entered the model deployment lifecycle. OpenAI's latest release shows the same pattern: on 26 June 2026 it previewed GPT-5.6, led by Sol, and at the government's request could only open the models to a small group of vetted partners before a wider rollout. Tellingly, OpenAI built its safeguards into the model's behaviour rather than bolting a classifier on top, reading as a direct response to the false-positive backlash Fable's routing produced.

For anyone building on frontier models, they are seeing this as a new dependency. The best model for a task may be unavailable in a given country, restricted to a class of organisation, or delayed while safeguards are reviewed. You do not have to hold an opinion on the policy to account for it in your architecture. Availability is now partly a policy variable.

The harness is the product, and there is now hard evidence for it

A provocative claim did the rounds recently: Claude Code is 98 per cent not AI. It comes from Dive into Claude Code, a source-level analysis of the public TypeScript codebase. I would not treat the exact figure as a law, since it is a community estimate and code volume is a rough proxy for value. However, the architectural point it makes survives regardless. The core agent is a thin loop: assemble context, call the model, parse tool requests, check permissions, execute approved actions, and feed the result back. Almost everything else is engineering wrapped around that loop, a deny-first permission system, a layered classifier and hook system, a multi-stage context pipeline, session persistence, tool routing, sandboxing, and recovery when calls or sessions fail. The model proposes, but the harness decides what can happen. It cannot touch the filesystem, run a shell command or make a network request directly. It emits a structured request, and the surrounding system checks policy before anything reaches the execution environment.

A stronger paper landed in April 2026. Synthesizing Multi-Agent Harnesses for Vulnerability Discovery, from UC Santa Barbara and Fuzzland, holds the model fixed and varies only the harness, the code that decides which agents exist, what each may call, and when they retry. Changing only the harness moved success rates several-fold on public benchmarks. Their system, AgentFlow, reached 84.3 per cent on TerminalBench-2 and found ten previously unknown zero-days in Google Chrome, including two critical sandbox escapes (CVE-2026-5280 and CVE-2026-6297). These CVE results should stay with you and make the case: those Chrome findings were produced with Kimi K2.5, an open-weight model, wired into the right harness. Capability is increasingly a commodity, whilst the orchestration around it is not.

Cloudflare's Build your own vulnerability harness article shows the same principle at production scale. Its pipeline treats models as replaceable workers, with one model performing discovery and a different model handling validation, so their weights act as an adversarial cross-check rather than an echo, and state lives in a database so stages resume after failure. The filtering is the whole point: a single repository pass compresses on the order of 100 raw candidates down to about 80 higher-confidence bugs, and across the fleet-wide loop it removes roughly 65 per cent of lifetime candidates. Every confirmed issue must include a proof of concept that runs against the original, untouched code, so the agent cannot edit the source to manufacture a result, and nothing merges into production without human review. As Cloudflare put it, the harness is the bit that lasts. Models change and providers change; the orchestration layer absorbs that volatility.

Verification is the unit of value

By now it should be evident that the human-guided part of this has already made the case, for being key in all of this. In Anthropic's study of roughly 400,000 Claude Code sessions, people made about 70 per cent of planning decisions while Claude made about 80 per cent of execution decisions, and the more domain expertise a person brought, the more the model got done per instruction. That is the right division of labour for offensive security: a strong hacker knows which assumptions are worth attacking and when a minor weakness might chain into something worse, while the repetitive execution around that judgement can be automated. Better still, the judgement can be encoded before a run begins. Human-on-the-Bridge makes this case, moving expert judgement upstream into reusable traps, scoring rules and fallback policy so the harness applies it repeatedly without a person inside every action. Automate the method. Preserve the judgement.

The related mistake is treating wider coverage as the goal. Coverage matters but evidence changes the work required. Anthropic's exploit evaluations separate exploit development into tiers: reaching vulnerable code, reproducing a known issue, building a useful primitive, achieving broader control. Those are materially different outcomes, and security products tend to flatten them into a single label, vulnerable, which throws away the information a remediation team actually needs. A useful evidence object makes clear which component is affected, what the attacker controls, whether the path is reachable in the real environment, what was safely reproduced, how it was independently checked, and whether the fix held on retest.

Cloudflare's pipeline requires a runnable test and a proposed patch. Anthropic's Claude Security attaches repository context, impact, reproduction steps and remediation. The principle is the same across all of them: find what is exposed, validate what can actually be exploited, and return evidence an owner can act on. Confidence is a weak primitive whilst verifiable proof is better. As I put it on stage to the audience:

I do not care how convincing an agent sounds, I care what it can prove.

The harness is also the authority layer

Once an agent can act, the security boundary follows its authority, and that is where most of the interesting engineering actually lives. The controls that matter are not prompt wording, rather they are establishing which identity the agent runs as, which tools it can invoke, which assets it can touch, which inputs are trusted, how far it can go without approval, whether an action is reversible, and what happens when two agents disagree. A model can be fooled by a poisoned input or a confused-deputy setup, and when that happens the boundary around the model is the only thing left doing its job. None of this is specific to security. The same logic governs a coding agent with repo access, a support agent wired to a payments API, or an internal copilot that can move money. The moment a model can act on the world, the engineering problem becomes authority, not intelligence.

Two things make that boundary practical. First, authority has to be explicit and least-privilege by default, so a compromised or mistaken agent inherits as little as possible. Secondly, state and permissions should not migrate silently across sessions or between agents; trust should be re-established when the context changes rather than assumed. Get those right and the underlying model becomes genuinely replaceable, since a better model improves the reasoning without gaining new reach.

Where the moat actually forms

Model quality matters, and I am not going to pretend otherwise. A stronger model finds subtler paths, uses fewer tokens, stays coherent longer and recovers better. Those gains are real and more importantly, increasingly available to everyone. An API can be bought, a benchmark lead can last a few weeks, and a provider can change a limit or pull access overnight, as the last month showed twice. A capable open-weight model can close the gap from below, and a government can change the terms of access from above.

The assets that are harder to copy accumulate somewhere else: methods refined through real use, historical attack and validation data, live environmental context, evidence standards, safe tool interfaces, permission and approval policy, and trust earned through reliable outcomes. That is the beauty of a harness. The newest frontier model can make it better, but it should not be allowed to define the product. The frontier models will change, and are changing as you are reading this. Thus, the harness must survive it.

I work at the intersection of applied AI and offensive security, on turning capable but unpredictable models into systems you can trust: adversarial validation, structured evaluation, and human oversight where judgement still matters. Most of the hard problems live in the boundary rather than the model, in how an agent behaves in the moment, how the wider system behaves once many agents interact, and the accountability that has to hold when you grant autonomy in a high-stakes environment. If you are thinking through those questions for your own security programme, or in general, I would be glad to compare notes. You can find and connect with me on LinkedIn.

{{related-article}}

Forget the Frontier Model: The Harness Is Where the Product Lives

{{quote-1}}

,

{{quote-2}}

,

Related articles.

All resources

Security solutions

A Frontier AI model is not a pentest

A Frontier AI model is not a pentest

Security solutions

Securing the Digital Frontier: Synergizing EASM and Automated Security Testing

Securing the Digital Frontier: Synergizing EASM and Automated Security Testing

Research

Can LLMs improve subdomain enumeration?

Can LLMs improve subdomain enumeration?

Related articles.

All resources

Threat Trends

Attack surface management: how it works and where it fits

Attack surface management: how it works and where it fits

Threat Trends

What is the attack surface in cybersecurity?

What is the attack surface in cybersecurity?

Threat Trends

What does an autonomous pentesting agent actually do?

What does an autonomous pentesting agent actually do?

get a 15 min demo

Start your journey today

Hadrian’s end-to-end offensive security platform sets up in minutes, operates autonomously, and provides easy-to-action insights.

What you will learn

  • Monitor assets and config changes

  • Understand asset context

  • Identify risks, reduce false positives

  • Prioritize high-impact risks

  • Streamline remediation

The Hadrian platform displayed on a tablet.
No items found.