Microsoft has had a narrow escape from total embarrassment: A security company uncovered a critical vulnerability that could have compromised all Azure Cosmos DB databases — both those of customers and Microsoft’s own.

Google subsidiary Wiz found a flaw in the database’s Gremlin API, usually used for storing and managing property graph data.

If bad actors had discovered it first, they could have exploited it to acquire what Wiz called the Cosmos Master Key, which would have enabled them to use the primary key of any Cosmos database, resulting in read and write access to any account. They would also have had access to a list of every database on the service, with identifiers such as subscription and tenant IDs.

Azure Cosmos DB is a NoSQL database that underpins Microsoft’s cloud services. It can be accessed through SDKs for framework such as Python, Node.js, Java, and .NET.

Wiz described how it discovered the vulnerability in a blog post. It disclosed details of the flaw to Microsoft in November 2025.

Microsoft deployed a hot fix within two days, but it took another eight months to re-engineer the infrastructure, removing the Cosmos Master Key and introducing new guardrails to Cosmos DB to prevent similar attacks.

It is not the first time Cosmos DB customers’ primary keys have been under threat: In 2021, Wiz found a flaw in data exploration tool Jupyter Notebook that could be exploited to access the database keys and other secrets.

This article first appeared on CSO.

Oracle on Tuesday described new EBCDIC character set compatibility features in Oracle AI Database for customers transitioning from legacy databases on IBM mainframes.

In its post, Oracle noted that EBCDIC compatibility has historically been one of the top technical challenges for enterprises re-platforming to use newer, ASCII-based databases while continuing to use proven legacy applications.  

“Achieving this goal requires more than simply moving data. It requires preserving the EBCDIC compatibility on which existing applications depend,” wrote Michael Yau, VP for Oracle Database Globalization Engineering. The feature rollout “addresses two fundamental challenges of preserving EBCDIC compatibility: accurate character encoding conversion and preservation of EBCDIC binary ordering.”

He added: “These client character sets implement IBM Character Data Representation Architecture (CDRA) code page definitions, providing source-to-target character mappings that are compatible with IBM’s published standards. This enables accurate and predictable character encoding conversion during data migration and subsequent database client/server communication.”

Yao observed that this is important because these mainframe migrations can be very complex.

“Many legacy EBCDIC applications, such as those written in COBOL, implicitly rely on the EBCDIC binary ordering defined by IBM EBCDIC code pages. SQL predicates that compare character values, perform range searches, or sort query results often assume this ordering,” he wrote. “After migration to an ASCII-based Oracle AI Database character set, these same SQL statements can produce different results, not because the data changed, but because the database’s default binary ordering follows that of the ASCII-based database character set rather than the source EBCDIC code page.” 

Compatibility repair, not modernization

While consultants generally applauded the new features, some questioned whether this will simply shift enterprise dependency on IBM to dependency on Oracle. 

Sanchit Vir Gogia, chief analyst at Greyhound Research, is one of the fans.

“Oracle has repaired one of the oldest silent faults in mainframe migration: EBCDIC ordering, the muscle memory of the legacy estate. Preserve the data and lose the ordering, and a query returns the wrong record while every dashboard stays green,” he said. “The application runs and the query completes. The answer is simply wrong.”

Gogia noted that the new feature is “not a modernization suite. It is a compatibility repair, narrow and genuinely useful, which CIOs who have bled on past migrations will read with equal parts relief and suspicion.”

AJ Thompson, CCO at UK IT consulting firm Northdoor, agreed that the Oracle announcement addresses a genuine technical barrier rather than just being a marketing gimmick, so it is worth taking seriously as a re-platforming enabler. “The two problems it solves, EBCDIC to ASCII character conversion and preserving EBCDIC binary sort ordering, have historically been real blockers for allowing COBOL to move away,” he said.

But, he cautioned, CIOs must also take resiliency challenges seriously. “Mainframes are not chosen primarily for character encoding, they are chosen for benefits like decades of proven uptime, IBM Z’s redundancy architecture, and workload isolation,” he pointed out.

“Oracle’s announcement solves a data compatibility problem, not a resilience or availability one. A client with genuinely mission-critical, zero-downtime workloads will still need convincing on the availability and disaster recovery side before moving [to the cloud], and Oracle’s own resilience claims would need scrutiny on their own merits, quite separate from this EBCDIC work.”

Leverages IT desperation

Mike Wilkes, enterprise CISO at Aikido Security, added that Oracle is leveraging IT desperation to squeeze long-term value from legacy systems. 

