Eight silicon qubits take the foundry route

Eight qubits, one manufacturing bet

Eight silicon qubits have now operated coherently on a chip made with the kind of process used in large semiconductor foundries. The experiment is small, but the manufacturing bet behind it is enormous.

On 13 July, Belgian research organisation Imec and Australia-founded quantum company Diraq reported coherent operation and readout of an eight-qubit silicon MOS spin array. MOS refers to metal-oxide-semiconductor technology, the foundation of conventional silicon chips.

The array was fabricated on a 300 millimetre wafer using a CMOS-compatible process. That’s important because 300 millimetre wafers and CMOS production are standard territory for modern chip factories. Many experimental quantum devices, by contrast, depend on specialised fabrication methods that work in a research lab but become difficult to reproduce at industrial scale.

There’s a crucial qualification here. This is a company-reported research milestone. Eight working qubits don’t amount to a commercially useful quantum computer, and the result doesn’t show that Diraq or Imec has solved error correction, yield, control complexity or reliable large-scale operation.

What it does offer is evidence for a particular route to scaling. Silicon spin qubits encode quantum information in the spin of electrons held inside tiny structures on a chip. If those structures can be made reliably with established semiconductor techniques, manufacturers may be able to draw on decades of process engineering rather than build an entirely separate production system.

That still leaves a brutal engineering problem. A useful fault-tolerant machine would need vastly more physical qubits, extremely low error rates and control systems capable of operating them without overwhelming the device. Moving from eight qubits to that scale won’t be a simple matter of printing more copies.

For Australia, the local connection is worth noting. Diraq grew out of research at UNSW Sydney, and its manufacturing strategy has long centred on silicon. This experiment doesn’t settle whether silicon will win the contest between quantum-computing architectures. It does make the foundry route look a little more credible.

Cloud providers enter the regulatory perimeter

From experimental chips, let’s move to infrastructure that financial institutions already depend on every day.

The UK has designated four major cloud businesses as Critical Third Parties to its financial sector: Microsoft Ireland Operations, Google Cloud EMEA, Amazon Web Services EMEA and Oracle UK. The designations took effect on 13 July, following the announcement on 10 July.

That status brings the providers under direct oversight from the Bank of England, the Prudential Regulation Authority and the Financial Conduct Authority. Those regulators can assess operational resilience and impose requirements tailored to an individual provider where its technology services are considered systemic to UK finance.

Until now, much of the compliance burden around outsourced technology has sat with banks, insurers and other regulated firms. They’re expected to understand their dependencies, manage supplier risk and maintain continuity plans. But there’s a limit to what one bank can discover or influence inside a cloud platform used by much of the sector.

The UK’s move recognises that concentration itself can become a systemic risk. A serious outage, cyber incident or operational failure at one provider could affect many institutions at once. Direct oversight gives regulators a view across those shared dependencies instead of forcing them to examine the problem bank by bank.

This isn’t a finding that the four companies are unsafe. It’s a judgement that their services have become important enough to warrant supervision at the infrastructure layer.

Australian regulators and financial institutions will be watching. The same global providers support workloads here, and Australian organisations face the same tension: cloud platforms can improve resilience and capability for an individual bank while increasing the industry’s collective dependence on a small number of companies.

Europe’s rules for synthetic content

Europe, meanwhile, has filled in a practical piece of its AI transparency regime just weeks before the relevant obligations begin.

On 8 July, the European Commission and European AI Board concluded that the voluntary Code of Practice on Transparency of AI-Generated Content provides an adequate route for demonstrating compliance with Article 50 of the EU AI Act. The conclusion was published on 9 July, and the transparency obligations are scheduled to apply from 2 August 2026.

The code covers two related jobs. AI providers are expected to support machine-readable marking and detection of generated or manipulated material. Deployers also have labelling duties for deepfakes and some AI-generated text published to inform the public on matters of public interest.

The code is voluntary, so joining it isn’t the only possible compliance path. But it gives companies a concrete reference for what regulators are likely to regard as an acceptable implementation. That reduces some uncertainty around a legal requirement that can otherwise sound straightforward but becomes messy once you ask how a label should travel across file formats, editing tools and distribution platforms.

International providers may decide it’s simpler to use compatible marking systems across markets rather than operate an entirely separate European pipeline. Even then, a machine-readable signal is only part of the answer. Labels can be removed, platforms need to preserve metadata, and detection tools have limits. The code supplies a compliance framework; it doesn’t solve the wider problem of authenticating everything people encounter online.

Micron’s quarter-trillion-dollar plan

The next story shows how far the AI investment cycle now reaches beyond the companies designing accelerators.

