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.

Every cloud architect, every financial services executive, and frankly every enterprise CTO should be paying attention to what is going on in the United Kingdom right now. Britain has formally designated Microsoft, Google, Amazon Web Services, and Oracle as “critical third parties” to the financial sector, meaning they are now subject to direct oversight by UK financial regulators rather than being treated as distant infrastructure suppliers outside the regulatory perimeter.

The designations took effect on July 13, 2026, and the oversight will be carried out by the Bank of England, the Prudential Regulation Authority, and the Financial Conduct Authority. The point is straightforward. If these platforms underpin critical banking and financial operations, then their resilience is no longer just a procurement issue. It is now a matter of financial stability.

This is a bigger deal than many people understand. For years, enterprises have treated cloud platforms as outsourced technology providers. Regulators are now making a different argument. They are saying that when enough banks, insurers, payment firms, and market infrastructures depend on the same small group of cloud providers, those providers become systemic infrastructure whether they like the label or not. Reuters reported that the UK’s framework will bring requirements such as resilience testing, self-assessments, and incident reporting directly to these providers. In other words, this is not just more policy language. It is operational oversight aimed at the platforms themselves.

The first thing to understand is that this move is not anti-cloud. It is the opposite. It is an acknowledgment that cloud has become too important to remain lightly touched when it comes to systemic risk. Regulators are not trying to unwind cloud adoption in financial services. They are accepting the reality that core financial operations now depend on a concentrated set of external platforms. When that happens, the conversation changes from vendor management to infrastructure resilience.

Systemic cloud concentration

The market has spent years talking about cloud concentration risk as if it were some vague future concern. It is no longer abstract. The UK is acting because concentration at this level means that a disruption at one major provider can ripple across multiple institutions simultaneously. That is the core issue. It is not whether Microsoft, Google, Amazon, or Oracle are competent operators. In many cases, they are exceptionally good at what they do. The problem is that too much critical activity depends on too few shared platforms.

This is a concept many business and technology leaders still struggle to internalize. A single bank can do a fine job managing its own vendor exposure and still be part of a broader systemic vulnerability if every other bank is relying on the same provider, the same region, the same identity layer, or the same operational dependencies. Regulators are stepping in because the risk is collective, not just institutional. That is why this matters well beyond the UK. It provides a framework for thinking about cloud not as outsourced capacity, but as part of the plumbing of the financial system itself.

Regulators expand their reach

Traditionally, regulators focused on the bank, insurer, or market institution and expected that entity to manage the risks created by outside suppliers. That approach still exists, and financial institutions remain accountable for their own resilience. However, the UK now says that, in some cases, this indirect model is not enough. If a third party becomes critical enough, regulators want direct line of sight into that provider’s resilience posture as well. This is probably the most important architectural and policy signal in the entire move.

That changes the relationship between the financial sector and the cloud providers in a meaningful way. Direct oversight means cloud providers are increasingly being treated less like optional technology partners and more like essential utilities that support national economic confidence. Once that happens, architecture decisions start to carry a different weight. Decisions about control planes, failover models, identity dependencies, regional design, observability, and incident response are no longer just internal engineering choices. They become part of a broader resilience conversation that may now include regulators.

A lot of enterprises have been behind the curve. They built architectures under the assumption that the cloud was simply a faster and cheaper hosting model. It is not. At scale, cloud is shared critical infrastructure. The UK has now made that point explicit.

More scrutiny isn’t more safety

It’s tempting to read this and assume the problem has now been solved. It has not. Direct oversight of hyperscalers does not remove the responsibility of banks or other enterprises to architect well. In fact, it should push them to architect better. A regulated provider can still be a concentration point. A resilient platform can still be used in a fragile way. And a well-run cloud service can still become part of a badly designed dependency chain.

If you are in a regulated or highly sensitive industry, you should take this as a warning that resilience can no longer be treated as a side topic. You need to know exactly which services are business-critical, which control planes are shared, which identity systems create cross-platform dependencies, and how your recovery assumptions actually work in the real world. Most organizations are much weaker here than they believe.

The UK’s move should also force a hard conversation about operational transparency. If regulators are requiring incident reporting and resilience evidence from major providers, enterprises should be demanding clearer dependency mapping and better architectural visibility inside their own environments. You cannot build true resilience on top of assumptions and vendor slide decks.

The start of a much larger shift

The deeper message is that cloud is crossing a line from enterprise technology choice into national and sector-level infrastructure policy. Once a few governments and central regulators start treating cloud this way, the rest of the world tends to follow in some form. We have already seen comparable concern in Europe, and now the UK has made its own move with direct designations and direct oversight.

Architects, CIOs, and boards need to mature their thinking quickly. The conversation is no longer limited to feature depth, discounts, migration speed, or which provider has the best AI story this quarter. The conversation is now about resilience, concentration, transparency, control, and systemic dependency. Those are bigger issues, and they are not going away.

The UK is telling the market something very clearly. Microsoft, Google, Amazon, and Oracle are not just selling cloud services into the financial sector. They are becoming part of the infrastructure on which that sector depends. Once you understand that, everything changes, including how we architect for the future.

All of the major AI providers want you to use, and ideally stay within, their super apps, and now Microsoft is looking to capture that attention, too.