“I have always believed that Oracle will own the very last white-knuckle-grip workloads that migrate from on-premises data centers into the cloud,” he said. “This announcement certainly demonstrates that they understand their position in the world of cloud service providers. They are not the biggest, they are not the oldest, and they are not the most technically advanced. But they do own the market share for the trailing edge of cloud adoption.”

He pointed out that the greatest barrier to cloud migration is not containerizing modern applications, it is the decades of business logic buried inside COBOL applications and EBCDIC-encoded data.

“Oracle’s EBCDIC compatibility features acknowledge a practical reality: organizations are not rewriting these systems from scratch,” he said. “If Oracle can reduce the cost, risk, and operational disruption associated with moving those workloads, the announcement represents meaningful value for IT teams that have been delaying modernization because the migration path was simply too complex or too expensive.”

Could cause vendor lock-in

Then again, Wilkes noted, there is the potential for increasing vendor lock-in.

“Compatibility layers almost always increase long-term dependence on the platform providing them,” he said. “Rather than eliminating legacy technology, they abstract it behind Oracle’s database and cloud ecosystem, making future migrations potentially more difficult. Enterprises should view these tools as transition accelerators rather than permanent architecture.”

Thus, he said, if they use the opportunity to gradually modernize applications and data models, there is substantial value, but if they simply relocate technical debt into Oracle Cloud, they may find that they have exchanged one form of legacy lock-in for another.

Easier, but not easy

Matt Kimball, VP and principal analyst with Moor Insights & Strategy, also saw the Oracle move as a good one, but stressed that while it should make things easier for organizations, re-platforming still won’t be easy because EBCDIC migration isn’t just a character-conversion exercise. However, “Oracle’s built-in character-set support and EBCDIC collations move part of that compatibility burden into the database, making it easier to preserve existing application behavior,” he said.

Ishraq Khan, CEO of coding productivity tool vendor Kodezi, agreed. 

“One of the biggest obstacles to leaving mainframes is decades of applications built around EBCDIC encoding and legacy data formats. If these compatibility features reduce the amount of code that needs to be rewritten, they can lower migration risk, cost, and implementation time,” Khan said. But, he added, organizations should also consider whether these features simply make migration easier, or make future moves more difficult.

This article originally appeared on CIO.com.

For years, the public cloud was the default for new workloads because its convenience, elasticity, and breadth of services made sense. However, as AI’s strategic importance grows, its economics and infrastructure are changing. Tesla is one of the clearest examples of a company deciding that AI is too important, too expensive, and too central to its business to leave largely in the hands of a third-party cloud provider.

 At the center of Tesla’s strategy is a simple idea. If AI is key to how you build your products, run your business, and define your future, the infrastructure that powers AI becomes a strategic asset. It is no longer just plumbing but part of the product itself. Tesla’s models, databases, applications, and workflows increasingly rely on infrastructure that is built, hosted, and managed by Tesla. That means the company has direct control over the hardware, the software stack, data movement, performance tuning, and security posture. For a company that depends on AI to support autonomy, robotics, manufacturing intelligence, and future product direction, that control matters.

This is the real heart of the matter. Tesla is not treating AI as a side project or a feature layer added on top of an existing business. AI is central to Tesla now and into the future. It is a force multiplier, but more than that, it is an essential aspect of product development, operational efficiency, automation, and competitive differentiation. Once a company reaches that level of dependence on AI, the conversation around infrastructure changes very quickly.

Public cloud is attractive because it provides a complete AI ecosystem on demand. You can provision compute, storage, training environments, managed services, orchestration tools, and deployment pipelines without building much yourself. That is why I often call public cloud “the easy button” for AI. It is fast, convenient, and feature-rich. But convenience comes with a premium, and for many companies moving deeply into AI, that premium is becoming very hard to justify.

Cost is driving AI out of the cloud

One of the biggest forces driving this shift is price. Many enterprises moving into AI are shocked by what public cloud providers charge for AI infrastructure. Training clusters, inference engines, storage, networking, observability, and support services all add up quickly. What begins as a convenient path to experimentation can become an extremely expensive operating model when AI moves into production at scale.

In my experience during the past 15 years, public cloud is often at least twice as expensive as comparable private infrastructure for sustained workloads. That is not true in every case, and it depends heavily on utilization patterns, architecture, and operational maturity. However, for large, predictable, always-on AI workloads, public cloud economics often become difficult to defend. The markup associated with convenience, elasticity, and managed ecosystems is substantial.

