Explore Related Topics

Claude is on every desk. So is ChatGPT. So is Cursor, and Copilot, and whichever AI client your CIO greenlit last quarter. The rollouts are done. The licenses are paid for. The adoption curve cleared the early-adopter phase a year ago. Every function in the company has people using these tools every day. And the same question keeps coming back from all of them: “Can I point this at our data?” Security keeps giving the same answer back: “Not yet.”

That “not yet” is where most enterprises are stuck right now. The AI clients are already on every desk. The workforce is already pulling productivity out of them on public data and personal projects. The next move is the one nobody can sign off on. How do you connect those clients to your data layer through an MCP server? As a result, pilots stall. POCs miss their dates. Workforce productivity that the business already paid for sits behind a gate the security team can’t open without standing up a credential program nobody has the budget for.

I’ve watched this exact scene play out at three customers in the last quarter. Every one of them had Databricks running production workloads. Every one of them had Claude or ChatGPT deployed across thousands of seats. Every one of them stalled at the same moment, on the same question, for the same reason. The data was right there. The clients were ready. The identity story was a service account.

This is the conversation between data and security that has to happen before a single MCP call from a workforce AI client reaches Unity Catalog. Databricks shipped a real piece of the answer. Your IdP holds the rest. Wired together correctly, security review becomes the moment workforce AI gets a green light. Pilots move to production on standard and with the audit chain compliance needs, all without anyone lowering the bar.

The shortcut that ends every audit badly

When a workforce AI client wants data on one side and a warehouse holds it on the other, the shortest line between them is an over-permissioned shared secret. Someone provisions a service account so Claude can connect. Someone generates a personal access token and drops it into the MCP client config. Someone tells thirty analysts to share the same warehouse credential because building per-user controls felt like a six-week project nobody budgeted.

This works. For a while.

Then the query log gets pulled in an audit and every read came from svc_claude_prod_01. Then someone exfiltrates a token from a laptop and it’s good across the entire workforce. Then a compliance team asks for role-based access reviews and you realize there are no roles — there’s one account that thirty people share, doing whatever any of them ask of it.

The shortcuts aren’t the problem. The accumulation is. Each one moves the human one step further from the query running on their behalf. By the time a real incident shows up, the audit trail is a dead end and the team that approved the AI rollout takes the blame for a security architecture nobody asked them to design.

Federated Exchange: the model that fits Databricks, Snowflake, and what comes next

Databricks ships account-wide token federation, a working Security Token Service: an RFC 8693 endpoint that accepts a JWT from any issuer your account trusts and returns a Databricks-native OAuth token in exchange. Snowflake supports the same outcome via External OAuth. The mechanics differ; the trust model is the same.

We call this pattern Federated Exchange, and it’s the model the rest of this post is built around. We’ve validated it end to end against Databricks and Snowflake using the same Maverics Authorization Server, the same RFC 8693 brokering, the same delegated identity claims, and the same audit chain. The data platform changes. The model doesn’t.

Translate that into something you can take to a security review:

  • The data platform never stores credentials for the caller.
  • The warehouse never sees a password.
  • Your trust chain — corporate IdP plus the Maverics Authorization Server — becomes the decision point for who gets in.

Provision trust to one issuer. Let your IdP and the Authorization Server do the rest. When someone joins, only their IdP account changes. When they leave, one deprovision removes warehouse access. Role changes, permission reviews, and MFA all stay in the system your identity team already runs. The pattern carries forward to whatever data platform the business adopts next.

Three Token Brokering flows the gateway supports

Federated Exchange is the model we recommend for the data layer. It isn’t the only flow the Maverics AI Identity Gateway supports, because not every upstream speaks RFC 8693 the same way and the gateway has to meet each one where it is. Token Brokering is the umbrella capability and is made up of three flows, one gateway, one OPA authorization layer evaluating every exchange before the gateway forwards it.

Session Passthrough (publicly available). The user authenticates to an upstream IdP during login; the Authorization Server caches the access token in the session and returns it from cache when the AI client asks for that audience. The upstream sees a normal OAuth token — it doesn’t know the gateway is in the chain. Use this when the upstream accepts standard OAuth tokens but doesn’t speak RFC 8693. Examples: GitHub OAuth Apps, Google Workspace APIs, Atlassian 3LO.

