How it works

Six primitives.
Every AI-assisted change passes all of them.

Kanonik is MCP-native and model-agnostic. Your AI proposes; an independent Verifier checks; a signed human approval gates; the change commits to a hash-chained audit log your auditor can verify offline. The flow below is what every consequential write goes through. There is no opt-out.

You bring

Your model

Any MCP-capable client and any supported provider.

  • Your model relationship
  • Your billing
  • Your prompts
Kanonik provides

Intelligence layer

Canonical model, Verifier, approvals, audit chain.

  • Non-bypassable Verifier
  • Human approval gate
  • Hash-chained log
  • Auditor export
You already own

Your GRC tool

Eramba today; Vanta, Drata, more soon.

  • Read all entities
  • Drafts land in-tool
  • Reversible writes

Why this matters: the dominant pattern in GRC isn't "we need a new tool." It's "we already have a GRC tool, and the busywork is killing us." Kanonik fixes the busywork without forcing a migration.

The flow

From "map this control" to a defendable audit trail.

Every operation that touches your GRC tool walks through the same six steps. None of them are skippable.

1

You ask your AI to do something

Inside your MCP-capable client (Claude Desktop or Code, OpenAI's MCP client, or any compatible SDK) you describe the work. "Map our access-control policy to ISO 27001 Annex A.9." "Draft evidence for control PR-04." Anything you'd ask a junior compliance analyst.

Your AI / MCP client
2

Your AI calls Kanonik tools over MCP

Your AI has access to a curated set of MCP tools: list_controls, get_framework, propose_mapping, draft_evidence_link, and more. Read tools return instantly; write tools generate proposals. Never direct writes.

Kanonik MCP server
3

The Verifier checks every proposal

Server-side, before any external write is even possible: rule-based checks (schema, constraints, scope) plus an LLM cross-check that catches hallucination and out-of-policy reasoning. The Verifier is not bypassable. Not by your AI. Not by you.

Kanonik Verifier
4

A human approves: out of the conversation

Verified proposals generate a signed approval token delivered via email or Slack. The approver sees the proposal, the reasoning, the Verifier's verdict, and the exact diff. They click once to approve. In-conversation approval inside the AI session is never sufficient. By design.

Email / Slack / signed token
5

The change lands in your GRC tool

Once approved, Kanonik writes through your GRC tool's API. Drafts where possible, direct writes only with explicit human authorization. Every write is reversible. One click in our observability dashboard rolls it back.

Eramba / Vanta / Drata / ...
6

Every event chained to the audit log

Proposal, verification, approval, commit: each captured as a FIPS-signed event chained to the previous one. The whole chain can be exported on demand as a signed PDF + JSON bundle.

Tamper-evident / auditor-ready
Getting started

You can be running in twenty minutes.

No infrastructure to deploy. No models to host. Bring your model, connect your GRC tool, configure your approver. That's it.

1. Install the MCP client

One config file in your MCP-capable client (Claude Desktop or Code, OpenAI MCP, or compatible). We provide the exact JSON. About two minutes.

2. Connect your GRC tool

Eramba API key. Vanta or Drata OAuth (coming soon). We verify the connection in real time.

3. Configure approvals

Pick the channel (email or Slack) and the people authorized to approve writes.

See the six primitives in action.

Founding Customer cohort enrolling now. Three charter spots open this quarter: founder-led onboarding, full DPA at signing.