kt cloud and Stacklok Partner on a Kubernetes-Native AI Future

Using MCP was not the hard part

Kt cloud is one of South Korea’s leading cloud and digital infrastructure companies, providing the foundation that more than 8,000 enterprise customers rely on to run critical workloads. With Korea’s largest data center infrastructure and growing investments across AI cloud and AI data centers, they’re helping define how Korean enterprises adopt and scale AI. Internally, they’ve taken a meticulous approach to how they want to architect and scale AI, starting with MCP, and they are building that future with Stacklok.

Like most engineering organizations in 2026, kt cloud’s teams did not need convincing to use MCP. An infrastructure developer built an MCP server for checking cloud costs, authenticated with their own account. A service team developer needed the same capability and rebuilt it. A third employee installed an unvetted MCP server found online, one with no review process and access to internal data.

Individually, everything worked. Organizationally, five problems were compounding:

The math made it worse. Every combination of AI client (AI Portal, Claude Code, Cursor) and MCP server (Jira, Slack, internal services) repeated the same registration, authentication, and credential work. kt cloud needed a shared MCP Hub: one place for registration, auth, permissions, and audit.

Why kt cloud chose Stacklok

The team defined six requirements for running MCP reliably inside the company: an MCP-aware gateway, aggregation of many servers behind one endpoint, standards-based user authentication, user and group access control, per-backend OAuth credential handling, and declarative deployment.

ToolHive, Stacklok’s open source MCP platform, met each requirement head on. The gateway controls tool exposure and call flow. VirtualMCPServer aggregates distributed servers into a single endpoint. OIDC connects kt cloud’s existing Okta identity provider. Cedar policies gate access by user and group, down to the individual tool. Upstream auth absorbs each provider’s OAuth method. And CRDs and an Operator own the full MCP lifecycle on the Kubernetes API.

That last point mattered most:

There is no separate management console to learn or operate. kt cloud’s MCP Hub is managed with the same declarative Kubernetes workflow the team already runs everything else on, making it extremely easy to use and natural to their team. 

One endpoint, no direct path to backends

In kt cloud’s architecture, every AI client connects to a single VirtualMCPServer endpoint. There is no direct path from clients to backends, making the Hub the single control point for all MCP connections.

On the way in, Okta OIDC verifies the user, and Cedar policies evaluate the token’s group claims to decide which tools that user can see and call. On the way out, the Hub injects per-user tokens, encrypted and stored in Redis, into each backend request. An audit log records every call: user, tool, MCP server.

Internal and SaaS backends needed different designs, and Stacklok supports both natively. Internal services like kt cloud’s billing system register as MCPServer resources and run as pods in the cluster, where the team controls the code, the network, and the auth design. External SaaS like Jira and Slack register as MCPRemoteProxy resources, bound by each provider’s policies. Both share the same MCPGroup, and vMCP presents them to users as one endpoint.

Identity carries all the way to the backend

The hardest lesson was that there is no single “authentication.” Incoming auth answers “who is this user?” Outgoing auth answers “with what credentials do we call the backend?” These are different problems, and each backend answers the second one differently. For example, kt cloud’s internal billing service used pre-registered OAuth clients. Atlassian’s MCP endpoint rejected pre-registered clients entirely and required Dynamic Client Registration, with client IDs issued at runtime. Slack required user-delegated tokens rather than bot tokens, because MCP tool permissions come from the user’s authority, not the app’s.

ToolHive’s per-backend upstream auth made this workable: each provider’s method is declared individually, and the Hub absorbs the differences rather than trying to erase them. At login, the Hub completes the provider OAuth flow once and stores the user’s access token encrypted in Redis. At call time, it looks up and injects the token without touching the provider’s authorization server, so every backend call carries the actual user’s identity and permissions.

Four things kt cloud confirmed while building an MCP Hub

• Design MCP around boundaries, not connections. Incoming and outgoing auth are different problems. Separate user identity from backend credential handling.
• OAuth will not unify into one method. Atlassian, Slack, and internal services all differed in client registration and token type. The Hub should absorb the differences, not erase them.
• Permissions must reach the tool level. Authentication alone is not enough. User and group information has to connect to policy that controls which tools are actually exposed.
• Operations must be Kubernetes-native too. Manually managing MCP servers does not scale. Declarative operations on CRDs, Operators, and GitOps are required.

kt cloud built exactly that with Stacklok’s ToolHive, on Kubernetes, and the operational patterns their platform team already trusted. Rather than simply deploying ToolHive, the kt cloud team has been validating it against real enterprise requirements while working closely with Stacklok to resolve architectural and operational questions that only emerge at enterprise scale. CTO, Jaesuk Ahn of kt cloud, phrased it:

For the kt cloud team, this partnership is about building an Enterprise MCP Platform that meets the realities of enterprise AI today with the flexibility to be ready for the future.