Security reference
Threat model. Drawn to the byte.
You have been handed a signed evidence report and asked to rely on it before you clear a vendor's AI application. This page draws the boundary precisely: who can attack the report, what the cryptography proves, what an attacker would have to do to fake evidence at each of the A/B/C evidence tiers, and (stated plainly) what it does not cover. The envelope itself is specified at /spec.
last reviewed 2026-06-10 · key fingerprint published at /keys/kolm-2026-04.pub
Trust the math, not the vendor and not us.
The point of a signed report is to move the burden of proof off your desk. So the trust base is kept small and inspectable. Every report is signed with Ed25519 (RFC 8032) over a canonical serialization of its fields. The public key travels inside the report, and you verify the signature in your own browser using WebCrypto at /verify, offline, with no account and no call to us. Any change to a single byte of a signed field invalidates the signature. To pin our identity out of band, the current public key is published at /keys/kolm-2026-04.pub.
Ed25519 (RFC 8032) · canonical field serialization · in-browser WebCrypto · append-only Merkle log
The trust base
What you rely on
- The Ed25519 primitive (RFC 8032) being sound.
- Your own verification environment: your browser and its WebCrypto.
- A kolm public key, pinned out of band at /keys/kolm-2026-04.pub.
Three things, all inspectable. Nothing else is load-bearing.
Outside the trust base
What you do not have to trust
- kolm's servers or uptime. Verification runs offline, with no kolm server in the path.
- The network path between vendor and buyer. Tampering in transit breaks the seal.
- The vendor's account of their own results. The signed bytes are the result.
- Any login. There is no account to create and none to verify.
What the signature and the log protect
- Integrity. The contents are exactly what kolm signed, byte for byte.
- Provenance. The report was issued by the holder of kolm's signing key, not forged.
- Auditability. A report's existence and time can be checked against an append-only Merkle transparency log (Ed25519 and SHA-256, RFC 6962 style), so issuance and ordering are independently verifiable.
- Confidentiality of your inputs. The application logs and configuration given for an engagement are handled as customer data, not published.
Scope is the boundary of every claim.
A report is precise about what it covers, and silent about what it does not. The scope statement is part of the signed object, so a reviewer reads the boundary in the same bytes as the findings.
Scope is contractual. Permission posture, redaction and audit-trail integrity are assessed. Injection is tested and reported, not warranted.
In scope · assessed
What a report covers
- Least-privilege permission posture: scopes held versus scopes used.
- Audit-trail integrity and retention: append-only, reviewable activity.
- Data egress and redaction: destinations, sub-processors, what is masked.
- Prompt-injection resistance, tested and reported with reproductions.
- Model and dependency provenance.
- The signed evidence object itself: logged and offline-verifiable.
Out of scope · not claimed
What a report does not cover
- Any warranty that the application is invincible or cannot be made to misbehave.
- Systems outside the agreed scope. A report never implies coverage it does not state.
- Runtime defense or live monitoring of the application in production.
- A guarantee that no injection path exists, only the results of the tests run.
Three ways to attack a report. Two tiers that answer them.
We model a vendor who would alter their own report, a forger who would fabricate one, and a tamperer on the wire between vendor and buyer. The skeptical buyer is modeled too, as a first-class participant rather than an adversary: they should be able to confirm everything themselves.
Tamper
Edit the report, break the seal
A vendor upgrades a finding, changes a date or widens the tested scope, or a tamperer alters the report in transit. The Ed25519 signature covers the canonical bytes, so any single-byte change fails verification in front of the reviewer.
Tier 1 · signature integrity
Rogue key
Sign with a fresh key, fail the keyring
A forger fabricates a kolm-styled report for an agent we never assessed and signs it with their own key. Tier 1 clears for that key, but Tier 2 checks the issuer against the buyer's keyring, where the key is not a kolm issuer.
Tier 2 · issuer provenance
Replay
Present a stale report as current
An old or superseded report is shown as today's, or a finding is back-dated. The append-only Merkle log fixes existence and ordering, re-attestation supersedes a stale report with a signed delta, and each report names its point in time.
Append-only Merkle log
Every check above runs in the buyer's own browser, against the key inside the report, with no kolm server in the path. There is nothing for us to fake after the fact.
What forging the input evidence would take.
The signature proves the report was not altered after kolm signed it. A separate question is how strong the evidence was before kolm ever saw it. Every report grades that on its face, inside the signed bytes, as evidence_tier A, B, or C, and the grade cannot be upgraded after signing without breaking the signature. Here is what an attacker would have to do to fake evidence at each tier.
Tier A · gateway capture
Compromise capture-time hashing
Events are captured by the kolm gateway at runtime, so the evidence stream is hashed as it happens. To fake Tier A evidence, an attacker must compromise that capture-time hashing itself, at the moment of capture. Fabricating or pruning events after the fact is detectable: the report binds to a sha256 digest of the exact event stream analyzed (evidence_digest), with the event count alongside it.
method: kolm-gateway-capture
Tier B · hash-verified vendor logs
Forge a consistent chain in advance
The vendor supplies its own logs, but they carry a hash chain that kolm verifies before grading. To fake Tier B evidence, an attacker must forge an internally consistent hash chain before submission. Editing the logs after the fact breaks the chain's continuity, and a broken chain is itself a finding, not a silent downgrade.
method: vendor-logs-hash-verified
Tier C · as-provided logs
Nothing. The report says so.
Vendor logs accepted as provided, with no cryptographic continuity. There is nothing to forge because nothing is warranted about the inputs: the report states this grade on its face, in the signed bytes, so a reviewer prices the evidence accordingly. What an attacker cannot do is dress Tier C evidence up as Tier A or B; the grade is signature-covered.
method: vendor-logs-asserted
Reports issued before tiered evidence carry no grade. They render as "Evidence tier: not graded (issued before tiered evidence)" and still verify; no grade is ever invented retroactively.
Three gaps, stated before you find them.
A threat model that only lists wins is marketing. These are the attacks this system does not stop, and what limits the damage in each case.
Capture-time collusion
A vendor that fabricates before submission
For Tiers B and C, the vendor produces the logs. A vendor that fabricates a clean, internally consistent log stream before it ever reaches kolm is not detected by cryptography; no signature can reach back before capture. The defense is disclosure, not denial: the evidence tier states exactly how the inputs arrived, and Tier A exists precisely so a buyer can require capture they do not have to take on faith.
Out-of-scope behavior
Anything the engagement did not cover
Scope is contractual. Permission posture, redaction and audit-trail integrity are assessed. Injection is tested and reported, not warranted. A report never implies coverage beyond what its scope statement names, and the absence of a finding is not proof the underlying risk is absent.
Key compromise
A signature from a stolen key verifies
If a signing key were compromised, signatures made with it would still pass Tier 1. The response is revocation plus the transparency log: the key's public status flips to revoked, every verifier that checks issuer status then returns trusted:false for reports under that key, and the append-only log bounds what the key could have signed and when, because every issued report digest was witnessed at signing time.
Where the guarantee ends.
A signature is a narrow instrument, and it is more useful when its edges are clear. These are the limits we design to, and the assumptions the whole model rests on.
Integrity, not security
A signature proves origin, not invincibility
It confirms the report is genuine and unaltered, and that a kolm key signed it. It does not assert that the audited application cannot be attacked.
Tested, not warranted
Injection results reflect the tests we ran
Prompt-injection and jailbreak resistance are tested and reported, not warranted. A passing result reflects the adversarial tests run within scope, not a proof that no attack exists.
Point in time
Findings describe a moment and a fixed scope
A later code change can alter the posture. A permission granted in January can still fire in August. Re-attestation captures the change as a signed delta.
Stated scope only
No coverage a report does not state
We do not assess systems outside the agreed scope, and a report never implies coverage beyond what its scope statement names.
Key custody, rotation, revocation
What has to hold, and what happens when it does not
The model holds if the Ed25519 primitive is sound, the signing key stays under kolm's exclusive control, and the buyer's verification environment is itself untampered. The key is single-purpose: it signs evidence reports and nothing else, and only its public half ever leaves; we do not describe its storage beyond that, deliberately. Every report names the key fingerprint that signed it, so rotation is routine: a rotated key's status becomes rotated and the reports it signed stay verifiable. A suspected compromise is different: the key is revoked, the revocation is published at the public key-status endpoint, every status-checking verifier then fails reports under that key as trusted:false, and affected reports are re-attested under a fresh key. The transparency log bounds the blast radius, because what the old key signed, and when, was witnessed in the append-only log at signing time.
Reporting an issue
Found a gap in the verification path or in this model? Tell us at dev@kolm.ai before disclosing publicly, per our Acceptable Use Policy. The signing core and the verifier are open source, so the verification path can be reviewed line by line.
See also: Security · The signed report format · Verify a report · Transparency log
Rely on the signature, exactly as far as this page says.
Verify a report yourself in your own browser, or read the controls behind each finding.
Caveats: Scope is contractual. Permission posture, redaction and audit-trail integrity are assessed. Injection is tested and reported, not warranted.