Roughly eight thousand stars. Somewhere between a hundred and a hundred and twenty probe families. Used inside frontier labs, inside banks, inside consultancies producing reports that end up in front of risk committees.

And no signature on the output.

That is the state of the most widely adopted open red-teaming tool for language models, and it is not a criticism of the people who built it. It became infrastructure while it was still a research tool, and signing was never in scope for a research tool. The same is true of the reinforcement-learning-based red-teaming toolkit from Microsoft, of the evaluation framework from the UK's AI Safety Institute, of the agent-attack benchmark suite, and of the public task suite from the leading independent evaluation organisation.

Every one of them produces, as its final artefact, a file. A file that cannot be distinguished — by any mechanism available to the person reading it — from a file somebody edited.

I want to take that fact seriously for the length of this edition, because it is the first of three structural problems with how agent assurance gets measured, and the three compound. The evidence is unattributable. The target is wrong. And the scoring hides the answer. Taken together they explain why an organisation can commission a red team, receive a clean report, and have learned almost nothing.

Part one: the evidence is unattributable

Start with the question a supervisor will eventually ask about a red-team report, and which almost nobody can currently answer.

Which model version was this run against? By whom? With which probe set, at which version? On what date? And can you demonstrate that the result you are showing me is the result the tool produced?

Every part of that is answerable in principle. Almost none of it is answerable from the artefact. The report says what was tested because somebody typed what was tested. The binding between the claim and the run is a human assertion, made in prose, in a document that anyone with write access can amend.

Compare this to how the same industry treats software artifacts. Container images are signed. Package registries have attestation. Build provenance has a specification, a transparency log, and adoption. The supply chain for code got taken seriously and the tooling now exists and is used.

The supply chain for assurance evidence did not. A report asserting that a model passed a safety evaluation carries less cryptographic weight than the container it runs in.

Why this is a two-week problem that nobody has done

The fix is not research. It is plumbing, and the reason it has not been done is that it sits between two communities.

The scanner maintainers are researchers optimising for probe quality and coverage, correctly, because that is where the scientific value is. The signing and transparency community builds infrastructure for artifacts, correctly, because that is where the supply-chain risk was. The gap is a small integration: wrap the scanner run, capture the inputs that identify it — target digest, probe-set version, configuration, timestamp, operator identity — and sign the result together with the output.

The design decision that matters is what the signature attests. It does not attest that the model is safe. It attests something much narrower and much more useful: this output was produced by this tool, at this version, against this target digest, under this configuration, at this time, by this identity. Everything about whether the result is good remains a matter for the reader's judgement. What the signature removes is the possibility of quietly disagreeing about what was run.

The corollary I hold to, and would recommend: build no scanner. The open ecosystem's probe corpora represent years of accumulated adversarial knowledge that nobody should rebuild, and a new scanner competing with them for attention makes the ecosystem worse. Sign what the commons already produces.

Part two: the target is wrong

The second problem is larger and it took me longer to see, because it hides behind a field that is visibly productive.

Look at what the major agent-safety benchmarks measure. One suite places a model in a simulated environment with injected adversarial content and asks whether it can be induced to misbehave. Another catalogues harmful agentic behaviours and measures refusal. A third measures susceptibility to indirect prompt injection through tool outputs. A fourth measures what a model is capable of achieving on autonomous tasks.

These are good instruments. I am not disparaging any of them.

But notice what every one of them has as its subject. The model. Does the model misbehave, refuse, get injected, succeed.

Now ask the question that decides whether an agent reaches your production database: can the layer beneath the model be made to grant authority it should not?

Nothing measures that. Not one of those suites. The entire evaluation field is aimed one level too high.

Why the level matters more than it sounds

Consider what "the model was successfully injected" actually means for an operator. It means an attacker got the model to attempt something. Whether that attempt reached anything is a completely separate question, decided by a completely different layer: whether the credential was valid, whether the tool was in scope, whether the delegation chain permitted it, whether the egress path existed, whether the action committed before evidence was durable.

An organisation with an excellent injection score and no authority substrate is an organisation whose model resists a class of attack until it does not, at which point nothing is in the way. An organisation with a mediocre injection score and a substrate that refuses out-of-scope actions deterministically has a worse benchmark number and a better outcome.

We have built an entire measurement discipline around the first number.

What testing the other level looks like

