How does Kanonik connect to my GRC tool?

Via the Model Context Protocol (MCP). Kanonik runs as an MCP gateway that exposes commit_* tools to your AI client. Direct connectors ship for Eramba; others integrate via MCP-compatible bridges.

What does the Verifier do?

Two-tier check on every AI-proposed change before it commits. Tier 1 is rule-based (control_id_exists, scope_in_tenant, confidence threshold). Tier 2 is an independent LLM cross-check from a different provider than the proposer. Non-bypassable: cannot be skipped from any client.

Why is human approval still required?

Because audit-defensibility requires it. Every commit needs a single-use, signed, scoped Ed25519/ECDSA-P384 approval token with 15-minute TTL. The token, the approver identity, and the diff are all hashed into the audit chain.

How it works

Six steps. All six signed.

You ask your AI to do compliance work. The Verifier checks every proposal. You approve with one click, outside the conversation. The change lands in your canonical record. The chain captures the full reasoning. Your auditor verifies the chain on her own laptop, offline.

No opt-out. No bypass. No "trust us." The trust layer enforces the workflow; the workflow is what makes the work defensible.

The trust layer

Five layers. Three of them non-bypassable.

Your AI sits at the top. The tamper-evident audit log sits at the bottom. In between, three layers the AI cannot bypass: the Verifier, the approval gate, and the canonical model. Every reasoning step records its inputs, model version, retrieved context, Verifier verdict, and approval evidence. Any historical decision is re-runnable.

This page is the mechanism, layer by layer. The control mappings (NIST SP 800-53 Rev. 5, EU AI Act Article 12), the cryptographic detail, and what an auditor verifies offline live on the security page.

Outside trust boundary

Customer's language model

Layer 4 / Transport

MCP gateway

Layer 3 / Non-bypassable

Verifier (rule + LLM cross-check)

Layer 2 / Non-bypassable

Approval gate (signed, time-boxed)

Layer 1 / System of record

Canonical model (bitemporal)

Layer 0 / Tamper-evident

Hash-chained audit log

Verifier

Runs on every state-changing operation. The AI cannot turn it off.

Approval gate

Single-use token cryptographically bound to the payload. Time-boxed.

Canonical model

Bitemporal. What did your SoA say on 2026-03-15? One query.

Audit log

Append-only. FIPS-signed root. Auditor verifies offline with an open-source tool.

The flow

From "draft this policy" to a defensible audit trail.

Every operation that changes state walks through the same six steps. None of them are skippable. The trust layer enforces the workflow by architecture; nothing inside the AI session can route around it.

01

You ask your AI

Inside your AI client (Claude Desktop, Claude Code, ChatGPT MCP, custom SDK) you describe the work. "Draft our access-control policy for ISO 27001:2022 A.5.1." "Assess our change-management control for Q1." Anything you would ask a senior compliance analyst.

02

Your AI calls Kanonik

Loaded with the matching Kanonik skill, your AI has access to a curated set of MCP tools - list_requirements, propose_policy, propose_assessment, narrative_synthesis, and more. Read tools return instantly. Write tools always generate proposals, never direct writes.

03

The Verifier checks

Server-side, inside every commit_* tool, before any write can land: rule-based checks (schema, scope, framework reference) plus an LLM cross-check that catches hallucination and out-of-policy reasoning. Not bypassable. Not by your AI. Not by you.

04

You approve, out of band

Verified proposals generate a signed approval token delivered via your tenant URL or Slack. The approver sees the proposal, the reasoning trail, the Verifier's verdict, and the exact diff. One click. In-conversation approval inside the AI session is never sufficient. By design.

05

The change lands

Once approved, the write commits to your canonical record. Versioned, bitemporal, reversible. The skill version that produced it is pinned to the event. If you keep an external GRC platform (Eramba is supported), the write propagates there too.

06

Chained to the audit log

Proposal, verification, approval, commit: each captured as a signed event chained to the previous one. The full chain exports on demand as a signed bundle. Your auditor verifies it offline, on her own laptop, no contact with us required.

Getting started

From signup to your first audit-ready output, the same afternoon.

No infrastructure to deploy. No models to host. Bring the AI you already have, load the skills, ask for the work.

01

Sign up & connect your AI

Sign up at kanonik.ai. Paste a single setup command into your AI client (Claude Desktop, Claude Code, ChatGPT MCP, custom SDK). OAuth handles the rest. About two minutes.

02

Pull the skill library

Your tenant fetches the signed skill bundles on first sign-in. Four core skills today: policy architect, control assessment, audit narrative, audit prep. More ship continuously.

03

Configure approvals

Pick who approves: a CISO email, a Slack channel, or both. The approval gate routes to that destination automatically. Card captured but not charged until your first successful AI call.