The Adversary Agent: Hostile Review as a Pipeline Step

Code generated by an agent and reviewed by the same agent inherits the original blind spots. Our development pipeline runs an adversary agent, a second model invoked with a hostile-reviewer prompt and a fresh context, as a required step before merging code in sensitive areas. The pattern has since crossed from workflow into product: a skill in the Versalist registry cannot be approved for verification without an adversary report attached to the verification record. This note describes the prompt shape, the enforcement mechanism, the gate, and the failure modes we have logged, including the run that produced no output at all.

After a change is produced, a second agent is invoked with a prompt that opens from distrust: it is a hostile code reviewer and security auditor, told to find bugs, race conditions, unhandled errors, security vulnerabilities, and edge cases, and told directly not to be nice, to assume the code is broken until proven otherwise. Every finding must arrive in a fixed shape: a severity, a location down to file and line, a description, a concrete exploit or failure scenario, and a recommended fix.

The adversary can read code, search it, and execute commands to chase a suspected failure. It cannot edit anything. It would be tidy to call that toolset read-only, but it is not accurate; execution is part of how the adversary earns a finding. The boundary that matters is no write access: it can prove a race exists by running the code, and the fix still travels back as a finding rather than a quiet patch.

• 01An agent asked to write and then critique its own change defends the change. A second agent with a fresh context reaches the code with no memory of the reasoning that produced it, and no stake in it being fine.
• 02The adversary is not asked to be balanced. Its output is only findings, ranked by severity. A review that comes back empty is not a compliment; it is a data point to be suspicious of.
• 03The step is enforced structurally. The launcher appends a system-prompt rule that the adversary must be invoked after any change before work is declared done, so skipping review is a visible protocol violation rather than a judgment call made quietly.

The gate is a declared list in the development guide, not a path-matching hook: authentication, payments, the challenge data pipeline, and anything security-sensitive. The list is about asymmetry. In those areas the cost of a missed bug is not proportional to the size of the diff.

• 01Changes that touch shared state or concurrency, where the generating agent is systematically weakest at seeing its own races.
• 02Changes to evaluation and scoring logic, where a bug does not crash anything, it just makes scores quietly wrong, which is the worst failure a measurement platform can have.
• 03Deciding whether a diff falls inside the gate is still human judgment. We have not automated that call, and we would rather say so than imply a filter that does not exist.

The pattern stopped being only a development habit when we built skill verification. In the Versalist registry, approving a skill for verified status requires an adversary report attached to the verification record; the API rejects an approval without one. Verification also only lands if the revision that was reviewed is still the latest, so a report cannot vouch for code it never saw.

This is the same trade the Trace makes for scores. The unit of trust is not a reviewer saying it looked fine; it is the hostile-review artifact itself, stored where the verdict is stored.

Two are worth naming. First, on small, well-isolated changes the adversary produces speculative findings, because a prompt built from distrust will produce something even when little is wrong. The triage cost is real, and it is the argument for keeping the gate scoped instead of running hostile review on every diff.

Second, the empty run. During a documented security remediation pass, the adversary was launched and produced no review output at all. The process record from that day treats the missing report as a blocker: the change should not merge until the review is rerun and its output attached. That rule is the whole point. The absence of findings is never evidence of the absence of bugs, and a missing report blocks the merge.

What we do not claim: a measured lift with controls. We have not run that study. The claim we can back is narrower, that the adversary finds problems, concurrency mistakes, validation gaps, silent failures, that the generating agent demonstrably did not, in the diff it had just written.