What frontier models actually change
Cyber frontier models such as Mythos compress the attacker's timeline substantially. Discovery, exploit chain construction, and proof-of-concept generation — historically the gating constraints on producing a working attack — now happen in a fraction of the time. The shape of an intrusion hasn't changed: reconnaissance, initial access, lateral movement, persistence, and exfiltration still have to occur. What has changed is the speed and scale at which attackers can operate. A model can search large bodies of public code and generate exploit variations faster than defenders can review every downstream use of a vulnerable library.
Three concerns shape the defensive architecture described in this post. First is speed of discovery: if you are not running these models against your own code, it is safe to assume someone else is. Second is exploit volume and adaptation: a model can produce thousands of variations of an exploit, but many share the same underlying signature. Adaptation is how attackers bypass signature-based detection — a model can probe a WAF, learn what gets blocked, and rewrite a payload until it slips past. Third is the impact of inevitable exploitation: no architecture catches everything, so the question becomes how far an attacker can travel with one identity, one path, or one credential before something stops them.
Visibility as the foundation
Cloudflare sees roughly a fifth of the web, which reveals in real time which payloads are mutating and where attacker tooling is moving. Two teams translate that visibility into action. Cloudforce One handles threat intelligence and research, turning network observations into tracked adversaries, campaigns, and indicators of compromise. The hard part of that work was never identifying malicious activity — it was the delay between knowledge and mitigation. Knowing of a new threat normally has to travel from a threat report into a feed, then into a company's defenses. With Cloudforce One threats can be blocked directly in the WAF, closing that gap.
The second team owns the WAF engine: the managed rulesets running in front of Cloudflare's own properties, the machine learning powering WAF Attack Score, and the relationships that sometimes allow a rule to ship before a CVE is public. Rules reach the entire network in under 30 seconds once deployed. React2Shell is one recent example where a managed WAF rule protected Cloudflare's properties — and those of every other customer on the platform — hours before the official advisory was published.
Scores over signatures
Signature-based defenses assume novel exploits are rare and variations take weeks to produce. That assumption no longer holds. Cloudflare's traditional SLA from a fresh proof-of-concept to a live deployed rule is 12 hours, which is not good enough when attacks need to be stopped before a CVE is even discovered. The ML-based detection layer runs on every request, scoring traffic from 1 to 99 based on how closely a request resembles known attack shapes — not against a list of known-bad signatures. A novel SQL injection or remote code execution chain is typically a rearrangement of previously seen attack shapes, so the model catches new variants before they are publicly known. The lower the score, the more aggressively the request is treated. AI Security for Apps applies the same scoring methodology to AI prompts, measuring similarity to actual attacks rather than matching against a list of known malicious prompts.
The layered architecture
The techniques only matter when stacked in front of an application, and defense-in-depth begins with the WAF dropping anything that matches a known-bad pattern, clearing obvious traffic so specialized layers can focus on what remains. On the API surface, API Shield runs a positive security model: valid requests are described from each API's own definition or learned from real traffic, and anything that doesn't fit is rejected. Because only validated traffic passes, generating thousands of novel attack variations fails to bypass the system.
Bot Management catches probing traffic before frontier models can map the network. It scores every request on the probability of automation, using behavior, browser realism, and connection patterns across the entire network. Zero Trust Network Access applies to every internal application, replacing implicit network trust with per-request identity and policy. The value of this became clear when an engineer shipped a misconfigured tool: in a flat network, everything on the same segment would have been exposed. In Cloudflare's deployment, the exposure stopped at the tool itself. Require Access Protection was subsequently built so that newly deployed or misconfigured applications cannot be reachable before an access policy is in place.
IdP Federation keeps that secure-by-default posture consistent across every Cloudflare account. Rather than asking each team to wire up SSO separately, the identity provider is configured once and shared across the organization. New accounts get SSO automatically, recipient-side IdP connections are read-only, and Access policies still evaluate identity as part of the normal request flow. MCP Server Portal gives teams a controlled way to connect AI agents to enterprise systems. Agents access centrally managed MCP servers through a single portal with every action logged. AI Gateway runs in front of internal AI tools just as AI Security for Apps runs in front of customer-facing AI features. Inside the company, visibility matters more than blocking — observing what engineers are building is prerequisite to writing meaningful policy.
Putting the architecture to work
Frontier models can help attackers find vulnerabilities, adapt payloads, and move faster, but they still have to pass through the layered defense you deploy in front of your application. That is where teams should start:
- Put inspection in front of public applications.
- Define what valid API traffic looks like.
- Use bot detection to limit automated probing.
- Require identity and access policy before any internal tool is reachable.
For AI and agentic systems:
- Route model traffic through a gateway.
- Keep agents connected through approved MCP servers.
- Log what they do.
The goal is to make sure that when one layer misses, the next layer limits what the attacker can see, reach, or change. The vulnerability may be what starts the attack, but the architecture determines how far it can go.
Validating the approach
Plenty of security stacks look impenetrable on a whiteboard but fall over in practice. That is why we test ours continuously, both at the perimeter and inside our environment, with our red team involved across both.
At the perimeter, frontier models are one tool we use to test our application security stack as an adaptive attacker. These models sit alongside the rest of our red team and detection workflows, including manual testing, threat intelligence, observed traffic patterns, proof-of-concept analysis, and signals from our own network. Together, those inputs help us decide where to aim testing: newly launched products, recently changed surfaces, and the paths an attacker is most likely to probe first. The most important part is the process that follows. When something gets through, we identify the gap, use the right mix of tools to understand it, write the rule or mitigation, ship the update, and test again to make sure the gap is closed.
Inside the environment, our red team starts from the assumption that the perimeter has already failed. They look at what has changed, where sensitive systems carry risk, and whether one compromised identity, path, or credential can reach farther than it should. When we change the architecture based on what they find, they run the scenario again against the new version to confirm the gap is actually closed.
We confirm that this architecture is working by continuously testing its behavior during failures, rather than relying on the perfection of individual layers.
