Agent access to databases used to need a bastion VM. Google, Oracle and Databricks made it an identity setting

Until recently, giving an AI agent access to an operational database often meant a small private project: a bastion VM, a service account with a password in a configuration file, and some custom middleware to turn questions into SQL. It worked, and every instance of it was a security review waiting to happen.

Two releases on October 27 replace that pattern with configuration.

What became available

Google and Oracle. The remote MCP server and ExecuteSQL Data API for Oracle AI Database@Google Cloud, first announced at Google Cloud Next, are now generally available. They give agents, Google Cloud services and applications a standard interface to run SQL against Oracle databases, governed by Google Cloud IAM, with credentials resolved through Secret Manager so no plaintext password is involved. Google says it removes the need for custom natural-language-to-SQL middleware and bastion VMs. Around it, several pieces are at different stages: more than 135 prebuilt skills for JD Edwards, E-Business Suite, NetSuite and Fusion are available; a Gemini connector for natural-language queries, a Knowledge Catalog integration and two-way Apache Iceberg access are in preview behind sign-up forms. New regions in Turin and Querétaro went live.

Databricks. ChatGPT, Codex, Claude, Claude Code and Cursor can now connect to Databricks MCP servers, including the Genie One MCP server, using default OAuth client IDs, generally available. In Databricks’ words, “an account admin doesn’t need to create an OAuth app.” Separately, metastore admins can now use Unity Catalog permissions to control which task-specific AI Functions people may run, also GA, enabled through the account team.

Less plumbing, the same decisions

Both releases move the agent’s access out of custom code and into the identity layer, which is where it belongs. We argued that enterprise MCP starts with identity: every tool call needs a name behind it. A remote MCP server governed by IAM, or an OAuth flow that runs as the signed-in user, gives each call that name.

What changes is who has to make the remaining decisions, because they no longer hide in middleware:

Whose identity runs the query? With OAuth, an external client acts as the user who consented, which is good: the database’s own permissions apply. With a service identity behind an IAM-governed endpoint, every caller gets that identity’s reach. Check which one each integration uses.

Which clients may connect at all? Default OAuth apps make it easy for an employee to connect ChatGPT or Cursor to company data. That is the point, and it is also a policy question. Decide which of the five clients are approved, for which workspaces, and whether the client’s own data terms (retention, training, region) fit the data involved.

What may the SQL do? An “execute SQL” interface is broad by design. Restrict the role to the schemas and operations the agent needs, prefer read-only for analysis agents, and enforce business rules in the database rather than in the agent’s instructions, the approach Oracle’s Deep Trust architecture proposes.

Can you see it afterward? Make sure database audit logs record the end user, the client and the MCP server behind each query, so an investigation does not stop at “the integration.”

The direction is right: fewer secrets in files, fewer one-off proxies, and access decided by the same identity systems that govern people. It also means the database can now be reached by more agents with less effort. Write down who approves each new client before the first one connects.