Oracle’s AI Security Posture and Infrastructure Stack
- Michael Hulbert
- May 15
- 4 min read
Title: Oracle AI
Date: 15 May 2026
Type: Blog
Author: Michael Hulbert (michael@saasiq.ai)
Word count: 1020 words
Reading time: 5 min
Published: 15 May 2026
Oracle is moving faster on AI security than most customers realise. Monthly critical patches, identity-aware data controls for AI agents, and a purpose-built networking fabric for GPU clusters all point to the same thesis: if you want enterprise AI that actually holds up under scrutiny, you build from the infrastructure upward.
The Patching Cycle Just Changed
For years, Oracle customers planned their security patching around the quarterly Critical Patch Update. That cadence worked when threat actors needed weeks or months to reverse-engineer a vulnerability.
Starting this month, Oracle is shipping monthly Critical Security Patch Updates, or CSPUs, alongside the existing quarterly cycle. The reasoning is straightforward: frontier AI models have compressed the time between vulnerability disclosure and working exploit code, and Oracle has seen this firsthand through its own use of models from Anthropic and OpenAI in internal security testing.
CSPUs are smaller, more targeted releases that address high-priority vulnerabilities without waiting for the next quarterly bundle. The quarterly CPU still rolls up everything, so customers who prefer the established rhythm can stay on it. But for anyone running internet-facing systems, databases with privileged accounts, or environments holding sensitive data, the guidance is clear: apply CSPUs as they land.
We have been advising clients for months to segment their installed base by risk profile. Systems with direct internet exposure or high-privilege access should be on the fastest patching track available. The new monthly cadence gives those customers a practical way to act on that advice.
Deep Data Security: Identity-Aware Controls for Agents
Faster patching is only half the picture. The other half is controlling what AI agents can actually see and do once they are connected to your data.
Oracle AI Database 26ai introduced Deep Data Security, a capability that enforces fine-grained, identity-aware authorisation directly inside the database engine. When an AI agent queries the database, Deep Data Security applies the same access controls that would govern a human user. The agent sees only the data it is authorised to access, nothing more.
This matters enormously in an agentic world. Without identity-aware controls at the data layer, every agent becomes a potential over-privileged accessor. It does not matter how tightly you lock down the model or the prompt if the database happily returns rows the agent should never have seen.
The shared-responsibility model also looks different depending on deployment. In Oracle-managed cloud environments, patches are applied automatically. In customer-managed deployments, planning, testing, and applying updates remain the customer’s job. We see too many organisations assuming cloud means fully managed when, in practice, their specific service tier still leaves patching in their hands.
Acceleron: Networking Purpose-Built for AI Clusters
Security and governance keep the house in order. But the house itself needs a foundation, and for AI workloads that foundation is the network.
Oracle Acceleron is OCI’s custom networking architecture, and the latest details on its Multiplanar Fabric and Multipath Reliable Connection protocol deserve attention. The multiplanar design uses multiple physically independent network planes to deliver fault isolation and near-linear bandwidth scaling. If one plane develops issues, traffic shifts to the remaining planes without application-level intervention.
Multipath Reliable Connection, or MRC, sits on top of this fabric. It extends the RDMA Reliable Connection model with multipath behaviour, allowing a single queue pair to push high throughput across multiple ports and network paths simultaneously. MRC was developed through collaboration with AMD, Broadcom, Intel, Microsoft, NVIDIA, and OpenAI, which tells you something about how seriously the industry takes this specification.
The practical upshot is that OCI can now construct GPU clusters scaling to 131,072 GPUs and beyond with deterministic, low-latency connectivity. This is the same architecture underpinning Stargate’s Abilene facility. For enterprise customers, the implication is that large training and inference jobs on OCI benefit from networking that was designed for this workload from the ground up, rather than retrofitted from a general-purpose data centre fabric.
Infrastructure Up, Not Model Down
A pattern is emerging across everything Oracle has shipped this year. While competitors focus on model selection and prompt engineering, Oracle is building the layers beneath: identity-aware data access, accelerated patching driven by AI-discovered vulnerabilities, and bare-metal networking designed specifically for GPU-to-GPU traffic. The models sit on top. They are important, and OCI Enterprise AI now offers strong options including Grok 4.3 with its million-token context window and NVIDIA Nemotron for multimodal reasoning.
But models change fast. Infrastructure changes slowly.
Building from the infrastructure upward means Oracle customers inherit security, performance, and governance properties that persist regardless of which model they choose next quarter. That is a fundamentally different bet to wrapping an API around a frontier model and calling it an enterprise product.
SoftBank’s sovereign AI platform in Japan illustrates this well. Using Oracle Alloy, SoftBank is deploying 200-plus OCI services inside its own data centres and layering its home-grown Sarashina large language model on top. The infrastructure is Oracle’s. The model is SoftBank’s. The data stays in Japan. This is what infrastructure-up looks like in production.
What This Means for Your Estate
If you are running Oracle Database on-premises, now is the time to evaluate your patching posture against the new monthly CSPU cycle. Start with internet-facing systems and databases holding sensitive data, and work outward from there. The upgrade path to Oracle AI Database 26ai or at minimum the 19c long-term support release is the baseline Oracle is recommending.
If you are running OCI workloads, review where you sit on the shared-responsibility spectrum. Autonomous Database customers get automatic patching. Customers on Database Cloud Service or Exadata Cloud@Customer need to confirm their update schedules explicitly. Do not assume the cloud is handling it.
And if you are planning AI workloads on OCI, the Acceleron networking story is worth understanding in detail. The gap between commodity cloud networking and purpose-built AI fabric is not a minor performance difference. It determines whether large-scale training jobs complete on time and on budget or stall behind network bottlenecks.
We are tracking all of these developments across our client base and will continue to publish practical guidance as the landscape evolves.
SaaSiQ | Oracle AI |
