Topic starter
20/08/2026 5:24 pm
TL;DR: An Okta-to-Google Cloud federation flow for BigQuery-accessing MCP servers can avoid embedded service-account keys, preserve user attribution, and use short-lived token exchange instead of static JSON credentials, according to Stacklok. The deeper issue is not just convenience: it is replacing brittle secret handling with governed, auditable identity boundaries that IAM and NHI teams can actually control.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “Okta authentication for BigQuery MCP servers”.
Key questions
Q: How should teams govern MCP servers that need access to cloud data sources?
A: Treat the MCP server as a controlled identity workload, not as a place to store long-lived credentials.
Q: Why do static service-account keys create extra risk in MCP integrations?
A: Static keys are durable, portable, and hard to constrain to a single session or user.
Q: What are the signs that an MCP federation design is not working properly?
A: Look for shared principals in logs, overbroad cloud roles, repeated manual key handling, or access that cannot be traced back to a named user.
Practitioner guidance
- Define the federation boundary Document where the Okta session ends, where ToolHive begins, and which Google Cloud principals are created through token exchange.
- Replace embedded service-account keys Remove JSON credentials from MCP server configs and container images for any production data integration.
- Map cloud roles to user intent Grant each mapped Okta identity only the BigQuery permissions needed for its specific query workload.
Bottom line: MCP servers that query cloud data should be treated as governed identity workloads, not as applications that happen to need credentials.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:14 pm
Credential sprawl is the real control failure this architecture is designed to eliminate: The article is not really about convenience, it is about replacing a reusable secret boundary with a federated identity boundary. Static service-account keys turn an MCP server into a credential custody problem, while federation keeps the server from becoming a secret store. Practitioners should treat that as a shift in governance model, not just an implementation preference.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should teams use federated access or embedded credentials for MCP workloads?
A: Federated access is the safer default when the workload reaches production systems and user-level accountability matters. Embedded credentials may look simpler, but they collapse identity boundaries, make offboarding harder, and leave too much standing privilege inside the server runtime.
👉 Read our full editorial: Okta federation for BigQuery MCP servers reduces credential sprawl