AI Red Teaming with OpenRouter: Real-World Results Including a Full Scan for $0.14

When the Defense Model Refuses to Work

There's an uncomfortable truth in AI security: when you need a model to help analyze vulnerabilities, it may refuse on safety grounds. During one Hugging Face security incident, the models the defense team reached for first — Claude Opus and Fable — declined most of the investigative work because their guardrails "treated reverse-engineering a vulnerability the same as actually launching an attack." The team eventually switched to GLM-5.2 running on their own hardware to continue.

That was incident response, not red teaming, but when you point AI red-team tooling at your own agents, the core questions are the same: Will the model actually do the work? What will it cost? And where does your data go?

It was precisely these three questions that led Humanbound to add OpenAI-compatible endpoint support to their open-source CLI tool (hb version 2.13, corresponding to PRs #166 and #170), allowing any OpenRouter model to plug straight in.

This phenomenon has a name in security circles: "over-refusal." Commercial models' RLHF training typically flags a broad category of requests involving vulnerabilities, malicious code, and reverse engineering as high-risk, leaving models unable to distinguish between "helping an attacker" and "helping a defender analyze an attack." Red teaming — which inherently involves simulating attack behavior to surface weaknesses — sits in natural tension with how guardrails are designed. Models like GLM and DeepSeek^Ad tend to impose fewer restrictions on these tasks, partly due to different training data and alignment strategies, though that can also mean looser safety boundaries in other areas. The right tradeoff depends heavily on your specific context.

Findings Across Five Configurations

The integration is straightforward — a few environment variables and you're set:

pip install "humanbound[engine]>=2.13"
export HB_PROVIDER=openai
export HB_ENDPOINT=https://openrouter.ai/api/v1
export HB_API_KEY=sk-or-...
export HB_MODEL=deepseek/deepseek-v4.1-flash

The test team ran five different configurations, and what they learned goes well beyond "it works." These pitfalls are relevant to any team looking to use third-party models for security testing.

Pin Your Host Node

The first surprise was a routing issue. A single model name on OpenRouter mapped to 32 different endpoints. That means you might think you're using the same model, while requests are actually fanning out across various backend providers — making results impossible to reproduce.

The fix is to use OpenRouter's preset configuration: set the only parameter to lock down the provider, set allow_fallbacks: false to disable fallbacks, and turn off inference features. Only then can you guarantee test consistency and traceability.

Thinking Models Go Silent

This was the most counterintuitive finding. In red-team testing, the scorer is allocated just 50 tokens of output budget. Thinking models burn through all of those tokens on internal reasoning, then return empty content.

Worse, when Humanbound can't get a score, it fabricates a 5/10 — meaning your test report could be built entirely on fake data. In practice, one small OpenAI model lost 66% to 81% of its scorer responses, effectively rendering the entire test meaningless.

By contrast, DeepSeek V4.1 Flash with thinking disabled didn't drop a single scorer response — and the full scan cost $0.14. That comparison makes the point: for tasks like scoring that require deterministic, short outputs, reasoning models are a liability. Cheap and direct beats smart.

"Thinking models" are models that perform chain-of-thought reasoning before generating a final response — OpenAI's o-series, DeepSeek-R1, and their derivatives are canonical examples. The reasoning process itself consumes substantial tokens, sometimes several times more than the final answer. When a downstream task imposes a hard output length limit (like the 50-token scorer budget here), the model can exhaust its budget during the reasoning phase, leaving the actual answer truncated or empty. This has nothing to do with the model being unwilling to respond — it's a purely mechanical token allocation issue. Beyond disabling thinking mode, you can also explicitly set max_tokens to reserve headroom for both reasoning and output, provided the API provider supports the relevant parameters.

Your Data Leaves the Machine

The third thing to watch out for is privacy: when you use hosted models, all transcripts from the testing process leave your machine and are sent to third-party hosts.

For security testing — which inherently involves sensitive content — this risk can't be ignored. The recommended approach is to carefully review the host's data policy, or simply run models locally with Ollama and keep everything within your own control.

Ollama is an open-source tool for running large language models locally, supporting dozens of mainstream open-source models including Llama, Mistral, Gemma, and DeepSeek. It exposes an OpenAI-compatible API (listening on http://localhost:11434 by default), so it can theoretically replace the OpenRouter endpoint in this setup without any changes to the application logic. The core advantage of running locally is that data never leaves the machine — ideal for security testing scenarios involving real vulnerability details, internal system topology, or customer data. The tradeoff is needing sufficient local compute: a consumer GPU like an RTX 4090 can comfortably run 7B to 70B quantized models, but larger models require multi-GPU setups or dedicated inference servers.

What This Test Actually Measured

To be clear, this evaluation only validated whether the pipeline works — whether models connect reliably, whether the scorer functions correctly, and what the cost and data flow look like. It did not assess the quality of the attacks themselves. In other words, it answers "can this toolchain be used" rather than "which model is better at red teaming."

That distinction matters. It's easy to conflate "the model connects" with "the model tests accurately," but across these five configurations, just keeping the pipeline stable surfaces plenty of hidden traps: unfixed routing, silent thinking models, fabricated scores. These problems directly contaminate test conclusions — and they rarely surface as obvious errors.

Takeaways for Practitioners

A few principles emerge from this open-source tooling experiment that are worth carrying into AI security work.

Vendor pinning isn't optional — it's a prerequisite for reproducibility. In a world of multi-endpoint routing, leaving the host unpinned means every test runs against a different black box.

Stronger capability doesn't mean fit for every task. Scorers need deterministic short outputs — precisely where reasoning models struggle. Chasing a "smarter" model can distort your entire test pipeline.

There's enormous room for cost optimization. A full scan for $0.14 shows that, with the right model, the economic barrier to large-scale automated security testing is lower than most assume.

Data sovereignty requires deliberate effort. Security testing is sensitive by nature. Defaulting to third-party data handling is risky; local solutions like Ollama deserve priority consideration.

Full technical details, preset configurations, and result comparison tables are available on the Humanbound official blog.