Anthropic created three access tiers for Claude’s offensive security use, matching cyber capabilities and safeguards to the user’s level of trust.

Anthropic is trying to solve the difficult balance between using AI for cybersecurity and preventing misuse. The same model that helps security teams fix vulnerabilities can also help attackers break into systems. Its answer, announced this week, is a revamped Cyber Verification Program with three access tiers instead of a simple on-off switch.

The company puts the problem plainly: standard models like Claude Opus 5.5, Claude Fable 5.1, and Claude Sonnet 5.5 ship with conservative cyber safeguards that block most offensive work by default. That’s the safe setting for the general public. It’s also exactly the setting that makes life harder for legitimate security researchers trying to do their jobs.

“The program now consists of three access tiers, which allow security teams to apply for the level of access that best suits their work.” reads the announcement. “Each tier includes access to our most capable models, including Claude Opus 5.5, Claude Sonnet 5.5, Claude Mythos 5.1, and new models moving forward.”

The new program merges two things Anthropic had been running separately, Project Glasswing and the original CVP, into one structure. Defense Access sits at the bottom, covering security operations, incident response, malware reverse engineering, and vulnerability validation. The bar here is low enough that regional hospitals, municipal utilities, open-source maintainers, and individual researchers with a track record can all qualify, and Anthropic says it aims to respond to these applications within days.

Red Team Access steps up to authorized penetration testing, open only to organizations testing systems they’re actually cleared to test. Even here, real-time blocks stay in place for anything that could cause physical harm or mass disruption, deploying ransomware or hitting high-risk safety systems included. Applications at this tier take weeks to review, not days, which tracks given what’s being unlocked.

Specialized Access is reserved for organizations cleared to test systems where a mistake could genuinely hurt people or break markets, things like flight systems, power grids, and interbank transfer infrastructure. Every applicant here gets reviewed in depth alongside the US government, and existing Project Glasswing members simply roll over into this tier without reapplying. That’s about as tightly controlled as commercial AI access gets right now.

Anthropic tested Claude Opus 5.5 with its internal CyScenarioBench benchmark, which measures how well the model can plan and carry out realistic multi-step cyber operations. Without CVP access, all tasks were blocked at the first prompt. In the Red Team Access tier, however, Claude Opus 5.5 completed 34 of 50 tasks without any blocks.

That’s the same completion rate the model hits with no safeguards at all, which is exactly what Specialized Access is meant to represent. The Defense Access tier landed in between, blocking 46 of 50 trials while letting four genuinely difficult ones through. In plain terms, the tiers behave the way they’re supposed to, tight for the general public, open for the people who’ve proven they need the access.

This isn’t just a policy reshuffle, there’s a track record behind it. Through Project Glasswing, Anthropic says partners uncovered at least 129,000 verified software vulnerabilities between April and July 2026, with more than 33,000 rated critical or high severity.

“Through the program, our partners uncovered at least 129,000 verified software vulnerabilities between April and July 2026.” states the announcement. “And through our own open-source scanning efforts, we found an additional 5,500 verified software vulnerabilities between April and October 2026. Of these verified vulnerabilities, more than 33,000 have so far been rated as critical- or high-severity. “

The company is upfront that these numbers are almost certainly a floor, not a ceiling, since the data comes from partial survey responses across a subset of partners. Several partners reportedly told Anthropic the models cut what would have taken months or years down to a fraction of that. If even a conservative read of that holds up, it’s a meaningful shift in how fast defenders can move relative to attackers.

What stands out is not simply that Anthropic built a more capable model, but that it created a verification system designed to match access with the level of risk. Dual-use AI tools need more than a single gate. They need controls that become stricter as the potential impact of misuse increases. The real test will be how this framework performs as more security firms start using it, not just the benchmark results Anthropic published.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Anthropic)

Google unveils Gemini 4 Argon, a frontier AI model built for coding, enterprise work, and autonomous cybersecurity defense, rolling out to trusted testers.

Google announced Gemini 4 Argon, and it’s not going straight to the public. It’s rolling out first to a set of trusted cyber defenders through what Google calls the Fairwind Program, which tells you something about where the company thinks this model’s sharpest edge actually is.

Argon is priced to start at $2 per million input tokens and $10 per million output tokens, with cached inputs at a 95% discount, before jumping to $4 and $20 once the introductory window closes. More interesting than the price is the output limit: 1 million tokens, up from 64,000 on the previous generation. It means the model can keep reasoning through a genuinely long, complicated problem in one continuous pass instead of getting cut off mid-thought.

