Security and trust layer
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.
The five layers
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.
The mechanism
Architecture, not policy mapping.
How each layer is enforced, in concrete terms. The architecture is the evidence, not a vendor reconstruction.
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 15 minutes, 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 writes proposals into an external GRC tool 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.
Bring your own model
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. This is a design-for posture and a roadmap item; Kanonik does not hold a FedRAMP authorization today.
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.
Where we are today
Pre-certification today. The architecture is the claim.
The architecture above is built and shipped. Framework availability and standard-text licensing are on the public frameworks page. Kanonik runs ISO 27001:2022, SOC 2, GDPR, and NIST CSF 2.0 today.
What is shipped
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.
What we do not claim
We do not display badges we have not earned. No SOC 2 attestation, no ISO 27001 certificate, no FedRAMP authorization, no autonomous mode. If you see a Kanonik page claiming something we have not earned, it is a defect; email [email protected] and we will fix it.
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.