Kanonik's six primitives map directly to NIST SP 800-53 Rev. 5 and EU AI Act Article 12: not by policy mapping, by design. Written for your security team, your auditors, and your procurement office.
This page documents what we built and how each piece maps to the controls your auditor will check. The mapping table below is the canonical reference. The rest of the page is the engineering detail behind each row.
Six architectural primitives. Every AI-assisted compliance change passes through all of them. Each one is bound to specific NIST SP 800-53 control families and to specific paragraphs of the EU AI Act and ISO/IEC 42001. Where incumbent GRC platforms satisfy these by policy mapping, Kanonik satisfies them by architecture.
| Mechanism | What it is | NIST SP 800-53 | EU AI Act / ISO 42001 |
|---|---|---|---|
| Independent Verifier | Server-side, non-bypassable cross-check on every AI proposal. Rule layer plus an independent LLM cross-check that does not share the proposing model's context. | AU-12 (audit generation) | Article 12 §1 (logging over the lifetime of the system) |
| Signed approval gate | Every consequential write requires an out-of-band approval token, signed against the approver's verified OIDC identity. In-conversation approval is structurally insufficient. | AU-10 (non-repudiation) | Article 14 (human oversight) |
| Hash chain | Each event references the previous event's hash. Chain root signed periodically with the tenant's ECDSA P-384 key. Tampering with any past event breaks the chain. | AU-11 (audit record retention) | Article 12 §2 (traceability) |
| Append-only event store | Database trigger rejects updates and deletes on the events table. Once written, an event cannot be changed by anyone. Kanonik operators included. | AU-11 | Article 12 §2(a) (chronological log) |
| Bitemporal timestamps | Every event carries both transaction_time (when we recorded it) and valid_time (when it was effective in the world). Auditors can reconstruct the system as of any past moment. |
AU-12 | Article 12 §2(c) (timestamping) |
| Auditor Export bundle | Signed PDF + JSON bundle covering any time range. Includes the full event chain, the chain root signature, and the public verification key. Your auditor verifies it offline with an open-source binary. No need to contact us. | AU-12 | Article 12 §1 (logs available throughout the lifecycle) |
The single sharpest implication: NIST AU-10 (non-repudiation) is satisfied by the signed approval gate as an architectural primitive. No incumbent GRC platform satisfies AU-10 architecturally; they satisfy it by policy. This is the line on which audit defensibility turns.
Kanonik is pre-certification. We are engineered against NIST SP 800-53 Rev. 5 Moderate, ISO/IEC 27001:2022, SOC 2 Trust Services Criteria, and FedRAMP Moderate. Formal authorization pursuit follows our public compliance roadmap. The controls described below are what we have built, not what we plan to claim. If you need anything that isn't here, contact security@kanonik.ai.
Kanonik is delivered as managed cloud SaaS. The system runs as three separate processes with explicit network and credential boundaries:
| Service | Role | Outbound access |
|---|---|---|
mcp-gateway |
The public-facing surface. Receives your MCP tool calls. Handles OIDC, OAuth 2.1, capability scoping, rate limiting. | Internal services only. No credential vault access. |
knowledge-service |
The canonical data model, the event store, and the Verifier. | Kanonik's Verifier model-provider account (current sub-processor: Anthropic) for the tier-2 LLM cross-check. No credential vault access. |
connector-sync |
The only process that holds your GRC tool credentials and reaches your GRC instance. | Credential vault. Your GRC tool endpoint. |
The separation is enforced at three layers: each service is a separate binary that does not link the vault client library at all where it's forbidden; Kubernetes NetworkPolicies deny egress between layers that should not communicate; and ServiceAccount RBAC denies vault-token issuance to services that should not hold credentials. The public attack surface (mcp-gateway) is structurally unable to read your GRC credentials even if compromised.
All inter-service communication runs over mutual TLS with FIPS-validated cipher suites. Certificates are issued by cert-manager with 90-day rotation.
| Data class | Examples | Storage | Retention |
|---|---|---|---|
| GRC metadata | Control IDs, framework references, mapping confidence, approval signatures | Your GRC tool plus our audit log | Life of the customer relationship; exportable on request; cryptographically erased within 30 days of contract termination |
| Operational telemetry | Verifier verdicts, system health, API metrics | Our observability stack (SigNoz, self-hosted) | 13 months rolling |
| GRC integration credentials | Per-tenant API token for your GRC tool | OpenBao (self-hosted, FIPS-validated) | Life of the integration; revocable instantly |
We never receive or store: your model-provider API key, your conversation history, your model usage data, business data from outside your GRC tool, or payment information.
We run on Oracle Cloud Infrastructure (OCI), with infrastructure-as-code (OpenTofu) that is portable across AWS, Azure, GCP, and OCI. Per-cloud configuration is isolated to provider-specific modules; the application code is cloud-agnostic. This is the foundation for a future GovCloud or AWS Bedrock path required by federal authorization.
Kanonik runs as managed SaaS today. Self-hosted single-tenant deployment via Helm chart is available to Enterprise customers on the roadmap.
Every consequential change passes through a server-side Verifier before it can land in your GRC tool. The Verifier is non-bypassable. There is no flag to disable it.
Tier 1, Rule layer. Pure Go, deterministic, sub-100ms. Per-event-type rules that catch categorical problems before any LLM cost is incurred. Example rules: 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.
Tier 2, LLM layer. Claude Opus 4.7 in Anthropic's 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 from our knowledge base, the tier-1 rule summary, and tenant context (never user-controlled text).
Tier 1 runs first. If it rejects categorically (a missing required field, a deprecated framework), the LLM tier never runs. If tier 1 passes, the LLM tier produces the final verdict.
The composite confidence score combines three independent signals:
Default threshold is 0.60. Below 0.60 routes to human review. Tenants can adjust the threshold upward (more conservative) but never downward; the floor is enforced server-side.
Every ambiguous failure mode routes to human review or rejection, never to auto-approve. Anthropic API timeouts, retries that still fail, structured-output parse failures, retrieval failures during input preparation: all of these produce HUMAN_REVIEW outcomes with reasoning. A misconfigured Verifier (missing API key, missing model access) fails the service health probe entirely; Kubernetes will not roll out a replica that cannot enforce the gate.
Eramba control descriptions, evidence titles, and policy bodies can contain text written by anyone with authoring access, including, in principle, hostile text intended to hijack the Verifier. Mitigations are layered:
No single mitigation is sufficient. The composition raises the bar significantly above any single-layer defense.
Every Verifier verdict is recorded in the event payload with full provenance: prompt purpose, prompt version, prompt content hash, model identifier, model version returned by the API, retrieval candidate IDs and relevance scores, the tier-1 rule summary, the tier-2 LLM summary, the confidence breakdown, and latency. An auditor with the export bundle can replay the Verifier on the same inputs and verify the verdict (within model nondeterminism).
All cryptography uses the Go FIPS 140-3 validated cryptographic module (Google's CMVP-validated Go Cryptographic Module). Algorithms and parameters:
| Purpose | Algorithm | Notes |
|---|---|---|
| External TLS | TLS 1.3 with FIPS cipher suites | Older protocols rejected at edge |
| Internal mTLS | TLS 1.3 with FIPS cipher suites | Per-pod certificates from cert-manager; 90-day rotation |
| Audit-log chain root | ECDSA P-384 with SHA-384 | The highest-value key in the system; per-tenant |
| Approval-token signing | ECDSA P-256 with SHA-256 | High-volume; per-tenant |
| At-rest encryption (envelope) | AES-256-GCM | Per-tenant Data Encryption Keys, wrapped by per-tenant Key Encryption Keys |
| Hashing | SHA-256 / SHA-384 | SHA-256 for general hashing; SHA-384 paired with P-384 |
| Random | crypto/rand (FIPS provider) | DRBG seeded from OS |
The FIPS module is validated by Google; the certificate is tracked in our dependency inventory and available on request under NDA. Cloud-portable: the same binary runs on commercial cloud (FIPS-mode optional) and on a future FedRAMP target (FIPS-mode enforced).
Multi-tenant isolation is enforced at multiple layers.
Every table that holds tenant data has Row-Level Security enabled with FORCE ROW LEVEL SECURITY, meaning even Kanonik's own application role cannot bypass it. The session variable app.current_tenant_id is set at the start of every transaction via the gRPC interceptor; if it is unset, RLS policies return zero rows (fail-closed).
CREATE POLICY tenant_isolation ON <table>
USING (tenant_id = current_setting('app.current_tenant_id', true)::uuid);CI lint scans for tables with a tenant_id column and verifies that an RLS policy exists. Migrations introducing a tenant-scoped table without RLS fail the build.
Each tenant has its own Key Encryption Key (KEK) in our self-hosted OpenBao vault. The KEK wraps a Data Encryption Key (DEK), which encrypts the event payload, all source-of-truth PII fields, and the audit-export bundles using AES-256-GCM. The KEK never leaves the vault; the vault performs the wrap and unwrap operations.
Both KEK and DEK rotate annually, plus on demand. Old data is lazily re-encrypted in the background.
On verified tenant deletion, the KEK is destroyed. Without the KEK, all DEKs become unrecoverable. Without the DEKs, all enveloped data becomes inaccessible ciphertext. The audit-log entries are not deleted (that would break the chain) but their content becomes unreadable. The chain still verifies; the content is gone.
This satisfies GDPR right-to-erasure without breaking the audit-trail immutability commitment.
Every internal request carries a signed TenantContext message (HMAC-SHA-256, daily-rotated service-internal key). Cross-tenant access is not representable in the API. There is no surface that accepts a tenant-less request or a raw tenant string outside the signed envelope.
The migration path does not require application changes. Only deployment topology.
The audit log is not a feature of Kanonik. It is the system of record. Every canonical entity change derives from an event. Every external write produces an event. Every MCP tool call produces an event.
Events are stored in a single Postgres table with per-tenant hash chains. Each event row contains the canonical event identifier, the tenant ID, the entity reference, the bitemporal timestamps (transaction_time and valid_time), the caller identity, the previous event's hash, the current event's hash, and the encrypted payload. Append-only enforcement is implemented as a database trigger that rejects updates and deletes on the events table.
Each tenant has its own hash chain. The chain links events by hash, signed periodically at the chain root with the tenant's ECDSA P-384 key. The signing key is held in OpenBao Transit and never exported.
Customers can verify their own audit log offline. The export bundle includes the full event sequence, the chain hashes, the chain root signature, and the public verification key. A standalone verifier (Go binary, signed release) checks chain continuity and signature validity without contacting Kanonik.
Seven years for audit data, matching common SOC 2 and ISO 27001 retention expectations.
Production access is limited to the engineering team currently operating Kanonik. As of mid-2026 this is the founder and a working group of one to three engineers and operators. All production access requires hardware-key SSH authentication; password-based access does not exist. All production sessions are logged to the same audit infrastructure customers use. Customer data access requires either (a) customer-initiated support ticket with explicit consent or (b) a court order with notice to the customer where legally permitted.
Kanonik is engineered against the following frameworks. We are pre-certification - formal authorization pursuit follows our public compliance roadmap. Our customers can use Kanonik in environments where their own compliance against these frameworks is the requirement, because our controls are designed to map cleanly to them.
| Framework | Kanonik posture |
|---|---|
| NIST SP 800-53 Rev. 5 | Architecture engineered against the Moderate baseline. Selected high-baseline controls (AU-10, SC-12) implemented for the audit log. |
| NIST CSF 2.0 | Identify, Protect, Detect, Respond, Recover functions mapped to internal runbooks. |
| ISO/IEC 27001:2022 | Annex A control coverage implemented. Statement of Applicability available under NDA. |
| SOC 2 (TSC 2017) | Security, Availability, and Confidentiality criteria designed for. Type I audit on the roadmap. |
| FedRAMP Moderate | Architecture engineered against the Moderate baseline from day one. Authorization pursuit follows our public compliance roadmap - In Process stage initiated once we hold three federally regulated customers. |
| GDPR | Data minimization, purpose limitation, and right-to-erasure (via crypto-erase) implemented. DPA available at kanonik.ai/dpa. EU data residency available. |
| HIPAA | Architecture supports the Security Rule. BAA available for healthcare customers. |
| ISO/IEC 42001 (AI Management Systems) | Designed against. The Verifier and audit log are the core controls relevant to this framework. |
A note on honesty: We do not display the badges of certifications we do not hold. If you see a Kanonik page claiming a certification we have not earned, it is a defect - please email security@kanonik.ai and we will fix it within 24 hours.
govulncheck, gosec, trivy fs, trivy image)status.kanonik.ai post-GA launchWe minimize the parties that touch customer data. The current sub-processor list:
| Sub-processor | Purpose | Data exposure |
|---|---|---|
| Oracle Cloud Infrastructure (OCI) | Compute, storage, networking for the managed SaaS | Encrypted data at rest; encrypted in transit. Region selectable at provisioning. |
| Cloudflare | Edge CDN, DDoS protection, WAF for marketing and customer-facing endpoints | TLS termination at edge; no customer data persistence |
| Anthropic | Tier-2 LLM cross-check inside the Verifier (runs on Kanonik's API account, not the customer's) | Limited to the structured proposal context; no PII in source-of-truth fields beyond what the proposal requires |
| (Email service) | Transactional email (waitlist, approval notifications) | Email addresses only |
| (Error reporting) | Operational error telemetry | Stack traces only; no customer payload data |
We notify customers 30 days in advance of any new sub-processor.
Contact: security@kanonik.ai
security.txt is available at kanonik.ai/.well-known/security.txtUnder NDA:
Publicly:
[VULN-DISCLOSURE]Architecture decision records, threat model, and the canonical IR spec are available to Founding Customer cohort members and serious evaluators under NDA. Get in touch.