What Is GLM-5.3? Defending Enterprises in the Age of Automated Attacks by Freely Available AI

GLM-5.3 is a 753B-scale AI model released with open weights by China's Z.ai, and it has been rated by the U.S. NIST as the open-weight model with the highest cyberattack capability among those already published. Anthropic's verification also showed that by disguising instructions as exercises or by modifying the weights, the safety measures could be removed and the model made to comply with writing attack code. This article is aimed at executives and IT/information systems personnel at Japanese companies operating in Thailand and Japan, and organizes what has changed with GLM-5.3 based on the conclusions of evaluation bodies, researchers' verifications, and reports of attack incidents, presenting an order of defensive steps that even companies with few dedicated security staff can begin to implement. By the end, you will be able to apply to your own company decisions about grasping publicly available assets, the speed of patching, recovery after a breach, and how to use AI in defense.

GLM-5.3 is a large-scale AI model released with its weights available for anyone to obtain, and whoever obtains it can run it in their own environment and even modify it. Understanding its scale and the manner of its release reveals why evaluation bodies and AI companies have treated this model as a special case.

GLM-5.3 is a MoE (Mixture of Experts) model with 753B total parameters, developed by Z.ai (formerly Zhipu AI). MoE is a structure in which only some specialized parts are activated for each input, which keeps the computation used per inference lower relative to the overall scale. The weights are distributed on Hugging Face at zai-org/GLM-5.3, in BF16 and FP8 formats.

The license is Z.ai's own GLM-5.3 License, not a general-purpose license like MIT. For business use, you need to check the terms for commercial use and redistribution in the text of the license itself.

The equipment required to run it is not small. The BF16 weights alone come to roughly 1.5TB, estimated from 753B × 2 bytes, which presupposes a server with multiple high-performance GPUs or a cloud GPU environment. While this is not a scale that can be run on a personal computer, in an era where GPUs can be rented by the hour, this is not an insurmountable barrier for a well-funded attacker. A smaller version, GLM-5.3-Flash, has also been released, and it runs with even fewer computational resources.

With AI provided via an API, the provider can monitor inputs and stop users who violate the terms of service. With a model whose weights have been released, this premise does not hold. Because those who obtain it run it on their own servers, the provider has no way of knowing what instructions were input, and even if a problem is found, it cannot recall weights that have already been distributed.

The same structure applies to safety measures. The property of "refusing to assist with attacks" that the developer built in during training can be weakened by the party who obtains the weights through additional training or modification. Anthropic verified this point with GLM-5.3 and demonstrated numerically that the safety measures could be removed through crafted instructions and modification of the weights.

The differences arising from the manner of provision can be summarized in the following three points.

For companies, the implication is that it is no longer possible to expect the provider's terms of service to stop AI that can be used for attacks. Defenses must now be built on the premise that attackers can freely use highly capable AI.

In a special committee of the House of Councillors, Takahiro Anno, leader of Team Mirai, cited Claude Mythos—which is not publicly released—as an example and stated that "it is possible that companies outside the United States could develop similar models within a few months at the earliest, or within a year at the latest." This was not a remark aimed at any specific company's plans, but a forecast that the capabilities of cutting-edge AI would spread to developers in other countries with a time lag.

GLM-5.3 has shown that this forecast is a real-world matter. In Anthropic's verification, the number of times attack code was completed to the end was roughly the same as for Claude Mythos Preview. On the other hand, NIST's evaluation concluded that, in terms of overall cyber capability, it lags about four months behind the U.S. cutting edge. Both figures indicate that we have reached a stage where the gap with the cutting edge is spoken of in terms of months rather than years. The timeline for preparedness needs to shift from "a threat that will eventually come" to "a tool that is already available."

GLM-5.3 has the highest cyber capability of any publicly released model, but it still falls short of the leading U.S. models overall. NIST and Anthropic evaluated it using different methods, and not confusing what the numbers mean is the starting point for correctly assessing the threat.

The U.S. NIST's CAISI (Center for AI Standards and Innovation) assessed GLM-5.3 as having the highest cyber capability among openly released weight models to date. At the same time, it explicitly states that this capability is substantially lower than the leading U.S. models, trailing by about 4 months overall. Reading only one side of this leads to either overestimating or underestimating the threat.

