Oracle quiere que la seguridad de agentes la imponga la base de datos, no el agente. Deep Trust baja reglas
Deep Trust AI de Oracle pone las reglas de acceso, las reglas de negocio y las API de datos dentro de la base de datos, para que una consulta o app generada no las esquive. Qué cambia y qué es.
Escuche este artículo · 4 min
Narración completa del artículo, generada con IA.
Un agente que sabe escribir SQL puede escribir cualquier SQL. Ese es el problema de arquitectura que hay detrás de la arquitectura Deep Trust AI de Oracle, anunciada el 26 de octubre, y es una versión más afilada de un problema que las aplicaciones empresariales siempre han tenido.
Durante décadas, la mayoría de las reglas de negocio vivían en el código de la aplicación. La pantalla de pedidos comprobaba el límite de crédito; la aplicación de RR. HH. filtraba los salarios por responsable. La base de datos confiaba en la aplicación, porque solo la aplicación hablaba con ella. La IA rompe ese acuerdo dos veces: los agentes generan sus propias consultas y llamadas a herramientas, y las herramientas de programación con IA generan nuevas aplicaciones más rápido de lo que cualquiera las revisa. Una regla que solo vive en la aplicación antigua no se aplica a ninguna de las dos.
La respuesta de Oracle es bajar las reglas a la capa que toda petición tiene que atravesar.
Dónde vive una regla, antes y después
| Impuesta por la aplicación | Impuesta por la base de datos (Deep Trust) | |
|---|---|---|
| Quién ve qué filas | Filtrado por cada app, si se acuerda | Deep Data Security comprueba al usuario final en cada petición SQL, mediante un token firmado del directorio corporativo |
| Invariantes de negocio | Código de validación en cada app | SQL Assertions rechaza cualquier cambio que rompa la regla, quien sea que lo envíe |
| Qué puede invocar un agente | Tablas en bruto o una API a medida | API de datos sobre objetos de negocio lógicos en lugar de SQL arbitrario |
| Preguntas en lenguaje natural | Texto a SQL genérico | Deep NL2SQL con metadatos de negocio y verificación de cambios |
| Apps generadas por IA | Código ejecutable generado | Definiciones APEXlang generadas, ejecutadas por el runtime de Oracle |
La quinta fila es la menos comentada y probablemente la más interesante. APEX AI Application Generator de Oracle convierte una descripción en APEXlang, un lenguaje declarativo abierto que ejecuta el runtime de Oracle. La IA escribe una definición, no código de programa, así que la seguridad y el comportamiento vienen del runtime y no de lo que haya producido el modelo. Es el mismo movimiento que los demás: mantener al modelo lejos de la parte que impone las reglas.
Por qué esta es la dirección correcta
Hemos defendido que los guardrails de prompt no son una frontera de seguridad; la frontera tiene que estar en algún sitio que el agente no pueda rodear a base de palabras. Para el acceso a datos, la base de datos es la candidata obvia, porque todo camino termina ahí. Imponer quién ve qué con la identidad del usuario final, verificada en cada petición, también corrige un fallo habitual de los agentes: el agente que se ejecuta con una cuenta de servicio que lo ve todo. Encaja de forma natural con credenciales por agente, como las nuevas Agent Identity y Vault 2.2 de IBM, que deciden qué agente se conecta; la base de datos decide después qué puede ver la persona que hay detrás.
Qué no es
Deep Trust es un plano, que Oracle compara con su Maximum Availability Architecture: una combinación recomendada de capacidades en cuatro capas, desde el parcheo automático en Autonomous AI Database hasta el runtime de la aplicación. No es un producto único con una fecha de disponibilidad, y el anuncio no indica el estado de cada componente. Antes de planificar en torno a él, pregunte a Oracle por cada pieza que necesite, qué versión de base de datos y despliegue requiere (Autonomous en OCI, otras nubes, Cloud@Customer, en local), y si está en disponibilidad general (GA).
Hay otros dos límites que conviene señalar. Las reglas a nivel de base de datos protegen los datos dentro de esa base de datos; un agente que también llama a API de SaaS, archivos y correo sigue necesitando controles ahí. Y “no se puede eludir” es un objetivo de diseño, no una garantía; las políticas mal configuradas y los roles demasiado amplios siguen siendo posibles. Ponga a prueba esos controles como cualquier otro control de acceso, con peticiones que deberían fallar.
El paso práctico, incluso para equipos que no usan Oracle, es enumerar las reglas de las que dependen sus agentes y escribir junto a cada una dónde se impone. Toda regla cuya respuesta sea “en el prompt” o “en una app que el agente no usa” es una regla que el agente puede romper.