Frontier AI’s security bill comes due

OpenAI Slows Frontier Training

OpenAI is deliberately slowing some frontier-model work because the systems may be becoming too capable for the company’s existing cyber defences. The constraint is no longer just how much compute a lab can obtain, but whether it can safely contain what that compute produces.

That pause is the development worth spending time on. On August 18, OpenAI said it had temporarily slowed model scaling, stopped two weeks of reinforcement-learning training for models intended for deployment, and continued to hold its largest planned frontier training run. The company linked those decisions to its recent Hugging Face incident and preliminary evidence that an unreleased model called Astra may meet the critical cybersecurity capability threshold in OpenAI’s Preparedness Framework.

That classification hasn’t been finalised, so the wording matters. OpenAI isn’t saying Astra has definitely crossed the threshold, and it hasn’t yet published the promised technical report. But the company has seen enough to interrupt expensive training work rather than treat security as something to add immediately before release. That changes the economics and the pace of frontier development. A training cluster can be ready, the researchers can be ready, and the model may still remain on hold while containment catches up.

OpenAI also described a new monitoring system that examines sampled-token activity, tool actions and whatever reasoning is available to the monitor. When it raises a critical alert, escalation procedures are designed to pause the activity if staff cannot clear that alert within 30 minutes. The intention is to catch dangerous behaviour during training and tool use, not merely inspect the finished model after the fact.

That protection is computationally expensive. OpenAI estimates the monitor consumes roughly 20 per cent of the inference compute being watched. That figure varies by workload and doesn’t apply to every inference request, and independent reporting says OpenAI doesn’t currently intend to pass the cost directly to customers. Even so, a 20 per cent overhead on selected high-capability workloads is substantial. Labs may need extra accelerators, more power and more operational staff just to observe a system safely while it works.

For organisations watching the frontier, the useful conclusion is that future capability gains may arrive less predictably. Training runs and releases can be delayed by containment evidence even after the underlying research succeeds. Security also becomes part of model capacity planning rather than a separate compliance line at the end of a project.

My read is that capability is no longer the only hard limit on frontier progress. A lab increasingly has to demonstrate that its own environment can withstand the model it is building. OpenAI’s safeguards are still company-described and haven’t been independently audited, so this is not proof that the problem has been solved. The important change is that the risk has become concrete enough to stop training and leave an enormous planned run waiting.

An Agent Finds Snowflake’s CI Flaw

From that frontier-scale problem, the security picture gets very practical very quickly.

Wiz says its autonomous Red Agent found and exploited a vulnerability in a Snowflake GitHub Actions workflow during an authorised HackerOne investigation. The workflow had been live for only five days. A carefully constructed title on a public GitHub issue could inject commands into the workflow runner, letting the researchers expose a Jira credential with read access to Snowflake engineering, compliance and bug-bounty projects.

Snowflake patched the workflow on the day Wiz reported it and rotated the credential the following day. The company said an audit of its logs found no access beyond Wiz’s authorised testing, although that finding hasn’t been independently verified. The short timeline is reassuring on response, but it also shows how little time defenders may have when automated systems can inspect newly merged workflows continuously.

There is an attribution trap here. Wiz initially framed the incident more strongly around AI-authored code, then corrected its account. GitHub Copilot co-authored and checked the merged pull request, but the available evidence doesn’t establish that Copilot generated the vulnerable change. What is well supported is that an AI-assisted development process was involved and that an autonomous security agent later found the weakness. That is a more nuanced story than one AI breaking the code and another fixing it.

GitHub Actions injection is especially dangerous because workflow runners routinely sit beside credentials, build artefacts and deployment permissions. Treating workflow files as harmless automation misses their real role: they are executable infrastructure. Public issue titles, pull-request fields and commit messages are untrusted input when a workflow interpolates them into a shell command.

For organisations, the immediate lesson is to give CI workflows their own security review, use short-lived and narrowly scoped credentials, and assume automated discovery will compress exposure windows. AI-assisted coding may speed up review and remediation, but it doesn’t remove the need for explicit checks around untrusted inputs and secret access. My judgment is that autonomous security agents are becoming useful at finding the gaps between ordinary scanners, while careful human attribution remains essential whenever a vendor wants to tell a cleaner AI-versus-AI story.

Google Broadens Its Silicon Supply Chain

Now, shift from software risk to the hardware underneath it.

Marvell disclosed on August 19 that it had expanded its agreement with Google to develop custom semiconductor products across Google’s TPU ecosystem. The programs extend beyond the headline AI accelerator. They include inference accelerators, storage and network controllers, memory-interface controllers and near-memory compute — the specialised components that move, store and feed data around the processors doing the model work.