In response, companies are increasingly exploring alternatives. Some are moving toward neoclouds that specialize in AI infrastructure. Others are evaluating sovereign cloud options for control, locality, or compliance reasons. Many are revisiting private cloud infrastructure for the most strategic and cost-intensive workloads. Tesla is becoming the poster child for how successful that approach can be when a company has the scale, the sophistication, and the long-term commitment to execute it well.

Control, governance, and security

Cost is only one part of the equation. Control is the other major driver. When Tesla runs its AI infrastructure on equipment it owns and operates, it gains much tighter control over performance, data handling, workload placement, governance models, and operational priorities. That matters a great deal when the workloads involved are mission-critical and directly connected to the future of the company.

A privately controlled AI environment can provide better security because the organization has direct oversight of the infrastructure stack. It can provide better governance because data, models, and workflows remain inside systems the enterprise fully controls. It can also improve reliability and performance tuning because engineering teams can optimize specifically for their own AI pipelines rather than adapting to the generalized patterns of a shared cloud environment.

Of course, many people are quick to point out that running your own private infrastructure comes with significant labor and cost. They are not wrong. Building and operating private AI infrastructure requires capital, engineering skill, facilities, procurement discipline, operational excellence, and long-term commitment. This is not a shortcut, nor is it easier than public cloud. In many ways, it is harder.

However, the point is that for sophisticated companies with large-scale, steady-state AI needs, it can be worth it. Better control, better governance, better security, and ultimately lower cost can justify the additional operational burden.

The future of AI infrastructure

What makes Tesla so important in this discussion is that the company chose this route because AI is inseparable from its business strategy. Many other enterprises are heading in this same direction. As AI becomes less experimental and more operational, the infrastructure conversation shifts from convenience to economics, control, and differentiation.

Not every company should follow Tesla’s path. Many enterprises are not ready to build, host, and manage their own AI environments. Many lack the scale to justify it. Many still benefit tremendously from the agility of public cloud. But for organizations where AI is becoming central to products, services, and competitive advantage, Tesla’s strategy is increasingly relevant.

There are three things every enterprise should think about when considering ownership of its own AI infrastructure:

• First, understand the operational burden in full. Private AI infrastructure requires teams, processes, facilities, and discipline that many organizations underestimate.
• Second, know the economics of your workload patterns. If AI demand is large, steady, and strategic, the cost advantages of ownership may be compelling.
• Third, think beyond cost alone and focus on control. If AI is core to your future, owning the infrastructure may offer strategic benefits in governance, security, optimization, and long-term independence that public cloud cannot easily match.

Tesla’s strategy is not for everyone, but it is a persuasive example of what happens when a company decides that AI is too important to rent forever. Public cloud remains the easy button, and for many organizations, that will be enough. But for companies that see AI as fundamental to how they will compete, private infrastructure may turn out to be the smarter choice.

Now that Samsung has jumped into the crowded AI-powered glasses arena alongside Apple, Google, Meta, and others, CISOs and IT leaders are again having to think through whether it makes sense to establish enterprise restrictions on such devices, given the likely data leakage and privacy and compliance issues.

And even if those tech leaders decide that such policies might make sense, the logistical hurdles to universally enforcing them outside the office are all but insurmountable.

For example, it is up to individual wearers to choose their device’s settings, making it difficult for IT policies around data acquisition and usage to be enforced. Worse, AI devices have a history of ignoring guardrails. That means that a setting that limits how data is used may not necessarily be obeyed. 

One possible mitigating factor is that smart glasses typically have a light on the frame that activates when the device is recording, but there are also many easy ways for workers to defeat or cover up those lights to conceal their activities. 

Enforcement is virtually impossible

However, said independent technology analyst Carmi Levy, “although some organizations have tried to physically ban smart glasses from their in-person and virtual workplaces, the sad reality for corporate technological gatekeepers is there is no way to completely keep any device out of the workplace.”

There is nothing stopping employees from wearing eyewear of any type, smart or not, he noted, “and attempting to do so might put employers on the wrong side of a disability lawsuit launched by a worker who needs prescription smart glasses to accommodate vision issues.”

As well, Jitesh Ubrani, an IDC director focusing on worldwide device trackers, pointed out that the biggest challenge in creating rules around usage of smart glasses is that the data leakage problem with devices is both not new and certainly not limited to glasses. 

