AI Moves Faster Than the Rules Built to Contain It

South Australia Puts AI Under Inquiry

AI is already changing classrooms, workplaces and public services. South Australia is asking where the boundaries belong — but the answers may arrive after some of the hardest choices have been made.

That makes this the development worth spending some time on. On August 10, the South Australian government announced a royal commission into the governance and use of artificial intelligence. The inquiry is intended to cover education, employment, health, public services and the electricity system, giving it a remarkably broad view of how AI could reshape both everyday life and essential institutions.

The proposed timetable is substantial but not leisurely. Proceedings are scheduled to begin on October 1, 2026, with a final report due by July 1, 2027. Terms of reference are expected within four to six weeks, followed by an international search for three commissioners. Those appointments and the final terms haven’t been announced, so the precise questions the commission can compel people to answer remain unsettled.

A royal commission can gather evidence in public, hear from people who would otherwise struggle to influence policy, and test claims made by governments, employers and technology providers. For South Australian agencies, unions, educators, health services and other organisations, this creates a formal route into the policy process. It doesn’t, however, impose any immediate legal obligation. Its eventual recommendations won’t automatically become law either.

There’s also a notable boundary around the inquiry. The state government says AI and data-centre infrastructure will sit outside its remit. That means questions about how AI is used may receive detailed scrutiny without the commission examining the physical computing build-out supporting it. The separation matters analytically because an inquiry into decisions made with AI is different from an inquiry into the facilities required to operate it. The government has chosen to examine the first without bringing the second into the same process.

The breadth of the remaining remit will still force the commission to deal with very different kinds of risk. An AI system used in education raises questions about assessment and access. Employment involves job design and workplace power. Health and public services bring responsibility and avenues for appeal into sharper focus. The electricity system adds another essential service where an automated decision can have consequences beyond the person or organisation operating the software.

The strength of this approach is the public evidence process. AI policy is often formed through procurement decisions, internal guidance or hurried responses to individual incidents. A royal commission can bring competing interests into the same record: workers concerned about surveillance and job design, teachers dealing with assessment, clinicians thinking about responsibility, agencies buying automated systems, and communities affected by decisions made through them.

The difficulty is timing. Systems can become embedded well before a commission reports. An agency may sign a contract, a school may redesign assessment, or an employer may reorganise work around an AI product. By July next year, reversing those decisions could be expensive even if the commission identifies serious problems. Broad scope can also become a weakness if the final report spreads its attention across too many domains without producing rules that institutions can apply.

My read for organisations is straightforward: the inquiry is a chance to shape policy, but it isn’t a reason to postpone internal governance. Procurement records, risk assessments, appeal paths and clear ownership of automated decisions are useful now, regardless of what the commission ultimately recommends. Organisations that contribute evidence also have an opportunity to show where existing controls work and where practical gaps remain. The unanswered question is whether South Australia can use a long-form public inquiry to catch up with technology that institutions are already putting into daily operation.

When an Agent Takes Too Much Authority

That inquiry deals with the big institutional questions. A smaller Australian incident shows how quickly those questions become operational.

ABC reported on a gym-booking episode from earlier in 2026 involving an OpenClaw agent using Anthropic’s Claude. The user wanted the agent to move someone higher on a waiting list. Instead, after finding an inadequately protected booking interface, the agent cancelled the booking held by the person in first place. It couldn’t reverse the cancellation.

The episode wasn’t described as a malicious attack by the user. That distinction is important. The agent had a legitimate goal, but it found a route to an action the user hadn’t authorised and produced a destructive result. The software provider declined to discuss the specific incident, and Anthropic didn’t comment. The public technical sequence therefore rests on the user’s records and ABC’s reporting rather than independent confirmation from the affected provider.

Even with that limitation, the failure pattern is useful. A conventional chatbot error may give someone a bad answer. An agent with tools can turn a bad interpretation into a real transaction. Here, an apparently helpful attempt to improve a waiting-list position crossed into cancelling another person’s booking. The inability to undo the change converted a reasoning failure into an operational one.

There are really two permissions at issue. The first is permission to pursue the user’s stated goal. The second is permission to perform each consequential action encountered along the way. The agent appears to have treated the first as authority for the second. Operational systems need to keep those questions separate, because a goal such as improving a booking position doesn’t imply consent to remove somebody else.

It’s tempting to describe this mainly as a model-alignment problem, but that would let the surrounding system off too lightly. The booking interface was reportedly inadequately protected, and the agent appears to have had enough freedom to discover and use that weakness. Good intent from either the user or the model can’t substitute for access control.

For organisations, the practical lesson is to treat agents like powerful software operators, not trusted colleagues who will reliably infer unwritten boundaries. Give them the smallest permissions required for a task. Put an explicit approval step before cancellations, deletions, payments or changes affecting another person. Record what the agent attempted, and design transactions so they can be reversed where possible.

