In Part 1 of this blog series, I looked at why AI agents change the analytics conversation. The important shift is not simply that AI can answer questions, but that agents can keep working towards a goal, call tools, retrieve context and potentially act on analytical findings.

That changes the risk profile. A wrong dashboard might mislead someone. A wrong agentic action can create consequences.

This second part looks at the architecture question: what needs to be in place before agentic analytics can be trusted in the enterprise?

From Insight to Action Requires Accountability

​As analytics moves closer to action, accountability becomes central.

If an agent recommends a price change, triggers a supplier review, escalates a customer issue, updates a forecast or starts a workflow, the organisation needs to understand what data was used, which business definitions were applied, what context was retrieved, which tools were invoked, what permissions were evaluated, who approved or delegated the action, and what audit trail was created.

This is the difference between a clever demo and an enterprise-ready capability.

Agentic analytics should not simply be measured by whether it can produce an answer. It should be measured by whether the answer, recommendation or action is trusted, explainable, governed and accountable.

What stood out to me was not simply that the agent could answer questions. It was that it could keep acting towards a goal. It could search, decide what to do next, click, type, email, spend money and continue the loop until it believed the task was complete.

That is the point where the conversation about AI changes.

The risk does not begin when AI can answer questions. The risk begins when AI can act.
​
That has direct relevance to the way I have been thinking about agentic analytics. If analytics agents are going to move beyond explaining dashboards and start recommending actions, triggering workflows, calling tools or coordinating with other agents, then the architecture underneath them becomes much more important.

It also connects strongly with a blog series by my friend Chris Buckel, Databases in the Age of AI, where he explores how AI agents change the way systems of record are accessed, queried and used.

Chris makes an important point: AI does not just place more demand on data platforms; it changes who or what is consuming the data. In his framing, inference is becoming a first-class database workload, and databases are becoming part of the reasoning path itself.

That is exactly why this matters for analytics. If analytics agents are going to move beyond explaining dashboards and start recommending actions, triggering workflows, calling tools or coordinating with other agents, then the architecture underneath them becomes much more important.
​
Agentic analytics is not just about better answers. It is about what happens when analytical systems can begin to act on those answers.

From Chatbots to Agents

A chatbot responds to a prompt.

An agent works towards a goal.

That distinction matters. In the video, the agent followed a loop: look, ask, act, then repeat. It reviewed what was on screen, asked a model what to do next, acted through the keyboard and mouse, and continued until the task progressed.

In simple situations, that can look useful. An agent can make a complaint, search for the best price, draft messages or attempt to complete administrative work that a human might not have the time or patience to do.
​
But the same persistence that makes agents useful also makes them risky. Once an agent can keep acting, it can also keep acting incorrectly, expensively, inappropriately or beyond the user’s original intention.
That is why the shift from chatbots to agents is not just a technical enhancement. It changes the risk profile.

Why This Matters for Analytics

​Traditional analytics has usually stopped at insight.

A report shows what happened. A dashboard helps users explore why it happened. A self-service tool allows a user to ask new questions. Augmented analytics may surface patterns, explain anomalies or suggest visualisations.

Agentic analytics goes further.

It begins to move from insight towards recommendation, orchestration and action. An analytics agent might not just explain why revenue fell in a region. It might retrieve supporting context, compare past trends, identify contributing factors, recommend follow-up actions and trigger a workflow for someone to investigate.

That is powerful, but it also changes the governance challenge.
A wrong chart can mislead a user. A wrong agentic action can trigger consequences.

The New Risk Profile of Agentic Analytics

Once analytics agents can act, several risks become more important:

• using the wrong business definition
• retrieving the wrong context
• exposing sensitive data
• overstepping the permissions of the user
• triggering the wrong workflow
• acting on malicious or untrusted instructions
• creating an audit trail that does not clearly show who or what made the decision

This is why agentic analytics cannot be treated simply as a new interface for existing dashboards.
If an agent is going to interpret business intent, query data, retrieve documents, call tools and recommend or execute actions, then the enterprise needs to understand how that behaviour is governed.

The Lethal Trifecta in Enterprise Terms

​One of the strongest ideas in the video was the reference to what is sometimes described as the Lethal Trifecta:

• access to private information
• access to the internet or external tools
• exposure to untrusted instructions

In a consumer setting, that might mean an agent with access to personal accounts, passwords, email and websites.

