Australia Backs Mandatory Tests for Frontier AI

The Test for Frontier AI Rules

Frontier AI companies are being asked to open their most capable models to outside testing before release. Australia wants that expectation to become mandatory.

Our main story today looks at Australia's support for an international frontier AI statement, and the gap between a shared diplomatic position and rules companies actually have to follow.

On 22 September, Australia joined other national leaders in calling for mandatory pre-deployment testing of frontier models, independent evaluation, shared reporting of serious safety incidents and common international standards. The statement also says these systems should remain under human direction, oversight and control. Australia’s Prime Minister said the country had played a central role in the initiative.

Frontier models are the highly capable, general-purpose systems near the leading edge of development. Testing before deployment is meant to find serious risks while a developer can still change how a model is released or controlled. Independent evaluation adds a second element: the people judging a system need enough access to examine it properly, rather than depending only on a company's own summary of its tests.

That access question will shape whether independent evaluation has any bite. The statement asks for sufficient access, but it doesn't spell out a common access regime. Governments still have to agree what evidence an evaluator can inspect, how results are compared and what follows when testing identifies a serious risk. Without that operational detail, independent evaluation could mean different things across markets.

The statement asks governments to coordinate standards and explore a United Nations-linked institution for standard-setting and verification. It also calls for shared reporting of serious safety incidents. That could give governments and evaluators a better view of failures that cross company or national boundaries, instead of leaving each incident inside one provider.

There is an important limit. This is a diplomatic statement, not binding law, and it remains open for more countries to endorse. It creates no immediate legal duty for a model developer to hand over evaluation access, report an incident or delay a release. We also don't know whether the proposed international institution will be created, which countries would join it or what enforcement powers it might receive.

For organisations building or buying frontier models, the signal is still useful. Governments are converging on an expectation that safety claims need evidence available to outsiders, and that serious incidents shouldn't stay private. Providers may need systems that preserve evaluation access and incident records across markets, even before legislators settle the details. Buyers could also start asking whether a model has been independently tested, what the evaluator could inspect and how failures are reported.

My read is that the wording is no longer the difficult part. The practical test is whether governments turn it into compatible evaluation and disclosure rules before model capabilities move again. If each country creates a different access regime, providers face duplication and evaluators get fragmented evidence. If the statement stays voluntary, its strongest verbs won't change release decisions. Australia's endorsement helps establish the direction; legislation, standards and enforcement will determine whether it has force.

Alibaba Builds Down the Stack

That policy push is arriving as major suppliers try to make advanced AI easier to buy as one integrated system.

Alibaba has laid out a roadmap covering its own chips, cloud infrastructure, Qwen models and agent services. The company says Qwen 4 is in training, with larger Qwen 4.5 and Qwen 5 models planned after that. It also unveiled the Zhenwu V900 accelerator and expanded its plans for agentic cloud services and smartphone agents.

The chip specifications are substantial on paper. Alibaba says the V900 has 216 gigabytes of memory, inter-chip bandwidth of 1,200 gigabytes per second and three times the performance of its predecessor. Commercial release is scheduled for the first quarter of 2027. Those are company claims. There are no independent benchmarks, price details or delivery results yet, so the V900 is a roadmap item rather than an available alternative today.

The model plans need the same restraint. Alibaba says future Qwen 4.5 and Qwen 5 systems could reach five to ten trillion parameters. Parameter count describes the scale of a model, not the quality of its answers or the cost of running it. Neither of those larger systems has been released. Alibaba is also targeting more than 20 gigawatts of global data-centre capacity by 2032, another long-range company target rather than installed capacity.

The more consequential idea is the shape of the offering. A customer could eventually get accelerators, cloud capacity, foundation models and agent services from the same supplier. That may reduce some integration work and let Alibaba optimise across layers, from hardware memory to the software serving a model. It also concentrates technical and commercial dependence in one stack.

For organisations assessing the roadmap, I’d pay more attention to delivered cost, availability and interoperability than the largest parameter number. An integrated supplier can make deployment cheaper or simpler when the pieces work well together. Until the chip ships and the planned models can be tested, though, the announcement shows Alibaba's intended position far more clearly than it shows real-world performance.

AI Scales an Old Phishing Trick

The next development is a reminder that AI can change the economics of an attack without inventing a new way in.

