AI agents are breaking into real websites. Who's watching the quieter ones?

Agent attacks reach real websites

A product-support website can become part of an AI-assisted hacking campaign, even when it isn't the business's main service. Researchers have now watched agents attacking live sites, including targets in Australia.

Our main story today is the Cairn hacking campaign, and what persistent automated attacks mean for the websites organisations can too easily overlook.

Research published by NorForge and reporting from Reuters on 19 October describe criminals using the Cairn agent framework to sustain intrusions against real businesses. An agent framework gives a model tools and a way to keep working through a task, rather than stopping after a single answer. Here, that capacity was being directed at websites without their owners' permission.

NorForge found more than twenty exposed dashboards associated with likely malicious activity. Those dashboards gave researchers a view into the operators' workflows. In one case, NorForge directly confirmed a successful intrusion by checking that a web shell had been uploaded. That's software that can give an attacker a way to issue commands through a compromised website.

The larger numbers come from researcher Snorre Fagerland. According to Reuters, he assessed that one operator's agents had attempted more than twelve hundred websites and compromised over a hundred. Reuters independently reviewed the activity to identify affected businesses. It did not independently confirm every victim in that total, and it couldn't establish how much data had been extracted.

That distinction changes how we read the campaign. An attempt, a successful foothold and a confirmed theft of sensitive information are different outcomes. The evidence includes a directly checked intrusion and identified affected businesses. It doesn't support treating every reported compromise as a proven major data breach.

The company responses show why that precision matters. Deere said it had no indication sensitive information was accessed. SharkNinja said an affected product-support site had been contained. Cummins was investigating a potential attack on a third-party vendor's website. Those are different statements about different situations, not interchangeable confirmations of the same damage.

For an Australian business, the uncomfortable detail is the range of websites involved. The main customer-facing website isn't necessarily the only place that needs attention. A support site or a supplier-operated website can sit outside the systems that get the most scrutiny, while still carrying the business's name or serving its customers. The reporting doesn't establish how every affected site was maintained. It does make those less-visible services relevant to the threat.

My reading is that the operational change is persistence. If one operator can keep agents working across many targets without personally supervising every step, the amount of probing they can sustain increases. That doesn't require us to assume the agents have discovered some entirely new kind of vulnerability. More sustained attempts can be consequential on their own.

It also puts a practical question between a business and its service provider: who is watching the website while it's running, and who responds when something changes? A vendor's involvement doesn't answer that question automatically. Neither does a familiar company name on the page.

There are uncertainties around the models used and estimates of token spending, so I wouldn't build a budget comparison around the campaign. The firmer conclusion for organisations is narrower and more useful: attention to small, externally facing services has become harder to defer when attackers can keep trying at this scale.

Perplexity opens its agent sandbox

That's the challenge for website owners; a separate release from Perplexity tackles where legitimate agents are allowed to work.

Perplexity has open-sourced SPACE, the execution environment behind its Computer agent. The release, reported on 15 October, gives developers an implementation they can inspect and adapt, including isolation and recovery features that would otherwise need to be built or sourced separately.

Each sandbox runs in its own virtual machine. A sandbox is a confined place for software to execute; the virtual machine provides a boundary between that work and the underlying host. Perplexity also keeps platform-held credentials and network controls outside the agent's workspace.

That separation is an important design choice. Instructions tell an agent what it's allowed to do. Controls outside its workspace govern what it can reach. Asking a model to respect a restriction and preventing it from changing that restriction are different engineering jobs.

The testing account makes the distinction unusually tangible. Perplexity reports no guest-to-host escape in a hundred and eight attempts. In plain terms, those tests didn't find an agent breaking out of its virtual machine into the host. But agents initially bypassed network restrictions. Perplexity says it fixed the identified weaknesses and they didn't recur in follow-up tests.

Both results belong in the same assessment. A virtual-machine boundary can hold while another boundary fails. And the follow-up result describes the company's tests, not proof that every escape method or deployment mistake has been eliminated.

SPACE also supports checkpoints, pausing and resuming work, and branching. Those features have a different sort of value: an agent's progress can be retained, interrupted or taken in another direction without treating every run as disposable. For developers dealing with longer tasks, recovery becomes part of the environment rather than something bolted onto each application.

I see the useful opportunity here as reducing the amount of infrastructure an agent-platform team has to invent. There is now concrete code to examine for isolation and state recovery. The security work still includes checking whether a particular deployment enforces its intended network and credential boundaries. The published test results show exactly why those deserve separate attention from the model's behaviour.