In an enterprise analytics setting, the equivalent could be even more serious. An agent may have access to sensitive business data, internal documents, customer information, operational workflows, SaaS applications and external services.

If that agent can also receive untrusted instructions through prompts, documents, web pages or user inputs, then governance becomes essential.

The issue is not that agents are inherently bad. The issue is that powerful agents need boundaries.

This is why agentic analytics cannot simply be treated as the next user interface for dashboards. Once analytics systems can interpret intent, retrieve context, call tools and recommend or trigger actions, the architecture underneath them becomes just as important as the intelligence of the model itself.
​
In the second part of this series, I will look at what that architecture needs to include: governed semantic meaning, data-layer security, trusted retrieval, observability, auditability and why Oracle’s broader platform direction across Oracle Analytics, Oracle AI Data Platform, Autonomous AI Lakehouse and database-level governance is relevant to this shift.

Introduction

In my previous post, I looked at how agentic analytics is the natural progression of augmented analytics.
If augmented analytics introduced AI assistance into the analytics experience, agentic analytics extends that further through business context, governed definitions, runtime knowledge retrieval, chained tasks, conversational explanation and action-oriented outcomes.

The next question, then, is what this looks like in practice.

For me, Oracle is increasingly assembling many of the building blocks needed to enable agentic analytics. Not through a single feature, but through the combination of Oracle Analytics, Oracle AI Data Platform, Autonomous AI Lakehouse, agent platform capabilities and database-level governance to name a few.
​
That does not mean the journey is finished. But it does suggest that Oracle is putting in place the architecture needed to move analytics beyond static reporting and even AI-assisted insight discovery into something more contextual, guided and potentially action-oriented.

Agentic Analytics Needs More Than a Chatbot

If agentic analytics is to be more than a chatbot placed in front of dashboards, it needs a wider set of capabilities underneath.

It needs:

• governed enterprise data
• semantic structure and business meaning
• contextual retrieval of enterprise knowledge
• connectivity to tools and workflows
• orchestration across tasks and agents
• governance, observability and control

This is why agentic analytics is not simply a user interface story. It is an architectural one.

Oracle Analytics Provides the Interaction Layer

Oracle Analytics already provides several of the capabilities that form part of this picture.

It brings together governed metrics, semantic models, dashboards, self-service exploration and AI-driven user experiences. Semantic models remain especially important here because they provide the governed definitions and business context that make analytics trustworthy.

The Oracle Analytics Cloud semantic modeller is central to this. It allows organisations to define logical business models, measures, hierarchies, joins, calculations, aliases, descriptions and access rules in a way that business users can consume consistently. That matters because AI features in OAC need more than access to tables and columns. They need business meaning.

As Oracle Analytics becomes more conversational and assistant-driven, those foundations become even more important. If analytics is going to interpret business intent and explain results in a meaningful way, it needs a stable semantic layer underneath. A well-designed semantic model can therefore improve the quality of AI-driven experiences by giving the platform clearer definitions, better context and a more reliable analytical structure to reason over.

In that sense, Oracle Analytics provides much of the user-facing interaction layer for agentic analytics.

Oracle AI Data Platform Provides the Broader Platform Layer

Oracle AI Data Platform extends that picture into the wider enterprise data and AI landscape.

It brings together structured and unstructured data, catalog capabilities, governed discovery, AI tooling, notebooks and an emerging agent platform story. That matters because agentic analytics needs access not only to trusted analytical data, but also to the documents, knowledge sources and broader platform services that can help ground and enrich results.

Oracle AI Data Platform is also positioned as a platform that unifies structured, unstructured, batch and real-time data across the enterprise. That broader platform view is important because agentic analytics depends on more than just curated dashboards. It depends on a governed data estate that AI-driven analytics can draw from more intelligently.

The March 2026 AIDP roadmap also makes the agentic AI direction much more explicit.
In the current roadmap view, Oracle calls out agents supported by OCI Generative AI models, tool types such as RAG, SQL and prompt, low-code agent flow creation, deployment to AI compute, a testing playground, observability and guardrails.

These already point towards a more complete agent development and runtime experience within AIDP.
The upcoming roadmap extends this further with multi-agent support, MCP client, server and tools, custom code tools, high-code agent development, MLOps and A2A.
For agentic analytics, those capabilities are important because they begin to cover the practical requirements of:

