GAUNTLEX introduces Adversarial Resilience Score to test AI code specs

The Adversarial Resilience Score: A New Metric for AI-Generated Code

The problem with "this AI writes secure code" Every AI coding tool now claims some flavor of security-awareness. Almost none of them will tell you, in a number, how resilient the code it just wrote actually is — and fewer still will let you verify that number yourself after the fact. That's the gap I built the Adversarial Resilience Score (ARS) to close. It's the core metric behind GAUNTLEX, and I want to walk through exactly how it's computed — not the marketing version, the actual formula — because a security metric nobody can audit isn't a metric, it's a claim. The formula ARS = Σ(attack_scores) / N Where N is the number of adversarial attacks fired at the generated code for a given run (5 in quick mode, 20 in standard, 50 in thorough), and each individual attack_score is one of exactly three values: 1.0 — mitigated. The attack was fully defended against. 0.5 — partial. The defense exists but is bypassable or incomplete. 0.0 — missed. No defense at all; the attack succeeded cleanly. Each attack is scored independently by GAUNTLEX's Arbiter — a separate model call that renders a verdict (mitigated / partial / missed) plus a one-line reason, so every score comes with an explanation attached, not just a number. ARS is the mean of those scores, so it lands somewhere in [0.0, 1.0]. Why an average, not a pass rate This is the detail I think matters most and gets glossed over the most. ARS is not "percentage of attacks blocked." A pass/fail count throws away information — it treats a defense that's 90% there the same as no defense at all, and it treats a narrowly-avoided bypass the same as an attack that never had a chance. Averaging continuous per-attack scores keeps that gradient. A codebase that mitigates most attacks cleanly but has two partially-bypassable defenses scores differently — and more informatively — than one that fully blocks some attacks and fully fails others, even if the raw counts look similar. It also means ARS resists gaming by test selection. You can't inflate it by throwing in a pile of trivially-blocked attacks, because a single fully-missed attack against something serious (say, an auth bypass) pulls the average down hard regardless of how many easy ones surround it. The gate, not a suggestion GAUNTLEX runs in CI with a configurable minimum ARS — 0.80 by default. If a run scores below that threshold, the build fails. Not a warning, not a Slack notification to review later — the merge is blocked, the same way a failing test suite blocks a merge. fail_open defaults to false: if GAUNTLEX itself can't complete a run for some reason, that's a failure state too, not a silent pass. The reasoning: a security score that's advisory gets ignored under deadline pressure, every time. A score that gates the merge doesn't have that problem. Domain-specific, not generic The 5/20/50 attacks per run aren't generic fuzzing — they're drawn from policy playbooks scoped to a specific regulatory or security domain: OWASP Top 10, HIPAA, FINRA, PCI DSS, SOC 2 (with NIST SSDF and OWASP API Security available as installable extensions). Each domain playbook is a curated set of scenarios specific to that domain's actual failure modes — HIPAA's playbook probes PHI-handling failure modes, FINRA's probes the record-retention and audit-trail patterns those regulations actually care about, not a repackaged OWASP list with a different label on it. Every finding GAUNTLEX produces also carries a CWE tag and maps to control frameworks (NIST SSDF, OWASP SAMM, SOC 2, ISO 27001) — so a report isn't just "here's a score," it's something a compliance reviewer can actually trace back to a specific control. Tamper-evident by construction A self-reported security score is worth exactly as much as the trust you place in whoever generated it — which is close to zero for a tool that hasn't earned it yet. So every GAUNTLEX report includes a SHA-256 hash computed over the ordered array of attack results. Anyone can run gauntlex verify <run_id> and confirm the report they're looking at hasn't been edited after the fact. It doesn't prove the score is good — it proves the score you're reading is the score that was actually computed, not a touched-up version of it. That distinction — provable versus claimed — is the whole design philosophy behind GAUNTLEX, and it's why I built ARS as an auditable formula instead of a black-box "security rating." Try it pip install gauntlex-ai gauntlex run --spec your_spec.md --mode quick Quick mode runs 5 attacks in under a minute and prints an ARS for whatever spec you point it at. Full writeup, the compliance domain list, and the MCP server integration (works inside Claude Code, Cursor, Windsurf, Zed) are in the repo and the Deep Dive doc. If you try it against something you've built, I'd genuinely like to know what it finds — that's what Discussions is for.

