These days, AI companies directly or indirectly announcing how their respective wares are smarter than their competitors has become a genre of elevator music. Even so, some in-depth articles can be quite insightful, like Anthropic's occasional reports on attempted misuse of its wares. The latest one covers activity between November 2025 and September 2026, with an important reveal: five situations where Claude was asked to perform work determined to potentially be used in biological weapons.

Right out of the gate, Anthropic remarks on the difficulty of understanding if a particular line of inquiry pertaining to biology is meant for nefarious purposes, to create defense mechanisms like vaccines, or simply to establish predictions of how a virus spreads. The company says that "out of an abundance of caution [....] launched recent models with stronger safeguards."

Among the tens of case studies presented in the lengthy report, Anthropic discusses five cases that it deemed particularly concerning, three regarding viruses, and two more discussing toxins. The common theme across all of them is that all threat actors used varying degrees of anonymization techniques and did their best to evade Anthropic's own regional blocking. The report doesn't mention specific states, but the firm is known to block access to Claude for China, Russia, Iran, North Korea, among others.

In the first case, a request for assistance in developing a grant application involved finding ways to improve the chikungunya virus. The purported researchers were trying to come up with ways to both add extra abilities to chikungunya (increased mutation) and increase its virulence. The topic itself already raised some concern, but Anthropic's hand was forced after finding that although the grant application seemed to be for civilian researchers, the actual investigation was meant to proceed at a military facility.

The firm also found that the request would have gone through a third-party LLM platform associated with military as well as civilian institutions. The countries involved are geo-blocked by Anthropic, and that platform routed comms traffic through the U.S. to try to evade detection, used gray-market resellers, and specifically catered to customers looking to skirt content restrictions. Anthropic banned the accounts in question and shared the information with government authorities, though the same people repeatedly tried reaching Claude again via zero-data-retention services.

Case #2 pertained to a non-US researched who was looking to dig into how avian flu adapts to mammals, and how it can cause diseases other than in the respiratory tract. The problem is that avian flu has a high fatality rate, and there's little population immunity.

While the virus doesn't easily spread from person to person, therein lies the rub — the research could end up discovering mechanisms to increase transmissibility. The researchers used a random username, a private email service, and accessed Claude through a VPS, leading Anthropic to investigate and ultimately turn its nose up at this strain of thought.

The story with the third case bears a resemblance to the previous two. Once again, an account was trying to prepare a supposed grant application, this time around about orthopoxviruses, the family that houses smallpox and Mpox, among others.

The application discussed containment facilities and live experimentation with the viruses, and focused on understanding their genetics for the purpose of evading immunity. The research didn't initially trigger alarms, but Anthropic came to notice it was created via a reselling service, with a randomly-generated email, tunneled through U.S. infrastructure to reach Claude, and traced back to a banned account farm.

In the last two cases, instead of viruses, the purported researchers were focusing on toxins. In case #4, a person mapped out venom toxin peptides from multiple families of animals and created a program to optimize their toxic characteristics.

Although the stated goal was to create painkillers, antidepressants, and other therapeutic molecules, the data would equally allow the creation of potent harmful compounds. Anthropic also came to learn the content Claude was generating was part of a state-sponsored program in an "unsupported region."

In the fifth and final case, a theoretical scientist was also using Claude to try and redesign a set of toxins, also supposedly for therapeutic purposes, under a national public search program. However, the work touched upon "a bacterial toxin subunit and a protein of the hemorrhagic-fever virus" that happens to be on the World Health Organization's list for particularly nasty, pandemic-inducing diseases.

The scientist tried to obscure the subject of the research, directing Claude to be vague about descriptions. Once again, the story ended with Anthropic cutting off access to Claude from a location that broke its terms of service.

Today is September 9, and the significance of the date for Australian consumers is that, by law, buying online apps and games now requires an over-18 age verification step. The local law isn't specific about the exact type of verification, only that it offers "appropriate age assurance measures." Valve is complying by asking for a bank card rather than government ID or a biometric check. The problem in the land down under is that while credit cards seemingly all work, debit card support is spotty and conditional.

This situation isn't unique, as it's basically a repeat of the same existing scenario in the United Kingdom. Valve's privacy-minded approach is laudable, as a bank card only links a payment method to a name and address. Meanwhile, a government ID is a more dangerous document if it gets leaked; face scans are quite fallible and revealing, and biometrics are intrinsic to the person and not replaceable if exposed — unlike bank cards, which can be canceled and swapped in minutes.