• building agents
• connecting them to tools
• supporting more advanced development patterns
• enabling collaboration between agents
• operating them in a governed and observable way

It is also worth noting that these are roadmap items, so timing and delivery remain subject to Oracle’s usual forward-looking safe harbour caveats.

Autonomous AI Lakehouse Helps Provide the Data Foundation

Within that broader story, Autonomous AI Lakehouse helps provide part of the underlying data foundation.

It adds a governed data and storage layer that can support both analytics and AI workloads, helping make enterprise data more accessible in a way that fits with the wider Oracle AI Data Platform architecture.

This matters because agentic analytics depends on more than interface-level intelligence. It also depends on having the right data foundation beneath it, one that can support trusted structured and unstructured data access at scale.

Agent Platform Capabilities Begin to Matter

The emergence of agentic analytics also depends on more explicit agent platform capabilities.

This is where the Oracle AI Data Platform Partner Summit was especially interesting. Oracle discussed Agent Studio, Agent Hub and Agent Registry as part of a broader direction towards building, exposing, orchestrating and governing AI agents.

That matters because agentic analytics is not just about generating a response. It increasingly involves chaining tasks together, retrieving the right context, invoking tools, coordinating actions and potentially handing work across systems or agents.

The more analytics becomes agentic, the more these platform capabilities begin to matter.

Governance Needs to Reach the Data Layer

One of the most important requirements for agentic analytics is governance.

If AI-driven analytics is going to interpret intent, retrieve knowledge, explain findings and support actions, then governance cannot be treated as an afterthought. It needs to remain enforceable all the way down to the data layer.

This is where Oracle’s broader governance story becomes relevant, including the emerging role of Deep Data Security in Oracle AI Database 26ai.

Deep Data Security is described by Oracle as a declarative, identity-aware access control system designed to simplify and modernise fine-grained authorisation directly in the database. That makes it particularly relevant to agentic AI because it points towards a model in which downstream services and AI-driven access paths can still be governed by centralised database-level policies.

For me, that is an important part of the story. Agentic analytics will only be credible in the enterprise if governance remains durable, auditable and enforceable beyond the front-end experience.

Bringing the Layers Together
​
Taken together, Oracle’s approach begins to look like this:

• Oracle Analytics provides the analytical interaction layer
• semantic models provide governed business meaning
• Oracle AI Data Platform provides the broader enterprise data and AI platform
• Autonomous AI Lakehouse helps provide the governed data foundation
• agent platform capabilities support orchestration, tools and actions
• database-level governance helps enforce durable control downstream
  
  

That does not yet amount to a finished end-state for every organisation. But it does show that Oracle is increasingly assembling the architecture needed to enable agentic analytics in practice.

Why This Matters

The value of this is not simply that Oracle has AI features across multiple products.

The more important point is that these components can start to work together.

Agentic analytics needs more than dashboards, and more than a natural language front end. It needs semantics, data foundations, retrieval, orchestration, tools and governance. Oracle’s current platform direction suggests that it is increasingly thinking about that fuller picture.

Conclusion

If agentic analytics is the next evolution of augmented analytics, then the enabling question becomes whether platforms can support that shift in a governed and enterprise-ready way.

For me, Oracle is increasingly showing that it can.

Not because one product alone solves the whole problem, but because Oracle Analytics, Oracle AI Data Platform, Autonomous AI Lakehouse, agent platform capabilities and database-level governance are beginning to form a more coherent foundation for analytics that is not just descriptive or exploratory, but more contextual, guided and action-oriented.

Introduction

Analytics has never stood still.

Over time, different modes of analytics have emerged to meet different business needs and different levels of user maturity. First came governed analytics, where trusted reporting and centrally managed definitions were the priority. Then came self-service analytics, where the focus shifted towards wider access, exploration and user-driven insight discovery.

More recently, analytics entered another phase: augmented analytics. This was the point at which AI and machine learning began to assist with activities such as pattern detection, insight surfacing, explanation and natural language generation and processing. In many ways, augmented analytics marked the beginning of AI becoming part of the analytics experience.

I think we are now seeing the next progression of that idea: agentic analytics.

For me, agentic analytics is not separate from augmented analytics but can be seen more as a natural evolution. If augmented analytics introduced AI assistance into the analytics workflow, agentic analytics extends that further by applying AI agents across more of the data-to-insight process, helping to orchestrate steps, interpret intent, retrieve context, explain findings and increasingly recommend or support actions.

