Oracle AI Security – When AI Finds The Flaws Faster, Fixing Becomes The Control

What AI Has Changed: Flaws Found Faster Than They Can Be Fixed

“If I could recommend, like, only one thing to a company right now to do with AI in the very short term … it would be to really understand the security threat landscape from AI and mitigate against that,” said Sam Altman, chief executive of OpenAI, in a discussion with Oracle chief executive Clay Magouyrk at Oracle AI World. “I find myself shocked at just how many vulnerabilities these AI systems are finding,” he added.

Magouyrk described the same shift from the vendor’s side. AI is “helping us discover all the security issues that we have developed over the past 50 years,” he said, adding “I’m glad that we’re able to discover them in AI rather than waiting for some unknown hacker to let us know.” Oracle’s security release from the event announced Oracle AI Security Mesh, powered by OpenAI, to help organizations “find and fix security vulnerabilities faster.” It paired the new service with OCI Identity Assurance, biometric verification for the people who approve sensitive actions, and OCI Zero Trust Packet Routing, which enforces access policies “beneath the applications and agents themselves.”

Greyhound Research reads the announcements as a correct diagnosis, and as a shift that moves the bottleneck rather than removing it. When AI finds flaws faster, the scarce resource becomes the capacity to fix them: the test environments, the change windows, and the people with the authority to approve a change to production. In its research note on Oracle’s agentic implementation, Greyhound Research found that when agents draft the setup, review becomes the control. Security is making the same move. When AI finds the flaws, fixing becomes the control.

The test for buyers is whether their security operating model can fix at the pace AI finds, and control what agents can reach while the fixes land. Passing it depends less on the AI than on four things buyers control: a patch cadence that matches discovery, one identity standard for every agent, stronger proof for the people who approve high-risk actions, and controls that sit beneath the agents, in the network and the data.

↑ Back to the section guide

What Oracle Announced: Three Offerings Beside A Cadence Already In Place

Oracle’s security announcements sit at different stages, and the stage decides what a security plan can rely on. A plan commits budget and change windows to dates, and an offering without a date cannot carry one. As Table 1 shows, the pieces a buyer can act on now are the ones Oracle already runs or offers: monthly security updates, Zero Trust Packet Routing, the identity service that Identity Assurance is built into, and the tools that come with the Deep Trust AI Architecture. AI Security Mesh, the headline, carries no availability wording.

Read by status, the picture favors the work a buyer can start now. Monthly patching is already Oracle’s practice, and Zero Trust Packet Routing is already part of OCI. The Deep Trust tools offer has a closing date, which makes it the most time-sensitive item in the set. Identity Assurance is built into OCI’s identity service, and its use for approvals needs written confirmation of regions and terms. The security release names no customer. AI Security Mesh belongs in a plan only once Oracle confirms its availability in writing, which leaves buyers time to agree the terms in Table 2 before the first engagement.

↑ Back to the section guide

Finding Is Cheap, Fixing Is The Job: Oracle’s Own Patch Record

Oracle has lived through the problem it now offers to solve. AI “has significantly accelerated the pace at which software vulnerabilities are discovered,” wrote Elke Phelps, product management director, as Oracle added a monthly release cycle for Critical Security Patch Updates and said it “will continue to deliver its quarterly Critical Patch Updates.” Oracle’s next quarterly update was, in the words of its Integrated Cyber Center, “Oracle’s largest security release to date”: 1,449 security patches addressing 1,434 distinct CVEs across 334 Oracle products. Oracle credited “AI-powered identification of actionable security findings,” and urged customers to “move immediately to a monthly security patching cycle.”

Oracle’s database leaders have made the same case to their own customers. AI is “dramatically lowering the barriers for attackers to discover and exploit software vulnerabilities,” wrote Jenny Tsai-Smith, senior vice president, product management, as Oracle urged customers onto its long-term support releases. Vipin Samar, senior vice president, database security, wrote that “those protections take effect only after customers deploy the update.” His conclusion is plain: “Delaying deployment extends the period during which systems may remain exposed.”

Altman put the scale of the task in one sentence. “I think the only way through this is to go find all these issues and fix them,” he said. He also warned that “we’ll need new ways to fix them, and it’s maybe too hard to patch every bug one by one across the entire supply chain.”

That is the arithmetic every security team now faces. Discovery scales with compute. Remediation scales with test environments, change windows, and the people who can approve a change to production, and none of those grew when AI arrived. A move from a quarterly to a monthly cycle triples the change windows a year for every product family it touches. For an estate that runs databases, middleware, and applications on separate cycles, that is a change in operating model, not a scheduling adjustment.

