Australia prepares national AI infrastructure laws for 2027

Australia’s AI Infrastructure Rules

Australia is preparing to regulate AI as heavy infrastructure, with national rules intended to stop data centres from straining water supplies or pushing up household power prices.

That’s the development worth staying with, because the argument is no longer confined to models, copyright or automated decisions. It now reaches electricity generation, transmission capacity, water systems and the physical location of enormous computing facilities.

After the National Cabinet meeting on 26 August, Prime Minister Anthony Albanese said state, territory and federal leaders had agreed to develop national artificial-intelligence laws for Commonwealth legislation in early 2027. The proposed standards are meant to address data-centre energy and water use, effects on power prices, and where facilities can be built.

That gives the industry a regulatory horizon, but not yet a rulebook. Another leaders’ meeting is expected before legislation reaches Parliament. Compliance thresholds haven’t been published, there’s no settled treatment for existing projects, and potential differences between jurisdictions remain unresolved.

Energy policy is the most visible open question. A uniform renewables-only requirement didn’t survive the final National Cabinet position. Queensland and the Northern Territory secured flexibility over the generation mix used to support data centres, including the ability to rely on coal or gas. That compromise preserves room for different state energy systems, but it also means developers can’t assume one national technical standard will produce one national energy model.

The government’s stated objective is important: new computing demand shouldn’t weaken water or energy security, and households shouldn’t absorb higher electricity prices simply because large data centres need more power. Delivering that result will be difficult. A standard may need to distinguish between projects that bring new generation and transmission capacity, projects that consume existing spare capacity, and projects built in regions where either water or electricity is already constrained. None of those details is available yet.

For developers and energy planners, the immediate consequence is uncertainty rather than prohibition. Projects with long construction and connection timelines now have to account for federal legislation expected next year, even though the tests governing siting, resource use and energy supply haven’t been settled. Designs that appear viable under current state rules could face additional national conditions.

My read is that Australia has crossed an important conceptual line. AI policy is beginning to treat computation as an industrial load with consequences outside the server room. That creates a real opportunity to protect households and coordinate infrastructure investment. It also leaves investors carrying near-term design risk until governments publish measurable standards, transition arrangements and any jurisdictional carve-outs.

TRACE and Verifiable AI Evidence

That Australian framework is still being negotiated. The shorter stories today show the kinds of systems future rules and audits will have to examine.

The Linux Foundation has accepted TRACE, an open specification for producing verifiable evidence about how an AI workload actually ran. TRACE was developed with AMD, Intel, Microsoft, OPAQUE and the Technology Innovation Institute, and it now sits under vendor-neutral governance.

The core idea is to create a portable, cryptographically verifiable record that binds together the runtime environment, software, policies, data classifications and tool use involved in an execution. Hardware attestation provides evidence about the machine and trusted environment, while the broader artifact records the controls and components surrounding the workload.

That’s a meaningful step beyond asking an organisation to retain ordinary logs or provide a policy document. Logs can be incomplete, editable or separated from the hardware that produced them. An attested record is intended to let another party check whether a particular workload ran in the declared environment under the declared controls.

TRACE isn’t trying to replace the security standards already in use. It composes work including RATS for remote attestation, EAT for attestation tokens, SLSA for software supply-chain integrity, SCITT for transparent statements, SPIFFE for workload identity and EAR for appraisal results. That approach may make integration more practical, although it also means an implementation depends on several supporting layers being configured correctly.

The limitation is maturity. The initial specification targets current agent architectures, but broad interoperability across clouds, confidential-computing systems and verification tools hasn’t been demonstrated. Regulators also haven’t established that TRACE evidence will satisfy their requirements.

For organisations putting agents near sensitive data or consequential tools, my assessment is that TRACE is worth evaluating as an audit format, not treating as a finished compliance solution. Its larger contribution is the shift from assurances about agent behaviour toward execution receipts that an independent verifier can check. The hard work now is making those receipts interoperable and useful during a real investigation.

Salesforce Opens Business Actions to Agents

A verifiable record helps after an agent acts. Salesforce is working on the equally difficult problem of deciding what an outside agent may do in the first place.

Salesforce has expanded Headless 360 with Model Context Protocol servers, reusable agent skills and interfaces designed for software rather than a human-operated screen. Authorised agents running through platforms including Claude, ChatGPT and Cursor can discover and invoke Salesforce business capabilities.

The Headless 360 MCP Server is in open beta. The Data 360 MCP Server and expanded Data 360 API coverage are generally available, with the server exposing nearly 200 APIs. Salesforce also says its reusable-skills repository contains more than 100 skills.

