| → / Space | Next slide |
| ← | Previous slide |
| Home | First slide |
| End | Last slide |
| Swipe | Touch navigation |
Scenario: employees asking Genie Agents questions from inside Teams and Copilot Studio, each seeing only their own row-level permissions
This deck covers the four integration paths, the two independent gates on per-user identity, the token exchange mechanics, and what breaks silently.
A custom Teams bot, Copilot Studio in two credential modes, and the native marketplace app — each with a different identity model.
Teams sign-in through Entra ID, an RFC 8693 token exchange, and how that identity reaches Agent Bricks and Genie Agents.
Token-layer identity is Gate 1. The Genie Agent's publish mode is Gate 2. Most rollouts only check the first.
Why a correctly-configured OAuth token still doesn't guarantee per-user data access if the space is published EMBEDDED_CREDENTIALS.
The two-user test, which setting to check on each path, and the gotchas that cause silent failures.
When two different employees ask Genie Agents the same question from inside Teams or Copilot Studio, do they get answers scoped to their own row-level permissions — or the same answer regardless of who's asking?
The answer depends on which of the four paths is in use, and on two separate settings, not one. The four paths look similar from the client side, which is exactly what makes this easy to get wrong.
| Path | Token-layer identity | Confidence |
|---|---|---|
| Custom AI agent + Azure Bot Service + OAuth federation | Per-user OBO | Code-traced from official reference implementation |
| Copilot Studio via MCP, “End user credentials” | Per-user (U2M) | Confirmed in official docs |
| Copilot Studio via MCP, “Maker credentials” | Shared, by design | Intentional M2M mode, not per-user |
| Native “Databricks Genie Agents” app (Teams / M365 Copilot marketplace) | Per-user (Entra ID) | Confirmed per-user sign-in required |
All four paths gate on the same second condition: the Genie Agent's publish mode. Regardless of which integration you choose, verify that the space is published VIEWER, not EMBEDDED_CREDENTIALS.
current_user() = the human at the Genie Agents/UC layer. Gate 1 passed: the human's identity reached Databricks. But Gate 2 (the space's publish mode) still decides whether RLS fires.
OAuth federation, no client_id in the exchange, “End user credentials” selected in Copilot Studio. This is the gate everyone checks — and the one all the setup guides walk you through.
This lives on the space, not the client integration. It's invisible from the Teams bot's or Copilot Studio connector's configuration screen — you have to check the space directly.
“We used OAuth / OBO, so we're covered.” Getting the token layer right is necessary — and, on its own, not sufficient. There's a second setting, on the Genie Agent itself, that decides whether any of that per-user auth actually reaches the data.
If Gate 2 is missed, every user sees the exact same data — regardless of how correctly the token exchange, OAuth federation, or Copilot Studio credential setting is configured upstream. There's no error and no warning; the space just quietly runs every query as its publisher.
POST {databricks_host}/oidc/v1/token grant_type=urn:ietf:params:oauth: grant-type:token-exchange &subject_token={entra_jwt} &subject_token_type= urn:ietf:params:oauth:token-type:jwt &scope=all-apis # Critical: no client_id # Omitting it keeps this per-user
workspace_client = WorkspaceClient( host=databricks_host, token=oauth_db_token, ) # calls to the serving endpoint now carry # the user's identity; Agent Bricks OBO # forwards it automatically to Genie Agents
This RFC 8693 exchange is the account-wide standard for per-user federation from any external IdP. Teams + Azure Bot Service is a new front-end for the same pattern used by Power BI Embedded and other clients.
| Publish mode | Who the SQL runs as | Per-user RLS? |
|---|---|---|
VIEWER |
The calling identity — the human, if a per-user token reached the API | Yes |
EMBEDDED_CREDENTIALS |
The space's publisher — always | No |
Critical: This setting lives on the Genie Agent itself, not on the Teams bot configuration or Copilot Studio connector. Don't infer it from the client integration settings. You have to check the space's publish mode directly.
Officially documented pattern. Check Gate 2 on the target Genie Agent before shipping.
Gives real per-user identity — still gated by Gate 2. “Maker credentials” is fine when shared access is the actual intent.
The marketplace apps require users to sign in with their Databricks identity. Still gated by Gate 2: verify the space's publish mode before rollout.
Don't infer it from the client integration's settings. It's a property of the space, and it silently overrides everything upstream of it.
| Issue | Detail |
|---|---|
| Correct per-user token, wrong Genie Agent publish mode | The most common silent failure. OAuth is right, but the space runs as publisher. Check the space's own settings, not the client integration. |
Include client_id in token exchange | Never include it. If you do, it selects a service principal and collapses RLS to the SP's identity regardless of whose token called it. |
preferred_username claim mismatch | The federation policy's subject_claim must match what your Entra tenant actually issues. If tenant issues upn instead, the exchange fails silently. |
| Confusing two “Teams + Genie Agents” integrations | The native marketplace app (automatic warehouse, no PrivateLink) is different from custom Azure Bot Service (manual setup, full control). Confirm which one before designing RLS. |
| “Maker credentials” in Copilot Studio | This is intentionally shared M2M by design, not an incomplete OBO mode. Use it when you want shared access. |