This is not simply self-service analytics with a chatbot bolted on. Nor is it a replacement for the strands that came before it. Governed analytics still matters. Self-service analytics still matters. Augmented analytics still matters. But AI assistants and agents are beginning to create a further mode of interaction with analytics, one that is more conversational, context-aware and increasingly action-oriented.

​Governed Analytics

Governed analytics was built around trust, consistency and control.

This was the world of centrally managed reporting, curated dashboards, semantic models, governed metrics and carefully controlled access to data. The emphasis was on ensuring that when people asked for revenue, margin, headcount or customer numbers, they were looking at the same definitions.
​
That model solved an important problem. It created confidence in enterprise reporting and gave organisations a stable analytical foundation.

Self-Service Analytics

Self-service analytics expanded the audience for data.

Instead of relying entirely on centrally built reports, business users were increasingly able to explore data for themselves, build their own dashboards and answer their own questions more directly.

This changed analytics significantly. It increased agility, broadened access to insight and reduced some of the bottlenecks associated with traditional BI delivery models.
​
At the same time, it introduced its own tensions around governance, consistency and control. That is why governed analytics did not disappear when self-service analytics arrived. The two strands have continued to coexist.

​Why a New Strand Is Emerging

AI is now changing the way users interact with analytics once again.

Users are no longer limited to navigating dashboards, building visualisations or writing queries. Increasingly, they can ask questions conversationally, request explanations, explore follow-up questions and receive suggested next steps.

In some cases, AI can also retrieve relevant knowledge, explain business context, simulate scenarios, recommend actions or even interact with downstream tools and workflows.

That is a different interaction model from either governed analytics or self-service analytics.

It is not simply about giving users more charts. It is about allowing analytics systems to behave more like intelligent collaborators.

What Agentic Analytics is

For me, analytics becomes agentic when the platform can do more than simply return a report, render a chart or answer a natural language query.

Agentic analytics begins to emerge when the system can:

• interpret business intent rather than just keywords
• use governed definitions and business context
• retrieve supporting knowledge at runtime
• explain results conversationally
• chain together multiple analytical steps
• recommend next actions or scenarios to consider
• interact with downstream tools, systems or workflows

This is where analytics begins to move from static consumption and even self-service exploration towards a more active, guided and potentially action-oriented experience.

"Agentic analytics represents the evolution of augmented analytics by applying AI agents... for data analysis. It involves software used for the process of data analysis that applies AI agents across the data-to-insight workflow, orchestrating tasks semi-autonomously or autonomously toward stated goals that support, augment, or automate insights." - Gartner

​What Sits Beneath Agentic Analytics

This new strand does not remove the need for the foundations that came before it. In fact, it often depends on them even more.

Agentic analytics still needs:

• trusted enterprise data
• governed metrics and semantic structure
• contextual knowledge
• retrieval mechanisms such as RAG
• connectivity to tools and systems
• governance, observability and guardrails

Without these layers, so-called agentic experiences risk becoming superficial, inconsistent or untrustworthy.

This is why agentic analytics is not just an interface change. It is also an architectural one.

Why It Does Not Replace Governed or Self-Service Analytics

It would be a mistake to think of agentic analytics as the end of governed analytics or self-service analytics.

Governed analytics still matters because organisations still need trusted reporting, shared definitions and control over critical metrics.

Self-service analytics still matters because many users will continue to want the freedom to explore data visually and directly.
​
Agentic analytics should instead be seen as an additional strand, one that sits alongside the others and introduces a new interaction model for certain types of analytical work.
In practice, most organisations will likely operate across all three.

​How Oracle Can Enable Agentic Analytics

Oracle already has many of the building blocks needed to support this emerging strand.

Oracle Analytics provides governed metrics, semantic models, dashboards, self-service exploration and AI-driven user experiences. Oracle AI Data Platform extends that picture by bringing together structured and unstructured data, catalog capabilities, governed discovery, notebooks, AI tooling and an emerging agent platform story. Within that broader platform, Autonomous AI Lakehouse adds an important data foundation by combining lakehouse-style data management with Autonomous Database capabilities, helping to make governed structured and unstructured data more accessible for analytics and AI workloads. In that sense, Oracle AI Data Platform provides the wider platform layer, while Autonomous AI Lakehouse helps provide one of the core data and storage layers that agentic analytics can build upon.