The four evaluations CAISI used are all based on real software flaws, and are divided into tasks of finding flaws and tasks of turning them into working exploit code.

The ExploitBench figure of 61.1% is a share of points scored, not the share of attempts in which exploit code was successfully completed.

Anthropic used ExploitBench to count the number of times exploit code was fully completed. GLM-5.3 completed it in 50 of 410 attempts, roughly on par with the 56 completions of Claude Mythos Preview, which is not publicly available. This differs from CAISI's 61.1% in how it is counted—this figure represents the actual number of completions.

What this result shows is that, when it comes specifically to the work of creating exploit code, there is almost no difference between a publicly released model and an undisclosed state-of-the-art model. Even though a gap exists in overall capability, for the specific tasks attackers need, the gap has in some respects already closed. The process of turning vulnerability information into exploit code that can actually be used for intrusion has historically required skilled engineers and time, even for attackers. Part of this process can now be handled instead by an AI that anyone can obtain. The point at issue for corporate defense is that this capability is already public and in a state where anyone can run it.

GLM-5.3 does not comply with instructions that directly request assistance with an attack. However, in Anthropic's testing, through crafted instructions and modified weights, the safety measures broke down in stages.

1. When given an instruction falsely claiming it was engaged in an exercise as an autonomous red-team agent, it complied 64% of the time.
2. When the model's written-out reasoning was inserted beforehand to make it appear as though it had considered the request and decided to proceed, this rose to 92%.
3. When abliteration—modifying the weights to remove the refusal property—was applied, it complied 100% of the time.

Abliteration is not a task that requires special equipment. Even for the Anthropic team tackling this task for the first time, it took only about 2,200 GPU hours for GLM-5.3, at a computing cost of about $4,400, and about 600 GPU hours for GLM-5.3-Flash. Given that the weights are publicly available, safety measures cannot be guaranteed by the party that distributed the model—they must be regarded as settings that whoever obtains the model can remove at any time.

It has been reported that AI agents dividing up the stages of an attack among themselves breached at least 27 companies within six days. We examine how the numbers from benchmarks connect to actual damage, drawing on an incident report from overseas and a data leak case in Japan.

Security firm Gambit Security has reported an incident in which financially motivated attackers divided roles among multiple AI agents to carry out attacks. Separate agents handled vulnerability discovery, intrusion execution, and overall command, and the attackers launched 105 attacks over 6 days, breaching at least 27 companies. From 2 of those companies, more than 600,000 valid card records were stolen.

What stands out in the report is the cost and speed. The cost per company ranged from a few dollars to several dozen dollars, and most intrusions were completed within a day. Carrying out this many attacks in just a few days is a scale that would be difficult to achieve through manual human effort alone.

Although this is a single incident, it has concretely demonstrated that dozens of companies can be targeted simultaneously at low cost. The reasoning that "we're too small to be targeted" is increasingly losing its grounding.

For e-commerce sites that handle card information and companies entrusted with customers' personal data, it is worth examining this incident as if it had happened to them. Since most intrusions are completed within a day, companies also need to shorten the time between noticing an anomaly, contacting their vendors, and deciding on a response. Determining who should be contacted at night or on holidays is part of this.

Within Japan too, breaches from unauthorized access and ransomware continue to occur. "infoQ," operated by GMO Research & AI, suffered unauthorized access that exploited a software vulnerability, affecting as many as approximately 950,000 records. Osaka Metropolitan University was hit by ransomware and announced that personal information for roughly 130,000 people may have leaked.

In neither incident has it been announced that AI was used in the attack. While they cannot be directly linked to GLM-5.3, unauthorized access exploiting vulnerabilities and ransomware are harms that have been occurring domestically even before AI capabilities improved.

The two incidents differ in their point of entry. The infoQ incident involved a direct exploitation of a weakness in a system reachable from outside, raising questions about the speed of patching and management of publicly exposed assets. Ransomware encrypts data after intrusion, and some cases involve data exfiltration as well, raising questions about backup and recovery design. What Gambit Security's report and Anthropic's verification show is that AI can carry out these stages of attack faster and more cheaply.