Set on a timeline in Exhibit 1, Oracle’s own record shows the vendor moving its patch cadence, and urging customers to follow, before it announced a service to find flaws faster.

↑ Back to the section guide

The Case For It: A Layered Design From The Approver To The Data

The announcements have a shape that is easy to miss when they are read one at a time. Read with the Deep Trust AI Architecture that Oracle set out the day before, they place a control at each layer an AI-era attack can cross: the person who approves, the agent that acts, the network path it uses, the data it reaches, and the code it runs on. “As AI agents take on more responsibility, enterprises need security that can keep pace with how these systems operate,” said Phil Newman, senior vice president, Security and Identity, at Oracle. “With Oracle AI Security Mesh and Oracle’s identity and network security capabilities, we’re helping organizations identify and resolve security risks faster while maintaining control over who can authorize sensitive actions and which systems AI workloads can access.”

The design of AI Security Mesh is where the credit is strongest. In Oracle’s description, the platform maps a customer’s systems and “then proposes a test plan for your approval.” Specialized agents test for weaknesses, and “a separate agent repeats the test to confirm the problem is real.” “Coding agents can help prepare code fixes for your team’s approval,” Oracle writes. The release adds that “customers approve remediation changes before Oracle AI Security Mesh applies them,” and that, within the customer-approved testing scope, it “tests proposed fixes for the identified vulnerability and checks their effect on expected application behavior.”

Greyhound Research reads that as the right sequence for a tool that behaves like an attacker. A plan the customer approves comes before any test, and a second agent reproduces a finding before anyone acts on it. The release says the service “provides supporting evidence, including reproduction steps and test results,” and a person decides before any fix is applied. A reproduced finding is worth more than a list of suspected ones, because it reaches the change advisory board with its own evidence. Oracle says its methods, tooling, and safeguards were “refined through testing its own systems at scale,” which fits the record in Exhibit 1.

Oracle has argued for automated security in the past, and the new design draws the line in a different place. Speaking as senior vice president, customer strategy and business development, Oracle APJ, in Greyhound Research’s #CounterpunchWithSVG, Chris Chelliah described Oracle Autonomous Database as a system that “configures itself, secures itself, and repairs itself,” with “better security because there’s no human intervention.” AI Security Mesh keeps a person before any fix to a customer’s own systems. Greyhound Research reads the two as consistent. A managed database patching Oracle’s own code inside Oracle’s service is one act, an agent changing a customer’s application is another, and Oracle has put the person where the second one needs it.

The other layers carry the same logic further down the stack. OCI Identity Assurance is meant to help customers confirm, in the release’s words, “that human approvals come from verified people.” The release states the network rule plainly: “Traffic to protected resources must be permitted by both OCI Zero Trust Packet Routing policies and existing network controls.” Such policies can “restrict paths for data exfiltration” and “block unauthorized lateral movement.” For data, the Deep Trust release says: “The database itself verifies the user’s identity from a cryptographically signed token issued by the corporate directory,” so that “applications and agents only work with the objects needed for a task.” For code, App Composer, Oracle’s builder for applications made with OpenAI’s Codex, “applies enterprise identity, permissions, networking, audit, and application life cycle controls,” according to the OpenAI release.

Layered defense is a long-standing Oracle argument. In Greyhound Research’s Product Spotlight on Oracle HCM, Shaakun Khanna, speaking as vice president and head for SaaS and HCM applications alliances for Asia Pacific, said “we have 6-7 layers of security” in HCM, beginning with role-based access, “which is critical.” The AI World announcements add layers for an actor that did not exist then, the agent, and for the approver it now depends on.

“AI trust is the biggest challenge we face today,” said Juan Loaiza, executive vice president, AI Database Technologies, at Oracle, adding that “enterprises can’t realize these benefits if they can’t trust what AI generates.” The principle beneath the layers answers him directly. A control beneath the agent holds even when the agent fails. A network policy that must agree before traffic flows does not depend on the agent behaving as designed, and a database that checks identity itself does not depend on the application passing the right one. Greyhound Research regards that as the right principle for an estate where software acts on its own, because it assumes that some agents will, at some point, be wrong.

The pairing itself is one Greyhound Research has read in security terms. When OpenAI turned to Oracle for infrastructure, Greyhound Research described Oracle as “blending its historical strengths in security, compliance, and enterprise support with future-looking AI throughput.” AI Security Mesh applies the same pairing to security work itself. Johannes Landgraf, head of cyber at OpenAI, described the aim in operational terms: “By combining OpenAI’s advanced models with Oracle’s enterprise security capabilities, we can help security teams investigate complex issues, prioritize critical risks, and accelerate remediation while maintaining the controls they require.” Laid out in Exhibit 2, each of the five layers carries an Oracle control, and the newest of them, AI Security Mesh, is the one a buyer cannot yet date.

