Connecting OAC to AIDP is one thing. Governing access by real user identity is the bigger challenge

Introduction

When I recently wrote about how to connect Oracle Analytics Cloud to the Oracle AI Data Platform catalogue, the focus was on getting the integration working end to end. That matters, because it helps bring analytics closer to the governed enterprise data estate and makes trusted data assets more discoverable to analytics users. However, the more I thought about it, the more I felt that connectivity is only part of the story.

In enterprise environments, a successful connection is not the same thing as governed access. If data access is ultimately mediated by the credentials configured in the connection rather than the identity of the actual Oracle Analytics Cloud user, there is a risk that users may be able to see or reach data in ways that do not fully reflect their own entitlements.

That matters even more now that analytics and AI are increasingly converging. The challenge is no longer just how a dashboard author connects to data. It is how a platform ensures that access policies follow the real user or agent making the request, and that those policies are enforced consistently, centrally, and with audit traces.

Why the issue matters

At first glance, this can sound like a technical detail about connection setup. In reality, it goes to the heart of enterprise governance.

If a shared connection identity is used to broker access, then the logical policy boundary may sit at the connection rather than at the individual user. That can be acceptable for some narrow scenarios, but it becomes much harder to defend in environments where access to data should be based on role, attribute, business context, geography, or sensitivity classification.

A simple example helps illustrate the point. Imagine an OAC workbook built over a catalogue-discovered sales dataset exposed through a connection that has been configured with a technical identity. A regional sales manager in the UK should only see UK records, while a counterpart in Germany should only see German records. If the access path is governed primarily by the shared connection identity rather than the runtime identity of the actual OAC user, then the policy boundary risks being applied too broadly. Even if the workbook itself is shared appropriately, the underlying data access model may still not be enforcing the correct row-level boundaries for each individual viewer.

It also becomes harder to explain cleanly to security and audit stakeholders. They do not just want to know that data was accessed through an approved tool. They want confidence that the person or agent requesting the data only saw what they were genuinely entitled to see, and that the control point enforcing that decision was robust.

Why this matters beyond dashboards

This is not only an Oracle Analytics Cloud question. It is increasingly an enterprise AI question too.

As organisations move towards agentic workflows, the number of system-to-system interactions grows. Requests may be assembled dynamically, delegated across components, or executed by agents acting on behalf of users. In that sort of world, relying on broad service identities can quickly become uncomfortable.

The long-term target should be a consistent model in which analytics users, applications, and AI agents are all governed by the same underlying identity-aware policy framework. Otherwise, there is a risk of ending up with one access model for dashboards, another for APIs, and yet another for agents.

Why Oracle’s recent messaging is interesting

That is why Oracle’s recent direction is worth paying attention to. In Oracle’s recent Enterprise-Ready AI webinar for Oracle AI Data Platform, the messaging was not just about clever prompts or isolated demos. The emphasis was on building dependable, governed AI with the right data foundation, tooling, architecture, and guardrails. That framing matters, because it places governance and control at the centre of the platform story rather than treating them as afterthoughts.

That same direction appears in Oracle’s recent Deep Data Security announcement for Oracle AI Database 26ai. Based on Oracle’s public positioning, Deep Data Security looks set to become a database-native authorisation layer that sits beneath consuming tools such as analytics platforms, applications, APIs, and AI agents. Rather than trusting each consuming layer to implement access rules correctly, Oracle is describing a model in which the database evaluates verified identity and runtime context, then applies declarative SQL policies to enforce row, column, and even cell-level access boundaries centrally. In enterprise AI terms, that places Deep Data Security in the control layer of the stack: below the user experience, below the agent or application orchestration layer, and directly alongside the enterprise data itself.

That matters because one of the biggest risks in both analytics and agentic AI is the use of broad service identities. If an analytics connection, application tier, or agent framework connects with more privilege than the end user should actually have, then a mistake, weak application logic, or even prompt injection can expose data too broadly. Oracle’s stated answer is to push least-privilege enforcement down into the database so that agents, analytics workloads, and normal application workloads are all constrained by the same underlying policy model. In other words, even if the request is assembled dynamically by an agent or arrives through a shared connection path, the database should still be able to determine who the real requester is, what context applies, and what subset of data that requester is genuinely allowed to see or act upon.
​
If that model is realised as Oracle is signalling, it would help resolve the exact issue discussed earlier in this article. Instead of relying solely on the credentials configured in the OAC connection, the longer-term pattern would be to propagate end-user or agent identity and let database-enforced policies decide access at execution time. That would make it far easier to ensure that human users only see authorised records, that AI agents act within tightly bounded privileges, and that audit trails show which real identity was behind the request. The broader significance is that Deep Data Security is not just another security feature. It has the potential to become a foundational trust layer for enterprise AI, ensuring that both agentic and non-agentic workloads can only access the data they are entitled to, regardless of which tool, interface, or autonomous workflow initiated the request.

