description: Five architectural layers. Every AI-assisted compliance change passes all of them. Three of the five cannot be bypassed: the Verifier, the approval gate, and the canonical model. Written for your security team, your auditors, and your procurement office. The live posture, sub-processors, and data handling are on the product trust page.¶
An audit log outside the system being audited¶
Five architectural layers. Every AI-assisted compliance change passes all of them. Three of the five cannot be bypassed: the Verifier, the approval gate, and the canonical model. Written for your security team, your auditors, and your procurement office. The live posture, sub-processors, and data handling are 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.
FIPS-signed chain. Single-use, time-boxed, payload-bound approval tokens. Seven-year retention. Your auditor verifies the chain offline with an open-source tool. The mechanism is below; the live posture lives on the security posture page.
Architecture, not policy mapping¶
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 an independent LLM cross-check from a different provider than the proposer, at temperature zero, emitting 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 events table is append-only at the database layer; a trigger rejects updates and deletes, including from Kanonik operators. Each event references the previous event's hash. The chain root is signed with the tenant's key, held in OpenBao and never exported. Tampering breaks the chain and is detectable. Retention is seven years.
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 auditor export is a signed bundle: 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 record carries a tenant id, enforced by row-level security at the database and again at the application and API layers. Tenant data is encrypted at rest with a per-tenant key, wrapped by a tenant key in OpenBao. The boundary is never weakened for convenience.
The LLM provider stays yours, not ours¶
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.
The Verifier's tier-2 cross-check runs on Kanonik's own provider account, deliberately separated from whichever provider you chose for the proposer. A model cross-checking itself is not a cross-check.
Cryptography¶
Signing, key derivation, TLS, and the hash chain run in the Google CMVP-validated Go cryptographic module, FIPS 140-3 validated. TLS 1.3 externally; mutual TLS between internal services.
FedRAMP Moderate posture¶
The architecture is engineered to FedRAMP Moderate standard from the first commit: FIPS crypto in every security-critical path, NIST 800-53-aligned audit logging, a documented system boundary, and signed images with an SBOM. Kanonik is built to serve highly regulated organisations, and the platform is built to comply with that standard from the ground up.
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¶
FIPS 140-3 module. Append-only events. Signed approval token. Hash chain. Offline verifier. A human approves every consequential write, and the trust layer refuses to ship without that gate.
Data handling, sub-processors 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 retention, 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.