Blog

Built for Security Work: Using RedRouter for Authorized Pentest, Red Team, and Bug Bounty

By the RedRouter Team
October 28, 2026

Most "uncensored" model APIs are sold for cheap chat. The pitch is a low per-token price and a model that won't lecture you. That's a fine pitch for roleplay. It's the wrong pitch for a security engineer who has written permission to break into a staging environment and needs a model suited to the task.

We built RedRouter for the second person.

If you do authorized offensive security — a pentest with a signed scope, a red-team engagement, a CVE write-up in a lab, a bug bounty on a program that invites testing — you have almost certainly hit the wall: you ask a mainstream assistant to help analyze a loader you pulled off a compromised laptop, or to draft rules of engagement for an environment you own, and it refuses. Not because the work is illegal — it isn't — but because the refusal classifier can't tell the difference between a defender and an attacker. So you lose time rephrasing, or you give up and do it by hand.

RedRouter runs open models modified to reduce refusals, behind an OpenAI-compatible (and Anthropic-compatible) API. You point your existing tools at it and keep working. This post is the practical version: how to wire it into the tools you already use, three real workflows framed the way real engagements are framed (in scope, in a lab, on paper), and an honest account of what we keep and for how long.

One rule, up front. RedRouter is for systems you own or are authorized in writing to test. Our Terms prohibit using the service to "attack, access, or test systems you do not own or are not authorized to test." Everything below assumes you have that authorization. If you don't, stop here.

Why not just race to the cheapest token?

Because that race is already crowded, and nobody serious wins it for long. Flash-class input keeps getting cheaper across the market. If your only differentiator is price, you are one competitor's pricing page away from irrelevance.

RedRouter's prices are honest and low, but that's not the pitch. The pitch is fit: models modified to reduce refusals, an API that drops into your existing agent, and a retention policy you can actually reason about. For reference, from the live models page and catalog:

All four carry about 1M-token context and 8,192 max output. Prices are per the live catalog at publish time; check the models page for current numbers.

One-page setup

Two base URLs, one API key. Get a key from your RedRouter account, export it, and point your tool at the right endpoint.

• OpenAI-compatible base: https://redrouter.org/v1
• Anthropic-compatible base: https://redrouter.org (Messages API at /v1/messages)
• Model IDs: deepseek-v4.1-flash-rr, glm-5.3-flash-rr, glm-5.3-rr, qwen3.8-27b-rr

export REDROUTER_API_KEY="rr-...your key..."

Quick sanity check with any OpenAI SDK (this mirrors the snippet on redrouter.org):

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://redrouter.org/v1",
    api_key=os.environ["REDROUTER_API_KEY"],
)

resp = client.chat.completions.create(
    model="glm-5.3-rr",
    messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)

Claude Code

Claude Code reaches a non-Anthropic provider through ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN (Bearer). Clear ANTHROPIC_API_KEY so it doesn't send a competing header. Point the aliases at a RedRouter model ID. (Source: Claude Code env vars, connecting to a gateway, and our Claude Code / OpenCode / Cline guide.)

export ANTHROPIC_BASE_URL="https://redrouter.org"
export ANTHROPIC_AUTH_TOKEN="$REDROUTER_API_KEY"
export ANTHROPIC_API_KEY=""
export ANTHROPIC_MODEL="glm-5.3-rr"
export ANTHROPIC_DEFAULT_SONNET_MODEL="glm-5.3-rr"
export ANTHROPIC_DEFAULT_OPUS_MODEL="glm-5.3-rr"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="glm-5.3-rr"
export ANTHROPIC_DEFAULT_FABLE_MODEL="glm-5.3-rr"
export CLAUDE_CODE_SUBAGENT_MODEL="glm-5.3-rr"
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC="1"
export ENABLE_TOOL_SEARCH="false"
claude

Models can still refuse requests or produce incorrect answers; reduced refusals are not a guarantee. Text and tool blocks work, but images, PDFs and server-side tools return 400. See the tested guide for the remaining compatibility limits.

To persist it, put the same keys in the env block of ~/.claude/settings.json. When ANTHROPIC_BASE_URL points away from api.anthropic.com, recent Claude Code builds disable Remote Control — expected for local use.

OpenCode

Declare RedRouter as a custom provider in opencode.json. This example reads the key from REDROUTER_API_KEY in your environment. (Source: OpenCode providers.)

{
  "$schema": "https://opencode.ai/config.json",
  "model": "redrouter/glm-5.3-flash-rr",
  "provider": {
    "redrouter": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "RedRouter",
      "options": {
        "baseURL": "https://redrouter.org/v1",
        "apiKey": "{env:REDROUTER_API_KEY}"
      },
      "models": {
        "glm-5.3-rr": { "name": "GLM 5.3 RR" },
        "deepseek-v4.1-flash-rr": { "name": "DeepSeek V4.1 Flash RR" },
        "glm-5.3-flash-rr": { "name": "GLM 5.3 Flash RR" },
        "qwen3.8-27b-rr": { "name": "Qwen 3.8 27B RR" }
      }
    }
  }
}

Start with glm-5.3-flash-rr or qwen3.8-27b-rr. Our October 27 test found that OpenCode 1.19.4 sent reasoning_content back on the second turn with DeepSeek V4.1 Flash RR, which RedRouter rejected. Listing a model in the config does not establish multi-turn compatibility.

Cursor

Open Cursor Settings → Models → API Keys, paste your RedRouter key into the OpenAI API Key field, enable Override OpenAI Base URL, and set it to https://redrouter.org/v1. Then + Add Custom Model and enter a RedRouter model ID exactly (e.g. glm-5.3-rr).