Recent announcements and summit discussions have also pointed towards a broader Oracle direction that includes AI assistants, Agent Studio, Agent Hub, Agent Registry, AI-powered applications and stronger orchestration between agents, tools and enterprise systems.

Taken together, this suggests that Oracle is not just adding AI features into analytics. It is increasingly putting in place the wider architecture needed to support agentic analytics in practice, including:

• governed enterprise data
• semantic structure and business context
• retrieval and knowledge grounding
• agent development and orchestration capabilities
• governance, observability and guardrails

That does not mean every organisation is there yet. But it does suggest that Oracle is assembling many of the components required to move analytics beyond static reporting and dashboard consumption towards more conversational, guided and action-oriented experiences.

Why This Matters

Naming this shift matters because it helps separate a real change in the analytics experience from a vague sense that AI is being added everywhere.

If agentic analytics is becoming a distinct strand, then organisations need to think more clearly about:
​

• where it fits in their analytics strategy
• what architectural foundations it depends on
• which use cases are best suited to it
• how it should be governed
• how it should coexist with governed and self-service analytics

That is a much more useful conversation than simply asking whether AI will replace dashboards.

Conclusion

We have already seen major shifts in analytics through governed, self-service and augmented models.

I think we are now beginning to see the emergence of an update to the third strand: augmented analytics to agentic analytics.

This strand is characterised by conversational interaction, contextual grounding, guided exploration, recommendation and, increasingly, the ability to support actions as well as insights.
It does not replace what came before it. But it does introduce a genuinely different way of engaging with analytics.
​
If that proves to be true, then agentic analytics may become one of the most important ways of thinking about the next phase of analytics evolution.

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

Introduction

Oracle Analytics Cloud is often discussed in the context of semantic models, dashboards and AI assistants, while Oracle AI Data Platform is increasingly discussed in the context of data platform, governance and catalog capabilities.

Connecting Oracle Analytics Cloud to the Oracle AI Data Platform catalog helps bring these worlds together. It allows analytics users to discover and work with catalogued data assets more directly, while aligning Oracle Analytics more closely with the broader governed enterprise data ecosystem.
In this post, I will walk through the process of connecting Oracle Analytics Cloud to the Oracle AI Data Platform catalog, show what the connection looks like in practice, and highlight a few observations along the way.

What This Connection Enables

At a practical level, connecting OAC to the AIDP catalog can help with several things:

• discovery of catalogued data assets from within Oracle Analytics Cloud
• closer alignment between analytics and the governed data platform
• improved visibility of trusted data assets for analytics users
• a more integrated workflow between catalog, governance and analytics

This is not just a connection exercise. It is also part of bringing Oracle Analytics more directly into the wider enterprise data and AI landscape.

Prerequisites

Before starting the connection, make sure the following are in place:

• access to Oracle Analytics Cloud
• access to an Oracle AI Data Platform environment
• appropriate permissions to the AIDP catalog
• any required identity, network or tenancy prerequisites
• the endpoint or connection details required by OAC

​Depending on your environment, you may also need to confirm whether there are region-specific, network or policy constraints that could affect connectivity.
​
Step 1: Start the Connection in OAC

Begin in Oracle Analytics Cloud and open the Create menu in the top-right corner. From there, select Connection.

This is the entry point for creating new source and platform connections in OAC.

Step 2: Retrieve the Connection Details from AIDP

Before completing the connection in OAC, go to Oracle AI Data Platform Workbench and navigate to the relevant workspace and compute instance. Open the Connection details tab and, under Connect with BI Tool, select Oracle Analytics Cloud.

This is where AIDP exposes the connection details needed by OAC. In practice, this step is easy to overlook, but it is central to the whole setup.

Step 3: Select the Oracle AI Data Platform Connection Type in OAC

Return to Oracle Analytics Cloud and create a new connection. In the connection type dialog, search for Oracle AI Data Platform and select it.

​Once selected, OAC opens the connection form for the AIDP catalog connector.

Step 4: Complete the Connection Form and Save

Populate the connection form using the details obtained from AIDP.

This includes:

• a connection name and description
• the downloaded connection details file from AIDP
• authentication type
• DSN
• user OCID
• tenancy OCID
• region
• private API key
• API key fingerprint
• catalog