“To support Gemini 4 Argon’s capabilities across longer, more complex use cases, we are significantly expanding the model’s output token limit to an industry-leading 1M tokens, up from the previous 64K tokens.” reads the announcement. “When the model has the headroom to think deeply and generate hundreds of thousands of tokens in a single trajectory, it adds a new level of depth in reasoning to solve tough problems in one go.”

Google engineers are already using Argon internally, with some impressive results. In one case, Argon helped quantum computing researchers optimize a resource-heavy process and improve the published baseline by 40% in just a few minutes. In another, Argon agents analyzed data from Google’s data centers and found memory optimizations that freed more than 300 TiB after deployment. Google estimates there could be another 500 TiB to 1 PiB of savings.

Argon is also being used to rewrite C and C++ code in Rust. This includes Google’s Fuchsia Zircon kernel, which has more than 800,000 lines of code. For the open-source libgav1 video decoder, Argon replaced 32,000 lines of SIMD code through repeated testing and compiler analysis. The new version runs 2.7 times faster than the previous Rust version, produces the same video output, and remains memory-safe.

On benchmarks, Argon tops DeepSWE v1.1 at 77.9% for long-horizon software engineering, leads the Vals Index across finance, legal, and tax work, and ranks first on Zapier’s AutomationBench at 51.3%. It also posts a state-of-the-art 91.7% on LVBench, a benchmark for understanding long video, which matters more than it sounds for any workflow that involves parsing hours of footage or a stack of visual documents instead of clean text.

Cybersecurity is one of the main areas where Google is focusing Argon. For trusted security teams and Google’s own engineers, Argon runs without its usual cyber safety restrictions. This allows it to actively look for vulnerabilities that defenders can then fix.

Wiz is already using Argon through its Scan for Good program, which looks for serious vulnerabilities in public systems and fixes them for free. Argon found a critical flaw in healthcare software used by hospitals worldwide that could expose personal data. Earlier AI models had examined the same issue but failed to find it. On CWE-bench v1, a test that measures how well AI models can fix vulnerabilities, Argon scored 68%, tying for first place.

None of this means Google is releasing a model that can autonomously hack things and calling it a day. Before any broader rollout, the company says it’s hardening defenses on four separate fronts: blocking misuse for cyber or CBRN attacks while still allowing legitimate dual-use research, improving resistance to indirect prompt injection, where hidden instructions try to hijack the model’s behavior, and sealing off the sandboxed environments used for high-risk training and testing before anything risky happens inside them.

“Argon is also our most resilient model yet against indirect prompt injections, where malicious instructions or context are used to hijack a model’s behavior.” Google states. “These are complex attacks that require constant vigilance and multiple layers of defense. Through automated red teaming and adversarial training, Gemini 4 Argon is leading in prompt injection robustness on the Gray Swan’s Indirect Prompt Injection (IPI) benchmark.”

The misalignment piece is the one that actually says something about how seriously Google is taking all this. Argon’s chain-of-thought and actions get monitored in real time, with execution halted if the model starts drifting past what the user actually asked for, and Google is careful not to feed what that monitoring catches back into training, specifically so the model doesn’t learn to reason its way around its own watchers.

“In order to prevent Argon from stepping out of bounds to try to accomplish a task in a way that goes beyond the user’s intentions, we are deploying misalignment mitigations that monitor Argon’s chain-of-thought and actions and stop execution when necessary.” concludes the announcement. “We strongly encourage the rest of the industry to preserve reasoning transparency in these pivotal moments of increased capabilities while navigating alignment risks, so that model thoughts remain helpful in identifying and diagnosing misalignment.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Google Gemini 4 Argon)

A Telegram Desktop flaw let bots inject JavaScript into exported chats, enabling data theft and page manipulation. Old HTML exports remain unsafe.

A vulnerability in Telegram Desktop could have turned an ordinary chat export into a serious data leak. Security researchers Denis and Aleksander Rostilov of ExPatch found a stored cross-site scripting flaw in the application’s HTML export feature that allowed malicious JavaScript to hide inside a Telegram message and run later when someone opened the exported file in a browser.

“A stored XSS in Telegram Desktop lets an attacker plant invisible JavaScript in an exportable chat through a bot’s inline keyboard button. The payload can sit in message history for months and detonates when a participant opens an HTML export page containing that message.” reads the report published by ExPatch. “No second click, no warning: every message and metadata field rendered in that document can be shipped to the attacker’s server, and the page itself can be rewritten. The bot never joins the target chat — one forwarded message can be enough.”

