Snowflake MCP federation exposes the real NHI control gap

At a glance

What this is: This lab shows how a federated JWT path can give Snowflake MCP queries a traceable human-and-agent identity instead of a shared service account.

Why it matters: It matters because IAM teams have to govern agent-driven data access with the same rigor they apply to NHI and human access, or audits will collapse into opaque shared credentials.

👉 Read Strata Identity's walkthrough of federated AI client access to Snowflake managed MCP

Context

MCP-connected workforce AI creates a familiar identity problem in a new place: a tool call now carries real data access and should not inherit a shared secret by default. In practice, many teams still treat agent-to-data access like a convenience integration, even though the underlying issue is NHI governance, not application wiring.

Strata Identity’s example focuses on Snowflake because it makes the governance trade-off visible. The article argues for federated, claim-rich JWTs so the query log can tie a human request to an agent action without handing the managed MCP server a reusable service-account token. That is a sound identity pattern for any environment where agent workloads touch the data layer.

Key questions

Q: How should security teams govern managed MCP access for AI clients?

A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task. That means no shared service-account secrets, narrow role scopes, and audit logs that can tie the human requester to the agent session and the resulting data access. Use the token as the control boundary, not the client config.

Q: Why do shared service accounts break auditability for agent-driven queries?

A: Shared service accounts collapse many human requests and agent actions into one identity, so logs no longer show who delegated what or whether the access matched the task. That breaks access reviews, incident reconstruction, and role accountability. In regulated environments, it also weakens evidence that query access was intentional and least-privileged.

Q: What breaks when MCP clients reuse one warehouse credential across a team?

A: Role assignment, offboarding, and forensic review all become ambiguous because the same credential can be used by multiple operators and multiple agent sessions. When the credential is compromised, every task behind it is exposed. The control failure is identity collapse, not just secret leakage.

Q: Who is accountable when an AI agent runs a query on behalf of a user?

A: Accountability sits with the identity chain, not with the tool call alone. The human who delegated the action, the issuer that minted the token, and the platform that activated the role all need a traceable record. If any of those links are missing, the organisation cannot prove who authorised the access.

Technical breakdown

Federated OAuth for managed MCP access

The lab uses OAuth 2.0 and external JWT validation so the resource server, Snowflake, can trust a token issued elsewhere without storing a shared credential. The key mechanism is EXTERNAL_OAUTH_INTEGRATION, which maps token claims to a user and role at session start. That makes the managed MCP server a federated resource, not a place where a persistent secret should live. The important detail is that authorization is expressed through signed claims, not a hardcoded service account.

Practical implication: treat managed MCP endpoints as federated resource servers and require identity-bound tokens, not shared credentials.

Claim enrichment and audit reconciliation

The Go Service Extension injects agent identity claims into the access token before signing, including agent_type, agent_provider, agent_instance_id, and delegation_purpose. Snowflake then records the session in LOGIN_HISTORY and the resulting work in QUERY_HISTORY, which lets a reviewer reconcile who asked for access, which identity received it, and what the agent actually did. This is the difference between authentication data and governance evidence. Without enriched claims, the logs may show activity but not accountable delegation.

Practical implication: preserve agent claims end to end so audit teams can reconcile token minting with query execution.

Why shared MCP secrets fail governance

A shared personal access token attached to a service account creates a structural blind spot. It collapses multiple humans and multiple agent actions into one identity, which breaks access review, role assignment, and incident reconstruction. The problem is not just exposure risk. It is that the identity no longer represents a single accountable actor, so the control plane cannot distinguish legitimate use from delegated misuse. In NHI terms, the account outlives the delegation relationship that created it.

Practical implication: eliminate shared MCP credentials wherever a query can be tied to a specific human or workload identity.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shared service-account access for workforce AI is a governance failure, not an implementation shortcut. The article shows why a reusable token tied to one warehouse account cannot support accountable delegation when multiple humans and agents are involved. Access reviews, role mapping, and incident reconstruction all break once several operators share one identity. Practitioners should treat this as a lifecycle and accountability problem, not a convenience pattern.

Federated identity is the correct baseline for managed MCP, because the resource server should validate claims, not inherit secrets. Snowflake’s external OAuth model is a useful example of how NHI governance can move into signed, short-lived assertions rather than persistent credentials. That does not solve everything, but it restores identity boundaries around the query. Practitioners should use federated trust wherever agent workloads touch governed data.