Microsoft and its partners have disrupted EvilTokens, a phishing-as-a-service operation linked by Microsoft to more than 12,000 compromised inboxes across over 10,000 organisations. Australia was among the countries with the highest victim activity. The operation seized 50 websites and disabled more than 150 associated domains, while British police confirmed two arrests to Axios. The investigation is continuing, and Microsoft's victim count remains an estimate.

EvilTokens abused Microsoft's legitimate device-code authentication flow. That flow is useful when someone needs to sign in on a device with limited input: a service displays a code, and the user authorises it from another browser. In this attack, the victim was persuaded to approve a session controlled by the attacker. The attacker didn't need to steal the victim's password because the victim granted access through the real authentication process.

The AI component came after access. Microsoft says the service analysed compromised inboxes, identified valuable targets and helped prepare financial fraud. That packaging matters. Work that once required an attacker to read messages, understand relationships and choose a target can be accelerated and offered as a service. Similar infrastructure could reappear under another operator even after these domains have been taken down.

For Microsoft 365 administrators, a password reset by itself doesn't resolve this attack path. Microsoft recommends blocking device-code authentication where it isn't needed, narrowly limiting exceptions where it is, and revoking sessions and tokens after a compromise. That last step is crucial because changing a password doesn't withdraw access already authorised through another route.

The useful security judgement here is quite specific: treat device-code access as an exception that needs an owner, not a harmless default. AI made the fraud easier to scale, but the control point is familiar identity hygiene. Removing an unused authentication path, and invalidating the access already granted when an incident occurs, does more than trying to detect whether a convincing message was written by a model.

A Runtime for Agents That Wait

Cloud infrastructure is also being redesigned around software that pauses, resumes and keeps a session alive for hours.

AWS has released the next generation of Amazon Bedrock AgentCore Runtime. It is a serverless environment for running agents inside isolated micro virtual machines, and the new platform changes how those sessions start and use memory. Existing AgentCore customers can select platform version V2 when they create or update a runtime.

The memory change is practical. The runtime allocates memory as an agent needs it, then reclaims memory during the session. On the previous design, billing could reflect the session's peak allocation even after the workload stopped using that peak. For an agent that spends long stretches waiting on a person, a tool or an external system, releasing unused memory could reduce the cost of keeping the session available. The actual saving will depend on the workload's memory pattern and AWS pricing.

AWS has also added snapshot-based starts. In its tests, images between 200 megabytes and two gigabytes recorded a seventy-fifth-percentile cold start of 1.9 to 2 seconds. The previous runtime took between 5.4 and 30 seconds in the comparison. Those figures come from AWS, so they describe its test conditions rather than a guaranteed result for every image.

Availability is limited to five regions across the United States, Europe and Japan. No Australian region is listed, which can affect latency, data-location decisions and whether an Australian organisation can use the service under its existing architecture.

For developers already on AgentCore, V2 is worth measuring with a real agent that has the same image, tools and idle periods as production. My broader read is that the design itself is revealing: cloud providers expect persistent agents to become an ordinary workload, and they are tuning infrastructure for time spent waiting as well as time spent computing. Faster starts and elastic memory make that pattern more economical, but regional availability and AWS dependence remain part of the decision.

Coding Agents Meet Robotics

That agent tooling is reaching beyond browsers and back-end services into machines that have to perceive and move through the physical world.

NVIDIA has released Isaac ROS 5.0, a free and open-source set of GPU-accelerated robotics tools. The release adds reusable skills and documentation structured so coding agents can help configure, adapt and deploy robotics applications. It supports ROS Lyrical and Ubuntu 24.04 across hardware ranging from Jetson Orin Nano to Jetson Thor.

ROS, the Robot Operating System, supplies common software components and interfaces for robotics development. A typical application still involves a lot of integration: sensors, perception models, hardware acceleration and task logic all need to fit the particular robot and environment. NVIDIA's new skills cover setup, fine-tuning a stereo model, and a pick-and-place workflow. That gives a coding agent more explicit procedures to follow instead of asking it to infer the structure of a specialised stack from scattered material.

The release also updates FoundationPose, NVIDIA's library for estimating and tracking an object's position and orientation. NVIDIA says inference can run up to 5.5 times faster. That number hasn't been independently verified, and actual performance will vary with the sensors, robot, scene and NVIDIA hardware in use.

The immediate gain for a robotics developer is less time spent assembling known parts of the toolchain. An agent may be able to apply a documented setup, adapt a model workflow or produce deployment configuration more consistently. The trade-off is that the accelerated path remains closely tied to CUDA and Jetson, even though Isaac ROS itself is open source.

