AI is only as useful as the data it can reach. To deliver results, AI agents and AI-generated applications need access to the systems where business data lives, and that access is often broad.
This fact is reshaping how enterprises think about risk. The more an organization leans on AI, the more valuable its data becomes, and the more attractive it is to attackers. At the same time, AI is helping those attackers move faster. The result is a familiar problem with new urgency. The data is worth more than ever, and there’s less time than ever to defend it.
Analyzing Oracle’s latest security announcement appears to be a direct response to that shift. The company is consolidating a set of new and updated database capabilities under a strategy it calls Secure at Source, Secure at Speed, and Secure through Resilience. For CIOs running large Oracle environments, the move is worth a close look, both for what it offers and for what it signals about where database security is heading.
The adoption numbers explain the pressure. McKinsey’s 2025 State of AI survey found that 88 percent of organizations now use AI in at least one business function, up from 78 percent a year earlier, with roughly a quarter already scaling agentic systems in at least one function. Every one of those deployments needs data, and agents in particular tend to request broad, privileged access to produce useful answers. That access is the new exposure. The IBM Cost of a Data Breach study, run by the Ponemon Institute, found that 97 percent of organizations reporting an AI-related breach lacked proper AI access controls. The same study put the global average breach cost at $ 4.44 million and noted that nearly a third of breaches now involve data spread across multiple cloud and on-premises systems.
The defensive clock is also running faster. The gap between a vulnerability’s disclosure and its active exploitation has collapsed from years to days, and in some cases to hours, as attackers use automation to find weaknesses and generate working exploits. Software vendors are responding by shipping fixes more often, leaving customers a larger number of patches to test and apply on a tighter schedule. Anecdotally, I constantly hear the frustration of IT security leaders who feel overwhelmed.
The harder problem is structural. Traditional security was built to protect operating systems, applications, and network perimeters, because humans and applications were the main consumers of data. With agentic, that assumption no longer holds. When an AI agent can read, analyze, and act on data directly, controls that live only in application code can be bypassed, misconfigured, or applied inconsistently from one system to the next. Maybe more simply put, an agent that sidesteps the application also sidesteps the security written into it.
This is the core of Oracle’s argument, and it’s a reasonable one. If the data layer is where AI now connects, then it has to become a primary place where security is enforced. Controls anchored to the data travel with it, regardless of which user, application, or agent comes calling. The idea isn’t new to anyone watching the shift toward data-centric security, but AI gives it a sharper edge and a clearer business case.
The Secure at Source pillar is the most differentiated part of Oracle’s announcement, and three capabilities carry it. Deep Data Security lets organizations define fine-grained authorization and visibility rules tied to an end user’s identity, role, and context, enforced in the database rather than in application code. In practice, an agent acting for a user sees only what that user is cleared to see, and the same policy applies across relational, vector, and lakehouse sources without moving data. SQL Firewall, built into the database engine, allows only approved SQL to run and is designed so it can’t be bypassed, which closes off injection attacks and unexpected query paths. Database Vault tightens control over privileged accounts, restricting when and how administrative rights can be used, so that a stolen credential causes less damage.
Secure at Speed addresses the time problem. Oracle groups its patching, testing, and lifecycle tools here, including the Database Lifecycle Management Pack and Exadata Management Pack for finding and applying patches across the environment; Real Application Testing for validating changes before they ship; and GoldenGate with Veridata for reducing downtime during upgrades. Data Safe and the new Database Security Central give security teams centralized visibility into configuration risk, user activity, sensitive data, and policy compliance across cloud and on-premises databases. The intent is to turn patching from an occasional project into a repeatable, governed process. And I think this is the right focus. Most breaches still trace back to known issues that weren’t fixed in time, not to exotic zero-days that capture headlines.
Secure through Resilience rounds out the strategy with recovery. Zero Data Loss Recovery solutions protect databases down to the last committed transaction and add immutable, air-gapped backups as a hedge against ransomware. The Globally Distributed AI Database keeps applications running through site or zone failures. It supports data sovereignty rules, while the Maximum Availability Architecture provides the reference designs that tie it all together. Recovery, in this framing, is a security capability rather than a separate discipline. As organizations wire AI into core operations, the cost of downtime rises, and the ability to restore trusted operations quickly becomes part of the defense.
Putting this all in operational terms, Oracle is trying to make security less dependent on an organization’s perfect execution. The platform is designed to prevent more attacks from succeeding, limit the damage when they do, and help organizations recover faster afterward. That means tighter control over who can access data, fewer missed patches and configuration mistakes, and less downtime if a breach, ransomware attack, or infrastructure failure occurs. The result should be a more secure environment that’s easier to operate and more resilient when things inevitably go wrong.
I believe we’ve passed the point of discussing “if an organization is attacked” and should now be focused on “when an organization is attacked.”
I think what I see as Oracle’s differentiation has less to do with any single capability. Rather, it’s where the enforcement happens, and why it can happen there. Oracle owns the database engine, the query path, and the data model, and it increasingly controls the surrounding identity, cloud, and AI layers as well. A standalone security product watches the database from the outside or wraps a layer around it. Oracle can enforce inside it, at the point where the SQL executes and the rows are actually returned. Identity-aware authorization, SQL inspection, and privileged-access limits that run in the engine are hard to circumvent, specifically because they don’t depend on the application behaving correctly. For organizations worried about agents reaching data through paths nobody designed, this is significant.
In reality, much of this is Oracle building on security technology it already had, repackaged and extended for the agentic era rather than invented for it. Deep Data Security is the newest element. The rest, from SQL Firewall to Database Vault to GoldenGate, will be known to Oracle customers.
There’s also a gravitational pull toward the Oracle stack. Data Safe is an Oracle Cloud service for Oracle databases, and while Database Security Central extends monitoring to non-Oracle systems, the deepest protection lives closest to Oracle’s own engine. So at the end of the day, value runs highest for organizations already standardized on Oracle.
Step back from the product sheet, and Oracle looks like an early mover in a shift the whole industry seems to be making – even coming to the same conclusion from different starting points. Snowflake and Databricks are extending governance and access controls through their catalogs. Microsoft Purview approaches it through classification and data loss prevention across the estate, while IBM Guardium uses database activity monitoring. A newer set of approaches, from data security posture management to AI gateways that broker how models and agents reach data, works the problem from the governance and policy side rather than the engine. What they share is the part that matters. Security policy has to sit closer to the data than it used to.
I think the question for CIOs isn’t which tool to buy. It’s about whether security policies remain enforceable when an agent accesses data directly, regardless of which model a team chooses. Oracle’s database-centric bet is credible, and the strongest one when the critical data already lives in Oracle. Organizations running mixed estates will likely blend approaches, using engine-level enforcement where they have it and governance-layer or gateway controls where they don’t. Enforceability is the test that actually protects the data.
The bigger story here goes beyond Oracle. The data layer is turning into the control point for AI security, and Oracle is making a strong move to claim its version of it. The strategy is coherent, the technology is proven, and aggressive pricing removes a common excuse for delay. The question CIOs should ask isn’t whether to secure the database. It’s whether their current controls would survive contact with an autonomous agent that has broad access and no regard for the application logic those controls assume.
Three steps follow from that. First, find out where AI agents and AI-generated applications can already access data, and whether anything other than application code stands between them and sensitive records. Second, treat patch latency as a security metric rather than an operations chore, and use Oracle’s current offer to close the gap on a Long Term Support release. Third, test recovery the way you’d test a backup you actually expect to need, because resilience now belongs to the security conversation.
AI has changed both what’s at stake and how fast events move. Securing data where it lives, rather than around the edges of an expanding system, is a sound approach. Oracle has put a clear stake in that ground. The work for enterprise IT is to decide how much of its own data already sits beyond the reach of the controls it thought it had.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。