Chinese AI developer Zhipu has launched GLM-5.3, a new coding-focused AI model that the company says has developed unexpectedly strong cybersecurity capabilities, putting it close to global leading models in vulnerability discovery while remaining behind them on deeper exploitation tasks.

Zhipu’s own testing places GLM-5.3 slightly ahead of Anthropic’s Mythos 5 and OpenAI’s GPT-5.6 Sol on CyberGym, a benchmark that tests vulnerability identification and validation. GLM-5.3 scored 84.5%, compared with 83.8% for Mythos 5 and 83.6% for GPT-5.6 Sol. But the model trails both competitors by a much wider margin on ExploitBench, where it scored 54.4%, compared with 78% for Mythos 5 and 76.5% for GPT-5.6 Sol.

“GLM-5.3 is the most capable open-weights model for coding, with a 50% improvement over GLM-5.2 on our in-house Z.ai Code Bench,” Zhipu said in a statement. “As we scaled post-training, cyber capability developed faster than we expected.” The company said GLM-5.3 moved beyond identifying isolated vulnerabilities to “forming coherent plans for complete exploitation chains.”

The company also claimed its latest model has shown improvement over Zhipu’s previous GLM-5.2. Its ExploitBench score more than doubled from 24.4%, while on ExploitGym, GLM-5.3 completed 105 exploitation tasks within two hours and 130 within six hours, compared with 29 and 39 respectively for GLM-5.2, according to the statement.

Zhipu attributes the gains to post-training, including reinforcement learning across increasingly complex task environments.

The progression reflects a broader issue emerging as coding models become more capable, said Neil Shah, VP for research and partner at Counterpoint Research.

“We are reaching a stage where if we teach an AI to be a brilliant software engineer, you’re accidentally teaching it how to be a good hacker, too,” Shah said. “The exact same reasoning an AI uses to test code and fix bugs is what an attacker uses to find a weak spot and break through it.”

He said offensive cyber capability is becoming an inherent capability of next-generation coding AI, making controls around such systems an increasingly important issue.

Thousands of vulnerabilities found

Zhipu said it has also been working with security teams in China to test its models against real-world codebases.

“After expert review, screening, and deduplication, the model identified 2,436 vulnerabilities across 269 projects, including 1,097 medium-to-high severity issues,” the statement added.

The findings cover system kernels, operating systems, browser engines, open-source infrastructure, Web applications and network protocols, Zhipu said.

Zhipu’s security disclosure ledger lists 107 critical and 990 high-severity findings. The company said 53 findings have been publicly disclosed and 2,383 remain under embargo. The oldest vulnerability identified dates to 1981, while vulnerabilities in the dataset had remained in code for an average of 26.6 years before discovery.

The company did not disclose how many of the 2,436 findings were previously unknown vulnerabilities or how many were independently reproduced. It said the findings are being tracked through its Z.ai Security Disclosure Ledger as they move through the disclosure process.

Shah described the capability as a double-edged development for security teams.

“These AI tools can audit systems and fix bugs faster,” he said. “But once an AI model’s weights are released freely to the public, any built-in safety guardrails can be stripped away without any cognizance or control.”

Same base model, scaled post-training

Zhipu attributes GLM-5.3’s gains to scaling post-training rather than developing a new base model.

The company expanded its training environments to simulate longer and more realistic units of professional work. In one example, the model is given access to compute clusters, storage systems, internal documentation, codebases and experiment results and must diagnose a bottleneck, implement an optimization, run experiments and deliver a measurable improvement while maintaining correctness.

Zhipu also added vulnerability-discovery data and environments to the training mix.

The company reported a 50% improvement over GLM-5.2 on its internal Z.ai Code Bench, alongside gains on public coding and agent benchmarks.

Shah said the connection between coding and offensive security is becoming harder to separate as these models improve.

“The exact same reasoning an AI uses to test code and fix bugs is what an attacker uses to find a weak spot and break through it,” he said.