MCP gives an agent a standard way to discover tools and send structured requests. In this case, those requests can reach CRM and data operations that a company already uses. Salesforce says actions inherit existing identity controls, permissions, validation rules, workflows and governance. If that works as intended, a company doesn’t have to recreate every business integration for every new agent client.

The attraction is straightforward. A sales or service workflow built in Salesforce could become available to several agent interfaces while the underlying platform continues to enforce access. The same employee permissions and business rules can, in principle, follow the action whether it began in Salesforce itself or through an external assistant.

But inherited governance also means inherited mistakes. An overly broad permission, stale customer record or brittle validation rule doesn’t become safe because the request arrived through MCP. Agents can perform actions more quickly and at greater volume than a person clicking through a screen, so weaknesses in identity design and business metadata may become more consequential.

Several components remain in beta, and pricing, packaging and regional availability vary. Salesforce’s claims about reliability, security and productivity also haven’t been independently established at scale.

For Salesforce customers, the practical judgement is that MCP can reduce duplicated integration work, but permission reviews become part of agent engineering rather than routine administration. The quality of the automation will depend less on whether the model can call a tool and more on whether the organisation has defined that tool, its data and its authority precisely.

Gitea Flaw Under Active Exploitation

Here’s the security item I wouldn’t leave sitting in an update queue.

CISA added CVE-2026-60004, a critical Gitea vulnerability, to its Known Exploited Vulnerabilities catalogue on 25 August after exploitation was identified. Versions before Gitea 1.27.1 are affected, and that release contains the fix.

Gitea is commonly used to host Git repositories on an organisation’s own infrastructure. According to the project’s security advisory, the vulnerability enables remote code execution through installation of a Git hook using diffpatch functionality. Git hooks are programs triggered by repository events. If an attacker can install one on the service, an operation that appears to concern source-code changes can become code execution on the hosting system.

The GitHub advisory gives the flaw a critical CVSS score of 9.8. The Canadian Centre for Cyber Security has directed administrators to apply available updates. Public advisories don’t disclose the number of compromised systems, the organisations targeted or the attackers’ objectives, so there’s no reliable basis for estimating the campaign’s scale.

That absence of detail shouldn’t be mistaken for a low-risk event. Entry in CISA’s exploited-vulnerability catalogue means administrators have evidence of use outside a controlled demonstration. An exposed Gitea server may also hold valuable source code, deployment credentials, automation tokens and trusted connections to build systems. The repository service is therefore an execution boundary, not merely a place where files are stored.

Operators should move to 1.27.1 or later immediately. They also need to examine internet-exposed and otherwise reachable systems for signs of compromise, because installing the patch closes the vulnerability but doesn’t remove access an attacker may already have established. Relevant evidence may include unexpected hooks, processes, accounts, scheduled activity and changes to credentials or automation.

My assessment for organisations running Gitea is blunt: treat this as incident-response work, not ordinary maintenance. Self-hosting provides control, but it also leaves the operator responsible for the security boundary around the code, credentials and machines that the service can reach.

Managed Ray on SageMaker HyperPod

From a compromised cluster boundary to the everyday challenge of keeping expensive compute working.

AWS has added managed Ray capabilities to SageMaker HyperPod clusters orchestrated by Amazon EKS. The release covers interactive development, observability, fault recovery, distributed training and inference through Ray Serve.

Ray is an open-source framework for distributing Python and machine-learning workloads across a cluster. Developers can now create and monitor Ray clusters through SageMaker Studio, then connect with JupyterLab, Code Editor or a local development environment. AWS says standard open-source Ray code can run unchanged.

The operational features are the interesting part. The service includes Grafana-based observability, automatic recovery of failed nodes, detection of hung jobs and tiered checkpointing. Checkpoints preserve workload state so a failed training run can resume without starting from the beginning. For inference, AWS has also added tiered key-value cache support, which is intended to manage the cached attention state used when serving language models.

Those features target an expensive problem. A distributed job may occupy many accelerators, yet a single failed node or stalled process can leave the wider cluster idle or force substantial work to be repeated. Cloud providers can differentiate themselves by recovering workloads and maintaining useful accelerator time, not simply by listing available GPU types.

There are clear boundaries. The managed capability applies to HyperPod clusters running on EKS and only in supported AWS regions. AWS hasn’t published independent cost comparisons or quantified real-world utilisation improvements. Teams also remain responsible for assessing whether the additional managed layer and associated cloud services justify their cost.

For developers already committed to Ray and AWS, this could remove a useful amount of Kubernetes, monitoring and recovery work. My read is that the trade is operational simplicity for deeper platform dependence: open-source Ray code may remain portable, while the surrounding recovery, observability and inference workflow becomes increasingly specific to AWS. That’s acceptable when failure recovery saves enough accelerator time, but it needs to be measured against an actual workload rather than assumed from the feature list.