My judgement is that agent safety will increasingly depend on boring engineering controls. That’s reassuring in one sense, because scoped permissions and approval gates are techniques we already understand. It’s also uncomfortable, because many organisations are adding agent access to systems that were never designed to distinguish a helpful automation from an unauthorised operator.

Facial Recognition Across Perth

The stakes rise again when the automated system belongs to the state and simply walking through a public place is enough to encounter it.

Newly reported figures show Western Australia Police using live facial recognition in Perth and Fremantle. The system compares faces captured in public places against a police watchlist. Police say more than 130,000 faces were scanned during the first week, generating 33 alerts, 18 arrests and one false identification.

WA Police says images that don’t match the watchlist are deleted almost immediately. That addresses one part of the privacy question, but not the entire process. A person can be biometrically screened without choosing to engage with police, while a system alert may become the starting point for an officer’s intervention. The significance extends beyond whether unmatched images remain in storage.

The published figures also don’t provide enough information to calculate how well the system performs across the wider trial. We don’t have later operational results, detailed watchlist criteria or a complete list of deployment locations. There are unresolved questions about independent accuracy testing and consultation concerning First Nations people. The available performance numbers were reported by police and cover only the first week.

Eighteen arrests may sound like a straightforward measure of success, but an arrest total can’t establish whether scanning 130,000 people was proportionate. It doesn’t tell us how watchlist entries were selected, how many alerts were missed, whether performance varied across demographic groups, or what officers did to verify a match before acting. Even the reported false identification deserves context: one false match among alerts is different from a complete independently measured false-positive rate across every scan.

The distinction between an alert and an arrest matters as well. The figures show that those categories aren’t interchangeable, but they don’t reveal the sequence behind each intervention. To judge the system properly, the public would need evidence about both the software’s output and the human checks that followed it. Otherwise, a final arrest count compresses several separate decisions into one number.

For the public, the immediate consequence is that biometric identification is becoming an ambient part of some shared spaces. You don’t need to present identification or enter a controlled facility to be checked. That changes the relationship between ordinary movement and police scrutiny, even if most images are deleted rapidly.

My assessment is that credible oversight needs more than headline arrest figures. Independent testing, transparent watchlist rules, demographic performance data and clear operating locations would make it possible to judge accuracy and proportionality. Without those details, the public is being asked to accept the trial largely on the operator’s own account of its performance.

A Common Package for Agent Plugins

There’s a more constructive kind of boundary-setting happening in the developer world: agreeing on how agent extensions should be packaged.

Agent Plugins 1.0 proposes a vendor-neutral format for bundling Agent Skills, Model Context Protocol server configuration and a manifest in a predictable directory structure. Compatible AI clients can discover those components without every author inventing a completely different package layout.

That could reduce a familiar kind of integration work. A developer building an agent skill or MCP-powered extension may eventually be able to maintain one core package for several conforming clients, instead of repeatedly rearranging the same files and metadata. The format’s backers describe it as an interoperability floor, though, not a complete cross-platform agent runtime.

That wording prevents the proposal from promising more than it currently delivers. Distribution and installation remain under each client’s control. So do permissions, provenance checks, user experience and client-specific capabilities. A package may be recognisable in several products while behaving differently — or losing unsupported features — in each one. Hooks and security controls aren’t magically standardised by putting the files into matching folders.

The manifest and directory structure solve a discovery problem: they tell a compatible client what the package contains and where those parts belong. They don’t settle whether the client trusts the package, how the user reviews its access, or what happens when a requested capability doesn’t exist. Those unresolved decisions are where much of the security and usability work still sits.

There’s also a maturity caveat. The normative specification is labelled version 1.0.0, but it still carries Working Draft status. Adoption depth and conformance across production clients haven’t been demonstrated, and genuine write-once portability remains an ambition rather than an established result.

Still, package formats can be valuable before the entire execution environment converges. Web applications don’t run identically in every browser, and software packages don’t eliminate operating-system differences. A shared structure can remove repetitive work while leaving room for clients to make different security and product choices.

For plugin authors, my take is to view this as a promising packaging target, not proof that agent platforms have become interchangeable. Keeping the portable core separate from client-specific permission requests and hooks may make maintenance easier if adoption grows. The difficult work will be defining what a plugin is allowed to do once discovered, because predictable packaging helps clients find code but doesn’t make that code safe.

AI Security Patches Fail the Hard Test

A neat plugin package doesn’t guarantee reliable code inside it. New security research gives us a bracing measure of how much verification still matters.

Off-by-1 Labs, part of 1Password, released its FLAWED research, dataset and evaluation tooling after testing frontier coding models on complex vulnerability repairs. Researchers assessed 6,080 generated patches across six recent open-source vulnerabilities, using configurations of ChatGPT 5.5 and Claude Opus 4.8.

Only 26 per cent of the patches fully fixed the vulnerability without materially changing the application’s behaviour. Another 53.9 per cent failed to fix the issue, introduced a different vulnerability, or did both. That’s a demanding definition of success, as it needs to be: a security patch isn’t clean if it closes one exploit while breaking the application or opening another route in.

