News

Cloudflare's Blueprint for Model-Agnostic AI Security Scanning

Cloudflare details how it built a vulnerability harness that treats LLMs as interchangeable components, enabling cross-repo, fleet-wide security scanning without per-language tuning.

July 2, 2026· 3 min read· Source: The Cloudflare Blog
Cloudflare's Blueprint for Model-Agnostic AI Security Scanning

Cloudflare's Project Glasswing continues to deliver practical insights for engineering teams building AI-powered security tooling. In their latest post, the team walks through the architecture of a vulnerability harness designed to be model-agnostic from day one. The core thesis: no single model, no matter how capable, should be the backbone of your security pipeline. Models are commodities; the orchestration layer is what lasts.

Why a harness, not an agent

The post directly addresses two common objections. First, why not use sub-agents? Sub-agents are fine for isolated tasks, but security analysis requires hundreds of persistent investigations that survive across runs, don't share a context window, and can be cross-referenced later. That's an orchestration problem, not a prompting one. Second, this isn't an ad for frontier models. Cloudflare runs the harness with whatever model is currently best for the job, and different models turn up different bugs. The harness is the durable asset.

From skill to pipeline

Cloudflare started with a 450-line security-audit skill that ran a 7-phase audit in a single session: recon, hunt, validate, report, mechanical validation, independent re-verification, and submission. That skill worked but hit three walls: context exhaustion (models forget bugs after an hour), lack of persistence (a crash means starting over), and blindness to cross-repo dependencies. The solution was to externalize state, treat the LLM as a stateless compute engine, and codify each phase into its own agent with a database behind it and an orchestrator in front. The mapping from skill to pipeline was almost one-to-one.

Two-stage workflow

Cloudflare's vulnerability research workflow splits into two stages: the Vulnerability Discovery Harness (VDH) and the Vulnerability Validation System (VVS). VDH scans codebases to surface potential issues. VVS handles deduplication, judgment, and fixing. Critically, VDH uses one model while VVS uses a completely different one. This forces the validation model to act as an adversarial third party, stress-testing the discovery model's assumptions with an entirely different set of logical weights and training data. Operationally, it also decouples the system from any single model provider's volatility—temperature changes, caching shifts, inference budget tweaks—without breaking the pipeline.

Practical advice for builders

The post offers straightforward guidance: start with a minimal harness consisting of Recon, Hunt, and Validate stages backed by a database. Skip cross-repo tracing until you have more than one repository that matters. Skip a dedicated deduplication agent until you're drowning in noise. Get your prompts working well in a development environment first, then build the next architectural stage only when not having it is the specific thing slowing you down.

Cloudflare's fleet of 128 repos runs on one unified harness with no per-language tuning. The harness doesn't care if it's looking at C pointers or TypeScript—it focuses on security orchestration, leaving syntax to the model. That's the kind of pragmatic, model-agnostic design that will outlast any single LLM release cycle.