Open-weight release raises the stakes

Zhipu plans to release GLM-5.3’s model weights about two weeks after launch, following safety evaluation and hardening.

The company is preparing to make an open-weight model available that it says has demonstrated capabilities ranging from vulnerability discovery to increasingly sophisticated exploitation reasoning.

Zhipu has not said in the announcement what additional safeguards will accompany the open-weight release beyond its planned safety evaluation and hardening.

For Shah, the issue is the speed at which vulnerabilities could potentially move from discovery to exploitation once such capabilities are widely available.

“If these AI-driven tools can discover thousands of unpatched flaws in real-world systems and anyone can download that capability, the response window shrinks to near zero,” he said.

He said defending against attacks operating at machine speed would require controls built into the development and deployment of AI models and autonomous agents.

Enterprise teams are moving from chat-based assistants to systems that can take actions. I see the shift in how people describe the work. They ask for an assistant that can write code, file tickets, update CRM records, run a compliance checklist, generate a pull request, and follow through on the next step. That shape of work requires an agentic system.

I define an agentic system as software that turns a user goal into a sequence of steps, executes those steps through tools, keeps track of what happened, and produces an auditable outcome. The model contributes planning and language. The surrounding system provides authority, state, verification, and control.

[ See also: “How to run enterprise GenAI like a production service” ]

The engineering question stays consistent across domains. How do you give the system enough autonomy to be useful while keeping outcomes predictable. A production answer comes from constraints that are explicit and enforced.

Define the agent loop

An agent loop is the repeated cycle the system follows to complete work. I use a simple loop and I make each stage observable.

1. Plan: The agent chooses the next action based on the goal, current state, and policy.
2. Act: The agent calls a tool with structured arguments, then records the result.
3. Verify: The system checks the result against policy and task expectations.
4. Commit: The system writes the state change to a durable store and produces an audit event.

These words carry specific meanings in implementation. Planning produces a structured intent. Action uses a limited interface with a defined schema. Verification runs deterministic checks. Commit writes the versioned state and the trace context.

Define tools and tool contracts

A tool is any callable capability outside the model. It can be an API, a database query, a workflow engine, a code repository action, or a browser automation step. Tool use dominates operational risk because tools can change systems of record.

A tool contract is the boundary that makes tool use safe to operate. I write it down as part of design review. A contract includes the following:

• Inputs: A schema that rejects free-form parameters and enforces types.
• Permissions: The identity context, the scopes, and the data boundaries.
• Idempotency: A request key and a replay rule so retries do not create duplicate changes.
• Rate limits: Per user, per agent, and per tool to protect shared systems.
• Error semantics: Stable error codes and retry guidance.
• Audit fields: Request ID, actor, time, target record, and before/after references.

This contract turns an agent into a regular distributed system client. It becomes testable. It becomes debuggable. It becomes something an operations team can own.

Define policy as executable rules

Policy in an agentic system means rules the runtime enforces on every step. I treat policy as an executable module. It sits in the request path. It is versioned. It emits an audit event on decisions.

Common policy domains include data access, tool allowlists, approved destinations for writes, required citations for retrieved material, and refusal rules for restricted requests. Policy starts simple and grows based on incident learning.

Treat state as a first-class component

State is the durable record of what the agent knows and what it has done. I keep state outside the model. I persist it with a clear schema. I version it per step.

I store at least the goal, the plan steps, tool inputs and outputs, verification results, and the final decision. I also store the retrieved sources when retrieval is part of the loop. This state supports replay during incidents and supports evaluation later.

Teams that keep state only in a conversation buffer lose the ability to reason about behavior at scale. A durable state store supports retries, handoffs, and governance reporting.

Use verification as a gate on action

Verification is a set of checks that run before a write and after a tool call. I use deterministic checks whenever possible. I treat the model output as an input to be validated.

Examples include schema validation, permission checks, reference integrity checks, and constraints on target systems. For content workflows, verification includes citation coverage and checks for restricted data.

