Databricks' agents now reach the terminal, your SaaS tools and outside AIs. Each carries the user's identity
Genie Code CLI, Genie Agents' MCP connectors and the Genie One MCP server all run with the requesting person's permissions. When analytics agents act, data permissions become action permissions.
Listen to this article · 5 min
AI-generated narration of the full article.

Databricks’ new Gmail connector for its analytics agents cannot send email or edit existing messages. That small limitation says more about where enterprise agents are heading than the feature list does: the moment an analytics agent can act outside the data platform, someone has to decide which actions it inherits.
In the space of three days, Databricks pushed its Genie agents in three directions at once, and the documentation for all three gives the same answer about identity.
Three directions, one rule
Into the terminal. Genie Code CLI, in beta since October 6, is a coding agent that runs on a developer’s machine, works with local files and uses the Databricks CLI to discover data, answer questions and build and deploy pipelines, models and apps. Model access goes through Databricks’ Unity Gateway, so there is no separate model subscription during the beta. It needs Unity Catalog and a workspace in a supported region, and it “runs under your own identity”.
Out to other tools. Genie Agents can now use MCP connectors to Google Drive, Gmail, Google Calendar, Microsoft 365, Atlassian, Slack, GitHub and Glean, in beta and only after a workspace administrator turns the feature on. Each person authenticates to each external system individually, and, in Databricks’ words, “every tool call runs with the permissions of the user who asks the question”. Read tools run automatically; write tools pause for the user’s approval.
In from other agents. The Genie One MCP server, generally available as of October 8 (the beta endpoint is deprecated on October 31), exposes Genie to external MCP clients such as Claude, ChatGPT and Cursor. Databricks recommends on-behalf-of-user OAuth, supports service principals for programmatic workloads, and states that Unity Catalog permissions are always enforced.
| Status | Whose permissions | Writes | |
|---|---|---|---|
| Genie Code CLI, in the terminal | Beta | The developer running it | Deploys what the developer may deploy |
| Genie Agents with MCP connectors | Beta, admin enabled | The user who asked | Pause for the user's approval |
| Genie One MCP server, for outside agents | Generally available | The calling user, or a service principal | Questions and results only |
What delegated identity settles
This is the design we argued for when we wrote that every MCP tool call needs a name behind it. An agent that borrows the user’s permissions cannot see data the user could not see, and every action lands in an audit trail under a real person. It avoids the worst pattern in early agent projects: a service account with broad access that every user’s agent shares.
It also keeps Databricks’ strongest asset in play. Unity Catalog already holds the data permissions, and in the case of Genie, the business definitions we discussed in our analysis of Genie One for regulated finance. Extending them to the terminal and to outside agents is cheaper and safer than rebuilding them in each tool.
What it does not settle
Data permissions become action permissions. A user who may read a sales table and send email now has an agent that may read the table and draft the email. Each permission was granted on its own, years apart, by different teams. Nobody reviewed the combination. The approval pause on write tools helps, but an approval prompt shown many times a day trains people to click yes.
The user’s whole scope is the agent’s whole scope. Delegation guarantees the agent cannot exceed the person. It does nothing to narrow the agent to the task. For an analyst with wide access, an agent that only needs one dataset still carries all of it into every external tool call.
Service principals reopen the question. The Genie One server accepts service principal authentication for programmatic workloads. That is reasonable for pipelines, and it is exactly where the shared broad credential can come back. Each one needs an owner and a scope, the same as any other non-human identity.
Shared spaces add an audience. When an agent answers inside a team channel, as we noted about Cisco’s agents in Webex, the requester’s permissions decide what it can read, but everyone in the space sees the answer.
Databricks’ Gmail connector that cannot send, and its write tools that wait for a click, are early signs that vendors know this. The next step is policy that can say “this agent, for this task, with this subset of what its user can do”. Delegated identity is the floor of agent authorization, not the ceiling.