How to check what Neriq says, without believing Neriq.
Every Neriq scan produces a receipt: a signed, tamper-evident record of the reads that scan made. This page explains what that receipt proves, what it deliberately does not prove, and how to check one yourself with nothing from us but a public key.
What a receipt is
A record of every read a scan performed, sealed so it cannot be quietly changed afterwards. Edit, insert, delete, or reorder one record after signing and verification fails, because the stored records are recomputed against the signature on every visit.
What the signature covers, exactly
Six fields, and we name them rather than saying "the receipt is signed" and leaving you to assume the rest:
- recipe
- organization_id
- scan_id
- chain_head
- record_count
- summary
Two fields on a receipt are not covered: signed_at and receipt_id. Holding one genuine receipt, anyone can relabel those two and the published verifier still reports valid. Both are shown on a receipt because a reader needs the id to correlate it, and both are labelled there for what they are. We would rather publish that than have you find it.
What it does not prove
A signature closes tampering. It says nothing about whether a check was the right check, whether the reading was interpreted correctly, or whether an organisation is compliant. Those are judgements, and an auditor makes them. What the receipt removes is the question of whether the record in front of you is the record that was made.
How it is sealed
ECDSA_SHA_256
What a scan can read, and what it structurally cannot
Every read a scan records falls into one of 4 categories. The set is closed, so this is the whole list:
- Configuration metadata
- Settings and feature flags, like whether branch protection is on.
- Identity metadata
- Account-level facts, like whether two-factor auth is enforced.
- Access evidence
- Who or what can reach a resource, never the resource content.
- Security posture state
- On or off security states, like Dependabot alerts being enabled.
There is no content category. Source code, files, messages, and customer records are outside what the scanner can record, because the category list is a closed set and none of its entries is content.
Check a receipt without us
The signing key is never taken from the receipt, because a receipt carries its own public key and that is forgeable. It is looked up by key id in a registry we publish separately, so a receipt Neriq did not sign cannot verify. Both files below are live right now.
the standalone verifier (node, zero dependencies)
curl -O https://app.neriq.ai/verify-receipt.mjs node verify-receipt.mjs https://app.neriq.ai/api/receipt/<receipt-id>
It fetches the key registry itself. Nothing to configure, and nothing you have to take from this page.
the trusted-key registry, out of band
https://app.neriq.ai/verify-receipt-keys.json
Committed to the repository as well as served, so a change to it is diff-visible rather than silent. Key rotation is additive: historical receipts keep verifying under the key id that signed them.
the raw envelope, if you would rather write your own check
https://app.neriq.ai/api/receipt/<receipt-id>
Getting a receipt to check
There is no public list of receipts, and there is not going to be one: a receipt names the organisation it belongs to. A link comes from the organisation that ran the scan. If you were sent one and it no longer resolves, that organisation revoked the share link, and the scan and its signed record are unchanged behind it.