↑ Back to the section guide

Agent Identity: Oracle Has Described The Model It Should Apply Everywhere

For AI Security Mesh, Oracle has written the most specific agent identity statement in its AI World announcements. “Each agent operates with a distinct identity, task-scope, and just-in-time permissions,” the release says, and “independent monitors can detect and stop activity outside approved boundaries.” That is close to the first test Greyhound Research set in its research report on Oracle’s agent runtime: “Every agent runs as its own principal, holding the least privilege its task allows, never borrowing a human’s credentials.” In that report’s words, a buyer whose agents fail the four tests has “an ungoverned employee with system access.”

Oracle describes its other agents differently. In its research report on Fusion Claw, Greyhound Research found that on name the identity, “the answer is documented and it is borrowed: the running user’s token, bounded by that user’s access, with a per-outcome principal described as the next step.” Oracle’s Fusion Center of Excellence wrote that “Every action carries the running user’s Fusion token.” For the six implementation agents in Oracle AI Success Navigator, Greyhound Research’s research note on agentic implementation found no account or identity described in the releases. For App Composer, Oracle states the controls it applies, enterprise identity among them, without describing the identity of an agent.

The borrowed model is defensible inside an application suite, because an agent bounded by its user’s access cannot exceed what that user could do. The difference matters most for an agent that acts with more independence than its user, or acts when no user is present, which describes an agent that tests production systems. Oracle has set its strictest identity model for exactly that agent. Greyhound Research sees no reason the same model should stop at the security team, since agents that post transactions and write configuration carry authority of their own.

Set side by side in Exhibit 3, the four identity models in Oracle’s documents show that only the AI Security Mesh model meets, as written, the first test Greyhound Research set for agents that act inside enterprise systems.

↑ Back to the section guide

Letting An Attacking Agent In: Ten Terms To Settle Before Testing

AI Security Mesh works by doing what an attacker would do, with the customer’s permission. Its product page says it maps systems and the connections between them “using the context and access you provide.” The OpenAI release describes “a managed service that uses OpenAI cyber models” across “OCI, other clouds, and on-premises environments.” That reaches into estates Oracle does not run, under terms the customer will have to write. A penetration test has always started with a signed scope and rules of engagement, and an AI tester needs the same, with a few terms that did not exist before.

Oracle has described several of those terms. Customers “define where testing is authorized and control its scope,” and “Oracle manages the safeguards to reduce the risk of outages or business disruption during testing,” according to the OpenAI release. Testing follows a plan the customer approves, and what agents learn “stays in your business’s private knowledge base.”

Oracle’s releases, blog, and product page do not yet say where the OpenAI cyber models run when they test a customer’s system, or what system data they see and whether any is retained. Nor do they say where the knowledge base is held and who at Oracle can read it, who carries the cost if testing disrupts production, or what record of tests, findings, and approvals the customer receives. Greyhound Research interprets these as terms not yet published rather than terms missing, and they are the ones a buyer’s counsel will ask for first.

Oracle has long offered customers control over where their workloads run and who holds the keys. In Greyhound Research’s Product Spotlight on OCI, with Oracle cloud leaders Palanivel Saravanan and Kapil Makhija, Oracle described a dedicated region “which we offer at customer premises within their firewall.” Of customers running VMware workloads on OCI, Oracle said: “They don’t even have to share the root password with us, and all that security control is only with them.” AI Security Mesh works the other way, on the access a customer grants it, which is why the terms of that grant matter.

Of the ten pre-engagement terms in Table 2, Oracle’s documents describe four, describe four more in part, and leave two undescribed: where the testing models run, and what system data they see.

The knowledge base deserves particular care. A store of a company’s confirmed weaknesses is useful for the next test, and it is also the document an attacker would most want to steal. Its location, encryption, access, retention, and deletion at the end of an engagement deserve the protection given to the most sensitive data the company holds.

↑ Back to the section guide

The Approver Is The New Target: Proving Who Signs

Agents that act within delegated authority move an attacker’s attention to the people who delegate it. When a payment, an access change, or a configuration can proceed once a person approves it, impersonating that person becomes the shortest path to the action. Before sensitive actions “such as releasing payments or changing access permissions,” Oracle says, OCI Identity Assurance can use biometrics “to verify the identity and presence of the person providing approval.” “Subsequent biometric checks help uncover impersonation and account handoffs,” the release adds. The same service applies “from hiring through ongoing access to enterprise systems,” where Oracle says it can “help detect impostors, including those involved in North Korean IT worker schemes.”