The override is global for OpenAI-family requests while it's on. BYOK applies to Chat (and may apply to Agent depending on Cursor's Responses API support — RedRouter currently exposes Chat Completions fields in the catalog, so verify Agent against your account before relying on it).

Three authorized workflows

Everything here is framed the way an engagement is actually run: a scope you were given, a lab you control, permission on paper. Each workflow shows a prompt shape and what a useful answer contains — not live API transcripts, and not copy-paste exploit payloads.

1. Recon on an in-scope target

Situation: You're on a web-app pentest. The statement of work lists app.staging.example.com and its API subdomain, Monday–Thursday, business hours, no production data. You want the model to help you plan and organize recon, not to "go hack it."

Prompt shape:

"I'm doing an authorized web-app pentest. In scope: app.staging.example.com and api.staging.example.com only. Help me build a recon checklist: subdomain and content discovery, tech-stack fingerprinting, auth surface, and the API's documented endpoints. For each item, name the standard tooling and the signal I'm looking for. Flag anything that could touch out-of-scope hosts so I avoid it."

What a good answer looks like:

• A structured checklist grouped by phase (passive → active), not a wall of commands.
• For each step: the why, the common tool, and the expected signal.
• An explicit scope-guard section: wildcard certs, shared CDNs, or third-party auth that could pull you out of scope.
• A note on rate and noise so you don't trip staging alerts.

2. Writing a PoC for a known CVE — in a lab

Situation: You maintain a lab that mirrors a known-vulnerable version of an app with an assigned CVE. You want a proof-of-concept to confirm the issue is reachable in your build and to validate your patch — on a box you own, disconnected from anything production.

Prompt shape:

"In an isolated lab I own, I'm reproducing CVE-XXXX-YYYY in component vX.Y. Walk me through the PoC at a structural level: the vulnerable code path, the precondition that makes it reachable, how I'd confirm the bug triggers, and how I'd verify a fix. Keep it high-level enough to understand and test, and note the version where it's patched."

What a good answer looks like:

• The root cause in plain terms.
• The reachability conditions — config, auth state, feature flags.
• A validation procedure: what to observe when the bug triggers.
• Fix verification: the patched version or mitigation, and how to re-run your check.

This is not a weaponized, drop-in payload. For known CVEs in a lab, the high-level structure plus a verification plan is what makes you faster and safer.

3. Triaging and writing a bug bounty report

Situation: You found something on a program that invites testing. Now you have to decide if it's real, rate it, and write it up so the triager reproduces it on the first read.

Prompt shape:

"Help me triage and write up a finding for a bug bounty report. Here's the behavior I observed on an in-scope endpoint: sanitized description. Help me (a) assess impact and likely severity with CVSS reasoning, (b) tighten the reproduction steps, and (c) draft a clear report: summary, impact, steps to reproduce, and a remediation suggestion. Keep the repro minimal and non-destructive."

What a good answer looks like:

• An impact assessment with a CVSS vector and the assumptions behind it.
• Reproduction steps rewritten to be minimal, ordered, and deterministic.
• A report draft as Summary / Impact / Steps to Reproduce / Remediation.
• A remediation suggestion the vendor can act on.

Honest trust notes

Security people read privacy policies. Here's ours in plain terms; the source is our Privacy page and Terms.

• Zero Data Retention is opt-in. It's off unless you turn it on in Settings. While it's off, we keep an encrypted copy of prompts and completions for up to 30 days, solely for abuse prevention, support, debugging, and billing disputes. Access is restricted and audited, and the copy is deleted automatically afterward.
• With ZDR on, we store no prompts or completions for your requests and chat-saving is off. It applies to requests made after you enable it and adds 20% to every token price (except during a paid monthly plan).
• We still record usage metadata either way — model, token counts, cost, timing, errors.
• Checkpoint and quantization are listed per model in the catalog. Today: glm-5.3-flash-rr and glm-5.3-rr are NVFP4; deepseek-v4.1-flash-rr and qwen3.8-27b-rr are FP8. Fields we can't verify are marked unknown rather than guessed.
• We don't sell your data, run advertising trackers, or record your sessions. Cloudflare delivers and secures traffic; AWS hosts; Stripe handles card and USDC payments. We also ask the inference infrastructure not to log requests, but we can't independently verify what it retains, and we'd rather say so.

A proposed 60–90 second demo

This is a recording plan, not a completed test or a transcript. Capture actual behavior and label the tool and model versions; if a model answers or refuses, show that outcome rather than staging it.

Shot list

1. (0:00–0:08) Cold open — the wall. Claude Code with a stock model. "We have written sign-off to red-team our own staging VPC. Draft the rules of engagement." Show the actual response; use a refusal only if one occurs.
2. (0:08–0:18) The fix, on screen. Terminal: export ANTHROPIC_BASE_URL="https://redrouter.org", export ANTHROPIC_AUTH_TOKEN=..., model aliases. Key masked.
3. (0:18–0:45) Same prompt, actual result. Re-run against glm-5.3-rr. Show the response as it streams. Highlight banned actions (DoS, real exfiltration, persistence).
4. (0:45–1:05) Second beat. Paste a sanitized finding; get a Summary / Impact / Steps / Remediation skeleton.
5. (1:05–1:20) Trust. ZDR toggle and catalog quantization row.
6. (1:20–1:30) Close. Wordmark: "Built for security work. Authorized only."

Voiceover: "If you do authorized security work, you know this screen. The task is legal. You have sign-off. A model may still say no. RedRouter runs open models modified to reduce refusals — behind the same API your tools already speak. Three lines, and you're back to work. Zero data retention is opt-in, and every model's checkpoint and quantization is right on the page. RedRouter. Built for security work — authorized only."

RedRouter is operated by Marker AI, Inc. It's for systems you own or are authorized in writing to test. See the Terms and Privacy policy.