Federated Exchange (private preview). The Authorization Server mints its own short-lived JWT, signs it with its own key, and exchanges it with the upstream AS via RFC 8693. The upstream trusts the Authorization Server as a federated issuer through a published OIDC discovery and JWKS endpoint. The JWT is short-lived and configurable (think minutes, not hours) and carries the user as sub, the AI client as act, and the data platform as aud. The upstream validates it and returns its own native, audience-bound access token for the actual query. This is the model we recommend for the data layer. Examples: Databricks account-wide token federation, Snowflake External OAuth, GCP Workload Identity Federation, and AWS STS via AssumeRoleWithWebIdentity — same trust model, provider-specific exchange APIs.

Brokered Exchange (private preview). The user’s IdP token (Okta, Entra, Ping) is already in the session from login. The Authorization Server forwards that token to the upstream AS as the subject_token in an RFC 8693 exchange. The upstream trusts the customer’s IdP directly, but but the gateway stays in the call path, and that’s the value. Inbound OPA policy on the MCP gateway evaluates every tool call before the exchange runs. Outbound policy narrows the audience and TTL of what the IdP token is allowed to authorize downstream — turning a long-lived workforce token into a short-lived, narrowly scoped exchange the data platform sees. The Maverics audit log captures the full user → agent → tool → upstream chain that neither the IdP nor the data platform records on its own. Use this when the customer’s IdP is already a trusted issuer on the data platform and you want governance and end-to-end observability without re-minting the token. Examples: Databricks federation with the customer’s IdP as the trusted issuer, GCP Workload Identity Federation with Okta or Entra as the trusted issuer.

Pick the flow that fits the upstream in front of you. The audit chain, the OPA policy gate, the short-lived tokens, and the delegated identity claims stay consistent across all three. Same gateway. Same Authorization Server. Same operational model for the team running it.

Session Passthrough is publicly available today. Federated Exchange and Brokered Exchange are in private preview — reach out if you want to validate them against your data platform.

Three properties that have to be true for sign-off

A CISO doesn’t approve protocols. They approve properties. The Maverics AI Identity Gateway sits in front of Databricks MCP traffic and the Maverics Authorization Server brokers the tokens behind it. Together they give a security review three things to inspect:

Standards-based Federated Exchange. The Authorization Server speaks RFC 8693 natively. No custom code per platform. No bespoke trust shim your incident-response team has to learn the night something goes wrong. The same Federated Exchange primitives that broker into Databricks today broker into Snowflake, GCP STS, AWS STS, and any RFC 8693-style endpoint that ships next.

Delegated identity on every call. Each exchange is driven by a short-lived JWT — again minutes, not hours, and configurable to your policy — that carries sub (the user driving the request) and act (the agent acting on their behalf). The data platform validates that JWT and issues its own short-lived, audience-bound access token for the query itself. Token leakage at either hop stays a non-event because the windows are too short to replay, the audiences too narrow to reuse.

User-scoped enforcement at the data layer. On Databricks, Unity Catalog applies the user’s existing table ACLs, row filters, and column masks; query history attributes every statement back to that user. On Snowflake, RBAC roles, row access policies, and dynamic data masking apply to the same federated identity, and QUERY_HISTORY attributes the run. The Maverics audit log preserves the full delegation chain on top: user, agent, tool, time. Three logs, one identity, no service account in sight.

The audit chain a reviewer can follow

Here’s what lands on the wire when an analyst asks an agent for last quarter’s claims trends. The Maverics Authorization Server presents a JWT to the Databricks STS that looks like this:

{

  “iss”: “https://auth.acme.com/”,

  “sub”: “[email protected]”,

  “aud”: “https://accounts.cloud.databricks.com/oidc/accounts/<account-id>”,

  “act”: { “sub”: “ai-analyst-agent” },

  “iat”: 1776859200,

  “exp”: 1776859500

}