Oracle’s OCI blog adds the detail a security architect will look for. “During each biometric verification, OCI performs liveness detection to help defend against presentation attacks and AI-driven deepfakes,” and “Raw images are never stored.” It describes step-up checks before “high-risk actions (e.g., changing payout details).” Greyhound Research credits Oracle for applying identity proof at the moment of approval, not only at sign-in, because the account that signed in is not always the person who signs.

This is where the security announcements meet Greyhound Research’s earlier Oracle research. The research note on agentic implementation argued that where configuration sets approvals, roles, and limits, signing it off is signing off authority. The Delegation Dial, Greyhound Consilium’s practical guide to Fusion Claw developed in partnership with Oracle, asks for a second signature before any widening of delegated authority. Identity Assurance adds what both assume: proof that the person signing is the person entitled to sign, present at the moment of signing.

Verification proves who approved. It does not prove that the approval was considered. Monthly patch cycles, AI-drafted fixes, and agent outcomes that wait for a person all route more approvals to the same few people. A verified approver who signs forty changes in an hour is still a weak control, so the strength of the check should rise with the reach of what is approved.

Mapped in Exhibit 4, six approvals now carry authority an attacker would want. Greyhound Research proposes verified presence and a ceiling on volume for all six, and a second signer for the four that reach furthest, with the other two needing one above a value limit.

↑ Back to the section guide

AI-Written Code: Patch Volume Starts In The Build

The volume of code is rising as fast as the rate of discovery. Magouyrk has said that “more than 70% of our software these days is written by AI. That’s only accelerating.” Greyhound Research’s research note on agentic implementation found no measurement basis for the figure, so it reads as a signal of internal practice and not a benchmark. It still tells buyers that, by its chief executive’s account, the vendor building these tools writes most of its software with AI, and the same vendor credits AI with finding the flaws behind its largest security release.

App Composer extends AI-written code to employees who do not write code. The same note found App Composer fast to build with and still someone’s to run, and the OpenAI release carries no availability wording for it. Its stated controls, “enterprise identity, permissions, networking, audit, and application life cycle controls,” cover how a generated application is deployed and run. They do not cover who reviews the code before it reaches production, or who patches it after.

AI writes code faster, and AI finds flaws in code faster, and the two meet in the patch queue. Code written by AI is still code. It needs review, testing, and patching, and its volume sets the patching load. What changes is the share of code whose author cannot be asked why it was written that way, and the number of dependencies it brings with it. Those dependencies are the supply chain Altman had in mind when he said it is “maybe too hard to patch every bug one by one across the entire supply chain.” AI Security Mesh speaks to part of this. Its product page gives the example that “before a release, teams building and running SaaS applications can test whether one customer could access another’s data.”

Traced through the six stages in Exhibit 5, from generation to patching, AI-written code meets a control Oracle describes at four, and its review and the patching of a buyer’s own generated applications are left to the buyer.

↑ Back to the section guide

Risks To Watch: Where AI-Speed Security Can Go Wrong

AI-speed security fails in different ways from a conventional program, because the speed that finds flaws also floods the processes that fix them. Five risks stand out.

Remediation can fall behind discovery. A service that finds and confirms more weaknesses raises the load on test environments, change windows, and approvers. Watch for the time from a confirmed finding to a deployed fix rising while the count of findings rises. The remedy is a target time to fix for each level of exposure, with capacity sized to meet it, owned by the CISO with the head of IT operations.

Coverage can be mistaken for security. A report that AI tested the estate invites the reading that the estate is secure. Testing covers only the systems in scope and the paths the agents tried. Watch for board reports that count findings and fixes without stating what was out of scope. The remedy is to report coverage against the asset inventory, with exclusions named, owned by the CISO.

Testing can disrupt what it tests. An agent that exploits a weakness to prove it is real is, for that moment, attacking production. Oracle says it manages safeguards against outages, and their content is not yet published. Watch for an engagement that starts before the safeguard terms are written. The remedy is the terms in Table 2, testing in non-production environments first, and a rehearsed halt, owned by the head of IT operations.

The findings store can become the target. A knowledge base of confirmed weaknesses is the most useful map of a company an attacker could hold. Watch for an engagement where no one can say where that store is held or who can read it. The remedy is to classify it with the most sensitive data the company holds, with access logged and deletion agreed at exit, owned by the CISO with the data protection officer.

Approvers can tire. Monthly patches, AI-drafted fixes, and agents waiting for agreement all route to the same few people. Watch for approval time per change falling while volume rises, or approvers signing changes outside their own area. The remedy is a ceiling on approvals per person, a second signer for high-reach changes, and sampling by internal audit, owned by the CIO with the head of internal audit.

