threat model

What it defends. What it doesn't.

A signed artifact is only useful if the threat scope is honest. Below: the five attacks the receipt chain catches, and the four it doesn't. Plus the cryptographic primitives behind both.

Primitive: the receipt chain

Every .kolm artifact emits a chain of HMAC-SHA256 hashes anchored on the manifest. At runtime, every output is signed against the chain. The verifier walks the chain backwards from the output to the manifest hash; any tampered link breaks verification.

// at compile time
manifest_hash   = SHA256(manifest.json)
model_hash      = SHA256(model.gguf)
lora_hash       = SHA256(lora.bin)
recipes_hash    = SHA256(recipes.json)
recall_hash     = SHA256(recall.sqlite-vec)

artifact_root   = HMAC-SHA256(secret, manifest_hash || model_hash ||
                              lora_hash || recipes_hash || recall_hash)

// at run time, every output gets a fresh receipt
output_receipt  = HMAC-SHA256(secret, artifact_root ||
                              SHA256(prompt) || SHA256(output) ||
                              timestamp || run_nonce)

// verification (anyone can run, no secret needed if signed by registry)
verify(output, receipt, artifact) => ok | tampered

What kolm defends against

defends · t1

Artifact tampering

Anyone modifies model.gguf, lora.bin, recipes.json, or recall.sqlite-vec inside a .kolm file. Receipt chain breaks; kolm verify fails immediately.

defends · t2

Output substitution

Adversary swaps a real model output for a forged one before the user sees it. The forged output's receipt does not chain to a valid artifact_root; verifier rejects.

defends · t3

Manifest forgery

Attacker writes a fake manifest claiming to describe a different artifact. Manifest hash diverges from artifact_root; verification fails on first link.

defends · t4

Recall index poisoning

Adversary edits the bundled sqlite-vec index to add or remove documents. recall_hash diverges; chain breaks. (This is why we ship the index inside the artifact, not alongside it.)

defends · t5

Replay across artifacts

Attacker copies a valid receipt from artifact A to claim it came from artifact B. Receipt embeds artifact_root; verification against B fails because A's root ≠ B's root.

defends · t6

Quality regression smuggling

Adversary swaps the LoRA delta with a deliberately worse one (e.g. trojan-trained). K-score gate rejects at compile time; manifest records both the K-score and the held-out test set hash.

What kolm does not defend against

out of scope · n1

Model-level adversarial prompts

If your prompt is jailbroken, the artifact will sign whatever the model produced. Receipts prove provenance, not safety. Use guardrail layers separately.

out of scope · n2

Compromised compile environment

If the machine running kolm compile is compromised, the attacker can produce a valid signed artifact with poisoned weights. Use a clean build environment; consider air-gapped compile for high-stakes use.

out of scope · n3

Side-channel timing inference

An attacker observing inference timing on shared hardware may infer aspects of input or output. The receipt is a content integrity primitive, not a confidentiality primitive. Use trusted hardware (SEV, TDX) for adversarial multi-tenant.

out of scope · n4

Human at the keyboard

Receipts prove what the artifact said. They cannot prove that the human who saw the output then acted on it correctly. Audit trail ends at the model's output; downstream business logic is your responsibility.

Trust roots

componentsignsverifies against
user secret all artifacts you produce locally your own pubkey (or registry-stored fingerprint)
Kolmogorov registry co-signs published artifacts; signs spec versions public registry pubkey at /v1/registry/pubkey
Recipe registry deterministic-pattern packs (recipes.json) RS-1 spec hash, MIT-licensed at /docs/rs-1.md
on-chain anchor (enterprise) root hash anchored in Bitcoin OP_RETURN or Arweave block height + tx hash, public

What an attacker would have to compromise

To produce a forged artifact that verifies as legitimate kolm output, an attacker would need simultaneously: (a) the user's signing secret or the Kolmogorov registry's signing secret, (b) a SHA-256 second-preimage on the manifest, and (c) if registry-co-signed, a second compromise on the registry side. The cost of all three is the cost of breaking SHA-256, plus social engineering against two parties.

For artifacts anchored on-chain (enterprise), forgery additionally requires rewriting the anchored block, which requires the cost of attacking the underlying chain.

Reporting

Found a way around any of T1–T6? Email security@kolm.ai with reproduction steps. Bounty brackets are listed on trust. Coordinated disclosure window: 90 days standard, 14 days for actively exploited.

Honest scope

kolm is an integrity primitive, not a safety primitive. The receipt chain proves what was said by which artifact. It does not prove the model said something safe, true, or aligned with your policy.

Pair with: prompt-side guardrails, output filters, downstream business logic. The receipt chain is the substrate underneath those layers, not a replacement for them.

trust center · security policy · RS-1 spec