This is because the time from a disclosed vulnerability to a working piece of attack code has shrunk to a matter of hours. The assumption that "patching can keep up" relies on there being a gap in time—between when vulnerability information is disclosed and when attack code starts circulating—during which companies can apply a fix.

In Anthropic's verification, researchers gave GLM-5.3-Flash the details of a publicly disclosed CVE along with information about another known flaw. With almost no instruction from the researchers, GLM-5.3-Flash chained the two flaws together and, in an ARM64 environment, built attack code that ran reliably by bypassing a defense mechanism called pointer authentication (PAC). It took 20 minutes of human involvement and 8 hours of the model's work, and the cost, converted by Anthropic using Zhipu's API pricing, came to $20.40.

The target was not an unknown vulnerability but a flaw that had already been publicly disclosed. Previously, turning public information into practical attack code required specialized engineers to spend time on verification, and that effort served as a grace period for companies. Given that this small model completed the process in under a day, the practice of taking several days to several weeks between the release of a patch and its application needs to be reconsidered. The date for applying a patch should be set not by a routine maintenance schedule, but based on how quickly attack code can be assembled.

The order in which to reconsider things is: grasping public-facing assets, speed of patching, recovery after a breach, and then the use of AI in defense. Now that the assumption that patching can keep up has broken down, the goal of defense expands beyond simply "not being breached" to also "knowing where you can be struck, and not letting a strike halt your business."

Externally exposed assets refer to things reachable from the internet—servers, web applications, VPN devices, API entry points, and the like—that is, the first things an outside attacker can touch. A company that has not listed these out does not itself know where it can be struck. To reduce blind spots in this inventory, cross-check three things: the DNS settings of the domains your company owns, the public-facing settings in your cloud management console, and the communications your firewall allows through.

The first step in this review is to record, for each asset, "which software and which version is running" and "who manages it." At a company with offices in Thailand and Japan, devices set up by different vendors at each office, or devices left without an administrator after personnel changes, tend to remain unaccounted for—these should be prioritized when conducting the inventory.

Patch deadlines should be set internally according to asset type. Internet-facing assets should have shorter deadlines than internal devices, and an exception procedure should be prepared so that, when a critical vulnerability is disclosed, a patch can be applied without waiting for the regular maintenance day. Even with deadlines set, they cannot be met unless it is clear who is responsible for applying the patch and who approves it. Adding a column for the person in charge in the inventory is a prerequisite for actually meeting the deadline.

Measures built on the premise of completely preventing intrusion fall behind in a situation where attack code can be assembled within hours. The focus of the review needs to shift from preventing intrusion to not stopping business operations even after an intrusion occurs.

The first thing to decide is the priority of which operations, if stopped, would directly affect sales or customer service. Separate the parts where the business cannot function if stopped—such as order-receiving and billing systems, or customer information databases—from the parts that can withstand a few days of downtime, and document the recovery procedures starting with the former. Deciding in advance on alternative methods, such as continuing to take orders by phone or paper slips while the system is down, can help reduce confusion. Keep a contact list in printed form or by some other means so it can be referenced even when internal systems are unavailable.

It is important that backups are not placed under the same network or the same administrator privileges as the production environment. Since ransomware attempts to encrypt backups along with production data, the restoration source should be kept in a separated location. Whether restoration will actually work cannot be known without actually testing it, so restoration drills should be conducted several times a year to confirm which operations can be resumed and within how many hours. If information has been exfiltrated, restoring from backup does not conclude the response to the leak, so procedures for notifying customers and authorities should also be decided in advance.

Anthropic has taken the position that defenders, too, should use the best tools suited to their purpose, and is working to safely extend its own AI's capabilities in the cybersecurity field to the defending side. Given that attackers can freely use highly capable AI, defenders who rely solely on manual effort cannot keep up in terms of speed.

AI proves useful for routine checks that tend to be deprioritized when done by hand. Collecting version information on public-facing assets, cross-referencing published vulnerabilities against one's own configuration, and picking up anomalies from logs are all highly repetitive tasks, and the value increases the more continuously they are run. This effect is greater for companies with fewer dedicated security personnel.

