Kubernetes is the source of truth
MCP servers are MCPServer resources, validated at admission and applied with kubectl, GitOps, or kavryctl. The Operator reports readiness and lists each server's tools, so kubectl get mcpservers is your inventory.
DEPLOY. SECURE. OPERATE.
MCP
control
plane.
Kavrynt helps platform teams register, secure, and route MCP servers for AI agents on Kubernetes. The Kavrynt Runtime installs in your cluster today as a signed beta: it authenticates every agent, decides each tool call with your policy, and audits it. Kavrynt Cloud, the hosted control plane, is in development.
KAVRYNT CONTROL PLANE
MCPServerOperatorGateway
THE PROBLEMAI agents need MCP servers.
AI agents need MCP servers.
Teams need control.
THE KAVRYNT MVP
One Kubernetes path from manifest
to routed MCP traffic.
Teams declare an MCP server as a Kubernetes resource, the Operator validates it, and the Gateway routes agent traffic to it on any Kubernetes cluster. Kind is only the local test option.
● KUBERNETES CONTROL-PLANE PATHRUNNING
01 · INSTALLHelm chartINSTALLED
02 · INTENTMCPServerAPPLIED
03 · CONTROLOperatorVALIDATED
04 · STATUSReadyREADY
05 · DATA PLANEGatewayLOADED
06 · AGENTMCP TrafficROUTED
◆ KavryntMCPServer APIOAuth 2.1 agentsRego tool policyAudit eventsHelm installKubernetes 1.29+
One resource. · One Gateway. · One Kubernetes-native control loop.
WHY KAVRYNT
A control plane for MCP,
not just a proxy.
An MCP gateway gives agents one entry point. Kavrynt also gives platform teams a Kubernetes API for MCP servers, an Operator that knows what each one offers, and the tools to run it day to day. Read why Kavrynt.
Caller tokens stay at the Gateway
Agents' credentials never reach MCP servers. A server gets its own credential, pinned to its endpoint, or the caller's token exchanged for its own audience (RFC 8693).
One token, one server
Every route has its own OAuth audience and Protected Resource Metadata, so a token for one MCP server is refused by the others. A shared Gateway audience is opt-in, for routes you list.
Secure by default, fail closed
An install fails until you name your identity provider or opt out. Policy denies unless it allows, and errors deny. With audit on, no call is served without its record.
Decisions on every tool
Rego policy in the Gateway decides each tool call from the verified caller, the tool, and its behavior hints, never its arguments. Each agent's tool list shows only what it may call.
Audit you can verify
One hash-chained event per MCP request, without arguments, results, or tokens. kavryctl audit verify reports every gap, reordering, or altered event.
Team boundaries in shared clusters
A server's endpoint cannot name another namespace's Service unless you allow the pair. Cloud metadata, link-local, and loopback addresses are refused, and NetworkPolicies keep traffic on the Gateway.
In your cluster, built for day two
MCP traffic never leaves your cluster. Open source under Apache 2.0, with doctor, export and import, checked upgrades, a tested high-availability profile, alerts with runbooks, and a console.
COMPONENTS
Small pieces with
clear responsibilities.
MCPServer
Kubernetes resource that declares an MCP server, validated at admission.
kavryctl
CLI for validating and registering MCP servers, checking an installation, exporting and importing registrations, verifying audit chains, and upgrading Kavrynt with checks.
Gateway
Data-plane entry point that authenticates AI agents, applies your tool policy, audits every call, and routes it to the MCP server without forwarding the caller's credentials.
Operator
Kubernetes controller that validates MCPServer resources, reports readiness, and discovers each server's tools.
TRIAL IMAGES FOR KUBERNETES
Run Kavrynt on Kubernetes
Install the signed beta chart into your own cluster. Agents authenticate with your identity provider; a local trial on Kind can opt out.
# With your identity provider
helm upgrade --install kavrynt oci://registry-1.docker.io/kavrynt/kavrynt \
--version 1.0.0-beta.5 \
--namespace kavrynt-system --create-namespace --wait \
--set gateway.auth.resourceURL=https://mcp.example.com \
--set-json 'gateway.auth.issuers=[{"issuer":"https://login.example.com/realms/agents"}]'
# Local trial on Kind, without authentication
kind create cluster --name kavrynt-trial
helm upgrade --install kavrynt oci://registry-1.docker.io/kavrynt/kavrynt \
--version 1.0.0-beta.5 \
--namespace kavrynt-system --create-namespace --wait \
--set gateway.auth.enabled=falseARCHITECTURE
Runtime in your cluster,
control plane in the cloud.
MCP traffic never leaves your cluster. Kavrynt Cloud will receive inventory and usage metadata, not tool payloads.
01
Declare
Teams declare MCP servers as MCPServer resources with kubectl, GitOps, or kavryctl. The Operator validates them and reports readiness.
Available · beta02
Secure and route
The Gateway in your cluster authenticates agents with OAuth 2.1, decides each tool call with Rego policy, writes a tamper-evident audit event, and routes the call to a ready MCP server.
Available · beta03
Govern
Kavrynt Cloud adds sign-in, cross-cluster inventory, central policy, approvals, and audit storage across clusters.
In developmentCOMMERCIAL TRIAL
Bring control
to MCP operations.
Kavrynt is in public beta for developers and platform teams who want to run MCP infrastructure on Kubernetes, from local Kind clusters to managed cloud clusters. Try it in a development or evaluation cluster with the testing runbook and tell us what you need before production.