Identity blast radius is the right named concept for this pattern. Once an MCP client is handed a broad service account, the blast radius expands from one delegated task to every query the token can reach. The article’s audit-log reconciliation problem is the symptom of that expansion. Practitioners should measure whether each agent call can be tied to a single accountable identity before the query is allowed to run.

NHI lifecycle discipline now extends to agent-driven data access. Tokens, claims, and workload identities used by MCP clients need the same joiner, mover, leaver thinking that teams apply to service accounts and privileged access. The article’s strongest signal is that the audit chain only works when identity issuance, role activation, and query execution are all connected. Practitioners should govern agent access as lifecycle, not as one-off integration work.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface.
• 48% of organisations say they cannot track and audit the data their AI agents access, leaving a complete compliance blind spot.
• For a broader control model, compare this with Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs and align token lifecycle with delegation lifecycle.

What this signals

Identity blast radius: the practical question is no longer whether an AI client can connect to data, but how far one delegated credential can travel before accountability disappears. Teams that already let workforce AI touch analytics or warehouse systems should assume every broad token becomes a future audit problem unless it is bound to a specific human, task, and role.

The operating model should now separate issuer trust, token scope, and query execution into distinct control points. That separation is what makes reviewable delegation possible, and it is where NHI governance starts to converge with broader zero-trust architecture patterns. For teams building this out, the Ultimate Guide to NHIs remains the clearest baseline for lifecycle thinking.

Agentic data access is quickly becoming a governance issue, not just an integration pattern. If a platform cannot prove which human asked which agent to run which query, then the organisation has not solved access management, only hidden it behind automation. That is the signal to tighten identity issuance before expanding MCP usage further.

For practitioners

• Replace shared MCP credentials with federated tokens Map each agent session to a signed access token that Snowflake or another data platform can validate directly. Keep the secret at the issuer, not in the client config, and require role activation through scoped claims rather than a reusable service-account token.
• Inject accountable agent claims into access tokens Carry agent_type, agent_instance_id, delegation_purpose, and the human subject through token minting so audit logs can correlate who delegated the action and which agent executed it.
• Reconcile query logs with token mint logs Join identity-provider mint events to platform query history so security teams can trace a single delegation chain without relying on a shared warehouse credential or manual tickets.
• Scope MCP roles to the minimum query surface Bind each token to a single role and a narrow scope set, then verify that the managed MCP server cannot escalate into broader warehouse access than the delegated task requires.
• Separate production trust anchors from lab shortcuts Use a hardened public JWKS origin and avoid tunnel-based publication patterns outside testing, because the trust anchor must remain stable and reviewable when the MCP workflow goes live.

Key takeaways

• Managed MCP access becomes an NHI governance problem the moment teams rely on shared service-account credentials.
• The strongest evidence in this pattern is auditability failure, not just secret exposure, because shared tokens erase the human-to-agent delegation chain.
• Federated JWT issuance, narrow role scope, and end-to-end log reconciliation are the controls that keep agent-driven data access reviewable.

Key terms

• Federated identity: Federated identity lets one system issue a signed assertion that another system trusts for access decisions. In NHI governance, it is the difference between a shared secret and a reviewable delegation chain, because the resource server can validate who acted, for what purpose, and under which scope.
• Identity blast radius: Identity blast radius is the amount of access, data, and operational scope that can be reached if one credential or token is misused. For agentic and non-human identities, the blast radius can expand quickly when one token serves many users, many tasks, or many queries.
• Service-account sprawl: Service-account sprawl is the accumulation of shared or long-lived machine identities that are created for convenience and then reused across teams or workflows. It increases governance friction because the account no longer maps cleanly to one operator, one purpose, or one lifecycle event.
• Delegation chain: A delegation chain is the sequence of identities and approvals that connect a human request to an automated or agent-driven action. In mature IAM and NHI programmes, the chain must remain visible from issuer to execution so that accountability survives the handoff.

Deepen your knowledge

Agentic data access and federated token governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for managed MCP or workforce AI data access, it is worth exploring.

This post draws on content published by Strata Identity: federated AI client access to Snowflake managed MCP through Maverics. Read the original.