“The instinct to ban AI smart glasses outright is understandable, but it misses that the underlying risk isn’t new. A smartphone has been able to record a whiteboard, a screen, or a conversation for close to two decades,” he said. “What’s changed is the friction. Glasses make covert capture nearly effortless and far harder to notice because there’s no phone being visibly raised or pointed. That’s a real escalation in ease of misuse, but it’s a difference of degree rather than a fundamentally new capability.”

In fact, Ubrani argued, “where this gets hard for CISOs is enforcement. A ban on paper is easy to write. Enforcing it inside a corporate office is already difficult, since most current-generation devices, including Meta’s Ray-Bans, are visually indistinguishable from ordinary eyewear.”

And, he added, “enforcing it in a hybrid or work-from-home setting is close to impossible. IT has no practical way to confirm what someone is wearing on a home Zoom call, and even in-office detection options, like scanning for Bluetooth or BLE advertising signals tied to known manufacturer IDs, only catch devices that haven’t been reconfigured or that happen to be broadcasting at the time.”

Additional risk

Connected glasses have a history going back decades, but enterprises didn’t take them seriously until this year.

But Anshel Sag, principal analyst at Moor Insights & Strategy, characterized the problem as more psychological than technological. 

“People want to ban it because they don’t know how to handle it. But that just creates more problems than it solves. It’s a very kneejerk fear reaction,” Sag said. “We live in an era where cameras are everywhere.”

Meghan Hollis, a senior principal analyst for Gartner, agreed that the focus on smart glasses is misplaced, given that even headphones can today capture audio for translation and transcription. The change is not in the data capture, Hollis said, but the fact that it is adding video.

This creates additional risk, with the new capability brought into the corporate environment causing “a potential exposure for corporate intellectual property,” Hollis said.

One other often-overlooked issue is data sovereignty. Even if the glasses manufacturer agrees to store data only in specific countries, it could easily change that policy or simply switch third-party vendors. 

“There could be export control issues, possibly violating regulatory controls in transmitting information,” Hollis noted. 

However, Hollis said, threatening to punish workers if they are caught using unauthorized devices “is your last line of defense,” and that the best initial approach should not be enforcement, but education.

“You need to be educating your end-users, with constant reinforcement, telling them, ‘If you do this, here’s how you can harm the company and our clients/customers.’ Combine that with, ‘And if you do this, we will take action against you.’”

Tiered policies required

Hollis noted that the risk goes beyond an employee initially recording something they shouldn’t. Consider, for example, a technical meeting where an employee asks the rest of the attendees for permission to record the discussion. They agree and he starts to record. 

At the end of the meeting, he leaves to return to his office, fully intending to turn off the recording function when he gets there. But on the way, he has a brief hallway meeting with an SVP who tells him, without warning, “FYI, but the board just decided to greenlight our hostile takeover of Smith Corp. We’ll explore the specifics at a 10 a.m. tomorrow. Have your team there.” The executive then walks off.

With the recording still running, that ultra-sensitive data has just been transmitted to the cloud. 

IDC’s Ubrani pointed out that situations like this make smart glasses governance more challenging. “Enterprise IT and security leaders need to stop framing this as ‘ban versus allow,’ and instead build a tiered policy based on where the actual risk sits,” he said. “Boardrooms, R&D labs, and any space where trade secrets or regulated data are visible or discussed out loud deserve strict no-wearables rules, enforced the same way phone bans already are in those rooms.”

Open floor plans and general office space probably don’t need that level of restriction, he said, but meeting policies should require disclosure when a device capable of recording is present, similar to the way in which some companies already handle personal recording devices in sensitive briefings.

“Companies that try to write one blanket rule for every environment are going to find it’s either unenforceable or so restrictive it interferes with accessibility, since some employees rely on these devices as assistive technology,” he said.

However, Brian Jackson, a principal research director at Info-Tech Research Group, argued that enterprise CISOs and IT Directors need to take a far more strict position.

“Organizations should update their acceptable use policies for personal technology ASAP,” he said. “Look back about 15 years ago at how smartphones moved from consumer life into the workplace, and we may be at the beginning of a redefinition of BYOD here. But it needs to start with an extremely restrictive policy against the use of AI wearables and similar devices.”

He added, “organizations need to hold the line against making personal recordings in the workplace and maintain not only their compliance standards, but their workplace culture. This restriction cannot go as far as an outright ban; look at how Walt Disney World got caught up in a lawsuit after telling an employee she could not use Meta glasses. Still, this exception can be made narrow, and it should be made clear that other employees must be alerted when they are being recorded.”

This article originally appeared on CSOonline.