However, having a card check as the only verification option is causing problems, and many users are already asking for other means of verification, even if they're more invasive, citing Xbox and Sony's services as more accommodating.

Since credit cards in Australia (and the UK) can only be issued to adults, they work fine for Steam verification. Debit cards, on the other hand, can be carried by minors, and they're only valid for age checks under specific conditions. For now, that seems to be those (a) belonging to the Mastercard network, which introduced its own global automatic age verification check on June 2, 2026, and (b) for which the issuing bank flagged the card product as adults-only. The transaction firm only passes the answer to "is the buyer an adult?" back to the merchant (in this case, Steam), without exposing an actual date of birth.

A quick harnessing of user reports, mainly from Reddit posts, seems to indicate that debit Mastercards from Commonwealth, Westpac, and Macquarie appear to work, while those from Bendigo, St. George, Revolut, ANZ, and most Visa cards seem to fail the check. Note that this is an evolving situation, so the situation may have changed by the time you're reading this.

The demographics of credit card ownership definitely don't help matters. Unlike the U.S., where credit cards are the default method of purchase, only about 45% of Australian buyers and 65% of UK punters own one. Perhaps most importantly, within the 18-24 age demographic, only 25% to 30% own a credit card — precisely the people who buy the most games and are the most affected. For both user satisfaction and business reasons, it's seemingly desirable that Steam add verification alternatives.

Most anyone involved in computing has heard about the P-NP problem, but fluid engineers and mathematicians would love to know if the Navier-Stokes equations have smooth, globally defined solutions. Both questions are part of the Millennium Prize Problems, solutions to which are worth a cool $1 million and eternal renown. OpenAI is claiming that its staff and internal models have solved the conditions of Navier-Stokes solutions set forth in the Millennium Prize. But the company's shouting from the rooftops is being met with a chorus of boos over claims it might have plagiarized the work of a research team that had been toiling on a related, stepping-stone problem for a year.

