Okta-authenticated MCP servers on Kubernetes need tighter identity controls

At a glance

What this is: This is a deployment guide for running an Okta-authenticated BigQuery MCP server on Kubernetes, with the key finding that secure production use depends on token exchange, scoped access, and managed lifecycle controls.

Why it matters: It matters because IAM teams are being asked to govern MCP servers like production identities, which means service accounts, secrets, and federated access need the same discipline as any other non-human identity.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Stacklok's guide to deploying an Okta-authenticated BigQuery MCP server

Context

An MCP server is a tool-facing identity endpoint, and once it moves from a local prototype into Kubernetes it becomes part of the enterprise identity plane. In this example, the real challenge is not container orchestration, but how Okta authentication, Google token exchange, and exposed endpoints are governed as a single access path.

The article shows a common transition point for NHI programmes: developers want remote access and short-lived credentials, while operations teams need repeatable control over secrets, proxying, and workload identity. That is exactly where unmanaged configuration drift and inconsistent lifecycle handling create exposure.

The deployment pattern is typical of modern MCP adoption. It is not unusual, which is why it deserves governance attention before teams treat it as a standard production integration.

Key questions

Q: How should security teams govern an MCP server that uses federated identity and token exchange?

A: Treat the MCP server as a managed non-human identity with a documented owner, explicit token audience, scoped permissions, and a defined revocation path. Federation reduces reliance on static keys, but it does not remove governance. The control question is whether the trust chain is narrowly bounded to the workload that actually needs access.

Q: When does an MCP server create excess identity risk?

A: Risk rises when the server can query more systems, data classes, or environment context than the task requires. The problem is not MCP itself, but scope creep in the connected identities and permissions. If a conversational request can reveal broad cloud posture without strong boundaries, the assistant becomes a privilege amplifier rather than a productivity layer.

Q: What breaks when developers expose an MCP server publicly without lifecycle review?

A: The access boundary and the governance boundary stop matching. A server that was acceptable inside a local development loop may become a production-facing identity endpoint with different authentication, monitoring, and offboarding expectations. Without review, teams can keep old credentials, stale clients, or unnecessary scopes alive after the deployment changes.

Q: How do security teams decide whether to use OIDC federation or service-account keys for MCP access?

A: Use OIDC federation when you can enforce issuer validation, audience restriction, and short-lived credential exchange for the exact workload. Use static service-account keys only when there is no viable federated alternative, and then treat them as high-risk assets with tight storage, rotation, and revocation controls.

Technical breakdown

OIDC token exchange for MCP server access

The deployment uses Okta as the identity provider and Google Cloud STS to exchange an Okta token for temporary BigQuery credentials. This is a federated access pattern: the MCP server does not need a long-lived Google service-account key because trust is established through token issuance and audience matching. In practical terms, the security boundary shifts from storing secrets to validating the token path, the issuer, the audience, and the scopes granted to the workload.

Practical implication: Practitioners should verify that every external auth bridge has explicit audience, issuer, and scope constraints before production exposure.

Kubernetes-managed MCP lifecycle and proxy separation

ToolHive splits the MCP server from the proxy and manages both through Kubernetes custom resources. That architecture centralises lifecycle handling, but it also creates a new control point where authentication, updates, and transport settings must stay in sync. The proxy becomes the policy enforcement layer, while the server remains the tool execution layer. If those responsibilities drift apart, teams can end up with exposed endpoints that are operationally convenient but not consistently governed.

Practical implication: Teams should treat the proxy as a policy boundary and review whether lifecycle automation preserves the same access rules across updates.

Remote exposure through ngrok and the identity trust boundary

Making the MCP server reachable through ngrok extends the trust boundary beyond the cluster. Once a public URL exists, the system depends on the integrity of the OIDC handshake, client configuration, and the ability to distinguish legitimate tool callers from unauthorised sessions. For MCP environments, remote access is not just a networking decision. It changes the identity model because the server is now reachable from outside the local development perimeter.

Practical implication: Security teams should classify every public MCP endpoint as an identity exposure point and apply external access review to it.

NHI Mgmt Group analysis