The specification I have been working on approaches this by taking the system's own formal invariants — statements like no action without an active identity, authority never expands along a delegation chain, evidence precedes commitment, failure is safe, an agent cannot modify its own enforcement boundary — and building one adversarial suite per invariant, whose job is to make that specific invariant false.

That is a different exercise from red-teaming a model. It has different failure modes, different affordances, and it produces a different kind of finding: not "the model can be persuaded to try X" but "under conditions Y, the substrate granted authority it should not have."

I want to be honest about status. That corpus is specified. It is not complete. In the honest ledger for this project it sits in the category of things established from the source rather than observed running, and I am not going to describe it otherwise in a piece complaining about unverifiable claims.

Part three: the scoring hides the answer

The third problem is the one I find most interesting, because it is a reporting decision rather than a technical gap, and reporting decisions are where good measurement usually dies.

If you are testing an authority substrate, there are three questions worth asking, and they are not the same question.

Does it match the specification? Run golden test vectors. Deterministic, cheap, repeatable.

Can it be broken? Run the adversarial corpus. Non-deterministic, expensive, and dependent on how hard you tried.

Can it stop? Run containment — can the system reach a defined safe state within a bounded time, and does it fail closed when components fail.

Those three can disagree, and the interesting cases are precisely the disagreements. An implementation that passes vectors and fails the corpus is the common and instructive case, because vectors test what the author thought of and the corpus tests what an attacker thinks of. An implementation that passes both and fails containment is a system that is correct right up until you need it to stop.

So the rule is: never blend them. Report three results. A single aggregate number across the three destroys exactly the information that matters — and worse, it lets a weak result in the expensive suite be carried by a strong result in the cheap one.

Which is what a single score always does. Aggregation moves weight toward whichever component is easiest to score well on, and in this case that is the deterministic vector suite, which is the least informative of the three.

The rule that makes a clean sheet suspicious

Here is the piece of the specification I would most like other people to steal.

A corpus run with zero violations must be reported as requiring review, not as a pass, until a human has reviewed how hard the attacker actually tried.

The reasoning is straightforward once stated. An adversarial suite measures the interaction of two things: the system's robustness, and the elicitation effort. A zero-violation result is consistent with a robust system. It is equally consistent with a suite that did not try hard, a target that recognised it was being tested, or a configuration that quietly disabled the interesting cases.

In a benchmark, those are the same number. In an assurance report, they are opposite conclusions.

So the harness refuses to emit a clean pass on its own authority. It reports the clean sheet, flags it for review, and requires somebody to look at the elicitation before the result can be called a pass. A clean result is a suspicion, not a conclusion.

Three further rules follow from the same reasoning, and each closes a way a suite can be gamed without anybody lying.

Every case declares its elicitation method, its affordances, and its noise floor. A case missing any of the three is marked indeterminate and excluded from scoring rather than counted as a pass. That distinction is load-bearing: counting an unmeasurable case as a pass is how a suite drifts upward over time without anybody making a decision.

At least one unannounced run per capability. A system under test that knows it is under test is measuring something other than what you want to know.

A rotating held-out fraction, reported separately. Otherwise implementations get tuned to the published set, and the number stops tracking the property.

And the rule about what is not in the report

One more, because it is the shortest sentence in the whole specification and the one with the most teeth.

A language absent from the report has not been verified. Absence is reported as absence, never as a pass.

The context is cross-language equivalence: where multiple language bindings expose the same security-relevant operation, they must agree byte for byte on the canonical serialisation, the digest, the verdict, and the denial gate. A divergence is a release-blocking defect rather than a binding-specific quirk to document, because a divergence means either a binding re-implemented something it should have called, or the canonicalisation is not actually deterministic — and both are the failure the rule exists to prevent.

The absence rule matters because the cheapest way to pass a conformance suite is to not run it on the thing that would fail. A report that silently omits an untested binding looks identical to a report where everything passed.

What this looks like when you apply it to yourself

I ran a version of this discipline against a safety classifier I had wired into my own system, and it produced two results worth reporting.

The first: the classifier's published figures had been measured under one configuration, and the configuration actually running was different. Not worse, necessarily — unknown, while the console and the documentation quoted the published numbers as though they described what was running. The parity discipline that this project applies rigorously to fine-tuned models was not being applied to the shipped one.