Two details are especially worth noting here. First, you need to select the connection details file exported from AIDP. Second, you also need to provide the private API key separately. Once everything has been entered correctly, save the connection.

This is one of the most important stages because even small mistakes in endpoints, permissions, fingerprints or authentication settings can prevent the connection from succeeding.

Step 5: Create a Dataset from the New Connection

After the connection has been created successfully, locate it in OAC, open the action menu, and select Create Dataset.

This is the point where the connection moves from simple setup into practical use.

Step 6: Select the AIDP Connection and Use the Exposed Assets

In the Create Dataset dialog, select the newly created AIDP connection

Introduction

Enterprise AI is one of the most widely used terms in technology today, but it is also one of the most loosely defined.

In many discussions, enterprise AI is reduced to a model, a chatbot or an assistant connected to company data. In practice, the reality is far more complex. Reliable enterprise AI depends on a layered architecture that brings together data, business meaning, retrieval, tools, agents, collaboration and governance.

That distinction matters because enterprise AI is not simply about generating responses. It is about generating responses and outcomes that are grounded in trusted data, aligned with business definitions, connected to the right systems and governed appropriately.

A useful way to think about this is as a stack of architectural layers sitting beneath the user-facing AI experience.

Today I attended Oracle AI World London, and this year’s message was clear from the outset:

This was the year of Agentic AI. Across every layer of the Oracle stack, from database to applications, the focus was on systems that can:

• reason
• decide
• act

What stood out was not just individual announcements, but how consistently this idea showed up:

• in the database, with private agent execution and embedded governance
• in OCI, with a unified platform for models, agents, and control
• in AI Data Platform, with semantic models grounding AI in business meaning
• in Fusion Applications with fully agentic, outcome-driven workflows

This was not a collection of AI features. It was a coordinated move towards agentic enterprise systems.

A joined-up Oracle AI story

One thing that stood out to me from the event was that Oracle was not presenting AI as a disconnected layer sitting above the enterprise stack. The keynote message felt much more integrated than that. Applications, database, infrastructure, and data platform were all presented as parts of the same broader enterprise AI story. From the stage content and panel discussions, Oracle’s direction looked clear: enterprise AI needs models, agents, governance, and trusted business data working together rather than as isolated components. 

That point matters because it helps explain the shape of the day’s announcements. Rather than one single headline, Oracle presented multiple pieces of an AI operating model: agentic applications at the business layer, agentic innovation in the database, OCI as the enterprise AI platform, and AI Data Platform as the foundation for unifying data and shared business semantics. 

Fusion Agentic Applications move beyond copilots

The main SaaS applications announcement was Oracle’s launch of Fusion Agentic Applications. Oracle described these as a new class of enterprise applications powered by co-ordinated teams of specialised AI agents that are outcome-driven, proactive, and reasoning-based. Built into Oracle Fusion Cloud Applications, they are designed to make and execute decisions inside business processes by securely accessing enterprise data, workflows, policies, approval hierarchies, permissions, and transactional context. 

For me, this is one of the most significant shifts in Oracle’s applications story. Oracle is now pushing a more ambitious proposition: Agentic AI that does not just help a user think, but can participate in the actual flow of work. That is a meaningful step forward because it moves AI closer to business outcomes rather than keeping it at the level of guidance and suggestion.

Oracle AI Database brings agentic AI and governance together

The database announcements were among the most strategically important parts of the keynote, not just because Oracle introduced new agentic AI capabilities, but because it made a strong case for governance being built directly into the data layer. The message was that AI and enterprise data should be architected together across operational databases and data lakehouses, rather than separated by additional layers of data movement and orchestration. 

For me, the most important part of that story was Oracle Deep Data Security. Oracle describes this as database-native, end-user-specific access control, where each end user, or AI agent acting on behalf of that user, can only see the data they are authorised to access. Oracle also positions it as a way to protect against AI-era threats such as prompt injection, while applying least-privilege access and centralising security away from application code. In other words, Oracle is arguing that governance for agentic AI is strongest when it is enforced at the source of the data, inside the database itself. 

That feels highly significant in an agentic AI world. If agents are going to query data dynamically and act within real business workflows, then security cannot just sit in the application tier. It needs to be embedded where the data is actually controlled. This was, in my view, one of the clearest and most important database messages of the day. 