3 hours ago

Why I Built an Adversarial Co-Generation Engine

I spent a chunk of last year around legacy modernization work — the kind of project where a bank or an insurer is taking twenty years of accumulated code and rebuilding it as modern services, one system at a time. Every one of those systems starts the same way: a PRD or a requirements document says what the business needs, that gets translated into a spec precise enough for an AI to implement, and eventually someone tests what came out. What struck me, watching this happen at scale, wasn't that the code was bad. It was that nobody was testing the thing that actually determined whether the code would be bad: the spec itself — the technical description handed to the model, not the PRD that motivated it. Every security tool I looked at — SAST scanners, DAST tools, even the AI coding assistants themselves — waited until an implementation existed before doing anything adversarial. Attack the code, once it's there. That's the whole industry's model, and it's worked fine for forty years because the volume was always survivable. A team ships a handful of PRs a week, a human reviews them, and eventually a pentest catches whatever slipped through. That math falls apart at modernization scale. When you're regenerating a few million lines of code, you're also generating a few thousand specs, faster than any review process was ever built to absorb. Testing after the fact doesn't just get slower under that load — it quietly stops happening, spec by spec, until the aggregate exposure is enormous and nobody can point to when it happened. So I built GAUNTLEX to test the thing that happens before the code does: the spec. This is also where I want to be precise about a word that gets overloaded. "Spec-driven development" — the broader industry shift toward writing structured, agent-facing specs instead of prompting an AI free-form — is exactly the world GAUNTLEX lives in. But a spec (what to build, precise enough for a model to implement) and a PRD or requirements doc (why it's needed) aren't the same artifact, even though people often use "spec" loosely to mean both. GAUNTLEX treats them as two separate inputs on purpose: build intent from the spec itself, business intent pulled in separately from wherever your team actually tracks the why — Jira, Confluence, Aha! — via what the product calls the Intent Adapter. The attack surface gets reasoned from both, not just one. How it actually works Two agents run on the same specification, at the same time. A Builder implements it. A Breaker attacks it, reading only the spec, with no visibility into what the Builder wrote. Neither one waits on the other. By the time the Builder has working code, the Breaker already has a full adversarial test suite derived from the same intent. A third agent, the Arbiter, scores every attack against whatever the Builder actually produced — mitigated, partially mitigated, or missed entirely — and that produces a single number, the Adversarial Resilience Score. Fall below the threshold your team sets (0.80 by default) and the merge is blocked automatically, the same way a failing test suite blocks one today. It isn't a new discipline. It's the same discipline, pointed at a gap nobody was covering. gauntlex run --issue SPEC.md --intent PROJ-123 --mode standard What actually comes out of it Every finding is tied to a real CWE, but more importantly, to the compliance controls an auditor is actually going to ask about — NIST SSDF, OWASP SAMM, SOC 2, ISO 27001. A CWE number is useful to an engineer. It isn't what satisfies a compliance review, and I wanted the report to be useful to both people in that conversation, not just one. Five regulated-industry playbooks — HIPAA, FINRA, PCI DSS, SOC 2, OWASP Top 10 — ship today, each mapped to the actual regulation it's checking against, not a generic scan wearing an industry label. If you want to try it gauntlex setup gauntlex run --issue examples/demo_issue.md --mode quick --pretty It's free, MIT licensed, and works with whichever model provider you already use, including fully local through Ollama if you can't send code to an external API at all. I'd genuinely like to hear what it catches in your own repos That's what the GitHub Discussions are for. github.com/sanjoy1234/gauntlex

1 day ago