Da VM bastion à identidade: Google, Oracle e Databricks mudam o acesso a bancos

Até recentemente, dar a um agente de IA acesso a um banco de dados operacional muitas vezes significava um pequeno projeto privado: uma VM bastion, uma conta de serviço com senha em um arquivo de configuração e algum middleware personalizado para transformar perguntas em SQL. Funcionava, e cada instância disso era uma revisão de segurança esperando para acontecer.

Dois lançamentos em 27 de outubro substituem esse padrão por configuração.

O que ficou disponível

Google e Oracle. O servidor MCP remoto e a ExecuteSQL Data API para Oracle AI Database@Google Cloud, anunciados pela primeira vez no Google Cloud Next, agora estão em disponibilidade geral (GA). Eles dão a agentes, serviços do Google Cloud e aplicações uma interface padrão para executar SQL em bancos Oracle, governada pelo IAM do Google Cloud, com credenciais resolvidas pelo Secret Manager, sem senha em texto simples envolvida. O Google diz que isso elimina a necessidade de middleware personalizado de linguagem natural para SQL e de VMs bastion. Em volta disso, várias peças estão em estágios diferentes: mais de 135 skills pré-construídas para JD Edwards, E-Business Suite, NetSuite e Fusion estão disponíveis; um conector Gemini para consultas em linguagem natural, uma integração com o Knowledge Catalog e acesso bidirecional a Apache Iceberg estão em preview atrás de formulários de inscrição. Novas regiões em Turim e Querétaro entraram em operação.

Databricks. ChatGPT, Codex, Claude, Claude Code e Cursor agora podem se conectar aos servidores MCP do Databricks, incluindo o servidor MCP Genie One, usando IDs de cliente OAuth padrão, em disponibilidade geral (GA). Nas palavras da Databricks, “um administrador da conta não precisa criar um app OAuth”. À parte, admins de metastore agora podem usar permissões do Unity Catalog para controlar quais AI Functions específicas de tarefa as pessoas podem executar, também em disponibilidade geral (GA), habilitado pelo time da conta.

Menos infraestrutura, as mesmas decisões

Os dois lançamentos tiram o acesso do agente do código personalizado e o colocam na camada de identidade, que é onde ele pertence. Defendemos que o MCP enterprise começa pela identidade: toda chamada de ferramenta precisa de um nome por trás. Um servidor MCP remoto governado pelo IAM, ou um fluxo OAuth que roda como o usuário autenticado, dá esse nome a cada chamada.

O que muda é quem precisa tomar as decisões restantes, porque elas não se escondem mais no middleware:

Qual identidade executa a consulta? Com OAuth, um cliente externo age como o usuário que consentiu, o que é bom: as permissões do próprio banco se aplicam. Com uma identidade de serviço por trás de um endpoint governado pelo IAM, todo chamador recebe o alcance dessa identidade. Verifique qual cada integração usa.

Quais clientes podem se conectar, afinal? Apps OAuth padrão facilitam que um funcionário conecte ChatGPT ou Cursor a dados da empresa. Esse é o ponto, e também é uma questão de política. Defina quais dos cinco clientes são aprovados, para quais workspaces, e se os termos de dados do próprio cliente (retenção, treinamento, região) se encaixam nos dados envolvidos.

O que o SQL pode fazer? Uma interface de “executar SQL” é ampla por design. Restrinja o role aos schemas e operações de que o agente precisa, prefira somente leitura para agentes de análise e aplique regras de negócio no banco, não nas instruções do agente, a abordagem que a arquitetura Deep Trust da Oracle propõe.

Dá para ver isso depois? Garanta que os logs de auditoria do banco registrem o usuário final, o cliente e o servidor MCP por trás de cada consulta, para que uma investigação não pare em “a integração”.

A direção está certa: menos segredos em arquivos, menos proxies avulsos e acesso decidido pelos mesmos sistemas de identidade que governam as pessoas. Isso também significa que o banco agora pode ser alcançado por mais agentes com menos esforço. Escreva quem aprova cada novo cliente antes que o primeiro se conecte.