Alongside that, Oracle also announced AI Database Private Agent Factory, which provides a no-code way to build and deploy data-driven agents and workflows, including prebuilt agents such as Database Knowledge Agent, Structured Data Analysis Agent, and Deep Data Research Agent. That is an important part of the story too, but to me it works best as an enabler within the wider message: Oracle wants the database not just to store business data, but to become a secure execution and control point for enterprise-grade agentic AI. 

AI Data Platform and the role of semantics

Another interesting part of the day was how Oracle AI Data Platform sat within the wider message. Oracle’s AI World content says Oracle AI Data Platform unifies enterprise data, applies shared business semantics, and embeds AI directly into workflows. It suggests that AI Data Platform is not just being positioned as storage or plumbing. It is being positioned as part of the grounding layer for enterprise AI, where business meaning is applied to enterprise data before AI is operationalised. 

I think this is a point worth dwelling on. If agentic AI is going to operate reliably in enterprise settings, then it needs more than access to raw data. It needs context. It needs meaning. It needs consistent business definitions. That is why semantics matter. In that sense, semantic models are not just an analytics concern. They are part of the enterprise grounding required to make AI outputs more trustworthy and more useful.

OCI Enterprise AI turns the OCI message into something more concrete

The OCI story at Oracle AI World London was not just that OCI underpins enterprise AI. It was that Oracle now has a more concrete way of packaging that story for customers.

With the general availability of OCI Enterprise AI, Oracle is bringing together models, agents, and governance in a single end-to-end developer offering designed to help teams move from experimentation to production faster. Oracle says the service combines AI intelligence, agentic execution, and built-in controls in one simplified environment, with support for both structured and unstructured data. 

That matters because one of the biggest barriers to enterprise AI is not access to models, but the complexity of stitching together tools, workflows, deployment patterns, and governance. Oracle’s answer is to package OCI Enterprise AI around three integrated layers: Models, Agents, and Governance. 

My takeaway from the day

My biggest takeaway from Oracle AI World London is that Oracle is trying to make AI practical for the enterprise by tying it closely to data, governance, and process.

The headline theme may well have been agentic AI, but the more important point is how Oracle has chosen to bring this to life. Fusion Agentic Applications bring agents into Fusion SaaS business workflows. Oracle AI Database brings agentic execution and governance closer to business data. OCI provides the wider platform layer. Oracle AI Data Platform helps unify enterprise data and apply shared semantics. Together the announcements feel less like a collection of disconnected AI announcements and more like an attempt to define a full enterprise AI stack. 

Introduction

Oracle Analytics updates often include small usability improvements that can significantly enhance how users interact with dashboards. While major capabilities such as AI agents tend to attract the most attention, incremental enhancements to data exploration can have an equally meaningful impact on day-to-day analytics workflows.

Long-time Oracle analytics users may remember the Column Selector feature in Oracle Business Intelligence Enterprise Edition (OBIEE). This capability allowed dashboard authors to define a set of columns that users could switch between dynamically. Instead of creating multiple charts or tables for different metrics, consumers could simply toggle between the available columns within a single visualisation.

​This provides a more flexible way to explore geographic performance while keeping dashboards simpler and easier to maintain.

Why This Matters for Dashboard Design

Although these enhancements may appear minor compared to larger platform features, they have important implications for dashboard design.

Traditionally, dashboard authors often needed to create multiple versions of the same chart in order to support different analytical perspectives. This could lead to crowded dashboards containing many similar visualisations that differed only by the metric being displayed.

By enabling columns to be swapped directly within visualisations, Oracle Analytics allows authors to design fewer but more flexible dashboards. Consumers can then explore the data more freely without requiring additional dashboard elements.

This approach offers several benefits:

• dashboards remain cleaner and easier to navigate
• fewer duplicate visualisations need to be maintained
• consumers can explore multiple analytical perspectives within a single chart

In many ways, these capabilities bring back a familiar concept from OBIEE’s column selector feature, but applied to modern visualisations in Oracle Analytics.

Conclusion

While large platform capabilities often dominate release announcements, improvements to usability and exploration can have an equally significant impact on how organisations interact with their data.

The column swapping enhancements introduced in the March 2026 Oracle Analytics update make it easier for consumers to explore data directly within visualisations while allowing dashboard authors to keep designs simpler and more maintainable.

Features such as overlay chart column swapping and map legend swapping may appear small individually, but together they represent another step towards more interactive and user-driven analytics experiences in Oracle Analytics.