Add kanonik plugin

[kanonik-ai]

What this PR does

Adds Kanonik, a governance runtime for compliance work. The plugin is a remote MCP server configuration only: no bundled code, no hooks, no scripts, no skills.

• Plugin name: kanonik
• Type: remote source
• Source URL + pinned SHA: https://github.com/Kanonik-LLC/kanonik-plugin.git @ 6e1513da433f2a5f64f052274435de236e92b5f3
• Homepage: https://kanonik.ai

Ownership

• I own this plugin or have the right to distribute it.
• The source repo is published under our official org (Kanonik-LLC).

Checklist

• Added/updated exactly one entry in .grok-plugin/marketplace.json (valid JSON, kebab-case name).
• Remote source pins a full 40-char lowercase commit sha, and that commit is public + reachable.
• Regenerated .grok-plugin/plugin-index.json (python3 scripts/generate-plugin-index.py).
• python3 scripts/validate-catalog.py passes locally.
• python3 scripts/generate-plugin-index.py --check passes locally.
• homepage + clear description set.
• License is stated (Apache-2.0 on the plugin repo).

Diff is 25 insertions, 0 deletions. The entry was inserted textually to preserve the existing file formatting rather than reserialised.

Security

• No curl | bash, remote-code download/exec, or postinstall RCE.
• No reading/exfiltration of secrets, tokens, .env, or env vars.
• Hooks and MCP scope are least-privilege.

Network endpoints this plugin calls (and why): exactly one, https://app.kanonik.ai/mcp. It is the hosted Kanonik MCP server. There are no other endpoints, no telemetry, and no analytics.

The complete functional payload of the plugin is:

{
  "mcpServers": {
    "kanonik": { "type": "http", "url": "https://app.kanonik.ai/mcp" }
  }
}

Credentials/permissions it requires (and why): none are held by the plugin. Authentication is OAuth 2.1 with Dynamic Client Registration and PKCE against https://auth.kanonik.ai; the resource server publishes RFC 9728 metadata at https://app.kanonik.ai/.well-known/oauth-protected-resource. Tokens are held by the Grok client. Three scopes are requested:

Scope	Purpose
kanonik:read	read the user's compliance record
kanonik:propose	draft changes for review
kanonik:commit	submit a change for human approval

No change reaches a user's record without a signed, single-use approval token and a human clicking to approve. The connected model cannot approve its own work.

The plugin ships no executable file of any kind. The repository contains .mcp.json, two plugin manifests, a README, the Apache-2.0 licence, and two SVG logos.

Notes for reviewers

Category. I used category: "security", which is a new value for this catalog (existing entries use deployment / development / database / monitoring / observability). validate-catalog.py does not constrain the field, so it validates, but happy to change it to an existing category if you would rather not add one.

Logo. assets/logo.svg is a dark evergreen mark on transparent, which reads well on light backgrounds. assets/logo-on-dark.svg is the light-on-dark variant, already in the repo. Tell me which the catalog UI prefers and I will re-pin.

What Kanonik is. A typed compliance model, a tamper-evident record, a server-side verifier, and a human-approval gate in front of every write. The connected model does the compliance reasoning; Kanonik makes the result auditable. Framework packages available today are ISO 27001:2022, SOC 2, GDPR, NIST CSF 2.0 and HIPAA.

[kanonik-ai]

Two corrections to the description above, and the reviewer access route, which the description does not currently mention.

How to get an account

The plugin repo carries a REVIEWING.md written to be followed cold in about 15 minutes. Short version: email evereshagin@kanonik.ai, say which directory you are reviewing for, and we send a sandbox invite code. The code creates your own isolated workspace at no cost, so you never enter a card. If you would rather not create an account at all, ask and we supply a shared sandbox login instead.

We deliberately do not publish the code here, since this PR is public and the code would be consumable by anyone.

The sandbox starts empty on purpose. You are walking the real first run path rather than touring a pre filled demo.

Correction 1: the pinned SHA in the description is stale

The description says 6e1513da433f2a5f64f052274435de236e92b5f3. The catalog entry in the diff pins c3de7d43804a5cc933338c5b7db32a0ca5781ce2, which is current and adds REVIEWING.md, a gemini-extension.json, and working docs and support links. The diff is authoritative; the description text was not updated across the re-pins.

Correction 2: Grok does not use DCR on this server

The security section says authentication is OAuth 2.1 with Dynamic Client Registration and PKCE. That is true of the server, and it is how Claude and Cursor connect, but it is not the path a Grok client takes. Grok performs a manual authorization code exchange against the static public client mcp-gateway, with PKCE S256 and the callback https://grok.com/connectors-oauth-exchange-code/. Both paths are supported. Flagging it so a reviewer testing the flow is not surprised when no dynamic registration happens.

That distinction was not academic on our side. Because every client in daily use registers via DCR, the static client path had never been exercised end to end, and it carried two defects that only affected non DCR clients. Both are fixed and the full handshake is now verified against production: authorization, login, code on the Grok callback, token exchange, initialize, and a first tool call returning the caller's workspace.

Happy to change category from security to an existing value if you would prefer not to add one.

[kanonik-ai]

Rebased onto current main (the daily pin bumps had moved the catalog, so the PR showed as conflicting) and refreshed the pin to the plugin repo's HEAD cdecc55e327fd0874d4ada62f3530a3e7a9c8067 (adds SETUP.md, no functional change). Single squashed commit; validate-catalog.py and generate-plugin-index.py --check pass locally. Ready for review whenever the queue reaches it; happy to adjust anything.