Notifications
Clear all
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.
NHIMG editorial — based on content published by Stacklok: Okta authentication for BigQuery MCP servers
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: How should security teams avoid service-account sprawl in MCP server deployments?
A: Use federation and token exchange so the MCP server does not store reusable cloud keys.
Q: Why do federated MCP workflows improve auditability?
A: They preserve the link between the human user, the authenticated session, and the cloud action taken by the server.
Q: What breaks when MCP servers rely on a single shared credential?
A: A single shared credential breaks attribution, scope control, and revocation precision.
Practitioner guidance
- Remove embedded service-account keys from MCP server configs Replace JSON credentials and other reusable Google Cloud keys with federated token exchange through a proxy or equivalent trust broker.
- Map user identity to cloud permissions explicitly Bind Okta identities or groups to the narrowest BigQuery roles needed for the workload, and preserve the subject mapping in logs so query activity remains attributable to the real user.
- Separate authentication from tool execution Run the MCP server as the tool layer and place authentication, callback handling, and STS exchange in a dedicated proxy so the access boundary is visible and enforceable.
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 Okta OIDC application and authorization-server configuration for MCP federation
- Exact Google Cloud workforce identity pool and audience-mapping setup for per-user BigQuery access
- Full ToolHive proxy command-line flags and callback settings for the remote-auth flow
- Client-side MCP registration details for Claude Code and other MCP-compatible tools
👉 Read Stacklok's blog on Okta authentication for BigQuery MCP servers →
Okta-authenticated BigQuery MCP access: what changes for IAM teams?
Explore further
20/08/2026 6:14 pm
Static cloud credentials are the wrong trust primitive for MCP server access. This pattern shows why service-account keys do not belong in an MCP configuration file when the server is brokering user-driven data access. Once a credential is embedded, every runtime path that can reach the file can potentially reuse it, which turns a federation problem into a secret sprawl problem. Practitioners should treat embedded cloud keys as a governance failure, not a convenience trade-off.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: What should IAM teams review before allowing MCP in production?
A: IAM teams should review how the protocol establishes identity, how tool permissions are assigned, and whether the same policy is enforced consistently across clients. If the answer differs by implementation, the organisation has a governance gap that can produce uneven access and weak audit trails.
👉 Read our full editorial: Okta federation for BigQuery MCP servers reduces credential sprawl