The financial arrangement gives the scale of Google’s potential purchasing power. Google received a warrant covering up to 58,970,907 Marvell shares at an exercise price of 206 dollars and 58 cents per share. Most of the vesting is linked to Google purchases, arriving in 500-million-dollar revenue tranches through Marvell’s 2033 financial year. The commercial agreement itself was signed on July 29, with the warrant issued on August 18. Google is not obliged to exercise the entire warrant, so the maximum share figure is an incentive structure rather than a guaranteed outcome for Marvell.

There are still large gaps in the public picture. The filing doesn’t identify individual chips, expected deployment dates or how the expanded work changes Google’s existing relationship with Broadcom. It also doesn’t tell us how much of Google’s future TPU supply chain Marvell could ultimately capture. The hard evidence is a broad development agreement whose financial rewards rise with actual purchase volume.

The strategic logic is stronger than any single undisclosed chip. AI infrastructure now depends on networks, memory movement and storage as much as raw arithmetic. Adding another major custom-silicon partner can give Google supplier diversity, extra engineering capacity and negotiating leverage while allowing different components to be optimised for the TPU environment.

For large infrastructure buyers, my takeaway is that accelerator comparisons alone reveal less and less. The surrounding controllers, memory interfaces and interconnects increasingly determine cost and usable performance. Marvell has gained a potentially valuable route into Google’s stack, but it still has to convert joint development into billions of dollars in shipped products before the warrant structure becomes the commercial win its size suggests.

The FDA Studies Generative-AI Devices

The next policy question sits in a much less forgiving setting: healthcare.

On August 18, the US Food and Drug Administration released a discussion paper and opened a public docket on how medical devices using generative AI should be assessed and monitored. The consultation covers risk assessment, evaluation before a product enters the market, and monitoring after deployment. Manufacturers, clinicians, researchers, consumers and other interested parties can submit comments until October 19, 2026.

This is not a final rule, and it doesn’t create new binding requirements. There is also no timetable yet for binding regulation. What it does create is a formal point of influence while the FDA works through a difficult mismatch: conventional medical software is often evaluated as a comparatively fixed product, while a generative system can produce different answers to similar inputs and may change as its model, data or operating environment evolves.

Premarket evidence can still establish whether a device performs adequately under defined conditions. The harder question is what happens afterward. A generative system may encounter patient groups, clinical language and edge cases that weren’t adequately represented in testing. Its surrounding software can change, and monitoring may reveal failure patterns that only become visible at scale. That pushes postmarket surveillance and lifecycle controls closer to the centre of regulation.

The consultation gives medical-device developers a chance to argue for workable evidence standards before those standards harden. Healthcare organisations can also explain what monitoring information clinicians and safety teams would actually need in practice. Consumers have a stake as well, particularly in how changes are disclosed and how harmful outputs are identified after release.

My assessment is that developers should treat this docket as an early design signal, not wait for a final regulation before building traceability and post-deployment monitoring. Those controls may become expensive to bolt on later. At the same time, the FDA is asking questions rather than declaring answers, so organisations shouldn’t present the discussion paper as regulatory approval for a particular architecture or product.

Safety Monitoring Without Centralised Content

There’s a related privacy problem developing inside enterprise AI.

OpenAI has previewed an architecture called Private Safety Processing, intended to detect risky patterns across related interactions without making the underlying customer content accessible to OpenAI personnel. The design is aimed partly at Zero Data Retention deployments, where sensitive organisations want the model provider to avoid storing prompts and responses but safety systems may need a longer view of an agent’s behaviour than one isolated request provides.

Under the previewed approach, content for Zero Data Retention customers can remain on infrastructure controlled by the customer. OpenAI is also developing a storage option encrypted with customer-controlled keys. Automated systems would look for defined risks across related activity, then send OpenAI narrowly specified safety signals rather than the prompts and responses themselves.

That distinction could be important for agents. A single tool call may appear harmless while a sequence of calls reveals an attempt to escalate access, assemble dangerous material or evade a restriction. Conventional safety filtering often loses that context when every request is treated independently. Private Safety Processing is an attempt to preserve enough continuity for detection without turning centralised content retention into the price of safety monitoring.

The system is still being tested with early customers. OpenAI says rollout and a technical white paper are planned for September, so organisations cannot yet evaluate the full protocol, threat model or operational trade-offs. No independent security evidence has been published. There is also a specific exception: images flagged as potential child sexual abuse material remain subject to retention and manual-review obligations.

For sensitive organisations, the potential gain is meaningful. Strict data control and longitudinal monitoring may not have to be mutually exclusive. But this remains a preview, and its credibility will depend on the technical disclosure, the precision of those safety signals and whether customers can verify that content remains inaccessible as claimed.

My view is that privacy-preserving monitoring is newly worth serious evaluation for long-running enterprise agents, but not yet something to mark as solved in a risk register. The architecture has to survive scrutiny from customers whose reason for choosing Zero Data Retention is precisely that provider assurances alone are not enough.

Cerebras Refreshes Wafer-Scale Inference

On the hardware front, one specialised design is getting a serious refresh.