Placed on the security cycle in Exhibit 6, from scoping a test to reporting on it, four of the five early warnings appear before a fix reaches production.

↑ Back to the section guide

The Greyhound CXO Runbook: Six Moves Before AI Finds Your Next Flaw

Six moves follow from the evidence, and they are written for the CIO, the CISO, and the CFO together, because fixing at the pace AI finds crosses all three desks. Each move names who decides. None waits for Oracle to date AI Security Mesh, because the cadence, the capacity to fix, the identity standard, and the approver checks are already within the buyer’s control.

1/ Move to the monthly patch cycle, starting where Oracle has flagged urgency.

Adopt Oracle’s monthly security updates, released on the third Tuesday of each month, starting with the database release updates Oracle has urged customers to apply immediately and the systems exposed to the internet. Take up the free or discounted security and patching tools Oracle offers with Deep Trust before the offer closes, on the date in Table 1.

A monthly cycle is an operating model, not a calendar entry, so agree the change windows with the business before the first one. The decision sits with the CIO, together with the head of infrastructure.

2/ Size the capacity to fix before buying more discovery.

Measure the time from a fix’s release to its deployment in production, by product family and by exposure. Build the test environments, change windows, and approver capacity that a monthly cycle and AI-confirmed findings will need, and set a target time to fix for each level of exposure.

A tool that finds more flaws is worth only what the team can fix. The decision sits with the CISO, together with the head of IT operations.

3/ Set one identity standard for every agent.

Adopt AI Security Mesh’s model as the internal standard: a distinct identity, a scope for each task, and permissions that expire. Record, for every agent in the estate, whose identity it acts under and what it may reach.

Where an agent borrows a user’s identity, as Fusion Claw does today, keep its authority narrow, and ask Oracle for the date of a per-agent principal. Apply the same standard to the agents of every vendor. The decision sits with the CISO, together with the identity lead.

4/ Protect the approvers.

List the approvals that release money, grant access, change payout details, approve agent-drafted configuration, or widen delegated authority. Require verified presence for each, through OCI Identity Assurance or an equivalent, a second signer where the value or reach is high, and a ceiling on how many one person signs in a period.

The approver is now the shortest path to an agent’s action, so the check should match what the approval releases. The decision sits with the CFO, together with the CISO.

5/ Write the test-scope contract before any attacking agent touches production.

Agree the ten terms in Table 2 in writing before the first engagement, with where the models run, what data they see, and how the findings store is held settled first. Test in non-production environments before production, and rehearse who halts testing and how.

These terms protect the buyer with any AI tester, not only Oracle’s. The decision sits with the CISO, together with the general counsel and the procurement lead.

6/ Inventory AI-written code, and put it on the same patch clock.

Know where AI-written code runs, who reviewed it, and who owns it. Test generated applications before release, and patch them on the cycle of the systems they run beside.

Set these rules for App Composer while it is still arriving, which is far easier than retrofitting them onto applications already in use. The decision sits with the CTO, together with the enterprise architecture lead.

Sequenced in Exhibit 7, four of the six moves start now. The code inventory follows in the next quarter, and the test-scope contract is timed to the first AI security test.

↑ Back to the section guide

Questions For Oracle: What Buyers Will Ask Next

Q1 Buyers discount announcements until they carry a date. Greyhound CIO Pulse 2026, across more than 1,000 enterprise technology leaders, finds 82 percent dismissing mega-announcements as more optics than delivery. A security plan needs a date, a region, and a price before it can commit change windows. When will AI Security Mesh be available, in which regions, and how will it be priced, and is OCI Identity Assurance for approvals available in every OCI region now?

Q2 Security teams will ask where the testing runs. A tester that reaches a production system can see what that system holds. Oracle describes “a managed service that uses OpenAI cyber models” across OCI, other clouds, and on-premises environments. Where do those models run when AI Security Mesh tests a customer’s system, what system data do they see, and is any of it retained or used to train models?

Q3 Findings are the most sensitive record a security program holds. Oracle says what agents learn “stays in your business’s private knowledge base.” A store of confirmed weaknesses needs the strongest protection the buyer applies anywhere. Where is that knowledge base held, who at Oracle can read it, and can a customer export it and have it deleted at the end of an engagement?

Q4 Buyers will want to know who carries the risk of testing. Oracle says it “manages the safeguards to reduce the risk of outages or business disruption during testing.” An agent that proves a weakness by exploiting it acts, for that moment, as an attacker on production. What do the safeguards consist of, and if testing disrupts production, who carries the cost?

