An audit log outside the system being audited¶
Every AI-assisted compliance change passes five architectural layers, and three of them cannot be bypassed. We wrote this page for the people who sign off on a vendor like us. The live posture is on the product trust page.
Five layers. Three of them non-bypassable¶
Your language model sits at the top, outside the trust boundary. The hash-chained audit log sits at the bottom, outside the system being audited. Between them, three layers the model cannot route around: the Verifier, the approval gate, and the canonical model.
Hash chain with a signed root. Single-use, time-boxed, payload-bound approval tokens. Append-only entries. Your auditor verifies the chain offline with an open-source tool. The mechanism is below; the live posture lives on the security posture page.
Built into the architecture¶
Non-bypassable, two-tier¶
The Verifier runs inside every commit tool, server-side, before any write can land. There is no opt-out tool and no escape hatch. Tier 1 is a deterministic rule layer in Go (control exists, framework active, mapping not a duplicate, owner assigned, similarity above floor). Tier 2 is a model check that runs on Kanonik's servers, under Kanonik's own model account, separate from the AI and key you bring, and emits only a verdict-shaped payload. Ambiguous failures route to human review, never to auto-approve.
One token, one use¶
Every consequential write requires a signed approval token, issued out of band of the AI conversation. Single-use, scoped to one operation, time-boxed to one hour, and cryptographically bound to the exact diff. The signature binds the approver's verified OIDC identity to the payload hash. In-conversation approval is structurally insufficient and the system refuses it.
Append-only, hash-chained¶
Every change derives from an event. The database rejects edits and deletes of audit entries, and any change made around that protection would break the signed hash chain and show up when the export is verified. Each event references the previous event's hash. The chain root is signed with Kanonik's chain-root key, held in OpenBao; the private key never leaves the vault. Nobody can change an entry without the change showing.
Outside the system being audited¶
The service that commits an approved change to your record is not the service that writes events into the chain. Different binaries, different credentials, different network paths. The system writing your compliance data cannot rewrite its own log.
Verified on your auditor's laptop¶
The Sealed Audit Package carries the signed chain root: the event sequence, the chain hashes, the chain root signature, the public key, the framework package, the canonical-model schemas, and a step-by-step VERIFY guide. A standalone open-source binary recomputes the chain with no network call to Kanonik. The math holds or it does not.
Per-tenant by construction¶
Every workspace's records carry a workspace id. Postgres row-level security is forced on the core record tables (events, entities, tenant settings), and the application checks the workspace on every request; some approval-workflow tables are isolated in application code only. Your data is encrypted at rest by our cloud provider (Oracle Cloud block storage, AES-256, Oracle-managed keys). Each workspace also has its own key in our vault; today it protects the workspace owner's email and the approval-channel addresses. The boundary is never weakened for convenience.
The LLM provider stays yours¶
Kanonik is the trust layer; you bring the AI. Anthropic Claude, OpenAI, AWS Bedrock, Google Gemini, or Azure OpenAI: your choice, your contract, your API key. The model provider is your direct contractor. Kanonik never becomes a layer between you and them.
What changes on your sub-processor list under GDPR Article 28: Kanonik becomes a sub-processor, one new entry. What does not change: if you already have Anthropic or OpenAI on your DPA, that line is unaffected. If you do not, you do not need to add it because of us.
A second check runs on Kanonik's servers, under Kanonik's own model account, separate from the AI and key you bring. Today it uses an Anthropic model, so if your AI is Claude the check comes from the same model company.
Cryptography¶
Our Go services use Go's FIPS 140-3 module, in FIPS mode. Our signing keys live in OpenBao.
Every connection from the internet uses TLS 1.2 or 1.3, terminated at Cloudflare. Our application services talk over mutual TLS, and to the database over TLS. Calls to the key vault and the sign-in service stay on the private network behind network policies and are not yet encrypted.
NIST SP 800-53 design choices¶
We build Kanonik to NIST SP 800-53, the control set FedRAMP is built on. Two examples are the append-only audit log and mutual TLS between services.
Framework mapping¶
The architecture maps back to control families control by control: the Verifier and reasoning-trace export to NIST 800-53 AU-12, the approval gate to AU-10 non-repudiation, the hash chain to AU-9 and AU-11, and the append-only store and traceability to EU AI Act Article 12. The Statement of Applicability and full mapping are available under NDA.
The architecture is the claim¶
What is running today¶
Go's FIPS 140-3 module, in FIPS mode. Append-only events. Signed approval token. Hash chain. Offline verifier.
Nothing your AI drafts reaches your compliance record without an approval from a signed-in person's account. Every policy, control, risk, mapping, piece of evidence or decision it drafts is checked on our servers first. It then waits until someone signed in to your workspace approves it, with a click on the single-use approval link or in the dashboard, and the approval is recorded against that person's account. Asking in the chat is never enough. Kanonik cannot tell whether the person, or software acting in their signed-in browser, made the click. A few things are saved without an approval; they are listed in Why you approve every change.
Data handling and the DPA¶
This page covers the mechanism. The security posture page carries what a reviewer signs off against: what we store and what we never hold, our sub-processors, data residency, and the DPA to sign before you connect. Read the security posture page.
The line on which audit defensibility turns is whether non-repudiation, traceability, and human oversight are satisfied by architecture or by paperwork. Kanonik satisfies them by architecture, then maps the architecture back to the control text.
The proof is the product.