Micron said on 9 July that its expected US fabrication and technology investment will exceed US$250 billion through 2035. The company linked that spending outlook to demand for memory used in AI systems.

These are announced plans, not money already spent. Projects stretching to 2035 remain exposed to market demand, construction risk, policy changes and Micron’s ability to execute. Still, the scale tells us something about where semiconductor companies expect the bottlenecks to form.

AI accelerators need processors, but they also need large quantities of fast memory. High-bandwidth memory sits close to the compute hardware and feeds it data quickly enough to keep expensive accelerators busy. A powerful processor waiting for data is an expensive piece of underused equipment.

Micron also announced up to US$3 billion for semiconductor supply-chain projects in the United States. That includes US$500 million supporting GlobalWafers’ 300 millimetre silicon-wafer facility in Texas. Wafers are the starting material on which chips are fabricated, so this pushes investment further upstream than memory production itself.

The practical point is that the AI build-out isn’t confined to model developers, data centres or GPU designers. It’s drawing capital into memory fabs, wafer production and the less visible layers of the semiconductor supply chain. Whether every announced project reaches completion is another question, particularly if AI infrastructure demand proves uneven.

Meta opens Muse Spark to developers

There’s also a new entrant in the developer-facing model market.

Meta announced Muse Spark 1.1 on 9 July and placed its Model API into public preview, giving outside developers direct access. Meta describes Muse Spark as a multimodal reasoning model built for coding, computer interaction, tool use and longer agent workflows.

Those capability descriptions are Meta’s claims. The supplied material doesn’t include independent testing or comparative benchmarks, so there’s no solid basis here for ranking the model against alternatives.

The more concrete change is access. An API turns Muse Spark from an internal Meta component into infrastructure that developers can test and build around. Public preview also means some caution is sensible: interfaces, availability and operating characteristics may still change before a general release.

For developers assessing it, the useful questions will be practical ones: how reliably it uses tools, how it handles long-running tasks, what failures look like, and whether cost and latency hold up in a real application. The announcement opens that evaluation process; it doesn’t answer it.

AWS tightens agent access and exposure checks

Staying with tools that act on real systems, AWS has made two security announcements aimed at different parts of the deployment problem.

On 9 July, AWS added OAuth support to its Model Context Protocol server. MCP is a standard for connecting models and agents to external tools and data. According to AWS, agents can now authenticate through AWS Sign-In while operating within existing identities, IAM permissions and governance arrangements.

For enterprise teams, that’s more useful than giving an agent a powerful shared credential and hoping everyone remembers where it went. AWS says the administrative controls include token introspection and revocation, dynamic client registration, condition keys and CloudTrail audit events. In plain terms, administrators can inspect and cancel access, control how clients register, apply policy conditions and retain a record of activity.

The limitation deserves equal weight. Better authentication doesn’t make an agent’s actions safe or correct. An agent with excessive permissions can still make an expensive or damaging mistake, only with a cleaner audit trail. Organisations need narrow permissions, approval boundaries for high-impact actions and monitoring that focuses on what the agent actually does.

A day earlier, on 8 July, AWS announced Network Scanning for Security Hub. The feature externally probes resources to determine whether they’re genuinely reachable from the public internet, rather than relying solely on configuration analysis. AWS says it can discover public-facing resources and services across both AWS and Azure, then correlate those observations with other security findings.

Again, those are AWS’s product claims; the supplied source doesn’t independently assess accuracy or coverage.

The distinction between configured exposure and actual reachability is useful. A security rule can look permissive even when another control blocks the route. Conversely, complicated networking can make a service reachable through a path that configuration-only analysis misses. External probing can give teams stronger evidence about which systems are accessible and therefore deserve urgent attention.

It won’t eliminate judgement. Scan coverage, timing and interpretation all matter, and an unreachable system can still have serious security flaws. But it could help teams spend less time arguing over theoretical exposure and more time fixing services that can demonstrably be reached.

Final recap

So, the lead development is an eight-qubit silicon array from Imec and Diraq made with a 300 millimetre, CMOS-compatible process. It’s an early research result, but one that supports the case for manufacturing silicon quantum processors with foundry-style techniques.

The UK is now supervising four cloud providers as critical infrastructure for finance. Europe has endorsed a voluntary compliance code for marking and labelling AI-generated material before Article 50 transparency duties apply on 2 August. Micron has outlined more than US$250 billion in planned US fabrication and technology investment through 2035, while Meta has opened public-preview API access to Muse Spark 1.1.

And at AWS, OAuth support brings established identity and audit controls to its MCP Server, while Security Hub’s new network scanning aims to test which resources are actually exposed to the internet.

The direct sources for every story are in the show notes.