​What good looks like

For me, a strong enterprise pattern should aim for a few clear outcomes:
​

1. The requesting identity should be preserved end to end as far as possible. The system should know who is asking, not just which shared connection is being used.
2. Policy enforcement should happen at the data layer as well as in the consuming platform. Catalogue visibility and connection controls are useful, but durable governance depends on the place where the data is actually being served.
3. Audit trails should remain meaningful. Security teams should be able to understand which person or agent requested access, which policy was evaluated, and what data was returned.
4. The same model should be capable of supporting both traditional analytics and newer agentic AI use cases. It would be a mistake to build a strong user access model for analytics and then bypass it for AI-driven access paths.

The following conceptual view shows how that future-state pattern could fit together across Oracle structured data, non-Oracle structured data, and unstructured content.

In this model, AIDP acts as the discovery, orchestration, and semantic coordination layer across the wider estate. It carries identity and policy context from the consuming workload, whether that workload is a standard analytics flow in OAC or an agentic AI workflow.

The key point is that both analytics and agentic AI follow the same governance path. Identity is propagated, policy intent is preserved, enforcement happens as close to the data as possible, and audit trails remain tied to the real requester rather than a broad shared connection.

Where this could lead

I think this is where the OAC and AIDP story starts to become much more interesting. The initial connection between Oracle Analytics Cloud and the Oracle AI Data Platform catalogue is useful because it improves discoverability and brings analytics closer to a governed data estate. But the broader enterprise question is how that access path evolves into a model where the real requesting user identity and runtime context drive policy decisions consistently. A forward-looking view is that AIDP could increasingly act as the orchestration and governance-aware access layer across a much wider enterprise data landscape, while Deep Data Security becomes the database-resident policy enforcement layer beneath it. In that sort of model, AIDP would not just catalogue Oracle-native assets. It could also organise access to non-Oracle platforms, federated structured sources, and unstructured content stores, while carrying identity context, workload context, and policy intent across analytics, applications, and agentic AI workflows.

That matters because enterprise AI is rarely confined to a single vendor estate. Valuable business context may sit in Oracle databases, third-party cloud platforms, SaaS applications, object storage, document repositories, and unstructured sources such as PDFs, transcripts, emails, and reports. For Oracle-managed structured data, Deep Data Security could provide the strongest final trust boundary by evaluating propagated identity and context at execution time and enforcing least-privilege access directly in the database. For non-Oracle structured data and unstructured repositories, the same principle should still apply, with AIDP acting as the policy-aware coordination layer and source-native controls enforcing access locally. In that sense, Deep Data Security could become the Oracle data-plane enforcement pattern, while AIDP provides the broader control-plane and orchestration pattern across heterogeneous enterprise sources.

This future-state view directly addresses the limitation observed in the current OAC connection pattern. Today, the concern is that the configured connection credentials can become the effective access identity. In the model described here, that burden shifts away from the shared connection and back towards propagated user or agent identity, with policy enforcement happening at execution time as close to the data as possible. Seen this way, AIDP and Deep Data Security are not competing controls but complementary parts of the same enterprise AI stack: AIDP organises, exposes, and orchestrates access across structured and unstructured assets, while Deep Data Security provides the final database-enforced trust boundary for Oracle-managed data and federated controls play the equivalent role for external sources.

Closing thoughts

Connecting OAC to AIDP is one thing. Extending that into a model where access is governed by real user identity across analytics and AI workflows is the next important step.

That does not reduce the value of the integration. If anything, it reinforces why it matters. As analytics platforms become more tightly connected to broader enterprise data and AI ecosystems, the quality of the security and governance model becomes even more important.
​
From Oracle’s recent messaging, it is clear that this bigger picture is very much on the radar. The direction of travel appears to be towards a more identity-aware, policy-driven, and enterprise-ready model. We are not fully there yet, but it is an important space to watch as the platform continues to evolve.

Reference points used in this post

• Oracle’s webinar messaging around dependable, governed AI and configurable guardrails
• Oracle Deep Data Security
• Oracle’s published Deep Data Security positioning for Oracle AI Database 26ai
• Previous technical post on connecting OAC to the AIDP catalogue