On the AI agent moment, the offence/defence asymmetry, and why a single private vendor making a globally significant security call is both the good news and the bad news.
The pace and the access
I think we are at a strange moment with AI and most of us, including the security community, have not really stopped to look at what is happening around us. The pace has been relentless. Every few months one of the major providers — OpenAI, Google, Anthropic — releases a new model that is, by their own benchmarks, magnitudes more capable than the previous one, and the gap between what was state of the art twelve months ago and what sits inside a free tier today is genuinely uncomfortable to think about. AI has moved from a thing that technical people experimented with to a thing that everyone, technical or not, uses several times a day, often without realising it. That broad accessibility is, on the surface, a good story. It probably is, mostly. But the speed of it is also why most of the consequences are still ahead of us rather than behind us.
Vibe coding and the tool-every-six-hours economy
A year or two ago, the conversation was about “access to a model” — somewhere to ask generic questions, generate a picture, summarise a document, replace a Google search with something that talks back. That framing already feels antique. We have moved into the “vibe coding” era, where powerful coding agents are not assisting software engineering teams, they are increasingly replacing them, producing end-to-end software artefacts from a paragraph of intent. On LinkedIn there is a new “tool” announced every six hours or so, often by people who are not software engineers at all and who, twelve months ago, would not have written a line of code. Some of these tools are genuinely useful. Many of them are a wrapper around an API with a Tailwind landing page and a waitlist. The signal-to-noise ratio is awful, and the volume is the point — the volume is what makes it feel like a movement rather than a market.
The cookies paradox
Now we are in the agentic moment. People are installing private agents on their machines — Claude, Cursor, OpenCode, all the “open claw” variants — and granting them, often by default and often without reading the consent screen, full access to their files, their email, their browser session/shell, their credentials. Many of these agents are open source, which means the supply chain is whatever any contributor can convince a maintainer to merge. Someone on LinkedIn — and I genuinely cannot remember who, if you are the original author and reading this please ping me for attribution — phrased it better than I could. The line was something like:
The same generation that aggressively rejects cookies installs AI agents on their machines and gives them full access to everything.
That resonates with me 110%, because it captures the asymmetry perfectly. We have spent ten years training people to be paranoid about a third-party tracker reading which page they visited, and in the same week those same people are willingly handing an autonomous process root-equivalent access to their inbox and their .ssh directory because the demo on YouTube looked clean.
The strangeness escalates from there. We are now seeing web applications designed not for humans but for AI agents — interfaces with no consideration for visual hierarchy because nothing biological will ever look at them. There are even, and I had to read this twice when I first saw it, “social networks” for AI agents. moltbook.com is the example that did the rounds recently. That escalated quickly. I do not have a strong opinion on whether agent-to-agent social platforms are useful or whether they are a venture-funded curiosity that will disappear in eighteen months. What I do have an opinion on is what their existence tells us about where the centre of gravity is moving. The implicit assumption behind a network for agents is that there will be a non-trivial amount of agent activity worth networking, that agents will be acting independently enough and at sufficient scale that they need their own infrastructure. That is an assumption with very large security consequences and almost no public scrutiny.
Cybersecurity catches the train
Predictably, every cybersecurity service provider on the planet has now pivoted to offering “AI-based” something. AI-powered SOC, AI-driven threat intelligence, AI-enhanced vulnerability management, AI-augmented red teaming. Some of this is real, in the sense that machine learning is genuinely useful for triage/deduplication/anomaly correlation and a handful of other classical problems where it has been useful for the last decade and we just did not put “AI” on the brochure. Some of it is a wrapper around an LLM that summarises a Splunk alert and calls itself a “co-pilot”. The actual question for a buyer is which one you are looking at, and the honest answer is that the marketing surface does not let you tell.
Are active threat actors using AI to be quicker, more creative, more productive, more effective at compromising targets? Most definitely. This is not speculation. We have already seen phishing kits that draft contextual lures from scraped LinkedIn profiles, malware that uses LLMs to vary its own behaviour at runtime to evade signature-based detection, and a steady stream of underground tooling that is essentially a thinly-jailbroken commercial model with a different front end. Do we, as security professionals, need to adapt? For sure. Are we doing it in the right way? I am not confident. I think most organisations are adopting AI defensively in the same way they adopted cloud in 2014 — by signing a contract, ticking a box on a programme plan, and assuming the vendor has thought about the implications more carefully than they actually have. Most of the people I speak to are riding the train without paying close attention to what the agents on their endpoints are doing with their data/machines/online accounts. The hype is doing the thinking for them.
The arms race finds security: Mythos and Glasswing
Underneath all of this sits the providers’ arms race. OpenAI, Google and Anthropic are competing day by day on benchmarks, on context windows, on price per million tokens, on which of their models can pass which exam, write which essay, debug which obscure piece of legacy C. That competition has, over the last year, extended in a very specific direction: who can find the most vulnerabilities, and how quickly. Vulnerability discovery — historically a slow, deeply human, instinct-driven discipline — is being framed as a benchmark in its own right. Models are being asked to find zero-days in real codebases, and they are, intermittently, succeeding. There is a turn now toward embracing security explicitly: models offering security scanning, assessment and analysis as part of their default capability surface. That is, on the face of it, positive. But at what cost, and under whose motives?
A couple of weeks ago, Anthropic announced Claude Mythos Preview, a new general-purpose frontier model that turned out, in their own pre-release testing, to be strikingly capable at offensive security work. The name itself is worth a beat — mythos (μῦθος) is the Greek for “story”, “tale” or “narrative”, and the root the English “myth” comes from, which is either a very deliberate piece of branding or an accidentally apt choice for a model whose core skill is constructing convincing exploit narratives out of someone else’s code. The numbers they put on the table are not the usual marketing material. Mythos identified zero-days in every major operating system and every major browser, including a previously unknown bug that had been sitting in OpenBSD for 27 years — OpenBSD, of all things, the OS people reach for precisely because of its security posture. It hit 72.4% on autonomous exploit development in the Firefox JS shell, where the previous frontier model, Claude Opus 4.6, was effectively at zero. In one case it chained four independent vulnerabilities into a working browser exploit that escaped both the renderer and the OS sandbox, autonomously, without orchestration scaffolding around it. Anthropic’s own framing is that Mythos “mostly saturates” the existing vulnerability discovery benchmarks, which is why they pivoted to measuring it on actual zero-days in real codebases — because the old benchmarks no longer distinguish “the model can reason about this class of bug” from “the model has memorised the writeup”. Critically, they are clear in the system card that they did not explicitly train for any of this. The capability emerged as a downstream side-effect of general improvements in code/reasoning/autonomy. The same improvements that make it better at patching bugs make it better at exploiting them. You cannot have one without the other.
Just before public launch, Anthropic took a step back and decided not to make Mythos Preview generally available. Instead, they launched Project Glasswing — a closed research preview to twelve launch partners (AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, the Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks, and Anthropic themselves), plus over forty additional organisations that build or maintain critical infrastructure, with $100M in model usage credits to cover the preview, $4M donated to open-source security maintainers ($2.5M split between Alpha-Omega and OpenSSF via the Linux Foundation, $1.5M to the Apache Software Foundation), and a 135-day coordinated disclosure window for the vulnerabilities Mythos finds. The reasoning Anthropic gave is precisely the asymmetry argument: the productivity gain to defenders, who already have controlled access to source and to internal scanners, is far smaller than the productivity gain to anyone else, and so general availability would tip the scale meaningfully toward attackers. This is the first time in nearly seven years that a leading AI lab has so visibly withheld a frontier model on safety grounds — the last comparable moment was OpenAI’s GPT-2 hold-back in 2019, and that decision aged into something most of the industry now treats as overcautious. Mythos is a different category of call because the capability is concrete and measurable, not speculative.
A vendor making a globally significant call alone
I think my reaction to this is split, and I think the split is worth sitting with.
On one side, this is genuinely a great initiative. It is encouraging that one of the major AI vendors has thought hard enough about the offence/defence asymmetry to voluntarily withhold a capability that would clearly benefit them commercially. That is not nothing. That is a vendor putting “we should not ship this in this form” above “we should ship this”, which is rare in any industry and almost unheard of in this one. The defensive donations to Alpha-Omega/OpenSSF/Apache are the right shape of gesture — those are the maintainers who will have to absorb whatever Glasswing surfaces, and they are catastrophically under-resourced relative to the codebases they look after.
On the other side, and this is the harder part to talk about because it sounds ungrateful, the reason this is also a sad reminder of where we are is that the call is being made by a single private vendor at all. There is no industry body that Anthropic is answering to. There is no regulator that imposed the test. There is no statutory threshold that determined whether the capability crossed a line. There is the vendor, their internal policy team, their legal counsel, almost certainly some marketing input on how the announcement was framed (and let us not pretend the timing relative to a rumoured October 2026 IPO is entirely coincidental), and that is the entire decision-making structure for what is, plausibly, a globally significant security event. The same announcement tells us that fewer than 1% of the vulnerabilities Mythos has found so far have been patched — which means the model is already producing findings at a rate the ecosystem cannot absorb, and the closed-beta governance model does nothing to fix that downstream bottleneck. Whoever ships the next Mythos-class model — and someone will, possibly without the same restraint — lands those findings into a remediation pipeline that is already failing.
Compare this to how grown-up infrastructure is governed
Compare this to how every other piece of critical infrastructure is governed and the contrast becomes uncomfortable. In financial services, an institution does not decide unilaterally that its red team exercise was sufficient. There are frameworks — CBEST in the UK, TIBER-EU across the European Union, and now DORA wrapping a hard regulatory perimeter around the operational resilience of the entire sector — that specify the threat intelligence inputs, the scope, the targeting methodology, the reporting standards, and the supervisory authority that signs the whole thing off. A retail bank cannot decide that its own internal team has done a good enough job and call it a day. A payment processor cannot pick the scenarios its red team will simulate based on what is convenient. The regulator picks, the regulator scopes, the regulator reviews, and the regulator can sanction. That is how grown-up critical infrastructure is governed. It is slow, it is sometimes annoying, it generates paperwork, and it works. Compare that to how the most consequential general-purpose technology of the decade is currently governed: a handful of private US-headquartered companies, each with their own internal safety policy, each making case-by-case decisions about which capabilities to release, each with very different incentives and very different definitions of “safe enough”, and a patchwork of national legislation that is years behind the technology and contradicts itself across borders.
The case for a regulator (not a working group)
I think — and this is where I expect to lose some readers, but I am going to say it anyway — that the only sensible response to this is a centralised regulatory body for AI, with cross-country participation and real enforcement power. Not advisory. Not guideline-issuing. Not a working group with a quarterly newsletter. A body with the authority to say “this capability is not allowed to ship in this form to this audience” and to make that stick. The closest analogue is probably the IAEA for nuclear material — an international body with inspection rights, classification powers, and the ability to escalate non-compliance to a level that has actual consequences. We are not going to get that overnight, and I am not naive about the geopolitics of it, but we should at least be pointing in that direction rather than pretending that the current model — vendor self-governance with occasional national legislation bolted on top — is sufficient. It is not sufficient now and it will be visibly less sufficient in eighteen months.
The important caveat, and I want to be very explicit about this because the regulation conversation always gets distorted into a “for or against AI” frame, is that this is not about hindering advancement or stopping research. The opposite. I want the research to continue. I want models to keep getting better at finding bugs, at reviewing code, at automating the mechanical parts of security work that human practitioners hate doing anyway. The argument for regulation is the argument for safeguarding that progress, not stopping it. A regulated environment with clear rules about what can ship to whom, under what conditions, with what evaluation harness, is an environment where serious institutional defenders can actually integrate these capabilities into their stack with confidence rather than treating every new release as a potential incident to manage. The current environment, where a model with novel offensive capability could appear on a Tuesday afternoon in a public API with a blog post and a pricing page, is not an environment that favours defenders. It favours whoever is fastest to weaponise.
Monday morning
So what does any of this mean for someone doing the work on Monday morning. Concretely: if you are a CISO, your AI policy is almost certainly out of date, and the bit that is most out of date is not the bit about staff using ChatGPT to summarise meeting notes. It is the bit about coding agents with shell access on developer endpoints, MCP servers running on production-adjacent machines with credentials in scope, and the autonomous browser sessions your engineering teams are quietly spinning up to “automate” parts of their workflow. If you are a platform engineer, the question to ask your team this week is not “are we using AI” but “which of our agents has write access to which system, who reviewed that grant, and what is the revocation procedure when, not if, an agent is compromised or behaves unexpectedly”. If you are on a board, the question to ask your CISO at the next meeting is not “what is our AI strategy” — that question generates slides, not answers — it is something closer to:
If one of the major model providers shipped a capability tomorrow that materially changed the offensive economics of attacking us, what would we do, who would make that call, and how long would it take us to react?
If the answer to that last one is longer than a week, you do not have a plan, you have an aspiration.