Topic starter
20/08/2026 5:24 pm
TL;DR: BigQuery-accessing MCP servers should be treated as governed identity workloads, Stacklok argues, rather than apps that merely need credentials. That shifts control to federation, scope mapping, and revocation so access stays tied to the real user or workload.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “Okta authentication for BigQuery MCP servers”.
Key questions
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.
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.
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.
Glossary terms: Identity Translation, Workforce identity pool, Federated Short-Lived Credentials, Per-user attribution
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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