A Oracle quer a segurança dos agentes imposta pelo banco, não confiada ao agente

Um agente que consegue escrever SQL consegue escrever qualquer SQL. Esse é o problema de arquitetura por trás do Deep Trust AI Architecture, da Oracle, anunciado em 26 de outubro, e é uma versão mais afiada de um problema que as aplicações enterprise sempre tiveram.

Por décadas, a maior parte das regras de negócio viveu no código das aplicações. A tela de pedido checava o limite de crédito; a aplicação de RH filtrava salários por gestor. O banco de dados confiava na aplicação, porque só a aplicação falava com ele. A IA quebra esse arranjo duas vezes: os agentes geram as próprias consultas e tool calls, e as ferramentas de codificação com IA geram novas aplicações mais rápido do que qualquer um consegue revisar. Uma regra que vive só na aplicação antiga não é aplicada em nenhum dos dois casos.

A resposta da Oracle é descer as regras para a camada que toda requisição precisa atravessar.

Onde uma regra vive, antes e depois

A mesma regra em duas arquiteturas

	Imposto pela aplicação	Imposto pelo banco (Deep Trust)
Quem vê quais linhas	Filtrado por cada app, se ele lembrar	O Deep Data Security verifica o usuário final em cada requisição SQL, via um token assinado do diretório corporativo
Invariantes de negócio	Código de validação em cada app	As SQL Assertions rejeitam qualquer alteração que quebre a regra, quem quer que a envie
O que um agente pode chamar	Tabelas cruas ou uma API própria	Data APIs sobre objetos de negócio lógicos em vez de SQL arbitrário
Perguntas em linguagem natural	Text-to-SQL genérico	Deep NL2SQL com metadados de negócio e verificação de mudanças
Apps geradas por IA	Código executável gerado	Definições APEXlang geradas, executadas pelo runtime da Oracle

A quinta linha é a menos discutida e provavelmente a mais interessante. O APEX AI Application Generator, da Oracle, transforma uma descrição em APEXlang, uma linguagem declarativa aberta que o runtime da Oracle executa. A IA escreve uma definição, não código de programa, então segurança e comportamento vêm do runtime, e não do que o modelo produziu. É o mesmo movimento dos outros casos: manter o modelo longe da parte que faz a regra valer.

Por que essa é a direção certa

Já defendemos que guardrails de prompt não são fronteira de segurança; a fronteira tem de ficar em algum lugar onde o agente não consiga passar por cima na conversa. Para acesso a dados, o banco de dados é o candidato óbvio, porque todo caminho termina ali. Impor quem vê o quê a partir da identidade do usuário final, verificada a cada requisição, também corrige uma falha comum em agentes: o agente rodando com uma conta de serviço que vê tudo. Isso combina naturalmente com credenciais por agente, como as do novo Agent Identity e Vault 2.2 da IBM, que decidem qual agente está se conectando; o banco então decide o que a pessoa por trás dele pode ver.

O que isso não é

O Deep Trust é um blueprint, que a Oracle compara ao seu Maximum Availability Architecture: uma combinação recomendada de capacidades em quatro camadas, do patching automático no Autonomous AI Database ao runtime da aplicação. Não é um produto único com uma data de disponibilidade, e o anúncio não informa o status de cada componente. Antes de planejar em cima disso, pergunte à Oracle, para cada peça de que você precisa, qual versão de banco e qual implantação ela exige (Autonomous na OCI, outras nuvens, Cloud@Customer, on premises) e se está em disponibilidade geral (GA).

Vale dizer outras duas limitações. Regras no nível do banco protegem os dados dentro daquele banco; um agente que também chama APIs de SaaS, arquivos e email ainda precisa de controles ali. E “não pode ser contornado” é uma meta de projeto, não uma garantia; políticas mal configuradas e roles amplos demais continuam possíveis. Teste como você testaria qualquer controle de acesso, com requisições que deveriam falhar.

O passo prático, mesmo para times que não rodam Oracle, é listar as regras das quais seus agentes dependem e anotar ao lado de cada uma onde ela é aplicada. Toda regra cuja resposta é “no prompt” ou “num app que o agente não usa” é uma regra que o agente pode quebrar.