Comments Are Claims

A pharmacist fills a prescription and reads the label out loud. Right drug, right dose, right patient. The label is clear, printed, confident. And then, in a well-run pharmacy, the pharmacist does something that looks redundant to anyone watching: they check the actual pills against the actual prescription, because the label is a claim about what is in the bottle, and the pills are what is in the bottle. Labels and bottles disagree often enough that an entire discipline exists to catch the gap. Nobody has ever been harmed by a correct label. People have been harmed by trusting one.

I keep that image close because it names the exact mistake I watched our own codebase make. We had two live security vulnerabilities sitting in production code, and both of them were wearing a confident, printed, completely false label.

The comment that lies is more dangerous than the bug that hides

During a security review of the org's own codebase, we found two real vulnerabilities. That part is ordinary; every codebase has them. The part that stopped me was where they were hiding.

Each one sat directly beneath a confident comment asserting that the exact thing that was broken had been handled. An annotation saying the input was checked, sitting on top of code that did not check it. A note swearing the path was safe, above a path that was not. These were not sloppy comments. They were confident ones, and their confidence is precisely why they had survived earlier review. A reviewer reads the comment, the comment is plausible and self-assured, the reviewer's eye relaxes at exactly the line where it should have sharpened. The lie did not slip past review despite being confident. It slipped past because it was confident.

Reading found the comments plausible. Only running the claimed behavior found them false.

A security comment is not documentation. It is a claim awaiting an experiment, and until you run the experiment it is decoration.

Here is the thing that makes this sharper in an agent org than it has ever been in a human one, and it is the whole reason this paper exists. The same process that writes the code writes the prose about the code. Generative models produce a fluent, confident "input validated here" with exactly the same ease, and exactly the same failure modes, as they produce the validation itself. The comment, the pull-request description, the reassuring "verified safe" annotation: all generated by the same author, with the same blind spots, as the thing they describe.

Which means reviewing AI-written code by reading its AI-written assurances is asking the author to audit itself in a slightly different font. That is the exact trap the series warns about one level up (No One Audits Themselves is the paper on why the actor that produced the work cannot be the actor that clears it). Same author, same blind spots, now pretending to be a second opinion.

The floor is behavioral, not textual

If reading cannot be trusted to catch what reading wrote, the verification floor has to move. It moves from what the code says about itself to what the code does when you push on it. In our remediation practice, that shift shows up as a set of disciplines that would look paranoid in a normal shop and look like the bare minimum in this one.

Start with the injection-class fix. When we hardened a boundary that hostile input could reach, we did not verify the fix by reading the patch and nodding at it. We fired the actual attack strings at the live function after it was deployed. Real hostile inputs, aimed at the real running code, rejected as they should be, and then the legitimate read confirmed still intact right behind them. The patch's own description of itself was not admitted as evidence. Its behavior under attack was.

Then the discipline I would tattoo on a junior engineer if it were legal. When a fix closes an attack path, the agent verifying it first reproduces the attack against the pre-fix code, proving the test can actually detect the vulnerability, and only then shows the same attack failing against the fixed code. This sounds pedantic until you have been burned by its absence. A test that passes after the fix proves nothing on its own, because a test that was never capable of failing passes after everything. A green checkmark from a test that could not have caught the bug is not evidence of safety. It is a smoke detector with no battery, chirping cheerfully in a house that may or may not be on fire. The negative has to have once been a positive, or the negative is a decoration too.

And the multiplier that turns a single bug into a real fix. When we tightened a guard or an allowlist, the reviewing agent did not stop at reproducing the one reported issue. It red-teamed the exemption seam itself, the set of paths the guard deliberately still permits, and it found several more ways through that nobody had reported, all closed before the change merged. The reported bug is never the whole bug. It is one sample drawn from a distribution, and the seam the guard permits is the shape of that whole distribution. Fix the sample and you have fixed the sample. Interrogate the seam and you have fixed the class.

Rules you can adopt on Monday

None of this is exotic. It compresses into four rules a team can put into practice immediately, and every one of them is about refusing to accept a claim you have not executed.

A security comment is a claim. The review either runs it or strikes it. There is no third option where the comment gets believed because it sounded sure of itself. Every closed attack path ships with a test that reproduced the attack first, so the test has demonstrated it can see the thing it is guarding against. Every tightened guard gets its exemptions red-teamed, not just its one reported failure re-run. And "the build is green" stays exactly what it has always been: necessary, and nowhere close to sufficient. Live behavior gets checked against live systems, and the evidence of that check attaches to the change record so the proof outlives the memory of the person who ran it (Logs Are Not Audit is the paper on why that record has to be queryable and not just a pile of console output).

The cost objection, answered by who is doing the work

I can hear the pushback from the back of the room, and it is a real constraint, not a strawman. This is expensive. You cannot execute every claim, reproduce every attack, and red-team every seam in a codebase of any size. There are not enough hours. Triage by blast radius, sure, the same way you already triage testing, but do not pretend this scales for free.

The blast-radius triage is correct and you should do it. But the "not enough hours" half of the objection quietly assumes the hours are yours, and in an agent org they are not. The reason this discipline is affordable here and punishing everywhere else is a structural fact, not a motivational one: the agent doing the verifying is not the agent that wrote the code, and its time is not your scarce human resource (No One Audits Themselves again, cashing out as economics this time). Reproducing the attack, firing the strings, probing the seam, this is exactly the tireless, adversarial, deeply boring labor that a separate verifying agent is built to do and a tired senior engineer at 6 p.m. is built to skip. The expensive-sounding floor gets cheap precisely when the verifier is not the author and not human.

What is actually expensive is the other path, and its price is just deferred. It is paid later, in an incident channel, at a worse hour, with a customer's name attached, for a vulnerability that shipped under a comment swearing it had been handled.

Autonomy is only as real as your assertions

The first paper in this series argued that constraint produces autonomy, that structure is what lets an org move fast without flying apart (Trust Scales with Structure). This paper is that same claim turned toward what the org believes about itself. An organization gets to act autonomously exactly to the degree that its statements about itself are true, and its statements are only reliably true to the degree that they are executed rather than believed.

An org that reads its own confident comments and trusts them is an org that has automated the production of reassurance. That is not safety. That is a very fast pharmacy that stopped checking the pills because the labels always look so sure. Run the claim. The bottle is the only thing that was ever true.

References

1. SpeyAI, Rise of the Agent Org library. Companion papers: No One Audits Themselves (the closest sibling, on why the author cannot clear its own work, and here the source of both the epistemics and the economics); Logs Are Not Audit (why executed-verification evidence attaches to a queryable record); Trust Scales with Structure (constraint produces autonomy, of which this is the epistemic case); Gates Ship Dark (shadow-mode measurement as the same execute-do-not-believe discipline applied to controls).

This paper is part of Rise of the Agent Org, a series by Ed Hoehn, SpeyAI. The full library is at speyai.com/record.