MCP, governed from the server.

Why Kryex does MCP differently

An MCP server exposes tools (for example searchJiraIssues or create_repository) that an agent can call. The common way to use MCP is to put each server's URL and credentials into a config file on every developer's laptop. That puts tokens on endpoints, gives every tool to every user, and leaves no central record. Kryex is built the other way around.

• Credentials never sit on developer machines. Every MCP call runs from Kryex Server. Credentials are encrypted per tenant and held server-side; the desktop agent only sends which tool and which arguments.
• No tool is usable until a human approves it. Kryex discovers a server's tools, an AI proposes READ / WRITE / ADMIN tiers, and an admin confirms them. The AI can only propose a higher tier than a fixed safety floor, never a lower one. If a tool's definition changes later, it goes back to quarantine automatically.
• Least privilege per person, per tool. Nobody has access by default. Admins grant READ, WRITE and ADMIN independently, per user and per tool. Any tool can be set to require approval, which holds every call until an admin approves it.
• Two connection models, one governance plane. Shared organization servers use one service identity; personal connectors use each person's own account. Both are controlled from the same admin console and recorded in the same tamper-evident audit log.
• Standards-based sign-in. For modern MCP servers (Atlassian, Linear, Sentry, Notion…), Kryex finds the server's own sign-in and registers itself automatically (OAuth 2.1 with RFC 9728, 8414 and 7591). Enterprises can also use their own OAuth apps or any custom OAuth provider.
• Self-diagnosing. Kryex classifies failures, tells the right person the right fix, refreshes and retries before blaming a sign-in, and opens incidents for systemic problems.

Terms

Two connection models

Both can exist for the same service at the same time, and they're independent. Use an organization server when one shared credential should serve everyone under Kryex's per-tool grants; use a personal connector when actions should be attributable to each person.

How one call flows

