Skip to main content

redteam-foundry

A measurement harness for checking whether the standard tests used to probe AI language models for unsafe behaviour still tell you anything.

PyPI CI License: MIT Python 3.13 Checked with mypy --strict

The question. Safety teams reach for a handful of published collections of attack prompts to decide whether a model is holding up. Those collections are years old and the models are not. Do they still separate a robust model from a weak one — and how much should you trust the answer?

The answer, in one line. Mostly they do not: across every configuration tested, the published attacks almost never succeed (0–4%), and a deliberately paranoid set of defences does not measurably change that.

Attack success rate across all 12 evaluation cells — point estimate with 95% bootstrap confidence interval. Ten of the twelve cells sit at 0%; the two non-zero cells are the AdvBench Llama baseline at 1% and the AgentDojo Llama baseline at 4%.

Status: active — the package is maintained, the research has reported. All roadmap phases are done and both research lines have concluded; the headline result is frozen. This measures whether benchmarks still discriminate. It does not certify any model as safe, and it is not a security audit.

pipx install redteam-foundry && redteam --help

What this is for

For anyone who has to decide whether a safety evaluation is still worth running: model evaluation teams, safety researchers, and engineers who inherited a benchmark suite and do not know whether a green result means the model is strong or the test is worn out. The problem it solves is that those two look identical — a robust model and an exhausted benchmark both report "0% of attacks succeeded", and the success rate alone cannot tell them apart.

Existing tooling runs the attacks. This one asks whether running them still tells you anything, and reports how much to trust its own answer. It is the research half of a two-part stack: the companion project agent-release-gates consumes the challenge packs exported here and makes the ship/warn/block call. Validate the benchmark before you trust the gate. Release decisions are deliberately out of scope here.

What the result means

That near-zero is a statement about the benchmarks as much as the models. Instruction tuning has largely saturated the static, published jailbreak and prompt-injection corpora the field still reaches for as a safety signal. They no longer discriminate.

The contribution is not a new attack. It is a reproducible, judge-validated measurement that these benchmarks have stopped discriminating, plus the tooling to quantify why. It is a meta-science result about benchmark validity, not a claim that any model is safe. What the benchmarks under-measure — the live agentic tool-use loop, multi-turn attacks, adaptive optimisation — is named in § Threats to validity, not hidden.

Why the result is trustworthy, not just low

A near-zero number is easy to report and easy to distrust.

  • A positive control rules out "the harness just under-elicits". Through the identical pipeline, a known-vulnerable model scores 80% (cross-judge 80.6%, κ = +0.935). The apparatus registers a high attack-success rate when the target really is vulnerable, so the 0–4% is a property of the aligned models.
  • Two judges, and honesty about when they agree. Every verdict is scored and re-scored independently. Where labels actually vary the judges agree strongly (κ = +0.935, n = 98). The 12 matrix cells also report κ = +1.000, but in 11 of them both judges labelled every case identically, which makes κ an undefined 0/0 rather than evidence — the repository says so, and a check enforces it.
  • Confidence intervals at honest sample sizes. Percentile-bootstrap, not CLT intervals, which under-cover at n≈50–100. With n = 100 and zero successes the detectable-effect bound is [0, 3.6%], stated rather than glossed.
  • Pinned and deterministic. Dated model versions, datasets pinned to upstream commits, every API call cached, so re-runs are free and reproduce exactly.
  • Scoped, with threats to validity written down. Single-turn only; static published prompts, not adaptive attacks.

One consequence is worth stating plainly: this reports attack-success rate and not refusal rate. The cross-judge layer found refusal is not well-posed — an indirect-injection task has two things that can be refused, so the judges disagree, sometimes worse than chance. Refusal is reported as a descriptive signal of response style, never as a safety metric.

Ethics