Okta-authenticated MCP access is still an NHI problem, not just an application integration problem. The article is about authentication plumbing, but the security question is who or what can act with tool permissions once the server is productionised. That makes the deployment an identity governance issue for service accounts, tokens, and federated access, not a simple developer convenience feature. Teams should govern MCP endpoints as non-human identities with explicit scope, ownership, and lifecycle rules.

ToolHive-style orchestration does not remove the need for NHI lifecycle discipline. The operator manages pods, proxies, and updates, but it does not automatically resolve who owns the access path, how secrets are rotated, or when credentials are revoked. That means provisioning can become easier while offboarding and review become more important, especially when the same server is exposed remotely. Practitioners should assume operational automation can hide governance gaps rather than close them.

Federated token exchange is safer than static keys, but only if the trust chain is bounded. Temporary credentials reduce blast radius, yet the real control is whether the token issuer, audience, and scope are tightly constrained to the exact MCP workload. In NHI terms, the trust problem moves from secret storage to delegated authority. Security teams should measure whether federation is narrowing access or simply replacing one long-lived credential with a broader trust bridge.

Remote MCP exposure creates a new identity perimeter that existing IAM reviews often miss. Once a tool server is reachable through a public URL, access review has to cover the endpoint, the OIDC client, the proxy, and the workload behind it. The named concept here is MCP trust boundary drift: the point where a local integration becomes externally reachable without equivalent governance maturity. Practitioners should align network exposure with identity review, not treat them as separate control planes.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to the same research.
• As a next step, review the NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that apply to MCP-linked identities.

What this signals

MCP trust boundary drift: once a tool server moves from local development to a public URL, the identity perimeter expands faster than most access reviews do. That is why MCP governance needs to sit alongside endpoint exposure decisions, not after them.

With 70% of organisations granting AI systems more access than a comparable human worker, per the 2026 Infrastructure Identity Survey, the same over-permissioning pattern is likely to appear in MCP-linked AI workflows unless teams force explicit scoping.

The practical programme signal is simple: if your identity controls cannot describe who can call the MCP endpoint, which scopes are active, and how the access path is revoked, the deployment is already ahead of governance.

For practitioners

• Inventory every MCP endpoint as a managed NHI asset Record the server, proxy, OIDC client, external auth config, and public URL as one governed access path. That inventory should include owners, expiry expectations, and the downstream data sources the tool can reach.
• Replace configuration-file secrets with reviewed secret references Store credentials only in dedicated secret resources or external secret systems, and verify that no client secret or token appears in deployment manifests, bootstrap files, or operator templates.
• Scope token exchange to the narrowest workable audience and scopes Limit STS audience values to the specific workload identity pool and restrict scopes to the minimum needed for BigQuery access. Recheck those scopes after each deployment change or environment promotion.
• Separate proxy policy from tool runtime permissions Confirm that the proxy enforces authentication and access rules independently from the MCP server’s execution role. If the proxy and the tool share the same privilege assumptions, a compromise of one layer can overextend the other.
• Review public MCP exposure as part of access governance Treat ngrok or any externally reachable endpoint as a review trigger. Validate who can reach the endpoint, how clients authenticate, and whether the server’s external exposure still matches the approved business purpose.

Key takeaways

• An Okta-authenticated MCP server on Kubernetes is still an identity governance problem, because the control plane now includes tokens, proxies, and public endpoints.
• Temporary credentials improve the posture, but only tight scope, audience validation, and lifecycle control keep the access path from drifting.
• Teams should treat exposed MCP servers like managed NHIs and review them with the same rigour as any other externally reachable identity endpoint.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.
• Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.
• Mcp Trust Boundary: The security boundary created by a Model Context Protocol connection between an AI assistant and an external system. Each connection can supply data, trigger actions, or both, so it must be governed like a delegated access path rather than a simple integration.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Kubernetes and Helm installation commands for the ToolHive Operator
• Full MCPServer and MCPExternalAuthConfig YAML for the BigQuery deployment
• Proxy tunnel setup details for ngrok and the ToolHive CLI
• VS Code MCP client configuration and authentication prompts

👉 Stacklok's full post covers the Kubernetes setup, token exchange, and VS Code connection steps in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.