Chrome’s 327-Fix Security Release

A browser update containing hundreds of fixes deserves more attention than the usual restart reminder.

Google promoted Chrome 152 to the stable desktop channel on 25 August with 327 security fixes, including ten vulnerabilities classed as critical. The release is rolling out across Windows, macOS and Linux over the following days and weeks.

SecurityWeek counted 299 internally discovered issues and reported that most were found through Google’s AI-assisted security process. Google’s own advisory lists the critical vulnerabilities but is withholding some technical detail until the update has reached most users. Neither source reports exploitation in the wild.

The size of the release doesn’t mean every user faced 327 equally reachable attacks. Vulnerabilities differ in trigger conditions, affected components and the protections an attacker would need to bypass. Still, the critical findings include memory-safety and authorisation problems in a program that routinely processes untrusted content from the internet.

AI-assisted bug discovery is the notable development here. Automated analysis can help defenders find more flaws before attackers do, but higher discovery throughput creates more patching work for device fleets. Finding a vulnerability doesn’t protect a browser that hasn’t installed the fix and restarted into the new version.

For individual users, the useful action is to let Chrome complete the update and restart promptly. Managed-device administrators should verify deployment rather than relying only on the rollout beginning. My interpretation is that AI-assisted security research makes fast update operations more valuable, not less: defensive tools can increase the supply of fixes, while protection still depends on getting those corrected binaries onto real machines.

IBM’s Dual-Architecture Mainframe Chip

Now for a processor design that sounds unusual even by mainframe standards.

IBM has announced a future chip for IBM Z and LinuxONE whose individual cores are designed to execute Arm-native instructions and IBM mainframe instructions concurrently. The aim is to run Arm-native Linux environments beside z/OS or Linux on IBM Z without dedicating a separate group of cores to Arm workloads.

IBM says the 2-nanometre design will contain 11 cores running above 5.7 gigahertz, along with AI inference accelerators and a dedicated data-processing unit. Those are design targets for a future processor, not specifications from a shipping product. IBM hasn’t provided a product name, release date, price or independently verified performance results, and it warns that the direction may change.

The software consequence could be more important than the headline architecture. Arm has a large and growing ecosystem across cloud services and AI infrastructure. Mainframes, by contrast, remain valuable where organisations need high transaction volumes, reliability and compatibility with long-lived systems. Running both instruction sets on the same cores could let customers bring more Arm-native software close to existing data and transactions without moving the critical system itself.

There are plenty of unanswered technical questions. IBM hasn’t shown how concurrent execution will affect performance isolation, scheduling, licensing or operational management. Nor do we know how much of the wider Arm software ecosystem will be supported in practice. A processor can execute an instruction set while the surrounding platform still determines which operating environments and applications are viable.

If IBM delivers the design, the strategic move is clear enough: modernise the mainframe by bringing a broader software ecosystem into the machine rather than asking regulated customers to replace their core platforms. For those customers, that could make some cloud-native and AI workloads easier to place beside transaction systems. Until IBM provides shipping hardware and measured results, though, this is a direction to watch rather than a platform decision to make.

What Changes for You

One release this week puts autonomous browser work within reach of many more people, along with a security trade-off that’s hard to ignore.

Anthropic has made Claude in Chrome generally available on every paid Claude plan. The extension can read and type on web pages, move between pages, click links and fill forms using the logins already active in the browser. It can now approve some actions automatically when a safety classifier determines that they match the user’s request.

That changes what a paid Claude user can delegate on websites that don’t provide an API. A task spread across several tabs and older web interfaces can be handled inside the authenticated browser rather than through a custom integration. Users can disable automatic approvals, and enterprise administrators can restrict the extension to approved domains.

The central limitation is prompt injection. A malicious or compromised page can contain instructions intended for the agent rather than the person viewing it. Anthropic says its probes and classifier stopped all tested attacks against Sonnet 5 and Opus 5, but the company also describes prompt injection as a moving target. These are Anthropic’s evaluations against known tests, not evidence that future attacks can’t succeed.

Platform support is narrower than the name may suggest. The extension doesn’t work on mobile or other Chromium-based browsers, and tasks involving local files still require the Claude desktop application.

For routine research and low-risk web administration, the new availability can remove real manual work. My practical judgement is to keep manual approval or tight domain restrictions around banking, administrator consoles, sensitive customer systems and other valuable sessions. The benefit comes from letting an agent act with your existing access; the risk comes from exactly the same place.