During an earnings call this week, CEO Satya Nadella confirmed that the tech giant is building a Copilot ‘super app’ that will be rolled out this quarter. The new platform will bring together various Copilot tools, including chat, Cowork, long-running Autopilot agents, and the always-on Microsoft Scout, powered by OpenClaw.

Microsoft said the super app will be wired into many of its other governance platforms, including Agent 365, IT Ops, SecOps, FinOps, and business processes. And, it said, CRM and ERP systems will “serve as skills and plug-ins that go into core work.”

“You’re able to take that enterprise-wide workflow and wire it into the super app,” Nadella said, describing it as “the coming together of a new way to work.”

With this move, Microsoft will compete with OpenAI’s ChatGPT Work, Claude Cowork, and a growing number of others trying to capture as much of a user’s workflow as possible. It could prove a strong contender, as everyday Copilot “usage intensity” is at the same level as that of Outlook or Teams, Nadella said, and paid seats now surpass 30 million.

Every model should be ‘swappable’

Even as it builds a super app to bridge workflows, Microsoft is acknowledging enterprise demand for model choice. Customers are making it clear that they don’t want to be locked into one model; they want the ability to move between open, closed, and frontier options based on the best tool for the job.

This trend is reflected in Redmond’s own usage statistics: Since the beginning of the year, it has tracked a 5x increase in the number of customers building with models from multiple providers featured on its platform.

The company claims it has the broadest model catalog in the cloud, offering more than 11,000 models from OpenAI, Anthropic, Mistral, its own MAI family, and others.

“We are building a new model system, where the harness, context, memory, and action space are separate from any one model family, thereby moving the frontier on the cost-to-outcome curve,” Nadella said. “That’s really the enterprise design architecture that we are going to evangelize.”

He described enterprises as “learning machines” that need their own internal learning machines, and said that they will be evaluating how providers are helping them reach their business goals and support knowledge creation.

“The models are an input, not some extraction of the knowledge of the enterprise,” Nadella said. “This is not going to be about, ‘come in and take all my knowledge and benefit yourself, [and] I am not getting anything out of it.’”

The key is in balancing the advantages of frontier models with lower-cost options, open weights with closed weights, and having the ability to train internal models based on outputs, traces, and context. “You should and you can use frontier models,” Nadella said. “There’s no reason not to.”

However, he said, any given model at any given time should be swappable to democratize design.

For instance, data from cybersecurity evaluation framework CyberGym showed that Microsoft’s new MAI-Cyber-1-Flash coding agent achieved Claude Mythos-level performance at 50% of the cost. This is because 90% of tasks were completed by Cyber-1-Flash and 10% by frontier models from OpenAI, Anthropic, and others. 

This ability to use the right model for the right task in what is essentially a pipeline job is a “super important characteristic,” Nadella said. Microsoft Copilot, Security Copilot, and GitHub Copilot are all built to support movement between different models based on the task.

This strategy is also reflected in the company’s new Project Perception cybersecurity offering. The platform features three specialized types of agent (red, blue, and green), and the underlying harness decides which AI model is best suited for a given task. Guided by specialized playbooks, red team agents discover vulnerabilities, blue team agents triage, and green team agents propose remediation plans.

“You create your own agentic system that’s continuously operating to create the cyber defense you need,” Nadella explained. “Especially in cyber[security], it becomes critical to have that multi-model approach.”

Nadella also pointed to the recent Hugging Face incident, in which an OpenAI model went rogue, broke out of its sandbox, and launched an attack against the popular open-source platform, noting that enterprises will likely need to use multiple models to offset and remediate the various challenges of each, and should not be “subject to the refusals of one model.”

“We talk about the frontier as if it’s one thing,” Nadella said. “The frontier is about every firm having a frontier, the choice, the cost control, and the capability that they need in order to be able to control their destiny.”

Increased push to usage-based pricing, closing demand gaps

As Microsoft emphasizes its model-agnostic architecture, it is also shifting from per-seat to per-seat-plus-consumption pricing; the company recently added usage-based billing to Cowork and Agent 365, and plans to continue that trend across its products.

While these moves have resulted in sticker shock and ‘tokenmaxxing’ at many companies, Nadella framed it as a revenue driver. “We are advancing the frontier on the cost-to-outcome curve, ensuring every customer can turn tokens into business results.”

Meanwhile, Microsoft said it will continue to close data demand-capacity gaps.

The company added 88 data centers in FY 2026, including 31 across five continents this past quarter. It contended that it is bringing capacity online “faster than ever,” reducing dock-to-live times for new GPUs in its largest regions by nearly 50% over the fiscal year.

However, CFO Amy Hood acknowledged during the earnings call, “the situation is obviously that demand exceeds available supply in a relatively extreme moment.”

Reflecting this, revenue for Azure and other cloud services grew by 43% in Microsoft’s fiscal year ended June 30, and the company expects similar revenue growth (45%) in fiscal year ‘27.

Hood said that Microsoft remains “focused on delivering efficiencies,” including in its CPU and GPU fleets, and engineers are also working on process improvements. The company added another gigawatt of capacity this quarter and is on track to roughly double its overall capacity in two years.

“We are also getting more from the infrastructure we already have by optimizing across silicon, systems, and software,” Hood said.

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.