[!IMPORTANT] This project uses only published adversarial prompts and does not generate novel jailbreaks in any language. Excluded categories (CSAM, weapons-of-mass-destruction synthesis, detailed self-harm methods) are filtered at corpus-load time and verified by a CI test. Results are aggregate; exported adversarial prompts are redacted. The multilingual work is benign-only. Full policy in ETHICS.md.

If you are a model provider whose model is included and want example transcripts removed, email rosscyking@gmail.com and I will remove them within 24 hours.

Documentation

Document What is in it
Getting started Install, development setup, reproducing the headline table
Command reference Every sub-command, offline and live, and how the stages fit together
Finding: are jailbreak benchmarks still worth running? The paper-style write-up: question, method, results with CIs, threats to validity, related work
Finding: what does this metric return when nothing happened? A running catalogue of metrics and checks in this repository that were satisfied by the absence of the thing they measured — several introduced while fixing the previous one
Finding: a preregistered null at p = 0.0001 A real, highly significant effect reported as null because it missed an effect-size bar fixed before the run
Finding: what mechanical conversion does to Taiwan-native safety text Converting 400 Taiwan-native safety prompts to Simplified and back changes 66% of them
METHODOLOGY.md Source of truth for every reported number; metric validation; threats to validity
ETHICS.md Excluded categories, redaction, disclosure, provider terms
tests/README.md Which claim each test suite defends
docs/ROADMAP.md The foundry pivot, phase status, follow-up hardening
docs/RELEASING.md How a release is cut, and what the release path refuses to publish
CONTRIBUTING.md Scope, dev setup, ethics rules for adding corpora
CHANGELOG.md Release history
reports/samples/ Committed real-data findings: staleness, defence comparison, data card

Two scoping documents record work considered and not built: porting the AgentDojo cell to a native Inspect task and a gap analysis toward an arXiv preprint.

Citation

@software{redteam_foundry_2026,
  title  = {redteam-foundry: An adversarial benchmark foundry for LLM safety},
  author = {Cheng-Yuan King},
  year   = {2026},
  url    = {https://github.com/rosscyking1115/redteam-foundry}
}

Licence

MIT — see LICENSE.

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

redteam_foundry-0.4.1.tar.gz (727.8 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

redteam_foundry-0.4.1-py3-none-any.whl (126.7 kB view details)

Uploaded Python 3

File details

Details for the file redteam_foundry-0.4.1.tar.gz.

File metadata

  • Download URL: redteam_foundry-0.4.1.tar.gz
  • Upload date:
  • Size: 727.8 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.13

File hashes

Hashes for redteam_foundry-0.4.1.tar.gz
Algorithm Hash digest
SHA256 d2e9dceca7b2cb1ef863a69feb2f163b3310194115591a480610bad312c9a502
MD5 e7fbffb5235285f5a0b9ab20f2b8bd69
BLAKE2b-256 e1ae6d61d0748d41b096ef6366ddc4a41ac60c79d7492449ee20aa33dc9c3f80

See more details on using hashes here.

Provenance

The following attestation bundles were made for redteam_foundry-0.4.1.tar.gz:

Publisher: publish.yml on rosscyking1115/redteam-foundry

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file redteam_foundry-0.4.1-py3-none-any.whl.

File metadata

  • Download URL: redteam_foundry-0.4.1-py3-none-any.whl
  • Upload date:
  • Size: 126.7 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.13

File hashes

Hashes for redteam_foundry-0.4.1-py3-none-any.whl
Algorithm Hash digest
SHA256 832bef896a7ca26b3f4f39bf1dee7f8f2fd22026bd000b147afffd07764a2ad9
MD5 5f30b37b71a1531af0e5a3a0158ed9b2
BLAKE2b-256 6a8c89978fa078ee02ba85be5ae33289b4088fdad26f133db6b47573435eb185

See more details on using hashes here.

Provenance

The following attestation bundles were made for redteam_foundry-0.4.1-py3-none-any.whl:

Publisher: publish.yml on rosscyking1115/redteam-foundry

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page