I also use a confidence policy for high-impact actions. The system can require a human approval step for certain tools or destinations. Approval works best when it is narrowly scoped to a clear action with context and evidence.

Build an evaluation harness around the loop

Evaluation for agents focuses on end-to-end task completion and on safety properties. I define task success criteria as observable facts. The ticket exists. The record was updated with the correct fields. The pull request passes checks. The change request has the right approvals.

I create scenario suites that cover routine tasks and edge cases. I run them with fixed seeds where possible and with stable tool mocks. I also run a small set of live tests against a staging environment with realistic data.

I track metrics that connect to operations. Task completion rate by scenario. Average steps per task. Tool error rate. Verification failure rate. Human approval rate. Mean time to recover when a tool returns partial results.

A practical reference pattern

I build production agents with a supervisor pattern. A supervisor owns policy, routing, and state. Specialized workers handle narrow tasks such as retrieval, summarization for a ticket, or a repository action. Workers run with the minimum permissions required for their contract.

A simplified sketch looks like this:

def run_task(goal, user):
    ctx = start_context(goal, user)
    while ctx.open_steps:
        intent = planner.propose_next(ctx)
        intent = policy.enforce_intent(intent, ctx)
        call = tool_router.bind(intent, ctx)
        result = call.execute(idempotency_key=ctx.step_key)
        checks = verifier.run(intent, result, ctx)
        ctx = commit_step(ctx, intent, result, checks)
        if checks.requires_approval:
            ctx = wait_for_approval(ctx)
    return ctx.outcome

This structure keeps authority in the supervisor. It keeps tool permissions narrow. It gives operations teams a single place to enforce policy and observe behavior.

Operational practices that keep agents stable

I use a short set of practices when teams want agents to run safely in production.

• Start with low-blast-radius workflows. Read-heavy tasks and draft generation build confidence and instrumentation.
• Ship with a limited tool allowlist. Expand based on measured outcomes and incident learning.
• Use staged rollouts. Start with internal users, then a small cohort, then broader exposure.
• Keep tool schemas strict. Free-form tool parameters create unpredictable writes.
• Set budgets. Enforce maximum steps per task, maximum tool calls, and a cost ceiling.
• Maintain runbooks. Include rollback, disable switches per tool, and escalation routes to humans.

Minimum viable checklist

I look for these elements before a team runs agentic workflows at scale.

• A written definition of the agent loop, with traces at each stage.
• Tool contracts with schemas, permissions, idempotency, rate limits, and audit fields.
• Policy module with versioning and enforcement in the request path.
• Durable state store with step-level records for replay and governance reporting.
• Verification gates on writes and high-impact actions.
• Evaluation suite that measures task completion and safety properties.
• Operational controls including budgets, staged rollout, and disable switches per tool.

Constraints are key

Agentic systems fit enterprise work because they connect language interfaces to business systems. The systems operate well when autonomy sits inside explicit constraints. Constraints turn agent behavior into something teams can measure, improve, and trust.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

The Bonsai 27B model from PrismML is the latest of many to squeeze a large number of parameters (27 billion) into a footprint compact enough to fit on a smartphone.

The original model weighed in at 54 GB. However, PrismML claims its 1-bit quantized version — a mere 3.9 GB — can deliver “multi-step reasoning, structured tool calls, vision tasks, and computer-use agentic loops that stay coherent across many steps,” while still retaining much of the accuracy of the larger version, due to “custom low-bit kernels built for its hybrid-attention architecture.”

The 1-bit quantized version of Bonsai 27B allows for a 262K token context and supports speculative decoding and flash attention. All of this is available with open weights under the Apache 2.0 open-source license.

Testing Bonsai 27B

I gave the 1-bit Bonsai 27B model a spin on my own hardware, using LM Studio 0.4.20 on Windows 11. My PC has an AMD Ryzen 5 3600 six-core CPU (32GB RAM) and an NVIDIA GeForce RTX 5060 (8GB VRAM). I ran Bonsai through what is now my standard test bed for models, a set of prompts covering different tasks:

• Two versions of a vision-functionality prompt: “Create a caption for the attached image, of no more than three sentences” and “Create a caption for the attached image, of no more than three sentences, with no editorialization.” (The image attached to this prompt, a burning car, is shown in the first screenshot below.)
• Two prompts intended to provoke web-search tool use, one asking for a detailed response and one asking for a simple response: “What is the copyright status of Franz Kafka’s works? Explain in detail” and “What did William Gibson think of Blade Runner?”
• A prompt for code generation and problem solving: “Python’s pip tool has a function ScriptMaker (accessed with from pip._vendor.distlib.scripts import ScriptMaker). On Microsoft Windows this is used to create an .exe stub launcher for a Python package’s entry points when it’s installed with pip. However, the icon created for this stub is the same generic icon used for the Python runtime itself. Let’s write a Python utility to allow the user to append their own custom icon to the .exe stub, but also preserve the stub’s appended archive and other metadata. The utility should use only the Python standard library, and should be kept as simple as possible.”
• Another coding-related prompt: “I have attached a Python program that takes Python applications and packages them to run with a standalone instance of the Python runtime. One drawback of the program is that it’s not very modular. Analyze the program and make some suggestions about how to increase its modularity so it can be used as a library with hooks for various advanced behaviors.”

Because Bonsai 27B has such a massive maximum token window (262,144), I set its default token window to 32,767 (up from the usual 4,096 or 16,384 I’ve used for other models). This allowed for complete context injection — for instance, when performing the coding tasks, the entire prompt including the code could be contained comfortably in the token window.

Bonsai 27B takeaways

The first thing that became clear: Despite its compactness, Bonsai isn’t the fastest model. One of the factors that impacts token-per-second speeds is the number of parameters in the model, not just the model’s physical size in memory. Bonsai’s 27 billion parameters resulted in token output that was on the whole slower than other models I’ve tested, like the Qwen 7B model. Tokenization also lags. Despite the giant token window I set for Bonsai, I still had to wait upwards of two minutes for my code examples to be tokenized and injected.

The most I could squeeze out of Bonsai’s output speed was around 40 tokens per second; the average was between 10 and 20. Disabling thinking boosted the output speed, and cut down the time to first token (and the overall output time), but sometimes that came at the cost of accuracy or coherency. For instance, the William Gibson question worked best with thinking on. With thinking off, I got a reply that was outrageously false. (No, William Gibson did not write Blood Meridian; Cormac McCarthy did.)

Thinking costs also had a major impact in the coding-related prompts. The code modularity question, for instance, took longer than six minutes just in the thinking phase, and the actual response took longer than two minutes to generate at 4.1 tokens per second. With thinking off, the results came more quickly (although there was a fair amount of overhead for tokenizing the input), and Bonsai generated a shorter but still useful reply at 7.7 tokens per second.

One intriguing capability in Bonsai 27B is its ability to use draft models for speculative decoding, a technique for speeding up token generation. This it does in place of using multi-token prediction, or MTP. However, speculative decoding requires loading both the main model and the draft model into GPU memory, so it’s only well-suited for cases where you have a lot of VRAM to throw at the problem. (MTP is integrated into the model itself.) My setup did not afford enough memory to use speculative decoding with Bonsai.

Bonsai’s strongest features — its giant token window, its massive number of parameters — come at clear costs. Other models with fewer parameters are faster. Set aside speed, though, and Bonsai performs well compared to other models with larger binary footprints. Bonsai’s coding advice and code generation were as good as the output I got from Gemma 4 and from Qwen3.5. And while I wasn’t thrilled about the tax imposed by enabling thinking, I found myself leaving Bonsai enabled for longer and more complex work. If I’m not getting instant answers, I might as well get well-thought-out ones.