Read the claims like a reviewer would. iss is your Authorization Server. sub is the analyst — and it has to resolve to a real principal the data platform already governs (a Unity Catalog user on Databricks, an RBAC identity on Snowflake) through the federation policy, or the exchange fails closed before any query runs. act is the agent she authorized. aud is the warehouse. iat and exp bound this token to a short, configurable window. Long enough for one exchange, short enough to forget.

Without the act claim, you’d still know who. You wouldn’t know what was acting on their behalf. When an AI client misbehaves at three in the morning, that distinction is the difference between disabling one client and locking out the human who never did anything wrong. AWS IAM role assumption carries the same property. Kubernetes impersonation carries it. Mature delegated authority looks like this everywhere it shows up in production.

What this looks like for the analyst opening Claude

The whole point of this architecture is that the user doesn’t see it. Walk through what an analyst named Alice actually does the first time she connects Claude to your data:

  1. Alice adds the Databricks MCP server in her Claude desktop client. Claude prompts her to authorize. The OAuth flow opens her browser at your IdP — Okta, Entra, Ping, whatever she signs into for everything else.
  2. She authenticates with her workforce credentials, including MFA if your policy requires it. Your IdP is the only thing that sees her password. Claude never does. Databricks never does.
  3. She asks Claude a question. “What’s the trend in claims paid out by region for the last four quarters?” Claude calls a tool on the Databricks MCP server. The call carries the access token your IdP issued to Alice.
  4. The AI Identity Gateway evaluates her request, exchanges the token through the Maverics Authorization Server for a short-lived Databricks-bound JWT carrying sub: alice and act: claude-desktop, and forwards the call.
  5. Databricks runs the query under Alice’s identity. Unity Catalog applies her existing row- and column-level permissions. The trend she gets back covers exactly the regions she’s allowed to see — no more, no less.
  6. Three logs capture the event. Claude logs the tool call. The Maverics audit log records alice → claude-desktop → databricks_mcp.query → 09:14:22 UTC. Databricks query history shows the SQL ran as Alice.

Alice didn’t see a token. She didn’t paste a credential. She didn’t pick which warehouse user to be. She did what she does every other day at work: signed into her corporate identity and got on with her job. The AI client got useful. Your data layer stayed governed.

Replace “Claude” with ChatGPT, Cursor, or any other MCP-aware AI client and the picture doesn’t change. One federation policy on the Databricks side. One brokering policy on the Strata side. Every workforce AI client your CIO approved tomorrow inherits the same governance you set up today.

How this becomes a workforce-wide rollout

The architecture clears the security bar without moving it. Compliance ends up with a cleaner audit chain than they have on most legacy applications. The data team gets the AI clients they wanted. The security team gets the evidence they need. The platform team doesn’t run a second permission system in parallel. Federation goes in once; the data estate inherits it.

That partnership between leadership, the practitioners running the system, and the security and compliance functions reviewing it is exactly what scales a single MCP integration into a workforce-wide rollout. Working with security and compliance is the win.

The short version

AI clients without data access are a chat toy. AI clients with shared service-account access to your warehouse are a pending incident report. Token federation is the way past that binary. The Maverics AI Identity Gateway supports three Token Brokering flows — Session Passthrough, Federated Exchange, and Brokered Exchange — across Databricks, Snowflake, Redshift, and the rest of the data and SaaS estate. Federated Exchange is the one we recommend for the data layer, validated end to end against Databricks and Snowflake. The Maverics Authorization Server signs short-lived JWTs that carry the human on the line. The data platform honors them. Unity Catalog enforces the permissions you already wrote. The audit log tells the truth.

Your workforce already has Claude. Your workforce already has ChatGPT. Either you connect them to your data layer with the user’s identity attached, or you watch a productivity gap open between you and every competitor that did. This is the conversation you can take into a security review without flinching. Bring it before the next AI rollout stalls.

Further reading

What you should do next...

  1. Want to read more? Download the CSA survey to learn more about what leading teams are doing.
  2. Figure out what AI agent authentication can look like for you. Test out the Maverics Agentic AI Sandbox to explore your options.
  3. Ready to see Strata in action? Book a demo with our product team.