Start

Adversarial Agent Review

Adversarial agent review: running a second agent with an attack posture against AI-written code before it ships. The cross-vendor form is the strongest variant.

Adversarial agent review is the practice of dispatching a second AI agent to attempt to defeat, bypass, or exploit code before it merges — not to confirm it, but to break it. The reviewing agent is given the code, a brief naming the known-dangerous surfaces, and an adversarial posture: find what an attacker would find.

It is structurally different from correctness review. Correctness review asks: does the code do what it says? Adversarial review asks: can an adversary make the code do what they want?

Why these are orthogonal

Code can be structurally correct — all tests green, spec faithfully implemented — while simultaneously containing an exploitable path. The correctness reviewer reads the code knowing what it was supposed to do. An adversary doesn’t have that context and isn’t constrained by it.

This is not a failure of correctness review. It is a feature of adversarial intent: the attacker’s search space is wider than the test suite’s.

The Adversarial Gate Development (AGD) protocol formalized this in April 2026 after Sprint 004 produced seven BLOCK-severity exploits on code that had passed five correctness gates and 165 tests.

The cross-vendor form

The strongest variant runs the adversarial review with a model from a different lab than the one that built the code. Same-vendor review shares training distribution, which means it shares blind spots. A model trained by a different lab on different data has a structurally different prior — it approaches the code without the implicit assumptions baked into the builder’s training.

In practice: build with Sonnet (Anthropic), gate correctness with Opus (same vendor, high capability), gate adversarially with Codex/GPT (OpenAI — different vendor). The cross-vendor adversarial gate is the one that finds the bugs the correctness gate passes.

Over one build session on the Mumega department microkernel, cross-vendor adversarial review (Codex) found an exploitable vector in every round that same-vendor correctness review (Opus) had already passed GREEN. Six rounds, six distinct findings. See Cross-Vendor Adversarial Review: The Bug Your Own Model Can’t See for the full evidence table.

What the brief names

An adversarial review brief names the known-dangerous surfaces for the specific feature being reviewed:

  • Write paths: anywhere data is persisted — collision behavior, dedup logic, fail behavior
  • Confinement claims: capability boundaries, module isolation, never-exported symbols
  • Boundary crossings: between bundles, services, or trust domains
  • Metric computations: formulas that could produce semantically invalid values
  • Last-wins structures: any map or registry where key collision has authority implications

The adversarial reviewer starts with these surfaces, not a blank search space.

The parallel gate structure

Adversarial review runs concurrently with correctness review, not after it. This matters for one reason: if the adversarial reviewer sees a GREEN correctness verdict before reviewing, their priors are anchored. Parallel execution removes the anchor.

Both verdicts are required before merge. BLOCK from either gate stops the feature.

What this does not replace

Adversarial agent review is not a substitute for:

  • Correctness review (structural integrity, spec conformance, test coverage)
  • Human security audit on external-facing surfaces before major releases
  • Formal verification on cryptographic primitives

It is a fast, parallel gate that catches the class of bugs that correctness review structurally misses. It is most valuable on load-bearing substrate code: identity, permissions, audit chains, metric surfaces, confinement claims.

Last updated: Jun 18, 2026