Q5 Buyers will hold every Oracle agent to the standard Oracle set for its security agents. AI Security Mesh agents operate “with a distinct identity, task-scope, and just-in-time permissions.” Fusion Claw acts on the running user’s token, and the identity of the implementation agents is not described. Will the AI Security Mesh identity model extend to Fusion Claw and to the AI Success Navigator agents, and when?

Q6 Technology leaders have moved from adopting AI to accounting for it. Greyhound CIO Pulse 2026 finds 84 percent have shifted their focus from AI adoption to AI accountability. For a security service, accountability means a record an auditor can follow from finding to fix. Does AI Security Mesh produce an exportable record of test plans, tests, findings, approvals, fixes applied, and retests, and can a customer roll back a fix it has applied?

Read together in Table 3, five of the six questions concern terms Oracle’s documents describe in part or not at all, and each maps to a Runbook move a buyer can make meanwhile.

↑ Back to the section guide

AI Security: The Final Greyhound Standpoint

Greyhound Research’s final judgment is that Oracle has read the AI-era security problem correctly and answered it with a sound design. AI finds flaws faster than organizations can fix them, and Oracle has shown as much in its own patch record. Its answer places a control at each layer an attack can cross, from the approver to the data, and requires a person’s approval before its attacking tool tests or fixes anything.

The evidence is uneven. The cadence, the network controls, and the data architecture are in place or on offer. AI Security Mesh has no date, region, or price, its data terms are not yet published, and its identity model is not yet Oracle’s standard for its other agents. The position would strengthen with dated availability and pricing, published terms for where the testing models run and how findings are held, the Mesh identity model extended to Fusion Claw and the implementation agents, and named customers reporting a shorter time to fix rather than a larger count of findings. It would weaken if customers’ patch backlogs grew despite the monthly cadence, or if approvals for fixes became a formality.

The test Greyhound Research set for Oracle’s AI infrastructure story applies here too: “The proof, however, will lie in execution, not in press releases.” For AI security, execution means a shorter time from a confirmed finding to a deployed fix, measured by the buyer.

Of the six signals in Exhibit 8, two would show up first in a buyer’s own estate rather than in anything Oracle publishes.

Until then, the buyers who gain most will be those who treat fixing as the control. They will move to the monthly cadence, size their capacity to fix before buying more discovery, set one identity standard for every agent, protect the people who approve, and write the terms before any attacking agent touches production. Altman’s one recommendation was to understand the threat and mitigate against it. For most enterprises, mitigation now means fixing at the pace AI finds.

↑ Back to the section guide

Sources And References: Every Document Behind Every Claim

Every fact, figure, and quotation in this research note traces to one of the sources below, presented in Harvard reference format and grouped by class. Each source is also linked in the sentence that carries it. Everything in the first three classes is Oracle’s own account of itself and proves what Oracle said rather than that the thing is true. Standing pages that carry no publication date are marked n.d. All sources were accessed on October 29, 2026.

Oracle announcements

Oracle Corporation (2026a) Oracle Advances Enterprise Security for the AI Era. Press release, October 27. Available at: https://www.oracle.com/news/announcement/ai-world-oracle-advances-enterprise-security-for-the-ai-era-2026-10-27/

Oracle Corporation (2026b) Oracle Announces Deep Trust AI Architecture to Help Enterprises Innovate with Confidence. Press release, October 26. Available at: https://www.oracle.com/news/announcement/ai-world-oracle-announces-deep-trust-ai-architecture-to-help-enterprises-innovate-with-confidence-2026-10-26/

Oracle Corporation (2026c) Oracle Reinvents Enterprise Computing for the AI Era with OpenAI. Press release, October 27. Available at: https://www.oracle.com/news/announcement/ai-world-oracle-reinvents-enterprise-computing-for-the-ai-era-with-openai-2026-10-27/

Oracle Corporation (2026d) Oracle Unveils Agentic AI Platform to Accelerate Implementation of Oracle Fusion Cloud Applications. Press release, October 26. Available at: https://www.oracle.com/news/announcement/ai-world-oracle-unveils-agentic-ai-platform-to-accelerate-implementation-of-oracle-fusion-cloud-applications-2026-10-26/

Oracle product pages

Oracle Corporation (n.d.) Oracle AI Security Mesh. Product page. Available at: https://www.oracle.com/artificial-intelligence/security-mesh/

Oracle blogs

Acosta, J. (2026a) Announcing biometrics-powered Identity Assurance feature from OCI IAM. Oracle Cloud Infrastructure blog, March 3. Available at: https://blogs.oracle.com/cloud-infrastructure/announcing-biometrics-identity-assurance-oci-iam

