Integrity and Audit

In short

Each step from the user's browser to your records is protected by the party that handles it, and Octet signs every verdict. An auditor checks a stored verdict against Octet's public key, so the check rests on the signature and not on the system that stored the verdict.

Why a signed verdict

A compliance review asks what you knew about a session when you acted on it. A verdict stored as plain JSON is only as trustworthy as the database that holds it: anyone with write access could change alarm from high to none, and nothing in the record would show it.

Octet signs each verdict with a private key that only Octet holds, and publishes the matching public key. The signature covers country, confidence, alarm and the details of the session. Changing any of them makes the signature fail. An auditor who checks the signature is relying on the cryptography, not on your records being complete and correct.

The path of one session

flowchart LR
    A[Browser<br/>collector] -->|encrypted to Octet| B[Your edge]
    B -->|mutual TLS| C[Octet API<br/>signs the verdict]
    N[Octet network hosts<br/>sign their measurements] --> C
    C -->|signed token| D[Your backend<br/>stores token and key]
    D --> E[Your auditor<br/>checks the signature]

Step	What protects it	Who can check it
The collector and edge files you run	Each release's `SHA256SUMS` is signed with cosign, and the collector has a Subresource Integrity hash.	You and your auditor, against the public release.
Browser to Octet, through your edge	The collector encrypts each collection to Octet. Your edge forwards it without being able to read it.	Octet.
Copies of a collection	Each collection carries a key kept in the browser. Octet refuses a copy of a collection it accepted recently, through any edge.	Octet.
Your edge to Octet	Mutual TLS with a client certificate Octet issued for your license, plus your license token.	Octet.
Octet's network measurements	In `full` mode, Octet's network hosts sign each measurement they take.	Octet.
The verdict	Octet signs the verdict and the session details into the token.	You, your auditor, and anyone else with Octet's public key.
Your decision record	Your own storage.	You.

Octet accepts a collection only on a connection that presents a client certificate issued for the same license as the license token.

What the browser reports

The collector encrypts each collection to Octet before it leaves the browser. Your edge forwards it without being able to read it, and Octet can tell if it was changed on the way. Each collection also carries a key kept in the browser, which lets Octet refuse a copy of a collection it has already accepted.

None of this shows that what the browser reported is true, because the user controls the browser. Scripts on your own page can also read a collection before it is encrypted, because the collector runs in the page. The published collector file is scrambled, which makes it harder to read. That doesn't make its data trustworthy either.

What a stored token shows

With a stored token and Octet's public key, an auditor can confirm that:

Octet issued the verdict. The signature verifies with Octet's key for the kid in the token header.
The verdict is unchanged. country, confidence and alarm are exactly what Octet signed.
It belongs to one session. sessionRef is the session reference you created.
It was issued at a known time. iat is when Octet signed it, and your decision falls between iat and exp.
It was issued for a network. clientNet is a hash of the user's network as your edge saw it, which the auditor can compare with the network you recorded.
It came from a known Octet release. modelVersion names the release that produced the verdict.

What a stored token doesn't show

Which user or action the session belonged to. Your records hold that link, so store the sessionRef with the user and the action.
That your records are complete. The token shows that a stored verdict is genuine. It doesn't show that you kept every verdict you fetched.
That your edge ran an unmodified Octet release. Keep the version you installed and its checksum from SHA256SUMS with your deployment records.
Where the user was. The verdict records what Octet concluded from the evidence it received.

What your auditor relies on

An auditor who checks your verdicts relies on two things:

Octet's public key. The auditor fetches it from Octet's key set, or confirms a stored copy with Octet. See Keep Verdicts for Audit.
Your records linking each sessionRef to a user and an action.

The auditor doesn't need to rely on your database, your queues, or any other system the token passed through. None of them can change a signed verdict without the signature failing.

Where to go next

Verify the Signed Token: check each token when your backend fetches it.
Keep Verdicts for Audit: store records an auditor can check, and check them later.
How It Works: one session, from page load to your policy.