The second: I ran a small hand-written bench of fourteen cases against the live model. It reported recall of 0.875 with a confidence interval running from roughly 0.53 to 0.98, and a false-positive rate of zero with an interval running to roughly 0.39.

Look at those intervals. Fourteen hand-written cases cannot measure a classifier. The interval on the false-positive rate spans from "excellent" to "unusable." What that bench established was not performance — it was that the configuration running here is the configuration the published figures came from. That is a useful thing to establish and it is a much smaller thing than a measurement, and reporting it as a measurement would have been the exact failure this edition is about.

I report the intervals for that reason. A point estimate without an interval is a claim dressed as a result.

What to check on Monday

One. Take your most recent red-team or safety-evaluation report. Ask what binds it to the run: which target digest, which probe version, which operator. If the binding is prose, the report is an assertion.

Two. For every safety benchmark number your organisation quotes, ask whether its subject is the model or the layer beneath it. Then ask what number you have for the second.

Three. Find any assurance report that produces a single aggregate score. Ask what it aggregates. If specification conformance and adversarial resistance are in the same number, the number is uninformative in a predictable direction.

Four. Find a clean result in an adversarial evaluation. Ask what the elicitation was, and whether the system knew it was being tested. If nobody can answer, the clean sheet is a suspicion.

Five. For any conformance or coverage report: check what is not in it. Ask whether an untested component appears as absent or does not appear at all. If it does not appear, you cannot tell a pass from a skip.

What I am not claiming

I am not claiming the open scanners are deficient. They are the accumulated adversarial knowledge of the field, and the argument here is that their output deserves better handling than it gets, not that the tools need replacing.

I am not claiming the model-level benchmarks are wrong. They measure what they measure, competently. The argument is that the field has only one level instrumented and treats it as though it had two.

And I am not claiming to have built the corpus that tests the other level. It is specified and it is incomplete, and that status is marked in my own ledger. A piece arguing that unverified claims are the problem cannot make an exception for its author's roadmap.

The invitation

This one is concrete and small enough to actually happen.

If you run an open scanner in anger — in a lab, a bank, a consultancy, anywhere the output ends up in front of somebody who has to decide something — I want to sign your output.

Not replace your tooling. Not change your workflow. A wrapper that captures the target digest, the probe-set version, the configuration and the operator identity, and emits a signed record alongside the report you already produce, verifiable by someone who does not have your credentials.

I want two things from you in exchange: the fields you actually need captured, which I will get wrong from the outside, and an honest answer about whether the signed artefact makes any difference to the conversation you have afterwards with your risk function. If it does not, the idea is worth less than I think it is, and I would like to find that out from someone who runs the scanner rather than from my own reasoning.

Claims register

  • The leading open LLM red-teaming tool has roughly 8,000 stars and 100–120 probe families · project repository · read
  • It does not sign its output; nor do the other four named suites · project documentation and output formats · read — no signing mechanism found in any
  • Major agent-safety benchmarks take the model as their subject · published benchmark descriptions · read
  • No published benchmark tests whether an authority substrate can be made to grant authority it should not · my search of the field · read — a negative; established by search, not by exhaustive proof
  • The conformance harness separates vectors, corpus and containment and forbids blending them · conformance harness specification, §1 · verified — in source
  • A zero-violation corpus run must be reported as requiring review rather than as a pass · conformance harness specification, §3 · verified — normative in source
  • Cases missing elicitation method, affordances or noise floor are indeterminate and excluded from scoring · conformance harness specification, §3 · verified — normative in source
  • Cross-language divergence is release-blocking; absence is reported as absence · conformance harness specification, §2 · verified — normative in source
  • The invariant attack corpus is specified and incomplete · project ledger · verified — status marked in source
  • A shipped classifier was running at a configuration different from the one its published figures were measured at · code and measurement scripts · verified — observed, and fixed
  • A 14-case bench returned recall 0.875 [0.529, 0.978] and FPR 0.000 [0.000, 0.390] · bench run on this machine · verified — observed; explicitly not a measurement of the classifier
  • Signing scanner output is integration work rather than research · my assessment · read — an engineering judgement, not a measured estimate

What would falsify the central argument: a published suite that takes an authority substrate rather than a model as its subject, or a widely used scanner that does sign its output. Either would mean the gap I am describing is narrower than I think, and I would rather be corrected than be first.