Tristan Buckmaster (a scientist at NYU) and Levent Alpöge (a member of Anthropic's staff) had been quietly working on proving Euler's equations — another long-standing mathematical problem, and one that is generally acknowledged to be a stepping stone to solving Navier-Stokes.

According to Buckmaster, his work with Alpöge was "a purely personal collaboration, free of any institutional agreements or official involvement by either of our employers." The researchers used Anthropic Claude and OpenAI Codex as assistants, as is apparently now common in the field, to perform busywork (documentation, searching, etc.) as well as running through logic steps. The substantial amount of compute time the project required was paid from Buckmaster's own pockets, too.

The pair worked for roughly a year until August 15, 2026, when it obtained "the blowup results, with smooth forcing, for both Boussinesq and Euler." Buckmaster says the novel approach was based on previous work by Diego Córdoba and Luis Martínez-Zoroa, and he believes Zoroa should be eligible for a Fields Medal.

Although the team was presumably happy with these achievements, Buckmaster said that the LLM-generated proof was "the most horrendous" he'd seen, calling it "AI slop," and meaning to rewrite it for clarity. Nevertheless, they verified it on August 22 using Lean, a standardized programming language designed specifically to verify mathematical proofs.

Come September 3, Alpöge told Buckmaster of rumors going around that Anthropic had solved an important mathematical problem. This almost certainly alluded to the team's work, and some apparently took it to mean the company itself was working on the problem. The rumor-mongers even theorized that the problem that Anthropic had solved was Navier-Stokes. Alpöge further believed that OpenAI had gotten wind of the news.

This prompted Buckmaster to email an unnamed "prominent mathematician" at OpenAI, clarifying that the effort was a personal collaboration between him and Alpöge and was unrelated to Anthropic. The mathematician replied asking for details, saying "it would be useful to avoid competing," and offering OpenAI compute time. After a few days, on September 6, Buckmaster, the unnamed person, and OpenAI's Sébastien Bubeck talked twice, without Alpöge. He was told that OpenAI had proven a finite-time blowup for the forced Navier-Stokes equations, a subset of the problem.

Alpöge asked by text for the precise statement and was told "existence of forced blowup in R³ and T³", and that "the forcing function is smooth option [C] and [D] in Fefferman," referring to one of the four possible categories established by the Millennium Prize, with any one of them being valid as eligible for the prize, but not constituting a full solution for all scenarios, a distinction remarked on by other scientists.

This is where the story becomes interesting. Buckmaster claims that that idea (forced blowup) was exactly the same one his team had "quietly" chosen, and that nobody else he knew was working on it. Perhaps most importantly, he says that that was "not the direction one arrives at in a few days by giving a model the problem statement," indicating that running the general problem through a bot wouldn't quickly reveal that potential approach.

In fact, Buckmaster claims that over the calls, Bubeck ultimately revealed that instead of just AI models and agents with a couple of handlers, there was an entire team of live humans working on Navier-Stokes. The OpenAI team first had the models try to work through easier paths, and the text prompt that generated the Navier-Stokes proof had itself been generated by prompting Codex, with an "insane" amount of computing needed.

Buckmaster then asked when the initial prompt was issued, and OpenAI's response of "in the past few days" did not arrive until "some time" passed. He proceeded to ask if the model "had been trained on, or had access to, our sessions in Codex," and was told by OpenAI that Codex does not access user data. Finally, he asked if the data was used for model training more generally and, crucially, apparently did not get an answer.

OpenAI allegedly offered Buckmaster two options: one, that Buckmaster and Alpöge publish their Euler proof first. The following day, OpenAI would post its Navier-Stokes proof, giving the two priority. The second option was that Buckmaster alone, without Levant, was to write a paper with the Navier-Stokes proof, acknowledging that an internal OpenAI model resolved it. Bubeck was apparently adamant about Levant's removal from the Euler proof, as his employment at Anthropic was "annoying." Buckmaster opted for neither, and told OpenAI that if it chose the first option, he'd go public with his findings, as has since occurred.

This prompted what Buckmaster interpreted as a threat from Bubeck, who asked him "why [he] would ruin [his] career." After Buckmaster asked why that would happen, Bubeck told him, "If you don't want me to be nice, then I don't have to be nice." Bubeck then allegedly reached out to Alpöge, questioning Buckmaster's sanity, to which Alpöge responded with a refusal, pointing inquiries back to his colleague.

The entire story raises pointed questions about what OpenAI (and others) are actually doing with user data collected via its LLMs, despite the toggle switches that are supposed to disable it. Not only has OpenAI neglected to tell Buckmaster whether it used his team's data for training, in its PR about Navier-Stokes, the company says while it "no specific user data was accessed in order to solve this problem," it "cannot rule out that de-identified data derived from their usage of our products helped improve [its] models."

OpenAI's proof still needs to undergo a likely years-long peer review before any party can take the Millennium Prize home. The firm has stated it does not intend to claim it. As for Bubeck, he predictably paints the story in a very different light, but insists that his pushing away of Alpöge is justified on the basis that "it would be inappropriate for an Anthropic employee to author OpenAI's work," a puzzling statement that some could take as meaning a double standard regarding scientific authorship, based solely on corporate rivalry.

For his part, OpenAI CEO Sam Altman claims his team was well-intentioned and cooperative, and supported Bubeck, saying "it was challenging to offer [the same publication options] to Levent." Neither person opted to discuss the matter of whether OpenAI used the research of Buckmaster and Alpöge as training data, or offered any further explanation of why Alpöge didn't deserve credit for his work as an equal to Buckmaster.

Given the groundbreaking nature of this apparent discovery and the ensuing fight for priority that these competing accounts have sparked, it'll likely take quite some time and review before we know whether and how OpenAI or Buckmaster and Alpöge will be credited with this discovery. But given the inter-lab rancor already on display, the process will surely be ugly.

Anyone keeping track of world news in the early 2010s, and reports on tech in particular, has probably heard about Stuxnet. That malware spawned a large number of conspiracy theories — with the kicker that some of them were actually true. The malware targeted Iranian nuclear facilities and is believed to be the first digital worm to cause direct physical damage in meatspace. An unknown security researcher has now published a source code reverse-engineering of Stuxnet in all its glory.

The worm's ultimate target, allegedly a successful one, were industrial controllers from Siemens that were reportedly used in Iranian's Natanz nuclear enrichment plant. Once it reached the target, Stuxnet's payload manipulated the frequency converters in industrial centrifuges, in a bid to subtly damage the rotors — all while keeping the plant staff in the dark by reporting normal operation.

The repository contains build instructions so interested techies can try it out for themselves and learn all about its inner workings. You'll need a Windows XP or Windows 7 virtual machine, and for obvious reasons, you shouldn't configure any network connectivity for it. To witness the full effects of the payload rather than just the spreading mechanisms, you'll need the appropriate Siemens software, and ideally hardware — though we figure that industrial-scale centrifuges aren't exactly common in techies' cable drawers.

In its heyday, Stuxnet spread via three mechanisms. The primary infection vector was USB sticks with Windows shortcuts and autorun.inf files. Upon plugging one of those sticks in, just viewing the drive's contents would immediately trigger infection thanks to a zero-day vulnerability.

Infected systems then autonomously tried to spread the worm further via the network using a zero-day Windows Print Spooler vulnerability that would let an attacker write system files into any machine sharing a printer. It would also copy itself into accessible network shares. To evade Windows driver signature checks, Stuxnet used two digital certificates stolen from Realtek and JMicron.

The worm also had code to inject itself into Siemens software, by way of the WinCC SQL Server database, and embedding its code in Step 7 project files that automatically ran when engineers opened them. Since those files were almost guaranteed to be shared among more than one engineer, it made for an excellent internal infection vector that didn't depend on having network share control.

The final step was taking charge of the DLL that communicated with the actual centrifuges and injecting malicious code into the PLCs (Programmable Logic Controllers) of those machines to stealthily mess with the rotors.

Stuxnet was part of Operation Olympic Games, an alleged coordinated effort between the U.S. and Israel to try and curb Iran's purported progress in creating nuclear weapons at its Natanz facility. The initiative seemingly ran under both the Bush and Obama administrations, and was supposedly a way to dissuade Israel from launching its own preemptive strike against Iran. The software was allegedly developed by both the Pentagon and Israel's Unit 8200, and was reportedly successful in bringing down about 10% of Natanz' centrifuges by ultimately seriously damaging their rotors.

However, the worm had a nasty bug: it didn't have sufficient checks about which environment it was in, and failed to notice it was no longer in a local network environment. When engineers took their laptops home, it escaped out to the internet at large, at which point security researchers worldwide let out a collective "huh, that's odd" and proceeded to investigate. Mercifully, the worm contained a hard-coded self-destruct date set for June 24, 2012.

Musicians and synth-heads in the audience, rejoice. A new vintage synthesizer plugin has arrived that has the potential to blow many commercial offerings out of the water — and it's completely free, to boot. Audio software maker Autodafe has released the Vintage Emulator Studio (VES), a fresh new plugin that integrates a fair number of the open-source MAME emulator's synthesizer cores in one neat package.

The entire list of emulated synths is below, but it includes iconic entries like the Akai MPC3000, LinnDrum, Oberheim DMX, and Roland TR-707 — used by names like Dr. Dre, New Order, The Police, INXS, and Prince, among many other high-level acts. There are a total of 44 machines, all with component-level emulation.

What makes VES different from most other synth plugins is that instead of presenting a facsimile of the final output or a hybrid mix of component- and output-stage emulation, it employs — by way of MAME — full component-level emulation. Each processor, tone generator, envelope generator, filter chip, and converter should be faithfully reproduced, potentially resulting in a "perfect" emulation of the gear in question, more or less depending on the status of each driver core.

Notably, on machines whose MAME emulation is farther along, analog and/or digital output stages are faithfully recreated, meaning you won't need additional low-pass filters or any other trickery to make the synth sound like the actual hardware. Additionally, the skeuomorphic, HiDPI-ready UI replicates the units' control panels, dials, buttons, and LCD displays, making them easy to interact with if you're familiar with the real hardware — and probably a nightmare if you're not, as "ease of use" wasn't high on the list of priorities back then. Floppy disk, CD-ROM, and peripheral emulation ought to be included too.

If by now you're thinking this is all too good to be true, there are indeed a couple or three catches. First and foremost, as with any emulator, you'll need to provide your own ROM/firmware, and depending on the synthesizer, any associated sample packs. Although obtaining those is not too difficult, having a copy of that data is a legal gray area if you don't own the original hardware. Although we haven't tested it ourselves, the CPU usage of the plug-in ought to be somewhat high, considering all the work it's doing simulating every single component.

Additionally, while MAME's emulation cores aim for full component-level emulation, not every synth driver has had the same amount of work put into it. For example, the Akai MPC-3000 driver is nearly complete, while the Prophet-5's has only been introduced to MAME fairly recently — so your mileage may vary. We'd expect this VST to be updated somewhat frequently as work on its MAME core moves forward.

For the sake of argument, though, if only a handful of synths are fully emulated, that's still an impressive showing out of a list of 44, given that in theory you'll get output that tracks exceedingly close to that of the original hardware, all from one plugin. You can download the Vintage Emulator Studio right here, in VST3 or AU format, for every major OS: Windows, macOS Intel/M-series, and Linux. It's also available as a handy standalone application.

Data center builds are one of the hotly contested items worldwide. Many states and cities have upheld moratoriums on new buildouts due to power usage, water consumption, and noise concerns. Thailand is the latest nation to pump the proverbial brakes, with the government requesting that existing buildouts hit the pause button while coming up with a more precise regulatory framework.

Government heads requested that agencies compile information about current and future data centers during this week, in a bid to create unified legislation. The country currently has few laws specific to data centers, leading to legal voids like zoning a data center as a "warehouse" right next to a hospital. Much like everywhere else, the country has seen growing complaints about data centers' water and power usage.

After the week is out on September 11, the government expects to take about a month to come up with a regulatory draft, making the pause technically an indeterminate timeframe — though further delays wouldn't benefit either party, as Thailand considers the industry critical to the country’s competitiveness. The catch is that pausing construction isn't enforceable, so companies can elect to plow ahead regardless while the legislation is discussed.

NESDC (National Economic and Social Development Council) secretary-general Danucha Pichayanan is very specific: "we don't have the power to suspend the construction of the 49 data centers" currently under construction. However, when the legislation arrives, it will apply retroactively to ongoing projects, though with an adjustment period for in-progress builds. New builds will naturally need to comply with the legislation from the get-go.

Some companies may elect to soldier on with the belief their buildouts will be in compliance with the reasonably predictable content of the new laws, or betting that they could win future legal challenges — a dynamic that's already in play elsewhere with Project Jupiter. The incoming legislation is expected to cover power consumption (and possibly generation), closed-loop cooling, and water-surplus guarantees, meaning builders already have a fairly good idea of what they'll need to do.

Not complying with the request for a pause might be a game of political chicken, though, as the government may retaliate with regulatory delays and additional costs to power connections. Just last Thursday, Thailand's energy ministry raised concerns over a Bangkok data center that may be planning to hold diesel stockpiles far in excess of the 200,000 liters it has permission to.

On that topic, Thailand revised laws on industrial power delivery last July, and among other requirements, demands a bank guarantee of ฿4.5 million ($134,000) per megawatt. Half the money will be refunded when the actual usage reaches 50% of proposed utilization, and the rest when usage hits 70%. This mechanism is meant to stop preemptive allocation of power delivery capacity that might remain unused for months, years, or not at all — once again, mirroring datacenter playbooks elsewhere around the world.

At face value, the amount of $134k per megawatt sounds like a small price to pay for a builder to get ahead of the pack, but its per-megawatt nature means that a hyperscale facility pulling 200 MW or more needs to place around $27 million in escrow.

With the power laws recently revised, water consumption is seemingly the largest concern, as the current legal framework allows companies to make deals directly with utilities without additional safeguards. For example, in Chonburi, an operator signed a decade-long deal with Eastwater Stecon Utilities for 3.3 million cubic meters annually, or about 36,900 residents. It's expected that the new laws will add much stricter requirements to avoid localized deserts.

Not that long ago, we reported that Nvidia was dusting off the blueprints for the RTX 3060, in its 12 GB form. At the time, we'd spotted it in stores for about $339.99, but just like with ever-climbing memory, hard drive, and SSD prices, two months passed is an eternity. The same cards are now selling for $489 new, and one particular specimen is the SRhonyra RTX 3060 12 GB Low Profile card, for $495.59.

• SRhonyra RTX 3060 12 GB Low Profile card - $495.59

This card and its price may raise more than a few eyebrows, but there are reasons why it exists. First off, it's a one-slot model, making it easy to put many of them to work in the same machine with relatively little concern for airflow. They have no power inputs and rely on 70 W delivered by the PCIe slot alone, eschewing the need for a high-end PSU and lots of cables. Third, the low-profile form factor makes it possible to place them in potent puny personal computers.

Attentive readers might surmise that one (or more) of these would be good candidates for an entry-level local LLM rig. That's precisely how SRhonyra is pitching the card, calling it "capable of local AI" and "running 7B [to] 13B LLMs." A standard-dimensioned, fully powered RTX 3060 is capable of drawing a maximum of 175 W, so it's fair to assume the performance of the diminutive variant will sit below that of its full-sized brethren, given it ought to only draw 70 W of juice from the PCIe slot.

Even then, it's likely that people interested in these cards are looking to use them either as secondary GPUs, or use more than one in the same box to be able to virtually pool their VRAM and use larger models than you'd otherwise be able to. The low power draw also means they're a simple, thoughtless drop-in to an existing system, whereas larger, more power-hungry cards require careful consideration with physical spacing (or lack thereof), power supply sizing, and ever-annoying cables.

Recently, the Kyoto Prefectural Police caught one of the initial-seeders of the well-known Japanese torrent website Nyaa. Masakazu Ono, 56, from Sagamihara in the Kamigawa Prefecture, was arrested after a multi-year investigation. While this news is straightforward by itself, the interesting bit is that CODA, the Japanese anti-piracy entity that performed the initial cyber-investigation, identified Ono allegedly without joining or monitoring BitTorrent swarm traffic, with the help of the Japan Hacker Association (JHA).

CODA's description of only having "[analyzed] how data moves through torrent sites, such as index sites and tracker sites" is vague and can be parsed in a number of ways. The distinction between indexer and tracker is relevant: while an indexer is a user-visible list of torrents (usually a website), the tracker is the background service that software like qBittorrent actually connects to, and it lists everyone who's currently active in that torrent, whether sharing, downloading, or both.

Our hypothesis is that CODA kept close tabs on the Nyaa trackers to see which IP address (in this case, Ono's) consistently appeared as the first person to offer up a 100% complete set of data for a show, a theory that would fit with how long the operation took. JHA's founder, Takayuki Sugiura, was the first to decrypt the Winny P2P protocol in 2004 to find original uploader sources, and the methods used weren't too different from the aforementioned theory. It's also possible that Ono wasn't using a VPN but was logged into Nyaa, or activity at another website's cookies or CDN logs was used to establish a link to his activity at Nyaa, and from thereon, to the tracker.

An initial-seeder is someone who is the first to offer up data for others to download — in this case, shows and movies. The show that reportedly got Ono nailed was Midnight Taxi, a 2026 Japanese drama produced by NHK and WOWOW. However, the police apparently had been tracking him for quite a while and claimed that he had uploaded close to a thousand NHK recordings over the investigation's span.

The process started in 2021 when CODA first launched its Cross-Border Enforcement Project, aiming to identify Nyaa's uploaders. During three years, with the help of JHA, CODA seemingly collected enough information to get the Kyoto police involved in 2024. Three "secondary uploaders" from "reach sites" were charged in 2025, likely meaning regular users participating in the torrents, who got there through link aggregator sites. Fast-forward to a couple of weeks ago, and Masakazu Ono was formally arrested with specific charges.

The most common techniques used by law enforcement agencies are creating a tracker honeypot or participating in the torrent swarm themselves in a bid to identify who's sharing files. However, Nyaa's list of trackers is small and comprises well-known, trusted servers, so together with CODA's wording, it's unlikely this was the method used. Furthermore, Japanese law generally frowns on non-targeted data monitoring, meaning that techniques like Deep Packet Inspection (DPI) and traffic volume monitoring likely weren't used, at least until such time as Ono was identified.

Whether driven by a desire for transparency or to keep OpenAI from hogging the spotlight when it comes to advertising advanced AI models, Anthropic revealed that Claude also hacked into three production systems belonging to unsuspecting targets during cybersecurity capabilities testing. Two of the affected companies didn't know they had been hacked, while a third one is unreachable.

The alleged incidents reportedly happened during the previous quarter and involved several versions of Claude: Opus 4.7, Mythos 5, and "an internal research test model." Similar to what happened when OpenAI Sol hacked into Hugging Face, Anthropic was running Claude through cybersecurity capture-the-flag scenarios where the bot was told to find a piece of information somewhere in its network. Anthropic says there were 141,006 test runs, and the three incidents occurred over six problematic runs. As expected, the tests ran with most AI safeguards disabled.

The problem is, the network was not isolated, a newbie mistake that some might even find suspicious. This was due to an alleged "miscommunication" between Anthropic’s virtual test lab firm Irregular, which gave the bots full access to the internet. For safety's sake, the Claudes were apparently told they were in an isolated environment, which didn't help much.

The first time, Claude Opus 4.7 had to find a piece of data belonging to an imaginary company. As it turns out, there was actually a real company whose website domain matched the fake one. With internet access, it gained application and infrastructure credentials and grabbed "several hundred rows" of data from a production database.

For two out of four runs where hacking took place, Claude didn't see any problem and "rationalized that the real company must be part of the exercise," but soldiered on. The other two times, it just kept going. Anthropic notes this was the only case of the three where the bot continued to operate after the realization the company actually existed for the aforementioned reason. However, the firm's interpretation is open to discussion.

The second, and potentially more interesting, was a bona fide supply-chain attack, this time perpetrated by Mythos. The fake data available to the bot included an installation script for a hypothetical developer that included installing Python packages. Much like a human would, Claude noticed the obvious attack vector and, once again, due to having internet access, inferred that publishing a booby-trapped package in the PyPI repository would do the trick. Unfortunately, it was the real one that the whole world uses.

In speedrun form for brevity: Claude needed a PyPI account, meaning it needed an email and a phone number. It tried buying one but found itself short of both pockets and funds; but it found another free email provider without that requirement, registered the PyPI account, and uploaded a malware package to PyPI. The package was seemingly only up for one hour but was downloaded and run on 15 systems.

In a twist of irony, one such system belonged to a security vendor that scans PyPI for malware, and lo and behold, promptly failed to find Claude's booby-trap and ran it. Once Claude presumably had remote code execution privileges, it used the credentials it found for further infiltration. The amusing bit is that Claude had no idea this company existed and didn't target it; the downloads just happened because the package was up and live for a short while.

According to Anthropic, the bot did detect it was acting on the real internet and even said that publishing a package like this was "NOT okay." However, it talked itself into believing it was in a test environment as it didn't recognize the real SSL certificates for the connections. It even believed the 2026 calendar date on the systems "proved" the environment was staged. It even recognized the systems that installed the malware as part of the experiment.

As for the third incident, Anthropic isn't saying much, other than Claude scanned 9,000 real live potential alternative targets once it noticed the intended one wasn't reachable. One of them reportedly had a live page with debugging information and was vulnerable to plain ol' SQL injection. Interestingly, this time around, once Claude noticed that the servers it was accessing resided on a cloud environment and not on the local network, it stopped the attack.

For its part, Anthropic recognizes that despite Claude following the instructions for the objectives, the fact that it stopped by itself once it found the target was real in only one of the cases is food for some thought. The firm says it's talking to METR for a third-party review, and it needs to "better co-design evaluation environments."

Oddly enough, Anthropic believes Claude probably wouldn't have gone online "if the prompt had clearly explained which systems were in and out of scope for the evaluation," while also stating the incidents were "closer to a harness and operational failure than a model alignment failure."

The Steam Machine helped grow the popularity of Linux gaming, including installations of Bazzite and other gaming-oriented Linux distributions. Valve seemingly doesn't want to stop its open-source development efforts anytime soon, and is now working on a port of the Mesa Radeon Vulkan driver (RADV) to Windows; It's already running Counter-Strike 2, according to developers at Collabora.

As cross-platform development is rather tricky, Valve opted to get a port of RADV to Windows going by way of sponsoring contractors at Collabora. In its blog post, Collabora explained the several hoops it had to jump through to accomplish this task.

With Windows 10 and WDDM 2.0, Microsoft improved the split between graphics drivers' userspace code (the vast majority of the driver itself) and the kernel-level portion that actually talks to the graphics card. This presented the opportunity to hook RADV to the AMD kernel card driver. That's easier said than done, however, as communication between those parts often carries non-standardized data that RADV needs to understand. And to understand the "conversation," it needs to be recorded and analyzed.

An earlier 2024 effort by Faith Ekstrand yielded a basic-but-valuable utility for logging WDDM 2.0 calls and reverse-engineering them to produce a basic RADV implementation. Out of both debugging necessity and as a development tool, Collabora built and expanded upon Ekstrand's work, improving the logger to the point where it can now fully analyze any Vulkan application that runs with AMD's official driver and dump all the data passing to the kernel.

After a lot of work getting to grips with how the AMD driver interacts with the kernel driver, including but not limited to reverse-engineering obscure data structures, the team made progress, and Windows RADV is now able to run some games, including Counter-Strike 2.

Despite the ongoing effort, Collabora explains that since user- and kernel-space driver are a matched pair, changes to those aren't guaranteed to be backwards-compatible, meaning that even a fully functional RADV could break at any point. For that reason, Collobora is requesting that AMD, Microsoft, or both provide a documented interface to the kernel driver or an intermediary compatibility layer.

AMD graphics driver development on Linux has coalesced around the Mesa Vulkan stack, with both company and community devs contributing to the RADV project. Over in the Windows world, the only option is AMD's proprietary driver, which can cause a lot of headaches when developing cross-platform games and applications.

AMD's Vulkan driver for Windows has developed a reputation for instability. Meanwhile, Linux RADV is generally praised for its stability and performance, sometimes running faster than the AMD Windows driver, especially on older cards. With a rapid development schedule, it also generally sees fixes and speed upticks often.

If at some point using RADV on Windows becomes viable, you'd be getting an arguably more stable, mature driver with active development. Games' graphical issues could become far easier to debug and patch thanks to the open nature of RADV, and studios developing with Linux in mind can target the one platform instead of two with different behaviors. Any developer or company can contribute to the project, too.

Furthermore, this lets Valve improve Windows compatibility layers, and any optimizations can be carried over to both operating systems. All told, this is likely one of the several moving parts to improve Linux — thus the Steam Deck, Steam Machine, and upcoming hardware — as a viable gaming platform. Even a future notion of gamers installing RADV on Windows to get a performance or stability boost isn't too far-fetched.

Additionally, RADV on Windows would also help keep discontinued cards usable, and given pricing right now, that certainly would be a good thing.

We're quite familiar with Sovol 3D printers around these parts, having reviewed several models over the years and finding that pretty much all of them produce high-quality prints. The company is now stepping up its game with the Sovol M1D, an open-source, independent dual-extruder (IDEX) printer with two nozzles and seven toolheads, a maximum print volume of 300 x 300 x 350 mm (11.81" x 11.81" x 13.78").

This bit o' kit can operate its nozzles in true independent mode (rather than alternating between them), letting users copy prints for easily printing duplicates and mirror them for doing left-right versions. In multi-head mode, each nozzle can output a different material. The first nozzle has a fixed toolhead, while the second can swap between heads independently. The open-source nature of the printer ought to let it be easy to mod, and as expected, it relies on the OrcaSlicer software by default rather than proprietary software such as Bambu's offerings.

The M1D comes in two variants, Essential and Advanced, with the higher-end model having the same basic specs but coming in a heated enclosure that keep inside air at 60°C (140°F). Sovol says each nozzle can print at up to 600 mm/s, and accelerate at 10,000 mm/s². The nozzle-and-toolhead interface seems quite nifty, as the M1D ought to swap toolheads in just five seconds, and keeps the standby heads warm so they're ready for printing the second they attach to the nozzle. One of the heads is fixed, and the other six are interchangeable.

The combination of the speed and tool-swapping technology has Sovol claiming the M1D can perform multi-colored prints five times faster than "others," displaying what appears to be a Bambu P1S in the comparison pictures. Likewise, said multi-color or multi-material prints supposedly produce "almost zero waste."

The M1D has a number of measures to prevent failed prints, including automatic bed leveling with nozzle Z-axis compensation thanks to an eddy current sensor, X/Y nozzle cameras, vibration compensation, and a 720p chamber camera that will have AI obstruction and spaghetti detection in a future firmware update.

The seven toolheads allow for easily integrating water-soluble materials for printing sacrificial supports and molds, movable mechanisms, and hollow parts, while the enclosure of the Advanced version lets the M1D print particularly resistant materials like ASA (acrylonitrile styrene acrylate), PA (polyamide), and PC (polycarbonate).

The Sovol M1D is available through a Kickstarter project that's already pulled in over $2.8 million — many times over the initial $191,254 goal. Buying into a crowdfunded project frequently elicits concern, but Sovol's track record has historically been pretty good. With early bird pricing and not accounting for shipping costs, the M1D Essential goes for $1,299, while the Advanced version with the heated enclosure costs $1,599. The printers are expected to start shipping in November.