What I’m most intrigued by with Bonsai 27B is the underlying quantization techniques used to build the model. Model providers have promised that 1-bit and ternary models can be made to deliver fast and accurate results in a fraction of the space as their higher-quant counterparts. Bonsai shows the promise is viable, and hints that future work in this direction has a lot of potential. For now, though, 1-bit quantized Bonsai 27B is best for those who care more about a small footprint than the fastest output.

If you want to try Bonsai 27B for yourself, you can download the model from Hugging Face or run the model locally in your web browser.

Senior data engineers are trained to be skeptical of proprietary platforms. When I entered a Palantir Foundry training bootcamp, I expected to find a slow, expensive alternative to the mature tools I know on AWS and Azure. What I found instead was a platform built for a radically different user, one who cannot write SQL but needs answers now.

I want to write about what I actually observed honestly, including where I think the hype is justified and where I think it is not, because most Foundry content I have seen is either from Palantir’s own marketing or from practitioners so embedded in the platform they have forgotten what it was like to come to it fresh. I am writing this while that perspective is still clear.

The speed thing is real

The surprise that hit me hardest was not a feature. It was pace. During the bootcamp we worked across a range of tasks: connecting data sources, building transformation pipelines, setting up workflows that business users could interact with directly. To make this concrete: building a pipeline that ingested data from multiple sources, applied transformations and exposed the output to business users took a matter of hours in Foundry. On a standard AWS or Snowflake stack with dbt and an orchestration layer, a comparable setup typically runs to a full sprint for a small team, not because of any single hard step, but because of the coordination overhead between tools.

I want to be careful about what I am and am not claiming here. This was a structured training environment with guided examples, not production infrastructure with real enterprise complexity and legacy constraints. The comparison is not controlled. But the direction of the difference was clear enough that I took notice. Foundry’s Pipeline Builder abstracts away a lot of the coordination work that consumes time in a more assembled stack. Whether that advantage holds at full scale is a question I cannot answer from a single bootcamp, but it is worth asking seriously.

The honest counterargument: speed in a training environment does not always translate to speed in production. A well-resourced engineering team that already knows Snowflake deeply can move fast too, without the overhead of learning a new paradigm. If your team is highly capable on your current stack, the productivity gain from switching may not justify the learning curve cost.

Who actually benefits most

However, raw speed is not the platform’s most disruptive feature. The more I used it, the more I realized that the real value of that speed is not for engineers. It is for the people who are usually waiting on us.

The more I worked with Foundry during the training, the clearer it became that the people getting the most out of it in the room were not the engineers. They were the non-technical participants, the analysts, the operations people, the business users who in a traditional stack would be waiting for an engineer to build them something before they could interact with data at all.

Foundry’s ontology model, the way it creates a shared semantic layer that different types of users can navigate without writing code, is differentiated from what I work with on AWS, Azure and Snowflake. On those platforms, self-service data access for non-engineers is possible, but it takes deliberate, often significant engineering effort to expose data in a way that non-technical people can actually use. In Foundry, it felt closer to the default.

If I were advising an organization on whether to consider Foundry, the first question I would ask is: what percentage of the people who need to interact with your data can actually write SQL? In organizations where more than half of business analysts and operational users cannot write code, the engineering burden of building self-service access on a traditional stack becomes a recurring, compounding cost. That is the environment where Foundry’s default self-service capabilities start to justify serious evaluation.

The counterargument here is worth stating directly: a strong, well-resourced data engineering team could build a better, more tailored self-service layer on Snowflake in the same time it takes to master Foundry’s ontology. If your organization has that team and the patience to build the right abstractions, the open platform may serve you better in the long run. Foundry’s self-service advantage is most compelling when you do not have that engineering capacity, or when the number of non-technical users is large enough that a custom-built solution would require constant maintenance.

The cost reality

