Trust and security
What Kanonik does with your data, how each workspace is isolated, and where our compliance posture actually stands. Written for the security review you run before you connect.
Reviewing us for a deal? Email [email protected] and we will answer your questionnaire directly.
How your data is handled
Kanonik is consumed by your own model over MCP. The model does the compliance reasoning; we provide the typed data graph, the checks, the approval gate, and the tamper-evident record. That shapes what we can and cannot see.
Bring your own model
Your LLM does the compliance reasoning in your own client, and your AI provider stays your contractor, not a sub-processor engaged by Kanonik under the Kanonik DPA. For its non-bypassable server-side verification Kanonik uses an external model provider (listed below): where a record type requires a model-based check, the proposed change and relevant record context are sent to that provider before the change is written.
We never reach into your source systems
Your model connects to your systems through its own MCP tools. Kanonik holds no credentials for your cloud, code host, identity provider, or ticketing.
Card data never touches us
Billing runs through Stripe Elements. Your card details are entered and confirmed in your browser against Stripe; the number never reaches a Kanonik server.
Your AI's drafts wait for a person's approval
Nothing your AI drafts reaches your compliance record without an approval from a signed-in person's account. Every policy, control, risk, mapping, piece of evidence or decision it drafts is checked on our servers first. It then waits until someone signed in to your workspace approves it, with a click on the single-use approval link or in the dashboard, and the approval is recorded against that person's account. Asking in the chat is never enough. Kanonik cannot tell whether the person, or software acting in their signed-in browser, made the click. A few things are saved without an approval; they are listed below.
What is saved without an approval
A few things are saved without an approval. This is the full list.
What you enter yourself
Your account, workspace, plan, billing and legal consent at signup, and the settings you change in the dashboard (approval channels, your framework licence statement, workspace settings), including inviting people and setting roles. An auditor invite needs an end date and a reason. You are the person acting, so there is no second click.
Your company profile
You can fill it in on the dashboard, or your AI can save it for you when you describe your company. Either way it is saved directly and recorded on the audit log. It shapes later checks, so review what your AI saved.
Drafts and working notes
What your AI proposes, the packages and gaps it opens, and any draft sent back for revision are recorded as drafts. They are not part of your approved record until someone approves them.
Kanonik's own records
Check results, approval and delivery events, and billing events are written by Kanonik itself.
Some records get rule checks but no model check
Decisions only a person can make (exceptions, risk acceptances, remediations), records of who is asking you to prove something, and framework or questionnaire choices still need your approval. Kanonik checks them with fixed rules, not with a model. Audit sessions and findings get the same for now.
In a one-person workspace, you approve your own AI's work
Where a record needs a second person and you are the only member, the record marks your approval as a named exception. Other records are approved as usual.
Architecture and isolation
Multi-tenant from the first commit, with each workspace's data kept apart in the database.
Row-level tenant isolation
Every row carries a tenant id; row-level security enforces the boundary in the database, not only in application code.
Credentials kept in a vault
The keys that wrap workspace secrets are held in OpenBao, not in application config or the database.
Encryption in transit
Every connection from the internet uses TLS. Our three services talk to each other over mutual TLS on their internal gRPC connections. Other internal calls stay on the private network behind network policies and are not yet encrypted; we are moving them to TLS. They include the key vault, the sign-in service, search embeddings, telemetry, the dashboard to the gateway, the gateway to billing, and one database connection used to set up workspaces.
Standard, reviewed cryptography
Signing, key derivation, TLS, and the audit hash chain use Go's standard cryptography library in every security-critical path.
Audit and provenance
Every change to your compliance record is an event on an append-only log. The application never rewrites or deletes an entry, and an auditor can verify the whole chain independently.
Tamper-evident hash chain
Each event references the hash of the one before it; the chain root is signed. A broken link is detectable.
Append-only event store
The event store only ever appends. Entries are never edited in place.
Signed auditor export
One click produces a signed PDF and JSON bundle with the reasoning trail, the human approval evidence, and a proof of the chain. The open verifier runs offline and checks the signature against Kanonik's pinned public keys, not a key taken from the bundle.
Reproducibility recorded
Each AI decision records the inputs, prompt version, model, and retrieved context needed to re-run and independently check it.
Compliance posture
Where Kanonik stands, item by item. Your own record maps to the FedRAMP baselines and NIST 800-53.
| Item | What it means | Status |
|---|---|---|
| Audit trail and tenant isolation | Every recorded decision is chained to the one before it and the chain is signed; each workspace's rows are isolated from every other workspace | In place |
| FedRAMP authorization (ATO) | Agency-sponsor track; GovCloud trial and 3PAO assessment come first | On roadmap |
| SOC 2 Type II | Audit period and report; not yet performed | On roadmap |
| GDPR and DPA (Art 28) | Async e-sign data processing agreement, standard contractual clauses where transfers apply | In place |
| HIPAA BAA | Not offered. Do not enter protected health information. | Not offered |
| Data residency | One production region today, in the United States. We cannot host a workspace elsewhere yet. If you need another region, email [email protected] before you sign. | US only |
Sub-processors
The third parties that process data on our behalf. We give notice before adding one, so you can object under the DPA.
| Sub-processor | Purpose | Data |
|---|---|---|
| Oracle Cloud Infrastructure (OCI) | Cloud hosting: compute, managed database, storage. | All Service data: your compliance model, audit log and account details. United States at launch. |
| Cloudflare, Inc. | Edge delivery and protection for the service: CDN, TLS termination, DDoS and WAF protection, security headers. | HTTP request metadata (IP address, request headers). No compliance content is stored at the edge. Global edge network, United States primary. |
| Anthropic, PBC | Model-based verification of proposed records, where the record type requires it (rule-based checks run first and can settle it without a model call). | The proposed change and the canonical-record context needed to verify it. United States; Anthropic data-handling terms apply. |
| Stripe, Inc. | Payment processing. | Billing and card details, held by Stripe, never stored by Kanonik. |
| Postmark (Wildbit, LLC) | Delivery of approval and account emails. | Recipient email, the approval link, and a short summary of the record (a title, name, or text cut to about 120 characters), not the full record. |
| GitLab Inc. (GitLab.com) | Customer feedback and support tickets you file from the app or through your AI. | Your workspace ID, user ID, account email and optional reply-to email, severity, the app page, a trace ID, the build version, whether it came from the dashboard or your AI, your message, and up to three attachments you add (doc, docx, pdf, png or jpeg, 5 MiB each). Kanonik adds no compliance records to a report; your message and attachments go as you write them, so leave record content out. United States. |
| Slack Technologies, LLC (optional, per-tenant opt-in) | Notices that a request is waiting, only if you connect a Slack channel. | The channel you choose, the name of the person who has a request waiting, and a short summary of the record (a title, name, or text cut to about 120 characters), not the full record. The approval link is not posted to Slack. |
| Plausible Insights OU | Cookieless website analytics on our public and signup pages only. Not present anywhere inside your workspace. | Page address and referrer on the signup path only. No cookies, no cross-site tracking, no compliance content. |
The model that does your compliance reasoning is your own provider, chosen and contracted by you, not by Kanonik, and not a sub-processor engaged by Kanonik under the Kanonik DPA. For server-side verification Kanonik uses an external provider (Anthropic, listed above), which receives the proposed change and relevant context when a record type requires a model-based check.
Data processing agreement
Our DPA covers processing under GDPR Article 28, sub-processor terms, and the standard contractual clauses where they apply. It is published and reviewable now; for a countersigned copy, email [email protected]. A countersigned copy is returned to your admin.
Questions for your review go to [email protected]. Ready to start? Create your workspace. Powered by Kanonik.
Build 872db428