Acosta, J. (2026b) Introducing Oracle AI Security Mesh: Put AI to work finding your hidden security gaps. Oracle AI and Data Science blog, October 27. Available at: https://blogs.oracle.com/ai-and-datascience/introducing-oracle-ai-security-mesh

Integrated Cyber Center (2026) July 2026 Critical Patch Update Released. Oracle Security blog, July 21. Available at: https://blogs.oracle.com/security/july-2026-critical-patch-update-released

Phelps, E. (2026) Oracle to Release Monthly Critical Security Patch Updates (CSPUs). Oracle E-Business Suite Technology blog, April 30. Available at: https://blogs.oracle.com/ebstech/oracle-to-release-monthly-critical-security-patch-updates-cspus

Rajgarhia, G., Satyamurthy, A., Ragul, A., Mathew, R. and Kerr, B. (2026) Identity and Security in AI Agent Studio. Oracle Fusion Development Center of Excellence blog, July 27. Available at: https://blogs.oracle.com/fusioncoe/identity-and-security-in-ai-agent-studio

Samar, V. (2026) Prepare Now: Apply Oracle Database Release Update Immediately Upon Availability. Oracle Database Insider blog, July 14, updated October 22. Available at: https://blogs.oracle.com/database/prepare-now-apply-the-upcoming-oracle-database-release-update-immediately-upon-availability

Tsai-Smith, J. (2026) Take Action Today: Protect Your Oracle Database Against AI-Enabled Cybersecurity Threats. Oracle Database Insider blog, April 30. Available at: https://blogs.oracle.com/database/take-action-today-protect-your-oracle-database-against-ai-enabled-cybersecurity-threats

Oracle and OpenAI executives in named media

Nagraj, A. (2026) OpenAI’s Sam Altman urges companies to focus on AI security threat as GPT-6 adoption soars. The National, October 27. Available at: https://www.thenationalnews.com/business/2026/10/27/openais-sam-altman-urges-companies-to-focus-on-ai-security-threat-as-gpt-6-adoption-soars/

Shrivastav, U. (2026) ‘Understand The Security Threat Landscape From AI And Mitigate Against That’: Sam Altman. BW Businessworld, October 27. Available at: https://www.businessworld.in/article/understand-the-security-threat-landscape-from-ai-and-mitigate-against-that-sam-altman-630755

Research this note builds on

Greyhound Consilium (2026) The Delegation Dial – How Much Authority To Hand Fusion Claw, Process By Process. Practical guide, developed in partnership with Oracle, October 23. Available at: https://greyhoundresearch.com/the-delegation-dial-how-much-authority-to-hand-fusion-claw-process-by-process/

Greyhound Research (2020) #CounterpunchWithSVG E08: Oracle Believes Its Cloud Is Like No Other. But Is It, Really?. Executive dialogue with Chris Chelliah, Oracle, September 27. Available at: https://greyhoundresearch.com/counterpunchwithsvg-e08/

Greyhound Research (2022) Product Spotlight E03: Oracle Cloud Infrastructure (OCI). Executive dialogue with Palanivel Saravanan and Kapil Makhija, Oracle, December 23. Available at: https://greyhoundresearch.com/product-spotlight-e03/

Greyhound Research (2023) Product Spotlight E05: Oracle Human Capital Management (HCM). Executive dialogue with Shaakun Khanna, Oracle, produced in partnership with Oracle, May 1. Available at: https://greyhoundresearch.com/product-spotlight-e05/

Greyhound Research (2025a) Oracle’s $40B AI Investment: A Game Changer. Commentary with Greyhound Pulse analysis, May 27. Available at: https://greyhoundresearch.com/oracles-40b-ai-investment-a-game-changer/

Greyhound Research (2025b) Backlog Isn’t Bank Balance: A Reality Check on Oracle’s AI Story. Sprint report, September 12. Available at: https://greyhoundresearch.com/backlog-isnt-bank-balance-a-reality-check-on-oracles-ai-story/

Greyhound Research (2026a) Panic Has A Shelf Life: Why Greyhound Research Remains Bullish On IBM After July 14. Research note, July 17, including findings from Greyhound CIO Pulse 2026. Available at: https://greyhoundresearch.com/panic-has-a-shelf-life-why-greyhound-research-remains-bullish-on-ibm-after-july-14/

Greyhound Research (2026b) Everyone Is Building AI Agents. Oracle Is Moving The Contest Inside The Runtime. Research report, July 20. Available at: https://greyhoundresearch.com/everyone-is-building-ai-agents-oracle-is-moving-the-contest-inside-the-runtime/

Greyhound Research (2026c) Oracle Fusion Claw – Autonomy Arrives With A Receipt. Research report, October 14. Available at: https://greyhoundresearch.com/oracle-fusion-claw-autonomy-arrives-with-a-receipt/