However, the AI used for defense is the same technology as the AI used for attacks. If a company introduces AI without deciding how much internal information to give it or which systems the AI is allowed to operate, the very privileges granted to the AI become a new weak point. It is necessary to decide in advance to limit the scope handled—for example, restricting inspection targets to public-facing assets—and to establish an operational rule where a human gives final approval before any fix is applied. For instance, one way to divide the work is to have the AI handle finding vulnerabilities and affected assets and notifying the person in charge, while the person in charge carries out configuration changes and applies fixes.

Even without a dedicated staff member, you can start by deciding on four things—an inventory of public-facing assets, deadlines for fixes, recovery procedures, and the scope to be entrusted to AI—aiming to complete this within about three months. Even without a large budget or a specialized department, you can get started by setting an order of priority and proceeding step by step.

1. In the first two weeks, identify all internet-facing assets. This should include domains, servers, VPN devices, cloud public settings, and even systems managed by outsourcing partners, and compile a list of versions and administrators.
2. Over the following month, decide on fix deadlines and exception procedures. Decide in advance, by name, who will make the decision and who will apply the fix when a serious vulnerability is publicly disclosed.
3. Starting in the second month, decide on the priority of operations that cannot be stopped, and begin separating backups and conducting restoration drills.
4. In parallel, decide on the scope of inspections to be entrusted to AI and the boundary of work requiring human approval.

For a company with locations in both Thailand and Japan, since the personnel in charge and outsourcing partners differ by location, it is easier to proceed by creating the inventory and procedures separately for each location while aligning deadlines and priorities at the head office. For systems operated by outsourcing partners, check the contract or maintenance agreement to confirm the response deadline and reporting method for when a vulnerability is publicly disclosed.

How to approach GLM-5.3 is not a simple choice between safe and dangerous. Here are answers to questions frequently raised by management and IT staff, along with the points where judgment diverges.

It depends on how the usage is designed. GLM-5.3 is released under its own GLM-5.3 License, not a general-purpose license like MIT, so the first step is to check the terms of commercial use and redistribution in the text of the license itself. Beyond that, on the premise that safety measures can be bypassed through instructions disguised as exercises or through modification of the weights, it is necessary to limit the scope of internal company information passed to the model and to establish an operational rule where a human approves the generated results. Running it on one's own servers requires a large-scale GPU environment, so in terms of cost as well, it is worth considering whether it is worthwhile compared to AI offered via API.

targeted. In incidents reported by Gambit Security, the cost per company ranged from a few dollars to a few dozen dollars. At this cost, attackers have little reason to choose targets based on company size. If anything, companies that have been slower to manage and patch their public-facing assets face a shorter time to breach. Simply maintaining an inventory of public-facing assets and setting patching deadlines can reduce the points of attack.

not enough. Given that there are cases where attack code is assembled in less than a day from a disclosed vulnerability, an annual inspection is no longer sufficient. It's realistic to vary the inspection frequency by asset type.

• For externally exposed servers and APIs, cross-check your own configuration against newly published CVEs every time one is announced.
• For internal endpoints and network devices, combine regular inspections with ad hoc inspections whenever a critical vulnerability is disclosed.
• For systems operated by outsourcing partners, confirm through contracts and regular reports that they are being inspected at the same frequency.

Since maintaining this frequency by manual effort alone is difficult, consider automating the collection and cross-checking of version information.

What GLM-5.3 changed is that a highly capable AI for offensive use has become something anyone can obtain and use with its safeguards removed. NIST's evaluation presented both sides: "the best among public models, roughly 4 months behind the U.S. state of the art," while Anthropic's verification showed that in creating attack code, it performs at nearly the same level as the top non-public models. The smaller GLM-5.3-Flash has assembled attack code chaining two disclosed flaws together, requiring only 20 minutes of human involvement and 8 hours of model processing.

What companies can start doing right away is clear: inventory public-facing assets and keep track of their versions and administrators; set patching deadlines for each asset and respond quickly to critical vulnerabilities through an exception process; abandon the premise that intrusions can be completely prevented, decide which operations need to resume within how many hours, and verify that restoration from isolated backups is possible; and use AI for routine inspections while having humans approve the application of patches.

Defense is not something that's complete the moment you deploy a tool. How closely the frequency of inspection and the speed of patching can approach the speed attackers have gained through AI will become the yardstick for evaluating preparedness going forward.