For an organization server, the agent sends the connection, tool, arguments and session with the user's license token. Kryex Server finds the connection in the caller's own organization only, refuses quarantined tools, checks the grant (default deny; a grant below the tool's tier is denied; “requires approval” holds the call), then decrypts the org credential server-side, calls the tool, redacts credential values from the response and applies the size cap. A tool.decision audit event records the decision, tier, capability, an argument hash, latency and outcome.

For a personal connector, the connector must be published and not turned off by the org; the user must have connected it (their token is refreshed if it's about to expire); for GitHub Apps, Kryex checks the app is installed on their account; and the tool must exist and not be blocked by the org. The call then runs with the user's own token. If the provider rejects it, Kryex refreshes once and retries before deciding what went wrong. A connector.call event is written, allowed or denied.

Discovery, tiering and quarantine

When an admin registers a server, Kryex calls tools/list (following pagination) and records each tool's name, description and a SHA-256 hash of its input schema. Discovery can be dry-run first, which writes nothing, and re-run later with Refresh discovery.

Servers can expose hundreds of tools, so Kryex proposes each tool's tier. Nothing is trusted blindly:

Only active (approved) tools appear in any user's manifest, and the gateway refuses non-active tools on every call. If a later discovery finds that a tool's input schema changed, the tool is re-quarantined until an admin re-approves it. A server can't silently change what an approved tool does.

{
  "name":        string,
  "private":     boolean,
  "description": string
}

Access: per person, per tool, per tier

• Default deny. With no grant, there is no access.
• Per user, per tool. READ, WRITE and ADMIN are independent: WRITE does not include READ. Kryex Server derives the capability from the tool's current tier, never from the client.
• No whole-connection grants. For MCP servers, access is always per tool, by design.
• Requires approval. Per tool, per user: every call is held, an admin approves or declines it, and on approval Kryex runs the original call. Identical repeated requests are de-duplicated.
• Changing a tier. Existing grants are re-checked against the new tier on the agent's next turn. A READ grant no longer covers a tool moved to WRITE.
• Disable and delete. Disable turns the whole server off for everyone at once. Delete revokes every grant (kept, marked revoked, for the audit trail) and removes the server's tools and stored credentials.

The shared credential itself is decrypted only inside Kryex Server at call time; no API returns it to a browser or to the desktop. OAuth sign-ins use authorization code + PKCE (S256) with a single-use, 15-minute state, are exchanged server-side and stored encrypted, and are refreshed only when close to expiry, one refresh at a time across servers. If refreshing fails, the server is marked reauth required: the admin sees Reconnect sign-in, and the agent tells the user an admin must reconnect it.

Personal connectors

Personal connectors come from a curated connector catalog. A platform admin defines each one: name, logo and copy, the MCP endpoint, how people sign in, an optional install step (GitHub Apps), help text shown when sign-in fails, setup steps each org's admin must do at the provider, and tool tiers. Connectors are invisible drafts until published. On the hosted service the platform admin is Kryex Labs; in a self-hosted or air-gapped deployment it's your own administrator.

Org admins (Governance → Connectors) can allow or turn off a connector for the whole org, block individual tools by tier, follow the provider-side setup checklist, and plug in a company sign-in app so their people sign in through the company's own OAuth app. The on/off switch and the block list are enforced server-side on every call.

Each person's token is encrypted with their organization's key, stored per person and connector, read only for that person's own calls, and never shared. Disconnect deletes the token and revokes it at the provider where the provider supports it. In Kryex Code, people connect from Settings → Connectors; their system browser opens the provider's own consent page, and the agent then sees the service as an @slug connection.

Controls in Kryex Code

The agent gets three fixed tools (list_governed_connections, call_mcp_tool, query_database) however many servers exist; connections and tools are described to it from the server-built manifest. Whether it asks before a call depends on the permission mode:

The tier used for that decision comes from the server manifest, never from the model; the desktop overwrites any tier the model tries to supply. The prompt is a convenience layer only: Kryex Server enforces grants on every call regardless, so a modified client gains nothing. If Kryex Server is unreachable, calls fail closed.

Sign-in methods

Security controls

Credential custody

Envelope encryption with AES-GCM. Each organization has its own randomly generated 256-bit data key, wrapped by a master key held in the deployment's secret store. Every secret is encrypted with its organization's key, with the organization ID bound as associated data, so a ciphertext copied into another tenant cannot be decrypted. Platform-level secrets (the built-in provider apps, catalog clients, automatic registrations) use a separate platform key. No API returns a stored secret, and the database schema that holds them isn't readable by any public API role at all.

Server-side execution and network safety

• Server-side only. MCP calls run only in Kryex Server. The desktop never receives credentials, and the manifest carries none.
• SSRF guard. The hostname is resolved on every call and each address is checked: private, loopback, link-local, reserved, multicast and the cloud-metadata address are blocked, and failed lookups are refused. Re-resolving each time defeats DNS rebinding.
• Redirects. Only method-preserving redirects (307/308) to the same origin are followed, each hop re-checked, at most three. Credentials never leave the registered origin.
• HTTPS by default. Plain HTTP must be enabled per server and never unblocks private addresses on the shared cloud. Self-hosted deployments inside a customer network can opt in to private addresses with a deployment flag.
• No shared cookies. Nothing carries over between tenants; authentication is attached per call.
• Limits. At most 4 concurrent calls per server per process, and a 30-second call timeout.
• Response handling. Every stored credential value is redacted ([REDACTED]) before a response reaches the agent or the audit log, and responses are capped at 200,000 characters.

OAuth hardening and tenant isolation

Authorization code + PKCE S256 with a single-use state that expires after 15 minutes; exchanges are server-side only with redirects refused; refreshes are serialized, which is safe for providers that rotate refresh tokens; and discovery refuses sign-in servers that don't support S256. Every admin action resolves the organization from the authenticated admin, never from client input, and agent calls resolve connections only within the caller's own organization.

License integrity

The license is an RS256 token signed by Kryex Server, bound to the user and device, valid for 24 hours, and re-checked live on every governed call. Kryex Code verifies the signature itself before trusting any claim locally, and keys carry an id so they can be rotated without signing anyone out. Self-hosted deployments pin their own server's key, after which the desktop accepts licenses from that server only. An edited, forged or untrusted license is refused and reported: to the audit log, the console's Security page, and the organization's admins by email. See pinning your server's key.

Reliability and self-diagnosis

Kryex classifies every failed connector call and gives the agent an exact instruction. The agent never handles credentials, and “reconnect” is advised only when it will actually help.

Every published connector is also checked automatically every 6 hours; a failed check opens an incident that resolves itself when the check passes. A 7-day sign-in funnel (started vs finished) shows when people are blocked at the provider.

Audit and evidence

Each event stores a hash of the previous event's hash plus its own kind, actor and payload, chained per agent session (or per organization for admin events). The table is append-only, enforced by the database itself, which refuses every update, delete and truncate. Tool arguments are never stored in clear: decisions record an argument hash, plus tool, tier, capability, decision, reason, outcome and latency.

Every event is recorded under its organization and visible on that org's Audit log page, filterable by tool calls, grants, connections, approvals, MCP servers and connectors; by actor (agent, admin, user); by outcome, team and user. Events include server lifecycle (mcp_connection.created, .discovery_run, .tiers_finalized, .deleted), tool approvals and grants (mcp_tool.approved, grant.created, grant.revoked, approval.decided), agent decisions (tool.decision), personal connectors (connector.connected, connector.call, connector.policy_updated), groups and tool policy, and sign-in and device events including license.tamper_detected.

What makes Kryex different

Known limits

As of 13 October 2026:

Standards used

• Model Context Protocol, Streamable HTTP transport, protocol version 2025-06-18 (JSON-RPC 2.0)
• OAuth 2.1 authorization code with PKCE (S256)
• RFC 9728 (Protected Resource Metadata), RFC 8414 (Authorization Server Metadata) and OpenID discovery
• RFC 7591 (Dynamic Client Registration), RFC 8707 (Resource Indicators), RFC 7009 (Token Revocation), RFC 6750 (Bearer tokens)
• AES-GCM envelope encryption with per-tenant data keys and associated data

Next