Trust layer & Security
An audit log outside the system being audited.
Five architectural layers. Every AI-assisted compliance change passes all of them. Each one binds to specific NIST SP 800-53 Rev. 5 control families and EU AI Act Article 12 paragraphs - by architecture, not by policy mapping.
Written for your security team, your auditors, and your procurement office.
The trust layer
Five layers. Three of them non-bypassable.
Your AI sits at the top. The hash-chained audit trail sits at the bottom, outside the system being audited. Between them, three layers the AI cannot route around: the canonical model, the Verifier, and the signed approval gate. The layer-by-layer diagram and the step-by-step flow live on how it works.
This page is the proof: how each layer is enforced, what it maps to in NIST SP 800-53 Rev. 5 and EU AI Act Article 12, and what your auditor can verify without us. Not policy, not promises, not vendor reconstructions: architecture.
The Verifier
Non-bypassable means server-side, every proposal, no flag.
The Verifier is the central trust mechanism. It runs inside every commit_* MCP tool before any write can land. There is no opt-out tool, no escape hatch, no developer mode. A misconfigured Verifier (missing API key, missing model access) fails the service health probe; Kubernetes will not roll out a replica that cannot enforce the gate.
It runs in two tiers. Tier 1 is a rule layer in pure Go, deterministic, sub-100ms: the referenced control exists, the framework is active, the proposed mapping is not a duplicate, the control has an assigned owner, embedding similarity is above floor. If tier 1 rejects categorically, the LLM tier never runs.
Tier 2 is an independent LLM cross-check from a different provider than the proposing model, executed in tool-use mode at temperature zero. The model can only emit a verdict-shaped payload (no free-form output that could be exploited as a prompt-injection side channel). Inputs include the proposed canonical entity, retrieved candidates, the tier-1 summary, and tenant context, never user-controlled text.
Fail closed. Every ambiguous failure mode routes to human review or rejection, never to auto-approve. Timeouts, parse failures, retrieval errors, all of these produce HUMAN_REVIEW outcomes with reasoning.
The signed approval gate
One token. One use. Bound to the payload.
Every consequential write requires a signed approval token, issued out-of-band of the AI conversation. The token is single-use, scoped to one operation, time-boxed to 15 minutes, and cryptographically bound to the exact diff being committed. The signing algorithm is Ed25519 or ECDSA P-256, depending on tenant configuration; both run inside the Go FIPS 140-3 validated cryptographic module.
The approver opens a notification (tenant URL or Slack), reads the proposal, sees the Verifier's verdict and the exact diff, and clicks once. The signature binds their verified OIDC identity to the payload hash. The token, the approver identity, the diff hash, and the Verifier verdict all land in the audit chain together.
In-conversation approval inside the AI session is structurally insufficient and the system refuses it. The reasoning trail captures who approved what at what time, against what proposal hash, with what signing key. This is what NIST AU-10 non-repudiation looks like when it is satisfied by architecture instead of by policy.
The audit trail
Append-only. FIPS-signed. Outside the system being audited.
Every canonical entity change derives from an event. Every external write produces an event. Every MCP tool call produces an event. The events table is append-only at the database layer: a Postgres trigger rejects updates and deletes, including from Kanonik operators. Once written, an event cannot be changed.
Each event references the previous event's hash. The chain root is signed with the tenant's ECDSA P-384 key, held in OpenBao Transit and never exported. Tampering with any past event breaks the chain and is detectable by recomputing hashes. Retention is seven years, matching common SOC 2 and ISO 27001:2022 retention expectations.
The chain lives outside the system being audited. The service that writes proposals into your GRC tool (connector-sync) is not the service that writes events into the chain (knowledge-service). Different binaries, different credentials, different network paths. The system writing your compliance data cannot rewrite its own log.
Offline verification
Your auditor verifies on her own laptop. No contact with us required.
The Auditor Export bundle is a signed tar.gz produced by finalize_audit_session and downloadable directly. It ships with the full event sequence, the chain hashes, the chain root signature, the public verification key, the framework package loaded at finalize time, the canonical-model schemas at the exact versions referenced, and a step-by-step VERIFY.md.
A standalone open-source binary (Go, signed release) recomputes the hash chain, verifies each event signature, and reports any tampering. Your auditor runs it on her own machine. No network call to Kanonik. No vendor reconstruction. No "trust us." The math holds or it does not.
This is the answer to NIST AU-12 (audit generation) and EU AI Act Article 12 paragraph 1 (logs available throughout the lifecycle): the customer can produce a third-party-verifiable bundle for any time range, on demand, without contacting the vendor.
Bring your own model
Model-agnostic. The LLM provider stays yours, not ours.
Kanonik is the trust layer. You bring the AI. Anthropic Claude, OpenAI, AWS Bedrock, Google Gemini, Azure OpenAI: any of them, your choice, your contract, your API key. The model provider is your direct contractor; Kanonik never becomes a layer between you and them.
What does change on your sub-processor list under GDPR Article 28: we are a sub-processor (one new entry on your list). 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 model vendor stays a direct relationship.
The Verifier itself runs on Kanonik's own provider account (currently Anthropic) for the tier-2 LLM cross-check, deliberately separated from whichever provider you chose for the proposer. The independence is the point. A model cross-checking itself is not a cross-check.
Framework mapping
Architecture, not policy mapping. Cited control by control.
The line on which audit defensibility turns is whether non-repudiation, traceability, and human oversight are satisfied by architecture or by paperwork. Incumbent GRC platforms satisfy them by policy mapping. Kanonik satisfies them by architecture, then maps the architecture back to the control text. The architecture is the evidence.
Each layer binds to specific control families:
- Verifier satisfies NIST 800-53 Rev. 5 AU-12 (audit generation) and EU AI Act Article 12 paragraph 1 (logging over the lifetime of the system).
- Signed approval gate satisfies NIST 800-53 Rev. 5 AU-10 (non-repudiation) and EU AI Act Article 14 (human oversight).
- Hash chain satisfies NIST 800-53 Rev. 5 AU-9 (protection of audit information), AU-11 (audit record retention), and EU AI Act Article 12 paragraph 2 (traceability).
- Append-only event store satisfies NIST 800-53 Rev. 5 AU-11 and EU AI Act Article 12 paragraph 2(a) (chronological log).
- Reasoning-trace export satisfies NIST 800-53 Rev. 5 AU-12 and EU AI Act Article 12 paragraph 1 (logs available throughout the lifecycle).
Architecture also engineered against ISO/IEC 27001:2022 Annex A and ISO/IEC 42001 (AI management systems). Statement of Applicability and the full control-by-control mapping available under NDA.
Where we are honestly
Pre-certification today. The architecture is the claim we stand behind.
The architecture above is what we have built. Certifications and external attestations are tracked on the public compliance roadmap: SOC 2 Type I then Type II, ISO/IEC 27001:2022 as the active control framework, and FedRAMP Moderate gated on holding federally regulated customers.
We do not display badges of certifications we do not hold. We do not claim FedRAMP authorization. We do not claim ISO 27001:2022 certified. We do not claim SOC 2 Type II attested. The Verifier is in-path and not autonomous; a human approves every consequential write, and the trust layer refuses to ship without that gate. If you see a Kanonik page claiming something we have not earned, it is a defect; email [email protected] and we will fix it within 24 hours.
What we will commit to today: the architecture above is real and shipped. The cryptography uses the Google CMVP-validated Go Cryptographic Module. The audit chain is offline-verifiable. The Verifier is non-bypassable. The approval gate is signed. The trust layer is what makes the work defensible, and it is the same trust layer that will be under the SOC 2 boundary, the ISO certificate, and the FedRAMP ATO when they arrive.
Read next
See the trust layer in motion.
The six-step flow shows exactly how propose / verify / approve / commit becomes a signed event in the chain, and what the auditor sees on the other side of the export bundle. If you want the architecture-decision records, threat model, and the canonical IR specification, those are available to design partners and serious evaluators under NDA.