Notifications
Clear all
Topic starter
20/08/2026 5:23 pm
TL;DR: An Okta-authenticated BigQuery MCP server can be moved from local development into a Kubernetes deployment using ToolHive, token exchange, and ngrok for remote access, according to Stacklok. The practical lesson is that MCP access, secrets handling, and workload identity still require explicit governance, because orchestration does not remove the identity risk.
NHIMG editorial — based on content published by Stacklok: Deploy an Okta-authenticated BigQuery MCP server on Kubernetes
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.
Questions worth separating out
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.
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.
Q: What breaks when developers expose an MCP server publicly without lifecycle review?
A: The access boundary and the governance boundary stop matching.
Practitioner guidance
- 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.
- 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.
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
👉 Read Stacklok's guide to deploying an Okta-authenticated BigQuery MCP server →
BigQuery MCP on Kubernetes: are your identity controls ready?
Explore further
20/08/2026 6:13 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Okta-authenticated MCP servers on Kubernetes need tighter identity controls
