A security or quality report you have to take on trust is marketing. A sealed, independently checkable one is evidence. The difference is the whole product.
Dennismary Chidiebere31 July 20265 min read
Operator Notes
Get the next essay in your inbox.
Field notes from building, deciding and carrying the cost of clarity.
A vendor sends you a PDF that says your API is clean. A green badge, a pass, a signature at the bottom. What exactly do you now know?
You know the vendor is willing to tell you it is clean. That is all. You cannot tell whether the scan finished or died halfway. You cannot tell whether a finding was quietly edited out between the run and the report. You cannot reproduce the result yourself. You are being asked to trust the messenger, and in security the messenger is the one thing you are not supposed to trust.
I think that is backwards. A verdict about whether software is safe should be something the customer can check without the vendor in the room.
Trust is the wrong primitive
The industry has normalised a strange arrangement. The party that produces the verdict is also the only party that can vouch for it. If you doubt the report, your only recourse is to doubt the company, and the company's answer is, in effect, "trust us."
That works right up until it doesn't: a dropped scan reported as a pass, a finding that disappears, a result that cannot survive an auditor's second look. The failure mode is not malice. It is that nothing in the arrangement makes tampering or truncation visible. A report you cannot independently check is indistinguishable from a report that was never really run.
So I built the opposite into Dino from the start. A verdict is not an assertion you accept. It is an artefact you verify.
Determinism first
Before a result can be verifiable, it has to be reproducible. If the same system under the same policy could return a different answer tomorrow, there is nothing stable to seal.
So Dino's verdicts are not AI judgements. The reasoning that explores a system is AI-assisted, but the verdict itself comes from executed evidence, evaluated deterministically against defined requirements. The same evidence under the same policy produces the same result, every time, on any machine. That is the foundation. A verdict you can reproduce is a verdict you can argue about on even terms.
It also forces honesty about coverage. A run that could not reach everything says so, in the result, with the reasons. It is never rounded up to clean. A gap reported as a gap is worth more than a pass that was quietly incomplete.
Seal the bytes
Here is the mechanism. Every result is built by a single constructor into fixed sections (identity, scope, verification, operations, findings, verdict, provenance) and then serialised canonically: the same bytes, in the same order, regardless of operating system, runtime or locale.
Those canonical bytes have a SHA-256 digest. That digest is the identity of the result. When a result is submitted, the cloud recomputes the digest from the bytes it received and rejects it on any mismatch. A partial scan cannot be dressed up as a complete one. A finding cannot be edited out after the fact, because changing a single byte changes the digest, and the changed digest no longer matches what was sealed.
This is what tamper-evidence actually means. Not a promise that nobody touched it. A guarantee that if anyone did, verification fails loudly.
The Verification Foundry
An interactive model of Dino's core loop that seals a real result with a live SHA-256 digest and lets you tamper with it.
The Verification Foundry
An interactive model of Dino's core loop that seals a real result with a live SHA-256 digest and lets you tamper with it.
An interactive model of Dino's core loop that seals a real result with a live SHA-256 digest and lets you tamper with it.
Interactive figure: The Verification Foundry. An interactive model of Dino's core loop that seals a real result with a live SHA-256 digest and lets you tamper with it.
Seal a result, change one byte, and watch verification fail. The digest is the result's identity, and it does not forgive edits.
Fig. 1The Verification Foundry. Seal a result, change one byte, and watch verification fail. The digest is the result's identity, and it does not forgive edits. Open the full exhibit
No key to leak
A digest proves integrity. It does not prove origin. For that the result is signed. And the way it is signed matters as much as the fact that it is.
Dino signs results keylessly with Sigstore(opens in a new tab), wrapped in an in-toto statement. Keyless is the important word. There is no long-lived signing key sitting in a vault waiting to be stolen, rotated, or mishandled. The signature is bound to an identity through short-lived credentials, recorded in a transparency log. There is no shared secret between Dino and the customer, and no key whose leak would quietly invalidate every attestation ever issued.
For an artefact you hand to an auditor, "there is no key to leak" is not a detail. It is the difference between a chain of custody and a single point of failure.
Verify without calling home
The last piece is the one that changes the power dynamic. The customer checks the result themselves.
dino verify validates any result offline, against a signer policy fixed by Dino's cloud. It confirms the bytes match the digest and the signature matches the identity, without phoning back to Dino, without a running account, without trusting that the server answering is being honest right now. A deploy pipeline can accept a verdict that arrived from anywhere, because it is not trusting where the verdict came from. It is checking the verdict.
That is the whole inversion. The customer is no longer asking Dino to be trustworthy. The customer is holding a sealed artefact and verifying it with mathematics they control.
Evidence beats reputation
Reputation is a fine thing to have and a terrible thing to depend on. It tells you nothing about this result, on this day, for this change. It cannot be checked by an auditor who has never heard of you. It does not survive the one time something goes wrong.
A sealed, deterministic, independently verifiable verdict depends on none of that. It stands on its own bytes. Anyone can check it, including people who do not trust the company that produced it, especially them.
The best thing a security report can say is not "trust us." It is "don't. Check."
Exhibit 02 · Dino
Fig. 02Verification foundryChoose an API · Approve or decline · TamperAuthorisation: probing the running API.
The API
The run
Changes one byte after sealing.
Readout
Operations discoveredlive introspection
37 / 37
Credential
In custody · agent never saw it
Approval
Authorised by a person
Agents run
2 / 7
Findingssynthetic
1
Verdict
Waiting
Digest
Waiting
Offline check
Waiting
Authorisation: probing the running API.
What happens, step by step
✓
done
Reads the schema from live introspection and inventories all 37 operations.
✓
done
An OAuth2 client secret is needed. The agent sends the person a link; they enter it into custody themselves. The agent never sees it.
✓
done
The agent proposes where and how the scan runs. Only the person can authorise it; Dino refuses that decision from the agent.
4
running · seven agents in sequence
Each agent probes one failure class of the running API under a share of the time budget.
5
Findings are grouped by operation. Anything that looks like a credential is redacted before evidence is stored.
6
One constructor builds the result as canonical bytes. Its SHA-256 is the digest that gets signed.
7
The digest is recomputed from the bytes and matches. The result is verified offline.
The digest is a real SHA-256 of the sealed result: tamper with one byte and it no longer matches.