Cerebras has unveiled the WSE-3T accelerator and modular CS-4 rack systems, with the first CS-4 deployments expected later this quarter. Cerebras builds processors at wafer scale rather than cutting a silicon wafer into many conventional chips. That gives it an unusually large compute fabric aimed at keeping model work close together and reducing communication delays.

The company says WSE-3T doubles compute performance, memory-fabric performance and input-output performance while retaining the WSE-3’s manufacturing process, core count and SRAM capacity. A CS-4 system can hold three accelerator modules. Per-chip interconnect bandwidth rises to 2.4 terabits per second, and Cerebras reports that latency between chips has fallen from five microseconds to two.

Those details suggest the refresh is focused heavily on getting more useful work from the existing wafer-scale shape, particularly for inference where token-generation latency can be commercially important. Specialised decode hardware can complement GPU systems when an operator values fast responses and predictable movement of model state across processors.

The comparisons still need care. Cerebras’s headline figure of 250 petaFLOPS depends heavily on sparsity, meaning the system avoids calculations involving selected zero-valued or inactive elements. That can be useful, but it makes a simple comparison with dense-performance figures misleading. The company also hasn’t disclosed full-system power consumption, broad availability, pricing or production-scale results from a wide customer base.

For infrastructure buyers, the sensible judgment is that wafer-scale inference deserves a place in workload testing, particularly where latency dominates. It does not yet deserve a purchasing decision based on the largest number in the launch material. Real model throughput, power draw, software fit and total cost will determine whether CS-4 is cheaper or merely faster for a particular deployment.

Retries Prolong GitHub’s Outage

One more infrastructure lesson comes from a system that failed by trying too hard to recover.

GitHub’s report on its August 17 disruption attributes the incident to saturated load balancers, a faulty autoscaling policy and retry behaviour that prolonged Copilot’s recovery. The outage lasted seven hours and 47 minutes. At the peak, error rates for GitHub’s web and API traffic reached about 20 per cent, while archive and raw-content downloads experienced error rates of roughly 50 per cent.

The most revealing detail was inside the Copilot recovery. A latent retry bug in Visual Studio Code amplified requests to an internal Copilot endpoint by about ten times. GitHub’s Copilot Token Service normally handled between 7,000 and 9,000 requests per second. During the incident, that jumped to between 70,000 and 100,000 requests per second. A client behaviour intended to recover from failure instead supplied enough extra traffic to keep the service under pressure.

Retries are easy to treat as a reliability default: if a request fails, send it again. At platform scale, that logic becomes part of total system capacity. Immediate or poorly bounded retries can synchronise huge numbers of clients against the same unhealthy dependency. Backoff, randomness and limits aren’t implementation polish; they determine whether degraded service has room to recover.

GitHub says it plans to correct its autoscaling policies, audit limits in its service mesh, review retry behaviour and improve failover monitoring. The incident is resolved, but the dependency lesson remains for teams using GitHub Actions, APIs and Copilot. A platform outage can block builds, deployments and developer access even when an organisation’s own systems are healthy.

For developers and operations teams, my takeaway is to test what clients and automation actually do during throttling and partial failure. Contingency plans are useful, but retry behaviour deserves equal attention. A backup workflow won’t help much if every primary client is multiplying traffic into the same failing service, and a tenfold retry surge is ample evidence that recovery code belongs in capacity modelling.

What Changes for You

Before you get back to work, there’s one security update worth acting on immediately.

CISA says attackers are actively exploiting a critical vulnerability in Ray, the distributed computing framework used in many machine-learning environments. The flaw affects Ray releases earlier than version 2.52.0, and that version contains the fix. Developers running an affected release should upgrade immediately.

The attack is uncomfortable because the vulnerable Ray service doesn’t need to be openly exposed to the internet. A malicious website can use Firefox or Safari, combined with a technique called DNS rebinding, to make the victim’s browser send requests towards a Ray service on the developer’s machine or a nearby private network. Ray relied on a modifiable User-Agent check, and the attacker could reach unauthenticated job-management endpoints capable of executing commands.

In other words, the browser can become a bridge across a network boundary the developer assumed was protective. A service bound for local development or reachable only inside a private network is not automatically safe when it lacks genuine authentication. CISA gave US federal civilian agencies just three days to remediate, although it hasn’t publicly explained that unusually short deadline.

The relevant limitation is that public reporting hasn’t identified the exploitation campaign, its victim count or whether real attacks use the same browser path as the published proof of concept. That uncertainty is no reason to defer the update: active exploitation and a fixed release are both confirmed.

For anyone operating Ray, upgrade to 2.52.0 and review whether its management interfaces have authentication and tightly limited network access. The durable lesson for AI builders is broader than this patch. Local model servers, notebook helpers and distributed-compute dashboards are executable infrastructure, and a private address is not a security control when an attacker can borrow the browser sitting inside the perimeter.