The attack is unusual because the attacker doesn’t need to be a member of the target group. A bot can create a message containing a specially crafted inline keyboard, and that message can then be forwarded into other chats. Once included in the conversation history, the payload can remain there for months or even years, waiting for someone to export the chat.

The Telegram app itself doesn’t execute the code. That’s an important distinction. The problem appears when Telegram Desktop converts the stored conversation into an HTML document that is later opened in a browser, where the injected content is interpreted as JavaScript.

The researchers traced the problem to Telegram Desktop’s HTML export code. In export_output_html.cpp, the application wrote the text of inline keyboard buttons directly into the HTML output instead of passing it through the existing SerializeString() sanitization function. That meant HTML tags placed in the button text could be treated as real markup in the exported document.

“When exporting a chat to HTML, Telegram Desktop writes inline-button text straight into the HTML page — unescaped. SerializeString(), which escapes every HTML-dangerous character (<, >, &, ", '), converts newlines and Unicode line/paragraph separators to <br>, and hex-encodes ASCII control characters, is defined in the same file and applied to message text, sender names, and other fields. It just wasn’t applied to button text.” continues the report. “That means any HTML sitting in a button’s text property renders as live markup in the exported page. <script> tags included.”

This created a particularly awkward security boundary. Telegram’s Bot API can restrict a bot’s access to ordinary group messages, especially when privacy mode is enabled. But once the bot’s own message was exported as HTML, the injected script could run in the user’s browser context and access the other messages rendered on that page.

The potential impact is significant. According to the researchers, the injected code could read messages, sender names, timestamps and other chat metadata from the exported document and send that information to an attacker-controlled server. It could also access the local file path of the export, potentially revealing the user’s operating-system name and directory structure.

The attack could also manipulate the page itself. The proof of concept demonstrated how an attacker could replace the exported conversation with a fake Telegram verification page, while the same browser-side control could be used to alter displayed messages, timestamps and sender information. That doesn’t change the original Telegram history, but it could make a compromised export look completely different from the real conversation.

The researchers also demonstrated how the problem could spread through forwarding. A single poisoned message could be forwarded into multiple groups, where each copy would retain the malicious content. Anyone who later exported a conversation containing that message and opened the resulting HTML file could trigger the payload.

There was another important feature: the attack didn’t have to happen immediately. The malicious message could sit harmlessly in a chat history until someone performed a completely legitimate action months later. The export process effectively turned previously inert message data into executable content.

ExPatch rated the vulnerability CVSS 8.2, High. The researchers deliberately used a local attack vector because the vulnerable component is the local HTML export process, which runs only when the user explicitly exports a chat and opens the resulting file.

The flaw had been in production for more than two years. The vulnerable code was introduced in February 2024 and reached the stable 4.15.1 release in March that year. Telegram fixed it in June 2026, after the researchers reported the issue on June 3.

Telegram fixed the problem by applying SerializeString() to inline keyboard button text. The patch also addressed another injection issue involving content inserted into a JavaScript onclick handler.

The first fixed beta release was Telegram Desktop 6.9.4, while the first stable release containing the fix was 7.0.1, released on July 14, 2026. Telegram has since released newer versions, so users should be running a current build rather than relying on the minimum fixed version.

There is, however, a detail that could easily be missed. Updating Telegram Desktop doesn’t repair HTML files that were exported with an affected version. If one of those files contains the malicious payload, the JavaScript remains in the file and can still execute when the document is opened in a browser.

That makes old exports the main issue for organizations that use Telegram to retain conversations for compliance, investigations or business records. The researchers recommend creating new exports after updating and treating older HTML exports as untrusted, particularly when they came from large groups where it may be difficult to know where every message originated.

The disclosure process also raises a separate security question. ExPatch says it reported the vulnerability with a full proof of concept and video demonstration, while Telegram fixed the issue and offered a bounty that the researchers declined. Telegram then refused to approve public disclosure even after the vulnerability had been fixed.

As of September 11, the researchers said Telegram had not published a dedicated security advisory and that no public CVE had been assigned. The fix is visible in the Telegram Desktop source code, but users weren’t given a direct warning that older HTML exports could still contain executable content.

For defenders, the practical lesson is straightforward. Update Telegram Desktop, regenerate sensitive HTML exports created before the fix, and don’t open old Telegram HTML files in a normal browser unless you know where they came from and have checked them carefully. The update fixes the client, but it can’t go back in time and clean files already sitting on someone’s disk.

The vulnerability is a good reminder that security problems don’t always live in the messaging system itself. Sometimes the dangerous step happens later, when trusted data is converted into another format and that format is treated as executable content.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, newsletter)