Palantir does not publish list pricing for Foundry. Everything is negotiated. The platform uses a core-based licensing model, meaning you pay based on the computational capacity (server cores) allocated to the platform rather than by the number of users. Based on publicly available government procurement records, core-based licenses start at roughly 66,000 pounds per server core per year, with no additional per-user fees on top. Solution-based use case licenses, which bundle implementation and support, start at 250,000 pounds at entry level and scale significantly from there depending on data complexity, user base and operational scope.

What this means practically is that Foundry’s cost is not a fixed number you can evaluate on a spreadsheet. It is a negotiation. According to procurement advisory analysis of Palantir Foundry negotiations conducted between 2024 and 2025, annual platform fees for comparable mid-size deployments varied by a factor of two to three depending purely on negotiation posture (Redress Compliance, 2025). The leverage comes primarily from having a credible, costed alternative, which for most organizations means Databricks or Snowflake with named engineering owners and a realistic build timeline. Organizations that enter Palantir conversations without that alternative built tend to pay significantly more for the same deployment than organizations that do.

My honest assessment after the bootcamp is that the cost is hard to justify for smaller organizations or simpler use cases. If your data engineering needs can be met by a well-designed Snowflake environment with dbt and a standard BI layer on top, Foundry is probably not the right answer, and the delta in platform cost will buy you a lot of engineering time on the stack you already know. The calculus changes for large enterprises with complex, multi-team data environments and a significant population of non-technical users who need meaningful data access.

What I would tell a data engineering leader

A few things I would want another senior data engineer or engineering leader to know before evaluating Foundry:

• Do not evaluate Foundry on pipeline performance alone. That is not its primary differentiator. Compare it to Snowflake or Databricks on what it does for the non-engineer users in your organization, not on compute efficiency.
• Build your alternative cost model first. Whatever your current stack is, cost out what it would take to build the data product capabilities Foundry promises on that stack, with your own team. That number is your negotiating anchor.
• Take the learning curve seriously. Foundry has a broad ecosystem: the ontology model, Pipeline Builder, Code Repositories, AI integrations and coming to it fresh from a traditional data engineering background takes real adjustment. The training helped, but it is not a platform you pick up in a day.
• Be specific about who your users are. Foundry earns its cost fastest in environments where non-technical users need to do more with data than your current stack allows. If your users are primarily technical, the value proposition narrows considerably.
• Negotiate the second contract inside the first. Procurement analysis consistently shows that organizations that lock in phase two pricing before signing the initial contract pay significantly less per added use case than those who do not. Treat the pilot as the deal.

The honest summary

I came to Palantir Foundry expecting to be underwhelmed. I was not. But understanding its value requires a paradigm shift for any engineer raised on AWS or Snowflake. Evaluate Foundry not as a faster pipeline tool, but as a platform for organizational data literacy. For enterprises drowning in data but starved of accessible insights, it is a compelling, if expensive, contender. For everyone else, the tools you already have remain the better investment. The challenge is being honest enough with yourself to know which bucket your organization falls into.

Google has introduced Credentio, an open source C++ library for C2PA (Coalition for Content Provenance and Authority) Content Credentials.

Announced August 13 and available at the mediaprovenance repository, Credentio provides an API designed to run locally within developer applications. This removes the need to send media files to cloud servers for validation, which incurs privacy, latency, bandwidth, and file size limitations.

Credentio is designed to start working with C2PA specification versions 2.2 and 2.4. This is the same code that has powered nearly 40 different conformant C2PA-enabled Google products to scale to tens of billions of generated assets, including images, videos, audio files, and documents across many file formats, Google said.

Through Credentio, media files do not need to be transmitted back to Google or external validation endpoints while offering zero bandwidth overhead, instant validation verdicts, and complete data privacy, the company said. By validating media files locally Credentio eliminates external data transmission requirements, minimizes verification latency, and delivers immediate results even in high-throughput workflows. And media contents remain securely within the local environment.

Credentio is tailored specifically for developers seeking to build performant, enterprise-grade C2PA validator products. Its small memory footprint makes it ideal for integrating into resource-constrained client applications, server pipelines, or high-performance edge software, according to Google.