Greyhound Research (2026d) Oracle Agentic Implementation – When Agents Draft The Setup, Review Becomes The Control. Research note, October 29. Available at: https://greyhoundresearch.com/oracle-agentic-implementation-when-agents-draft-the-setup-review-becomes-the-control/

↑ Back to the section guide

Disclosures: Independence, Financial, Intended Use, Methodology, Authoring, And Copyright

The evidence in this research note is current through October 29, 2026. Any written response received from an organization named in it after that date is dated where it appears.

Independence Disclosure

Research under the Greyhound Research brand is independent, and no organization holds a right of approval over its content or publication. Greyhound Research did not offer any named organization a pre-publication factual review of this research note. Editorial control remained entirely with Greyhound Research throughout. Greyhound Consilium is the B2B thought-leadership arm of The House Of Greyhound and a sister brand to Greyhound Research. It builds on Greyhound Research’s independent research through collaborations that produce thought-leadership content, research, and practical toolkits for decision-makers. Every Greyhound Consilium publication names its partner on the face of the document. This research note is published under the Greyhound Research brand.

Financial Disclosure

Greyhound Research undertakes advisory and consulting engagements with enterprise buyers and technology providers, and no such engagement confers control over its research findings or its decision to publish them. Oracle is a client of Greyhound Research (part of The House Of Greyhound). The engagement covers only thought-leadership content published under the Greyhound Consilium brand and did not fund this research note. Greyhound Research holds no other financial interest in Oracle or its subsidiaries.

Intended Use

This research note is written for chief information security officers, chief information officers, heads of infrastructure and IT operations, chief financial officers and controllers who own high-risk approvals, general counsel and procurement leaders who contract security services, internal audit leaders, and the press. It reads Oracle’s security announcements at Oracle AI World 2026, with the patching record that preceded them, to inform security operations, identity, sourcing, and governance decisions. This research note is not investment advice, a recommendation to buy, sell, or hold any security, or a view on any company’s share price or valuation. Its assessments rest on the documents listed in Sources And References as they stood on October 29, 2026, and can change as Oracle and others publish more. Product availability, features, and terms are described as Oracle published them through October 29, 2026, so confirm them with your Oracle account team before acting on them.

Research Methodology

Greyhound Research’s analysis rests on source evidence verified against the document that supports each claim. The evidence comprises the twenty-four sources listed in Sources And References, in five classes, from Oracle’s announcements, product page, and blogs to executives’ statements in named media and the research this note builds on. A finding that something is not described is bounded to the documents the text names.

Every executive quoted is named and linked where the quotation appears. No customer is quoted, because Oracle’s security release names none, and no composite or invented customer appears. Greyhound Research’s earlier dialogues with Oracle executives are cited for what Oracle said at the time, with each executive’s title as given then. The Greyhound CIO Pulse 2026 figures are cited as published in Greyhound Research’s research note of July 17, 2026. No Greyhound Fieldnotes are cited, and no factual claim in this research note rests on unpublished material. Quotations are checked against the live source before publication.

Authoring Disclosure

This material reflects the analysis, viewpoint and editorial judgment of Greyhound Research. The position presented is developed from Greyhound Research’s research, advisory work and accumulated institutional knowledge. Depending on the assignment, AI may be used to retrieve relevant material; structure, draft or polish prose from analyst-provided concepts, dictation, notes, rough drafts and source material; support secondary research and factual cross-checking; and assist with editing, condensation and consistency with Greyhound Research’s house style. AI does not independently establish Greyhound Research’s viewpoint, analytical position or conclusions. Material factual claims are verified against source evidence before release. Greyhound Research reviews and approves the final material and retains responsibility for it.

Copyright Policy

All content in this document and on the Greyhound Research website is protected by copyright law and may not be reproduced, distributed, transmitted, displayed, published, or broadcast without the prior written permission of Greyhound Research or, in the case of third-party materials, the prior written consent of the copyright owner of that content. You may not alter, delete, obscure, or conceal any trademark, copyright, or other notice appearing in any Greyhound Research content. Quotation of up to one hundred words is permitted where it carries attribution to Greyhound Research and a link to the published page. Reproduction, redistribution or republication beyond that extent, in whole or in part, by email or in any medium including websites, newsletters and intranets, requires prior written permission, which may be requested at the address below. The published version of each content piece on the Greyhound Research website carries sharing tools for readers who wish to share it.

For questions arising from these disclosures, including licensing requests and media inquiries, contact the Greyhound Research Community Relations Team at connect@thofgr.com.

↑ Back to the section guide