G7 plans cyberattack rehearsals

There's also a response being planned well beyond the people writing agent software.

G7 finance ministers and central bank governors have agreed to hold tabletop exercises on AI-enabled cyberattacks. Japanese Finance Minister Satsuki Katayama announced the agreement on 15 October, and Reuters reported it on 16 October.

A tabletop exercise is a rehearsal built around a simulated incident. Participants work through how they'd respond, rather than waiting for a real emergency to discover whether their plans fit together. The finance authorities intend to develop simulated attacks, test response protocols and use the results to revise their manuals.

Private financial institutions may take part, depending on the scenario. That leaves room for exercises involving both public authorities and banks, but it isn't a newly imposed requirement for every financial institution. There are no firm exercise dates, full participant lists or published scenarios in the report.

The useful shift is towards practising the response. Prevention gets much of the attention in cyber security, understandably. A rehearsal asks what happens after something goes wrong and the people responsible have incomplete information. It can test the decisions around an incident as well as the technical response.

For example, an exercise could explore when an institution has enough evidence to escalate a problem, or how it shares an evolving picture with other participants. Those are illustrations of what this kind of rehearsal can examine, not announced G7 scenarios. We don't yet know which situations the authorities will choose.

For financial organisations, my view is that the value will come from finding disagreements before a real incident forces an answer. Two institutions can each have a sensible response manual and still have different expectations about who contacts whom or when. Revising the manuals after a shared rehearsal is the concrete follow-through described here.

For listeners in Australia, this agreement creates no new compliance obligation established by the reporting. It's a development in international operational planning. Its usefulness will become easier to judge once the exercises have participants, scenarios and results, rather than just an agreement to hold them.

Managed Wiz monitoring comes to GKE

Back at the level of a running application, there's a more immediate change for some cloud operators.

Google Cloud introduced the Wiz Runtime Sensor as a managed add-on for Google Kubernetes Engine on 16 October. It's available in preview for both Standard and Autopilot clusters. GKE is Google's managed service for running containerised applications with Kubernetes.

The sensor watches running processes, network connections and file activity. That's a different view from scanning stored software: it looks at what an application is doing while it's operating. The two approaches complement each other, because information about the software you deployed doesn't describe every action it takes once it's running.

Google's part of the integration is managing deployment and sensor updates. Organisation policies can also require the add-on on new clusters. For an organisation already using Wiz, that creates a way to make coverage more consistent as new infrastructure is created. It doesn't depend entirely on someone remembering a separate installation for each new cluster.

The cost description needs a little care. The GKE add-on has no additional charge, but an active Wiz Runtime Sensor licence is required. The sensor also uses CPU and memory, and optional Secret Manager usage can incur costs. So the managed integration isn't the same as free runtime security. Its potential saving is partly in the work of deploying and maintaining it.

There is also a practical wrinkle in the documentation. The launch post describes automatic credential syncing without intervention. The installation guide says changes to deployed secrets require a sensor restart. If you're evaluating the preview, that difference affects how you plan credential changes; the broad launch description doesn't settle the operational detail.

My assessment is that consistent installation may be the most useful part for existing Wiz customers on GKE. A detection tool can only observe the workloads where it's present. Making it easier to deploy, update and require on new clusters could reduce gaps created by ordinary infrastructure growth.

Nvidia takes local AI into laptops

Let's leave the cloud for a moment, because some of this work is being brought back onto the laptop.

Nvidia announced commercial availability of RTX Spark laptops on 16 October. These Windows machines combine its Grace CPU with a Blackwell RTX GPU, with configurations supporting up to a hundred and twenty-eight gigabytes of unified memory.

Unified memory means the CPU and GPU share a memory pool. For local AI, available memory is part of what determines which models and workloads can fit on a machine. A large capacity is useful, but it doesn't tell us how quickly a particular model will run. That requires a workload comparison, and the launch announcement isn't an independent one.

On the software side, Nvidia lists native CUDA support and a PyTorch-CUDA build for Windows on Arm. CUDA is Nvidia's GPU computing platform, and PyTorch is widely used to build and run machine-learning models. The specific Windows-on-Arm support matters because hardware capacity is only helpful if the software you need can use it.

Nvidia says the machines support local coding, testing and model execution. Some creative application support is still in beta, including native Photoshop and Premiere releases. So there's a difference between a laptop being commercially available and every application in a creator's working day being equally mature on it.

