Oracle AI World 2026 incluirá la seguridad de Oracle AI Database entre sus temas, con sesiones dedicadas a Deep Data Security y al acceso a información sensible. El sistema permite aplicar reglas de autorización dentro de la base de datos antes de que una aplicación o un agente de inteligencia artificial reciba los resultados de una consulta.
Su funcionamiento ya estaba descrito por Oracle en mayo de 2026, por lo que estas capacidades documentadas no deben confundirse con anuncios nuevos del encuentro en Las Vegas. Para entender su alcance conviene separar tres cuestiones: quién inicia una solicitud, qué operaciones puede ejecutar una aplicación y qué datos está autorizado a consultar ese usuario.
Admin
Las reglas de acceso se aplican en la base de datos y no dependen del modelo
Deep Data Security, también denominado Deep Sec, utiliza políticas declarativas de SQL llamadas data grants. Estas establecen quién puede consultar, insertar, modificar o eliminar información mediante permisos SELECT, INSERT, UPDATE y DELETE, y pueden incorporar condiciones sobre los registros y los campos afectados.
Una política puede limitar una consulta a las cuentas asignadas a un trabajador o impedir que determinada función acceda a datos personales. Como las restricciones se comprueban en la base de datos, la aplicación no necesita reproducir esa misma lógica en cada pantalla, herramienta o instrucción dirigida al modelo.
Admin
Burak Akkus, gerente principal de producto de Oracle Database Development, describió en mayo de 2026 el riesgo de operar con permisos superiores a los del usuario final. Su explicación se refiere a las cuentas de servicio y a las rutas de acceso sin controles suficientes.
“Sin una política aplicada por la base de datos, una cuenta de servicio o una vía de acceso sin restricciones de la aplicación puede recuperar más datos de los que el usuario solicitante está autorizado a ver”.
Para los accesos sujetos a Deep Sec, Oracle describe un modelo que deniega el acceso sin una concesión aplicable, pero su eficacia depende de políticas previamente definidas, asignadas y mantenidas según responsabilidades y tipos de datos.
La identidad y el contexto determinan qué permisos se activan
El control comienza con la identidad de la persona que utiliza una aplicación. Oracle contempla gestores externos de identidades, como OCI Identity Domain, cuyos grupos pueden relacionarse con roles de datos creados dentro de la base; también admite entornos con usuarios y roles gestionados localmente.
El mecanismo combina control por roles (RBAC) y por atributos (ABAC). Así, no basta con identificar a alguien como integrante de ventas o finanzas: una política también puede considerar su región, función u otros atributos incluidos en un contexto de seguridad confiable.
En el flujo documentado con identidad externa, la aplicación transmite las credenciales y los atributos asociados a la conexión mediante tokens, habitualmente con OAuth 2.0 y JWT. La base de datos establece entonces el contexto del usuario final, relaciona sus roles con las concesiones de datos y evalúa esas reglas al ejecutar SQL.
Admin
Las políticas pueden consultar los atributos de ese contexto mediante la función ORA_END_USER_CONTEXT. Los permisos de distintos roles se acumulan, por lo que una persona con varias asignaciones puede acceder a la unión de los datos autorizados por ellas; esta característica exige revisar las combinaciones de roles, además de cada permiso individual.
Las restricciones por fila, columna y celda no significan lo mismo
El primer nivel selecciona las filas que un usuario puede recuperar. Si una política autoriza únicamente los registros propios de un empleado, la base incorpora la condición correspondiente a la consulta, de modo que el resultado no incluya las filas de otras personas.
El segundo nivel restringe columnas completas, como un identificador personal o un campo salarial. El tercero combina condiciones de fila y columna: alguien puede ver cierto dato en su propio registro, pero encontrar ese mismo campo oculto cuando consulta el registro de otra persona.
Columnas al director
La documentación de Oracle utiliza una tabla de empleados para ilustrar estas diferencias. El usuario Emma solo puede consultar su ficha y modificar su teléfono; Marvin, que también tiene el rol de responsable, puede ver fichas de personas a su cargo y modificar sus salarios, pero recibe NULL en el campo de identificación sensible de esos subordinados.
Ese NULL es una forma de enmascaramiento que puede confundirse con un valor realmente vacío. Para distinguir ambos casos, Deep Sec documenta la función ORA_IS_COLUMN_AUTHORIZED; otra función, ORA_CHECK_DATA_PRIVILEGE, permite comprobar de antemano si una persona tiene autorización para una operación determinada, por ejemplo antes de habilitar un botón de edición.
El recorrido de una consulta termina con los datos que recibió el agente
El proceso comienza cuando una persona se autentica y formula una pregunta en lenguaje natural. La aplicación transmite a la base de datos el contexto de identidad configurado; después, el agente o la aplicación prepara una consulta SQL relacionada con la solicitud.
Ivan
Antes de devolver registros, Deep Sec verifica las concesiones aplicables al usuario y a la operación solicitada. Filtra filas y restringe valores o columnas según las políticas, tras lo cual la aplicación o el modelo genera una respuesta a partir de los resultados autorizados, no de una copia completa de la tabla.
Oracle ilustró este recorrido en una demostración con dos perfiles que formularon la misma petición. Alice Carter, representante comercial de la región Oeste, obtuvo resultados limitados a sus cuentas y sin determinados datos personales, mientras que Frank Patel, analista financiero con alcance global, recibió un conjunto más amplio permitido por su función.
La comparación que presenta Oracle entre una consulta sin esas reglas y otra protegida permite apreciar la diferencia por identidad, aunque una demostración del fabricante no sustituye una auditoría independiente de resistencia a ataques ni garantiza un comportamiento equivalente en cualquier implementación.
La comparación del fabricante muestra cómo cambia la información disponible al aplicar el contexto y las políticas del usuario | Créditos: Oracle
Proteger los datos no equivale a autorizar todas las acciones del agente
Una aplicación puede estar autorizada para conectarse y ejecutar consultas, sin que cada persona que la utiliza tenga acceso a todas las filas o columnas. Sin embargo, Deep Sec controla las operaciones y los datos cubiertos por sus políticas en Oracle Database; no reemplaza los permisos para invocar herramientas externas, utilizar conectores MCP, aprobar transacciones o ejecutar procesos empresariales.
Admin
También importa la vía por la que se llega a una tabla. Oracle documenta un caso en que una vista podía exponer filas restringidas porque utilizaba los privilegios de su propietario; para aplicar un control obligatorio uniforme a una tabla y sus vistas, describe la configuración USE DATA GRANTS ONLY.
En su documentación de autorización detallada, Oracle distingue los usuarios finales de aplicaciones de los usuarios nativos de la base, como propietarios de esquemas y administradores, que siguen utilizando otros controles. La separación impide interpretar Deep Sec como un reemplazo automático de toda la seguridad de la plataforma.
Al restringir la información antes de entregarla al modelo, el sistema puede reducir la exposición derivada de consultas excesivas o instrucciones maliciosas, siempre que las políticas y el contexto funcionen como se diseñaron. Esa protección no constituye por sí sola una garantía contra toda filtración, abuso de una herramienta o error de configuración.
Julio Herrera Zúñiga
La configuración, las pruebas y la auditoría siguen siendo necesarias
Implementar estas autorizaciones supone definir roles de datos, relacionarlos con identidades y atributos confiables, redactar los data grants y decidir en qué objetos se exigirá su aplicación. Las reglas también deben comprobarse con distintas personas, combinaciones de roles y operaciones de lectura y modificación, incluidas las consultas realizadas mediante vistas.
Es especialmente relevante verificar qué identidad llega realmente a Oracle Database cuando un agente opera mediante una cuenta de servicio compartida. Si el contexto del usuario final no se transmite de forma fiable, la organización no puede presumir que una conexión genérica refleje automáticamente los permisos de cada solicitante.
Oracle describe la posibilidad de registrar actividades de usuarios y agentes, así como cambios administrativos, dentro de la auditoría de la base. Esos registros requieren una configuración y una revisión operativa adecuadas para poder reconstruir qué identidad, roles y políticas intervinieron en una consulta.
Ivan
¿Qué permanece pendiente de confirmar durante Oracle AI World 2026?
El programa de Oracle AI World 2026 anuncia sesiones sobre Deep Data Security y otras tecnologías de protección de datos, pero no documenta por sí mismo una nueva función ni una disponibilidad adicional. Para distinguir una actualización de una capacidad ya conocida, será necesario revisar las presentaciones y las especificaciones efectivamente publicadas durante el evento.
Admin
Entre las preguntas abiertas de la pauta editorial están el alcance concreto de Deep Sec dentro de las distintas configuraciones de Oracle AI Database 26ai, la transmisión de identidad cuando intervienen cuentas compartidas y la evaluación de permisos en consultas agregadas. También queda por precisar qué registros permiten reconstruir cada decisión de autorización aplicada a una respuesta de IA.