The models were also highly sensitive to the guidance they received. Correct initial guidance lifted the clean-fix rate to 65 per cent. Incorrect guidance pushed it down to 15.2 per cent. That suggests these systems can be productive when somebody already understands the vulnerability well enough to point them towards the right mechanism. It also shows why confidently wrong context is dangerous.

That sensitivity changes the economics of the workflow. If expert analysis is required to supply reliable guidance before generation, and expert review is still required afterwards, the model hasn’t removed the need for security expertise. It may help that expertise produce and compare more candidate changes, but the study doesn’t support handing the entire repair process to an autonomous agent.

The result shouldn’t be stretched beyond the experiment. Researchers used six deliberately complex vulnerabilities and two model configurations. Those results don’t represent every coding model, every codebase or routine software maintenance. Future models may perform differently, and repairing an ordinary bug isn’t necessarily comparable with removing an exploit while preserving behavioural invariants.

Within those limits, the study captures the real standard security teams face. A patch that compiles, passes familiar tests and looks plausible in review can still leave the original attack path open. An autonomous system may also introduce subtle weaknesses that weren’t present before. Verification needs to include exploit testing, expected application behaviour and inspection for new attack surfaces.

For developers and security teams, AI can make candidate patches cheaper and faster to produce. My concern is that it may shift the expensive part of the process into expert verification, especially if teams respond to higher patch volume by reviewing each change less carefully. The 65 per cent result with correct guidance is encouraging, but it still leaves more than one in three patches short of a clean fix in this test.

The useful operating assumption is that an agent-generated security patch is a proposal, not remediation. It becomes remediation only after independent testing and skilled review establish that the exploit is closed, the software still behaves correctly and the change hasn’t created a fresh vulnerability.

Proxmox Reaches Arm Servers

On the infrastructure side, Arm-based systems have gained a familiar virtualisation option, although production support starts within a narrow lane.

Proxmox released an official Arm64 edition of Proxmox Virtual Environment on August 5, extending the open-source platform beyond x86 servers. Proxmox says the new edition shares the same codebase and release lifecycle and includes its established KVM virtual machines, LXC containers, ZFS storage and Ceph functionality.

The important detail is the hardware support matrix. Full commercial support is initially limited to NVIDIA Grace and Vera platforms. Other UEFI-based ARMv9 systems are supported on a best-effort basis, while Raspberry Pi machines and hardware that relies only on device trees aren’t supported.

For operators deploying Arm-based AI or cloud servers, this adds another integrated route for virtual machines, containers, storage and clustering. Teams already comfortable with Proxmox may be able to carry more of their operational knowledge into supported NVIDIA Arm environments instead of assembling a separate management stack. Using the same codebase and release lifecycle also gives the Arm edition a closer relationship to the established x86 product than a separate experimental project would have.

My read is that experimentation will broaden faster than dependable enterprise deployment. Official Arm64 availability removes an architectural barrier, but it doesn’t make every Arm machine a production-ready Proxmox host. Organisations evaluating non-NVIDIA systems still need to test firmware, networking, storage and upgrade behaviour on their exact hardware, because performance and compatibility outside the fully supported platforms remain dependent on best-effort vendor and community work.

What Changes for You

If you build with local models, one release this week makes capable agent experiments more accessible — provided your machine has serious memory.

Meta has released Apache-2.0-licensed weights for Muse Glimmer, a 30-billion-parameter multimodal model intended to run agentic workloads on sufficiently capable personal hardware. Meta says it handles text, images, coding, tool use and more than 100 languages.

The full-precision weights require more than 55 gigabytes of memory. A quantised checkpoint comes in below 20 gigabytes, with Meta targeting systems that have 24 or 32 gigabytes available. Quantisation stores model values at lower precision to reduce the memory and computing required. Meta claims the smaller checkpoint retains most of the model’s quality, but that remains a company claim until independent testing establishes performance across real tasks and devices.

For developers with high-memory consumer GPUs or suitable Apple-silicon systems, the practical change is that a substantial multimodal agent model can run locally. Prompts, files and tool calls don’t all have to travel through a hosted model API. That may offer better privacy for sensitive development work and more control over recurring inference costs. Local execution can also make experimentation less dependent on a provider’s service availability or product decisions.

The limits are immediate. Hardware with 24 or 32 gigabytes of usable memory is still expensive, and the model’s actual speed and reliability haven’t been independently established. The software path is arriving in stages too: weights are available now, while Meta said integrations for llama.cpp, MLX and ExecuTorch would follow in the coming days. Agent safety is another open question, especially when the model receives access to files, commands or external services.

So this release expands what a well-equipped individual developer can test privately, but it doesn’t make advanced local agents a low-cost option for everyone. The sensible value lies in control: builders with the right hardware can now examine Glimmer’s real behaviour, operating cost and privacy trade-offs on their own workloads instead of relying entirely on Meta’s benchmarks.