For a developer, the interesting option is having supported AI workloads available on a portable machine instead of relying exclusively on hosted inference. Local execution can also give you more control over where code and context are processed. But that depends on the chosen tools staying local; buying a laptop doesn't change where an application sends its requests.

I'd judge these machines by the exact model and software combination someone needs to run, rather than the memory ceiling alone. A working local setup could be valuable for that person even without replacing all their cloud use.

Pricing and configurations vary by region. The announcement doesn't establish stock at a particular Australian retailer, and verified end-to-end performance isn't available in this reporting. The new option is real; an Australian purchasing decision still needs local availability and evidence from the intended workload.

GitHub tightens some anonymous access

A smaller change could be quite noticeable if it lands in the middle of your automated build.

GitHub said on 19 October that some unauthenticated HTTPS clones and fetches of public repositories may temporarily require authentication during unusual traffic. Legitimate requests can get caught by the protection.

This is limited to those anonymous Git operations. Authenticated HTTPS operations, SSH and pushes are unaffected, as are unrelated website and API traffic. Public repositories aren't being placed behind a blanket login requirement.

The practical consequence is that a build which anonymously downloads public source may fail until it authenticates or retries after the restriction ends. GitHub hasn't published the precise thresholds that trigger the protection or how long a restriction lasts. That makes it difficult to predict when a previously working anonymous fetch might encounter it.

For developers maintaining build systems, I'd treat this as a change to an availability assumption. The source can remain public while a particular way of fetching it is temporarily restricted. A failed anonymous clone therefore doesn't necessarily mean the repository has disappeared or become private. Knowing that distinction can save a fairly unproductive investigation into the wrong problem.

Mistral forecasts numbers on CPUs

There's a useful reminder in this next release that an AI model doesn't have to be a conversational assistant.

Mistral released Timestral on 15 October, its first family of time-series foundation models, with a public implementation for forecasting your own numerical data. A time series is a sequence of measurements over time, such as demand, capacity use or equipment readings.

The four model sizes range from five million to two hundred and nine million parameters. Mistral says inference doesn't require a GPU. That makes the family relevant to organisations evaluating forecasting on CPU infrastructure they already have, rather than assuming specialised graphics hardware is part of the entry cost.

Timestral produces probabilistic forecasts. Instead of offering only one predicted value, that approach represents uncertainty around possible outcomes. The models can also accept related historical series and known future inputs, such as schedules. A schedule can supply information about what's planned, alongside the patterns visible in past measurements.

Those capabilities are useful distinctions for someone comparing this with a system that only extends the history of one series. They don't establish that Timestral will predict a particular organisation's demand or equipment behaviour accurately. That still depends on the data and the forecasting task.

Mistral's benchmark-leading results are company claims, and the full technical report was still forthcoming. The announced licence is Modified MIT, which isn't the same label as unqualified MIT. Its terms are part of assessing whether the implementation fits a planned use.

The opportunity I see is a specialised model that could make useful forecasting practical without a new GPU purchase. The meaningful test is the quality of its forecasts on the measurements a business already uses to make decisions, including how well it represents uncertainty. A small numerical model could earn its place there without ever producing a line of chat.

What Changes for You

If you're building an agent, there's also a new hosted model with a fairly concrete price to compare.

MiniMax released M3.1 Flash on 19 October for agent workflows, coding and computer use. It's available through the MiniMax API, M Plan and MiniMax Code. For working builders, that means another paid option for applications that call tools repeatedly or make changes to code.

The published API prices, all in US dollars, are fifteen cents per million input tokens, sixty cents per million output tokens, and one and a half cents per million cached input tokens. Tokens are the chunks of text a model processes. Cached input is priced separately from ordinary input, so the mix of work matters to the bill.

MiniMax claims nearly three times faster online inference and seventy per cent lower overall agent-task costs than its predecessor. Those are company comparisons, not a guarantee of equivalent savings or reliability in your application.

The immediate access is hosted. Model weights have been promised for later, without a firm release date established here, so this launch doesn't yet let you self-host the announced model. Australian data residency also isn't established by the launch source. That limits what an organisation can conclude about where its code or other context would be processed.

For a developer comparing models, I'd put the published rates beside the cost of a successfully completed task. Repeated attempts and review can change the economics, even when each individual call is cheap. M3.1 Flash gives builders another model they can use now; whether it lowers the cost of useful work depends on how reliably it finishes that work.