I wouldn't read agent-ready documentation as evidence that a robot is ready for unsupervised operation. It can reduce integration effort; it doesn't validate how the finished system behaves around people, unfamiliar objects or changing conditions. Robotics teams still need application-specific testing. The useful shift is narrower and credible: better-structured tools can move coding agents deeper into physical-AI development, while responsibility for real-world behaviour stays with the engineers testing the machine.

Critical Check Point Flaws Under Attack

A shorter security item now, but one with an unusually small margin for delay.

Check Point says attackers are actively exploiting two critical vulnerabilities in its Security Gateway, Spark firewall and Security Management products. Both are rated 9.8 on the CVSS severity scale, both can be reached before authentication, and fixes are available.

The first, CVE-2026-85102, is a remote-code-execution flaw in the handling of VPN certificates. Check Point says exploitation attempts against Spark customers began on 12 September. The second, CVE-2026-93616, is a path-traversal flaw that can lead to arbitrary script execution and Java class loading. Check Point reports a handful of targeted attacks involving that issue.

Affected releases and the required hotfix level vary by product, and some end-of-support versions are included. Operators need to match the advisory to the exact appliance and software release, install the applicable fix immediately, then inspect authentication and management logs for suspicious activity. Perimeter placement doesn't compensate for a pre-authentication flaw in the device guarding that perimeter.

Check Point's telemetry establishes observed exploitation, but it doesn't yet identify the responsible actors, the full victim count or the wider impact. My judgement for operators is still straightforward: patch delay is especially risky when the target is security infrastructure and an attacker doesn't need valid credentials to reach the vulnerable code. Apply the product-specific fix, and check whether someone arrived before it.

Two More GPT-6 Choices in Copilot

Back at the developer's desk, GitHub is widening the model picker rather than presenting one GPT-6 option for every job.

GitHub has begun adding OpenAI's GPT-6 Sol and GPT-6 Luna to Copilot. GitHub positions Sol as the balanced option for multistep coding work, while Luna is the lowest-cost GPT-6 choice. Sol is available to Copilot Pro+, Max, Business and Enterprise customers. Luna also comes to the standard Pro plan.

Both models use usage-based billing and can be selected across major IDEs, the Copilot command-line interface, GitHub's cloud coding agent and GitHub.com. Organisation administrators keep control over which models users can select. The rollout is gradual, so an eligible account may not show either model immediately.

GitHub hasn't provided an independent, task-level comparison in the announcement. That leaves the useful questions to actual project work: whether Luna is reliable enough for routine edits, whether Sol completes a larger change with fewer corrections, and what each completed task costs once retries are counted.

More choice can lower cost when a lightweight model handles ordinary work well. It also shifts evaluation onto development organisations. My practical take is to choose by task class, not by model name: a team needs evidence about which option can pass its own tests and review for a given kind of change. Without that, a cheaper run can become an expensive loop of retries, while a more capable model may be unnecessary for a contained edit.

What Changes for You

One model release is immediately usable and changes the price calculation for long-running coding agents.

Anthropic released Claude Opus 5.5 on 22 September, and developers can use it through Claude or the API. GitHub is also gradually rolling it out to Copilot Pro+, Max, Business and Enterprise customers under usage-based billing. GitHub says text produced by the model in Copilot is watermarked.

The API list price is four US dollars per million input tokens, 20 US dollars per million output tokens and 20 US cents per million cache-read tokens. Anthropic says input and output prices are 20 per cent lower than Opus 5, while cache reads are 60 per cent lower. Cheaper cache reads are particularly relevant to agents that repeatedly reuse a large project context across many steps.

There is a catch in Anthropic's own guidance: Opus 5.5 always reasons before it replies and can consume more tokens. A lower rate per token doesn't guarantee a lower bill for the completed task. Reasoning effort, cache behaviour, the number of turns and failed attempts all affect the result, and Anthropic's capability and efficiency comparisons remain vendor claims.

For developers who can access it, the useful change is the ability to test a newer Opus model at lower list rates without waiting for a future release. Compare the cost of a finished job, including retries, rather than the price of one request. If Opus 5.5 completes long agent work in fewer turns and reuses cached context effectively, the saving could be meaningful. If it thinks longer without improving completion, the cheaper token price may disappear inside higher usage.